[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] Open Issue: verify_data processing
On 17/10/06, Eric Rescorla <ekr@xxxxxxxxxxxxxxxxxxxx> wrote:
Stipulating for the moment that we intend to replace the PRF,
we're left with the issue of how to compute the verify_data.
Currently, the verify_data is computed as:
PRF(master_secret, finished_label, MD5(handshake_messages) +
SHA-1(handshake_messages)) [0..11];
If you're not using MD5 for your PRF, it doesn't make sense to use
it here either. This leaves us with two possibilities:
1. PRF the handshake_messages directly.
2. Hash them first.
The argument for hashing them first is that it avoids having
to store them (2-5k) for the entire handshake. It also will
accomodate PRFs which won't take unlimited size data.
The argument against is that it puts the security of the
handshake on an unkeyed hash rather than a MAC (since
you only need to mount a 2nd preimage attack on the hash
and then you have 2nd preimage on MAC(K,hash).).
A pedantic quibble here: this makes the assumption that a hash can
always be calculated by chaining partial inputs, which is not a
required property of hashes, just one we're used to having.
My preference here would be to move to PRF(messages) and
if new PRFs can't cope with that then they can specify
a hash reduction of their own. Recall that the PRF needs
to be able to deal with fairly large data anyway since
the PMS + randoms could easily be 300+ bytes...
Comments?
-Ekr
P.S. Please don't use this thread to say you don't want to
replace the PRF at all. The only question here is what we
do if *do* replace the PRF.
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls