On 11/08/2015 17:08 pm, Werner Koch wrote:
On Tue, 11 Aug 2015 14:29, iang(_at_)iang(_dot_)org said:
* to choose which SHA3 we're going for. This not only means
addressing the additionals (like the 4 lengths) but also resolving the
uncertainty (perhaps in my mind only) about SHAKES.
I don't think so. Let's assume that 4880bis specifies SHA-256 as the
replacement for SHA throughout the protocol. Then it would be pretty
clear that SHA3-256 can be used if surprisingly a Chinese researcher
finds weaknesses in SHA2.
This assumes that any future breach of SHA2 is of the class that we can
then drop in a replacement from SHA3 -- without any change. Eg, a
prediction that the Chinese researcher attack actually comes true a
second time.
I find this unlikely. We're fighting a mythical enemy here, indeed the
Chinese research attacker hasn't as yet actually count coup [0] on SHA1
let alone SHA2 :)
I suggest we get back to other things, we're wheel-spinning. If you
really want to allocate those numbers, go ahead - I think it is
pointless but it does no harm to the document, and it's better to move on.
* to build a more comprehensive alg-failure recovery strategy. By
this I mean, more than handwaving at SHA3 as a potential drop in;
making it the actual drop in with a process by which we trigger that
We already have this. The preference systems greatly helped with the
migration from SHA-1 to SHA-256 et al.
OK, I'd have to review that in the doc. (But I don't have time, so I'll
defer.)
iang
[0] old Hollywood term for scalping the enemy in westerns.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp