[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [openpgp] New fingerprint: to v5 or not to v5

On 21/09/2015 05:13 am, Simon Josefsson wrote:
ianG <iang@xxxxxxxx> 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 :)


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.


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.


openpgp mailing list