2
$\begingroup$

I developing an encrypted messaging for ZeroNet (aP2P file-based network, website: zeronet.io) and would like to have some guidelines if any of this could work.

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 then a new (Bitcoin 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, 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 decode them using his ECC privatekey.

To make privacy better the sender does not specify the messages recipient, so have to check every messages added to the network. The messages are signed with one ECC private key and encrypted with an another one.

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. (or better to use per-message, unencrypted IV?)
  • Then from now Alice will use this shared secret to encrypt messages to Bob (random prefix + protocol id + message)
  • If a new file is published then Bob checks encrypted shared secrets in it and see if he able to decrypt any of them.
  • If he successfully decrypt a shared AES secret from Alice file then he checks Alice's encrypted messages and decrypt the messages in Alice file.

The pros of second idea: - Shorter messages - Don't have to store the messages twice (one for other user, one for our sent folder) - AES provides 100x faster message checking.

The cons of second idea: - If the AES key is broken then all messages can be decrypted (applies both if privkey broken). - Anyone able to see if you added a new shared secret (start messaging with new people)

Thanks for any suggestions!

Improve this question
$\endgroup$
0

1 Answer 1

Reset to default
1
$\begingroup$

You should consider “sign-then-encrypt” instead of “encrypt-then-sign”.

Note that it is very important that the “encrypt” in “sign-then-encrypt” should be authenticated encryption. If you don’t use authenticated** encryption, you should definitely use an athenticating “sign-then-encrypt-then-MAC” approach.

Besides that:, when thinking about all this, you should definitely keep ECIES and ECDSA in mind.

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ Standard reference for problems with both generic compositions sign-then-encrypt and encrypt-then-sign: world.std.com/~dtd/sign_encrypt/sign_encrypt7.html (The desired security properties are not clear enough to me to guess what crypto the author really needs, though.) $\endgroup$
    – Squeamish Ossifrage
    Dec 7, 2017 at 17:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.