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(_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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp