I've implemented ECIES (see the below pseudo-Python).

r = urandom(32)
p_r = x25519(r, BASE_POINT)
shared_secret = x25519(r, x25519_public)
iv = urandom(12)
key = sha256(p_r + x25519_public + shared_secret + 
plaintext_sig = ed25519_sign(eddsa_secret, plaintext)
ciphertext, tag = chacha20_poly1305_encrypt(key, iv, plaintext) # as per RFC
output(p_r, iv, plaintext_sig, ciphertext, tag)

As you can see, the plaintext is signed to provide authentication. Does this signature make the Poly1305 MAC redundant?


From the standpoint of integrity and proof of origin, signature is a superset of MAC, with the tremendous operational benefit that no secret is required for verification (drawbacks include larger size, slower generation, and typically slower verification with the possible exception of RSA/Rabin signature). Thus the poly1305 MAC in theory is redundant. From the standpoint of down-to-earth IT security (not cryptography), it may still be useful by making it harder to exploit software bugs in the code for decryption and whatever manipulates the result of decryption until signature verification.

But from the standpoint of confidentiality, a huge mistake is made: signing then enciphering without enciphering the signature! A guess of the plaintext can be checked. For example, if the plaintext is a name from the public class roll, poof goes secrecy!


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.