1
$\begingroup$

I know of a project that implemented e2e encryption using both authenticated encryption and public key signing. So the ciphertext produced for a message would be:

ciphertext = signature_Ed25519 + nonce + mac_Poly1305 + XSalsa20(plaintext)

I struggle to understand what the benefits of doing both could be, as MAC is already there to authenticate the sender. Any ideas?


The full flow is as follows:

Alice and Bob each have an X25519 encryption key pair for talking to each other.
Alice has an Ed25519 signing key pair that is used for everybody.

Alice sends a message to Bob:

1. encrypted = crypto_box(plaintext, nonce, bob_publickey, alice_secretkey)

This is provided by crypto_box().

encrypted is now = nonce + mac_Poly1305 + XSalsa20(plaintext)

2. ciphertext = crypto_sign(encryted, alice_signing_secretkey)

This is provided by crypto_sign().

ciphertext is now = signature_Ed25519 + encrypted

$\endgroup$
3
  • $\begingroup$ Can you be more clear? What was included in the signature? Using which key ? On what part of protocol etc? It could be that signature is only used to authenticate the identity of sender and to authenticate some key used (e.g. Server's Diffie Hellman public key) and the content was only encrypted using AEAD, allowing deniability. $\endgroup$ Jan 25 at 13:40
  • $\begingroup$ I've elaborated! $\endgroup$ Jan 25 at 13:57
  • 1
    $\begingroup$ I have not used any of the C's crypto libraries so I am not very familiar with it. I assume this crypto_box performs ECDH in X2559, Key derivation (maybe involving nonce) and encryption. Anyway, It looks like it is encrypted with AEAD and then the ciphertext signed. First to authenticate the message that it is indeed created by someone Bob did X25519 ECDH Key exchange with (assuming Ephemeral) and second to prove that that someone is Alice. $\endgroup$ Jan 25 at 15:46
4
$\begingroup$

Signatures provide one property that MACs don't: non-repudiation. With only a MAC (or an AEAD) any party with the secret key could have sent the message. So Bob could forge a message and claim Alice sent it. With a signature only the party holding the corresponding private key could have created the signature. MACs authenticate the message, not the sender.

When this property is needed one must accept the performance decrease of adding the signature. If this property isn't needed, then there's no need to sign.

$\endgroup$
4
  • $\begingroup$ So it's more about key management... But why can Bob claim Alice has used certain encryption keys and can't claim she used certain signing keys? What if private keys for both algorithms are stored the same way in the same place? Doesn't it negate the usefulness of the signature? $\endgroup$ Jan 25 at 14:44
  • 2
    $\begingroup$ With Alice's signature verified using Alice's verified public key, anyone can see that only Alice could have signed that message and Alice cannot deny signing it. But presence of MAC alone can't act as evidence for anything because anyone (sender and receiver) who knows the key could have created an authenticated message. $\endgroup$ Jan 25 at 15:36
  • 1
    $\begingroup$ Private keys are, by definition, private. Only one entity ever has access to use them. If they're ever shared or leaked, all security guarantees are lost. So if Bob can access Alice's private keys the system has no security, and none of the guarantees hold. Therefore, if the private keys for both are stored in the same way in the same place it does negate the security of the signature. $\endgroup$ Jan 25 at 16:10
  • $\begingroup$ Now it's clear, thanks! The project I'm talking about generated and stored the private keys for both algorithms in the same place using the same security measures. Effectively, if you could steal a private key for one thing–encryption or signing–it automatically meant you could get the other. So, that implementation was in fact pointless. 🤷‍♂️ Could be as easily just the MAC and AEAD. $\endgroup$ Jan 25 at 16:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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