On 21/09/2015 05:13 am, Simon Josefsson wrote:
ianG <iang(_at_)iang(_dot_)org> writes:
Hi Werner,
On 17/09/2015 19:41 pm, Werner Koch wrote:
I'd like to get opinions on one specific aspect of a new fingerprint
format in 4880bis.
In the past we bound the fingerprint format to the key packet version:
v3 keys used MD5 and v4 keys SHA-1 fingerprints. This gained us the
benefit of having a bijective connection between fingerprint and key.
I'm hugely on that side. I'll always vote for that. I even staked my
rep on it :)
http://iang.org/ssl/h1_the_one_true_cipher_suite.html
Which came directly from the experience of hacking PGP & OpenPGP in
Perl/Java as part of Cryptix. The tears, the fears, the costs.
So: the only choice for me is which hash you pick for v5. If you
want another one, start planning for v6.
+1
I believe sub-negotiating in security protocol leads to obscure problems
and makes security evaluation harder. If we can avoid that, and that
appears to be the case, I'm all for it.
Regarding which hash to use, SHA-256 is probably the simplest choice
From a practicallity and consensus point of view. Are there any strong
reasons to favor something else?
What would be the relevant options be anyway? SHA-256, BLAKE2,
SHA3-256, SHA-512, CubeHash? Would there be value in being able to use
variable length SHAKE variants?
There are a few reasons to go to SHA3 or SHAKE, as far as I see it.
1. It leaps us ahead by about a decade in terms of cryptographic
experience.
2. It can do any size so we can use the same algorithm for all the
different uses, without getting into esoteric arguments about
truncation. Indeed this is intended -- although rare, the team that
made SHA3 felt our pain and improved our interface to the black box
known as the message digest.
3. This further leads to the possibility that if we get scared of the
"short" length, we can just lengthen the base array and let the software
work it out. Similar to PHB's concept, we could just pre-ordain some
applicable lengths that work for all purposes.
4. The same base algorithm can be used as a symmetric AE cipher. This
leads to the possibility of one algorithm family giving most of the
cryptographic needs (we'd need an asymmetric one too). The development
savings and the size savings are not to be sniffed at: leads to small
lightweight deployments e.g., on IoT and many more and maintainable
language implementations.
5. As a higher level meta-advantage, getting us away from the alphabet
soup approach to protocol design might clarify to us why it is that
there is an advantage in having more than one of everything around.
iang
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp