Bitcoin Forum
December 18, 2017, 08:09:41 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: [CRYPTO] Need help for ECC based messaging  (Read 536 times)
nofish
Newbie
*
Offline Offline

Activity: 9


View Profile WWW
November 17, 2015, 03:53:20 PM
 #1

Hello, I developing an encrypted messaging for ZeroNet (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!
1513584581
Hero Member
*
Offline Offline

Posts: 1513584581

View Profile Personal Message (Offline)

Ignore
1513584581
Reply with quote  #2

1513584581
Report to moderator
1513584581
Hero Member
*
Offline Offline

Posts: 1513584581

View Profile Personal Message (Offline)

Ignore
1513584581
Reply with quote  #2

1513584581
Report to moderator
1513584581
Hero Member
*
Offline Offline

Posts: 1513584581

View Profile Personal Message (Offline)

Ignore
1513584581
Reply with quote  #2

1513584581
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513584581
Hero Member
*
Offline Offline

Posts: 1513584581

View Profile Personal Message (Offline)

Ignore
1513584581
Reply with quote  #2

1513584581
Report to moderator
1513584581
Hero Member
*
Offline Offline

Posts: 1513584581

View Profile Personal Message (Offline)

Ignore
1513584581
Reply with quote  #2

1513584581
Report to moderator
samuel999
Sr. Member
****
Offline Offline

Activity: 240


View Profile
November 18, 2015, 01:31:42 AM
 #2

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.
nofish
Newbie
*
Offline Offline

Activity: 9


View Profile WWW
November 18, 2015, 01:50:51 AM
 #3

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.

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.

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.

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 it should be avoided to start the messages with same text. (we going to use AES CBC mode)
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!