On the surface, Version 3 looks very much like Versions 1 & 2. Underneath the hood however, cSocket2.cls has been replaced by the slimmer and faster NewSocket.cls, as well as utilizing an updated clsCrypto.cls. Versions 1 & 2 had difficulty working with systems that did not utilize the Latin character set (such as Chinese or Arabic), and the addtion of these 2 classes now makes Hidden Conversations Unicode compatible. It is NOT Unicode compliant.
Like Version 2, Version 3 incorporates a 2048 bit/256 byte Public/Private key pair to initiate the conversation. Using the Public key, the Client sends a random 32 byte encrypted number to the Host. The Host then decrypts that number using the Private key. The Host then sends a Private Key encrypted message to the Client, who decrypts it using the Public key to verify that the Host is the holder of the private key. And you can change that key pair at any time. Of course the Public key has to be sent by alternate means to the Client after a change, as only the Host is capable of creating new keys.
If only one key is present, Hidden Conversations will automatically use that key. However, some Clients will need to converse with more than one Host, and provision has been made to deal with that. In addition to the IP Address and Port, the key file name needs to be stored and recovered. If no Keys are present, the program will complain but will still load. However, without a key you will not be able to communicate.
All this security would be useless if an unauthorized person gains physical access to the resident computer. The password is saved in the registry as a hashed number.
To permit longer packets to be sent, the packets are formatted with a record header that includes the packet length along with version information.
What happens if someone goes to the location in the registry where the key is stored and deletes it and then creates a new key with the same name but no data and then tries to run the project?
when you quote a post could you please do it via the "Reply With Quote" button or if it multiple post click the "''+" button then "Reply With Quote" button.
If this thread is finished with please mark it "Resolved" by selecting "Mark thread resolved" from the "Thread tools" drop-down menu. https://get.cryptobrowser.site/30/4111672
I don't see Function StrToByte and Function ByteToStr preserving Unicode.
There are a couple of easy ways to convert Unicode Strings to ByteArray and back.
Both of these methods will fully preserve Unicode.
1. This is built into vb6 and preserves Unicode. The Byte Array will always be 2 bytes per character.
Code:
Dim b() as Byte
b = myyString
'
mystring = b
2. If you intend on using a lot of Latin strings but still want to support Unicode you can convert string to UTF-8 byte array while still preserving full Unicode. Latin characters will be one byte while other languages will be 2 or more bytes.
Code:
Const CP_UTF8 As Long = 65001
Private Declare Function MultiByteToWideChar Lib "kernel32" (ByVal CodePage As Long, ByVal dwFlags As Long, ByVal lpMultiByteStr As Long, ByVal cbMultiByte As Long, ByVal lpWideCharStr As Long, ByVal cchWideChar As Long) As Long
Private Declare Function WideCharToMultiByte Lib "kernel32" (ByVal CodePage As Long, ByVal dwFlags As Long, ByVal lpWideCharStr As Long, ByVal cchWideChar As Long, ByVal lpMultiByteStr As Long, ByVal cchMultiByte As Long, ByVal lpDefaultChar As Long, ByVal lpUsedDefaultChar As Long) As Long
Public Function ToUTF8(ByVal Text As String) As Byte()
Dim lngOutLen As Long
Dim Utf8() As Byte
lngOutLen = WideCharToMultiByte(CP_UTF8, 0, StrPtr(Text), Len(Text), 0, 0, 0, 0)
If lngOutLen = 0 Then
Err.Raise Err.LastDllError, "ToUTF8", "WideCharToMultiByte"
Else
ReDim Utf8(lngOutLen - 1)
WideCharToMultiByte CP_UTF8, 0, StrPtr(Text), Len(Text), VarPtr(Utf8(0)), lngOutLen, 0, 0
ToUTF8 = Utf8
End If
End Function
Public Function FromUTF8(ByRef Utf8() As Byte) As String
Dim lngOutLen As Long
Dim strWide As String
lngOutLen = MultiByteToWideChar(CP_UTF8, 0, VarPtr(Utf8(LBound(Utf8))), UBound(Utf8) - LBound(Utf8) + 1, 0, 0)
If lngOutLen = 0 Then
Err.Raise Err.LastDllError, "FromUTF8", "MultiByteToWideChar"
Else
strWide = String$(lngOutLen, 0)
lngOutLen = MultiByteToWideChar(CP_UTF8, 0, VarPtr(Utf8(LBound(Utf8))), UBound(Utf8) - LBound(Utf8) + 1, StrPtr(strWide), lngOutLen)
If lngOutLen = 0 Then
Err.Raise Err.LastDllError, "FromUTF8", "MultiByteToWideChar"
Else
FromUTF8 = strWide
End If
End If
End Function
3. You need to use Unicode aware TextBoxes for your messages.
Last edited by DrUnicode; Sep 29th, 2014 at 08:23 AM.
Reason: More info
What happens if someone goes to the location in the registry where the key is stored and deletes it and then creates a new key with the same name but no data and then tries to run the project?
Good point, even though the keys are not stored in the registry. They are stored in a file in the application directory. The average user has difficulty managing keys, so I have made it easy for the user to create & destroy keys. One could argue that if access is gained to the client or host, then the system is compromised. This is true, but if access is gained, it really doesn't matter if the keys are securely stored or not. A person who knows what they are doing can still recover those keys.
I don't see Function StrToByte and Function ByteToStr preserving Unicode.
As I said in the description, it is Unicode compatible. It is NOT Unicode compliant. It does not preserve Unicode data. I leave that up to someone more familiar with true Unicode characters. I only wish that VB had the same function support for byte strings as it does for Unicode strings, as it would have made life a lot simpler.
I only wish that VB had the same function support for byte strings as it does for Unicode strings, as it would have made life a lot simpler.
Most String-Functions exist also in a ByteString (or ByteArray-) aware incarnation (LenB, RightB, MidB, InstrB).
So, parsing such a ByteArray for vbCrLF or other "delimiters" which might mark the end of an incoming
message or the start of a new one - is quite simple.
Also the task of appending a ByteArray to a MessageBuffer "as the chunks come in", is solvable pretty
directly per:
Static sMsgBuf As String '<- 8Bit String-MessageBuffer
sMsgBuf = sMsgBuf & CStr(ByteArr) '<- 8Bit appending of ByteArrays to a VB-StringContainer
Aside from that - as soon as you converted an incoming UTF8-Message from a ByteArr
back into a VB-String, you can use all the normal String-Functions as usual.
The ToUTF8 and FromUTF8 routines Dr Unicode has posted, will only need to be applied shortly before
"sending Data" (as UTF8-ByteArrays) - or shortly after receiving a complete message (in form of a ByteArray
or an 8Bit-StringBuffer).
Gentlemen. I appreciate your attempts to get me to use UTF8, but the difficulty I have with UTF8 is that it is a variable length protocol. If I use DrUnicode's "ToUTF8" routine to convert the string "Test string!" I get:
54 65 73 74 20 73 74 72 69 6E 67 21
If I change the space character to "&H98", I get:
54 65 73 74 CB 9C 73 74 72 69 6E 67 21
Not only does it change the "98" to "CB 9C", but the extra character wreaks havoc with the encryption routines.
Gentlemen. I appreciate your attempts to get me to use UTF8, but the difficulty I have with UTF8 is that it is a variable length protocol. If I use DrUnicode's "ToUTF8" routine to convert the string "Test string!" I get:
54 65 73 74 20 73 74 72 69 6E 67 21
If I change the space character to "&H98", I get:
54 65 73 74 CB 9C 73 74 72 69 6E 67 21
Not only does it change the "98" to "CB 9C", but the extra character wreaks havoc with the encryption routines.
In what regard does it "wreak havoc with the encryption routines"?
Is there GUI-interaction involved - and could you post an example?
Do you still use ANSI-TextBoxes to enter passwords?
In what regard does it "wreak havoc with the encryption routines"?
Is there GUI-interaction involved - and could you post an example?
Do you still use ANSI-TextBoxes to enter passwords?
Olaf
There are dozens. For example, when I prepare a record header it is possible to end up with a record length character in the problematic upper ANSI range. When that header string is added to the record string itself and then sent to the encrtyption routine as UTF8, it will bomb out because the single byte character will get converted to 2 bytes. I could force everyone to use nothing but byte arrays, but that would increase the complexity many fold. When I referred to byte string functions, I did not mean byte array functions. They are not the same.
For example, when I prepare a record header it is possible to end up with a record length character in the problematic upper ANSI range. When that header string is added to the record string itself and then sent to the encrtyption routine as UTF8, it will bomb out because the single byte character will get converted to 2 bytes.
Post an appropriate and concrete example, which "bombs out" - and we will show you,
how to "make it behave" in UTF8-Mode (if you're interested).
Originally Posted by couttsj
I could force everyone to use nothing but byte arrays,
but that would increase the complexity many fold.
No - not at all.
VB-Strings usually contain 16Bit WChars and are perfectly Unicode-capable containers.
So, at the outside of your Lib you can allow "User-String-Data" to be passed as
e.g. a "Message-Parameter to send", with a normal VB-String-Type.
Only internally (shortly before sending) you would encode to UTF8, before the Data
gets send over the wire.
Originally Posted by couttsj
When I referred to byte string functions, I did not mean byte array functions. They are not the same.
As I already tried to explain in Post #6 - VB-Strings *can* contain 8-Bit-Data as well.
You don't need to use ByteArrays with InstrB, MidB, LeftB etc.
You can use these functions also with VB-Strings which contain "plain 8Bit-per-Char"-data.
Code:
Private Sub Form_Load()
Dim B() As Byte
ReDim B(0 To 2)
B(0) = 65: B(1) = 66: B(2) = 67 '3 Bytes, Values for 'ABC'
Dim S8Bit As String, LeftSingleChar8Bit As String, MidSingleChar8Bit As String
S8Bit = B
LeftSingleChar8Bit = LeftB$(S8Bit, 1)
MidSingleChar8Bit = MidB$(S8Bit, 2, 1)
Debug.Print LenB(S8Bit), LenB(LeftSingleChar8Bit), LenB(MidSingleChar8Bit)
Debug.Print AscB(LeftSingleChar8Bit), AscB(MidSingleChar8Bit)
End Sub
What makes VB "Basic" is the ease with which programs can be put together. Part of that is the easy handling of text data via the many string functions provided in Visual Basic. Someone obviously thought that it should be able to handle different character sets, but from my perspective, all that has done is complicate the issue and is only partially supported in Visual Basic. It seems to me that if someone would like to use my class modules to encrypt/send true Unicode data, then simply convert the UTF8 byte array to string before using it. My program doesn't care what the text is, as long as it is consistent. It will preserve the data that is sent to it without any magical transformation in the background.
J.A. Coutts
Addendum: This is about as concrete as I can get. A 5 character record header is prepended to a 152 character string of periods using simple string concatenation before being sent to the encryption routine.
48 33 31 00 98 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E .........
Using StrToByte I get:
48 33 31 00 98 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E .........
Using ToUTF8 I get:
48 33 31 00 CB 9C 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E .........
The string length as defined in the header is wrong, as is the string itself. The AddRecHeader routine used to create the combined string can be found in the TLSSend download.
Last edited by couttsj; Oct 1st, 2014 at 10:18 PM.
Using StrToByte I get:
48 33 31 00 98 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E .........
Using ToUTF8 I get:
48 33 31 00 CB 9C 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E 2E .........
The string length as defined in the header is wrong, as is the string itself.
Yes, but once you call FromUTF8 at the receiving end it will be back to "98" again.
AFAIK these UTF8 functions are rock solid.
If you are using the raw bytes at the receiving end to decode header it will fail since it hasn't been decoded yet with FromUTF8. Probably need to use Mid$ to decode your header after calling FromUTF8.
Last edited by DrUnicode; Oct 2nd, 2014 at 03:52 PM.
Reason: More info
Yes, but once you call FromUTF8 at the receiving end it will be back to "98" again.
AFAIK these UTF8 functions are rock solid.
Yep, it's a "losless" 1:1 conversion on Win-Systems
(as long as WideCharToMultiByte and MultiByteToWideChar with CP_UTF8 are used on both ends).
And when someone prepares for sending a "just converted UTF8-ByteArray-Blob" over sockets,
then the Header should respect the length (in Bytes) of that UTF8-Blob *after* conversion from
(V)BString-WChars took place (and not measuring the lenght in "Chars" per VB Len-function
beforehand).
A Content-Length Member in ones Header (which describes the length in *Bytes*)
is common practice also with the http-protocol (as well as with many others).
Reply With Quote
Originally Posted by Nightwalker83
