[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AI : follow up to Issue 14
On the question of using P_SHA1 rather
than the full PRF function defined in TLS: The assumption of PRF is that either SHA1
or MD5 would provide sufficient security so PRF has two independent terms using
each of these. History has shown that SHA1 is more secure than MD5, so if
we believe that PRF is secure, then we correspondingly believe that SHA1 is
secure. For simplification reasons, the derived key specification chose
to simply use the P_SHA1 given that MD5 wouldn’t provide additional
security. In terms of analysis, I believe the original TLS work provides
sufficient material here since P_xxxx is defined as a general algorithm for any
digest and the combination of SHA1 and MD5 was historical. On the question of recent SHA1 attacks: Many crypto folks still feel that P_SHA1
is a reasonable choice given how we are using it for derived keys.
However, since TLS does define P_xxxx as general function for digest
algorithms, we could define an alternate derivation key algorithm that uses
P_SHA256 (either truncated or not). We could explore that as an option,
but I don’t see any reason to drop P_SHA1 since many folks believe it
still safe and many have this code implemented and interop tested already (e.g.
as part of TLS stacks). |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]