-----BEGIN PGP SIGNED MESSAGE-----
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
is that there will be suggestions on new usage modes like
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
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.
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
-----END PGP SIGNATURE-----