Encrypt-then-sign or sign-then-encrypt? re: ed22519 about arduinolibs HOT 5 OPEN

My library provides the basic building blocks for creating larger protocols like PEM, SSL/TLS, Noise, etc but it doesn't currently implement any of them.

Ed25519 is for signatures only. It doesn't provide any encryption facilities. A separate mechanism needs to be provided to encrypt the message contents. The usual method would be to use Curve25519 to establish a shared secret between the parties, and then hash that to create a key for AES-CTR or something similar. Then ed25519 is used to sign the encrypted message that is sent under the shared secret to verify the origin.

In general, encrypt-then-sign is the better choice because if an attacker manages to break the signature scheme, all they learn is statistical information about the ciphertext - which they already have. With sign-then-encrypt, if the signature scheme is broken then the attacker may learn some statistical information about the plaintext. The same applies to authenticated encryption modes like GCM and EAX.

from arduinolibs.

Hello. I found this issue while searching for the following link I referenced to a friend.

https://theworld.com/~dtd/sign_encrypt/sign_encrypt7.html

This article describes why you don't want either sign-then-encrypt nor encrypt-then-sign and offers (dated) alternatives.

Short version. If Alice signs a message "I love you" and encrypts it to Bob, then Bob may re-encrypt the signed message and send Alice' love letter to Carol, who now believes Alice loves Carol. If Alice encrypts the same message for Bob and signs it, an active attacker may intercept the message and replace the signature with her own.

The "simple solution" (one of several offered in the article) is to sign the message along with a tag saying who the intended recipient is, then encrypt it.

The typical modern solution is hybrid encryption, meaning you asymmetrically exchange a key you then use to symmetrically authenticate and encrypt the messages. For one-offs use libsodium's crypto_box. To auth-encrypt a sequence of related messages and detect messages being dropped, duplicated, reordered, or truncated; use libsodium's secret_stream interface. Unlike crypto_box the secret_stream consumes a preshared key, so you'll need to do the key exchange yourself. For this I recommend 3DH (triple Diffie-Hellman) with static and ephemeral keypairs on both sides, using curve25519. This gives you 3 uniform keys, hash them together with blake2 to establish the shared session key.

(Ignore the X [dotted line] of Signal's X3DH to get the simpler and stronger 3DH.)

from arduinolibs.

Thank you @rweather. I understand only bits and pieces of your comment (no fault of yours, of course), and by now my lack of understanding of encryption should be evident. Do you have examples demonstrating simple interfaces for encrypting, signing, and decrypting? Similar to these: PyNaCl public key encryption and PyNaCl digital signatures.

from arduinolibs.

In general, encrypt-then-sign is the better choice because if an attacker manages to break the signature scheme

If you sign then encrypt one would need to first break the outer encryption before having access to the signature scheme. This article makes a pretty good case for sign then encrypt: https://www.quora.com/Which-one-is-more-preferable-encrypt-then-sign-or-sign-then-encrypt

from arduinolibs.

In general, encrypt-then-sign is the better choice because if an attacker manages to break the signature scheme

If you sign then encrypt one would need to first break the outer encryption before having access to the signature scheme. This article makes a pretty good case for sign then encrypt: https://www.quora.com/Which-one-is-more-preferable-encrypt-then-sign-or-sign-then-encrypt

Thanks for the comment. However, I don't agree with you. Or I should say, experts don't agree with you. This is a good reference on the subject : https://docs.google.com/viewer?url=https%3A%2F%2Fwww.iacr.org%2Farchive%2Fcrypto2001%2F21390309.pdf

from arduinolibs.