Bitcoin Forum

Hello, I developing an encrypted messaging for ZeroNet (http:/zeronet.io (http://zeronet.io)) and would like to have some guidelines.

My first idea:

• In ZeroNet every user has his/her own files signed by ECC this ensures the messages authenticity.
• When Bob visits the site first time a new (BIP32 based) public key will be generated, written to his file, signed and published to the network.
• If Alice want to message to Bob then reads the Bob's public key, then creates a new message using `ecc_encrypt_using_bob_pubkey("ZNE1" + generated_aes256key + generated_aes256iv + aesencrypted_text)`, puts it to her file, sign and publish to network.
• If a new file is published to the network then Bob checks the added messages in it and try to them using his ECC privatekey.

 To make privacy better the sender does not specify the messages recipient.
 So the messages are signed with one ECC private key and encrypted with an another.

My other idea:

• If Alice wants to send a message to Bob, then she puts `ecc_encrypt_using_bob_pubkey("ZNE1" + generated_aes256key + generated_aes256iv)` encrypted shared secret to her file.
• Then from now Alice will use this shared secret to encrypt messages to Bob
• If a new file is published Bob checks encrypted shared secrets and see if he able to decrypt any of it.
• If he successfully decrypt a shared AES secret from Alice file then he checks Alice's encrypted messages and decrypt the messages she sent to him.

 This way the same AES256 key would be used for every message, so it reduces encrypted messages length by AES256key+iv / message.

 Thanks for any suggestions!

The only issue I can see with both of these schemes is that the recipient must check every single message he receives to see if any of the encrypted messages will be decrypted by his key. However, someone could be encrypting random data to send to the recipient, which when decrypted, will look just like any other ciphertext that is encrypted with another key since decrypting a message not meant for you will also result in random data.

My old core2duo cpu able to decrypt ECC + AES at 100messages/sec (first solution) and AES over 10000messages/sec (second solution), so I don't think its going to be a problem. Every site in zeronet is totally independent, so if the updating/verification become problematic anyone able to clone the site and creating a new network of messages.


To solve this we could add fixed prefix to the encrypted text, eg.: os.urandom(16)+"ZNE1"+message
The random needed because according to stackexchange (http://security.stackexchange.com/questions/21371/decryption-on-aes-when-the-same-key-and-iv-are-used) it should be avoided to start the messages with same text. (we going to use AES CBC mode)