ietf-openpgp
[Top] [All Lists]

Re: Next Steps

2007-11-07 12:32:36

-----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-----