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

Hi,

I fully support the "One True Cipher Suite" paradigm of Ian. At Ethereum
(which is where I currently work), we have had quite a long explorative
discussion about the choice of THE hash function, and we came out in
favor of SHA3 (Keccak) for a multitude of good reasons most of which
apply to OpenPGP as well. I believe that the most important documents
from that debate are publicly available, but if necessary, I am willing
to repeat the arguments in a nutshell.

Furthermore, I also believe that if OpenPGP finally leaves the
convoluted CFB variant behind and goes for stream ciphers, SHAKE has
some very clear benefits over AES-CTR, chief among them that by using a
closely related hash function and stream cipher, we follow the "keep all
your eggs in one basket and watch that basket" principle; in other
words, we present a smaller cross-section to potential attackers.

Bests,

Daniel

On 2015-09-29 15:54, ianG wrote:
> On 21/09/2015 05:13 am, Simon Josefsson wrote:
>> ianG <iang@iang.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@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp