[noise] Collision-resilience from hashing ciphertext?
Trevor Perrin
trevp at trevp.net
Sat Sep 3 10:51:27 PDT 2016
Question for symmetric cryptographers:
The Noise handshake hash (the "h" value) hashes the transmitted bytes,
so it covers any ciphertext transmitted in the handshake. An
alternative would've been to hash plaintext.
The rationale for hashing ciphertext, instead of plaintext, is:
"""
* This ensures h is a non-secret value that can be used for
channel-binding or other purposes without leaking secret information.
* This provides stronger guarantees against ciphertext malleability.
"""
I'm wondering if hashing ciphertext also makes h more
collision-resistant in the case of a weak hash, since h ends up
covering the AEAD auth tags.
The design goal for h is collision-resistance, i.e. it should be
unique for every session. Practical attacks would probably have to do
better, e.g. calculate a 2nd-preimage for a legitimate value.
But let's contrive a situation that depends on collision-resistance.
For example, imagine if we had signatures that sign h:
-> e
<- e, dhee, s, sig, [payload = server cert]
-> s, sig
The client sends a non-deniable signature in the 3rd message. If the
server can send a cert in the payload of the 2nd message that contains
weird blocks that force a collision in h, the server might be able to
exhibit a signature from the client over some incriminating data the
client never saw.
QUESTION: Does hashing the ciphertext for [payload = server cert]
make this attack harder? I'm thinking the attacker would have to
solve for a collision in the auth tag simultaneous with a hash
collision. If we were using a weak hash like MD5 or SHA1, how much
difficulty would that add to a collision attack?
Trevor
More information about the Noise
mailing list