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.
J.A. Coutts
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.
J.A. Coutts