-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We should sync us with the NIST hash competition so that a new version
would be due not before 4 years from now.
Although SHA-3 will be a drop-in replacement for SHA-2, my
understanding
is that there will be suggestions on new usage modes like
randomization
of hashing. That requires substantial changes to OpenPGP.
That is not my understanding.
There are people who want that. But there are people who point out
that if you require something like salted hashing for a hash
function, then it loses its most valuable facet -- that it is a hash
function. The latter group are all of us who have to implement these
in real world systems.
As I understand the consensus, there is value in having people define
modes of operation for hash functions like salted hashes, that's
good. And defining how you'd use a salted hash into a signature might
be good.
But requiring a mode of operation would be like creating CFB along
with AES. Modes of operation can be used with *any* underlying function.
We can, and should separate any mode of operation from the other
discussion. The whole point of salted hashing, for example, is to
compensate for broken hash functions, and making a hash function that
works is a better solution.
If 4880 were still open, I'd drop in constants SHA-3 for all four of
its lengths, and we'd be done, just as we were for AES. Now, that
would be a short RFC.
Jon
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII
wj8DBQFHMg6RsTedWZOD3gYRAvAUAJ9NjAYzvydP5XadfMVhN2LenNUJ/wCcCNOh
o47ufH5YLxwyseX6O/n8Ajo=
=rRqF
-----END PGP SIGNATURE-----