Dear IETF,
Hello. I am Tanveer Salim and am a Computer Engineering Student from Texas Tech
University.
Firstly, I would like to thank you for taking the time to work on GNUPG for all
these years.
I personally am really glad you are willing to ensure people have a sound
option for secure communication on the internet.
I discussed the pros and cons of using ChaCha20-Poly1305 first with the
ProtonMail Security Team on a Reddit Forum:
(https://www.reddit.com/r/ProtonMail/comments/g0pa55/protonmail_securitys_opinion_on_using_the/)
and as of now with the creators of WireGuard VPN.
ProtonMail users and the ProtonMail Security Team admitted that most hardware
devices already have hardware support for AES-GC 256-bit encryption and
therefore AES-GCM 256-bit will be faster than a pure-software implementation of
ChaCha20.
Jason Dononfeld, one of the creators of WireGuard VPN, said that although that
was true ARX-512 bit vector extensions for the Intel and AMD instruction set
architectures will allow hardware-accelerated implementations of
ChaCha20-Poly1305 to run even faster than hardware-accelerated implemetnations
of AES (e.g. AES-NI). (https://www.wireguard.com/papers/wireguard.pdf)
This was why Jason Dononfeld and the rest of the WireGuard VPN team made
ChaCha20-Poly1305 the primary, exclusive AEAD in their VPN.
For now, support for AVX-512 bit instructions is not as widespread just yet.
But that should be the case in a matter of a few years as cited in the
WireGuard VPN Whitepaper.(https://en.wikipedia.org/wiki/AVX-512).
(https://www.wireguard.com/papers/wireguard.pdf)
For now, although ProtonMail is mostly correct in their saying that
hardware-accelerated AES is faster than pure-software, Jason Dononfeld
definitely seems to be making a strong argument for using ChaCha20-Poly1305.
Soon in the future, ARX-512 bit vector extensions will allow
hardware-accelerated ChaCha20-Poly1305 to run faster than hardware-accelerated
AES.
ProtonMail did admit it would be a good idea to try to add the
ChaCha20-Poly1305 to OpenPGP and WebCrypto. Afterwards, they would be happy to
add support for ChaCha20-Poly1305.
This is perhaps also why other projects are adding support for
ChaCha20-Poly1305 as we speak.
Other famous projects that are using ChaCha20-Poly1305 in their works include
NordPass (https://nordpass.com/features/xchacha20-encryption/), KeePassXC, and
SSH (http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html).
Considering the growing usage of ChaCha20-Poly1305, would you consider adding
ChaCha20-Poly1305 as an additional cipher to your draft of OpenPGP
standardization. I noticed you were working on a new draft for OpenPGP in RFC
4880bis: (https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-09).
Libgcrypt already supports ChaCha20 and Poly1305 individually after all. But
OpenPGP does not yet accept ChaCha20-Poly1305 as an additional/experimental
cipher yet.
Since you are the lead developer of GNUPG, which is the world's most
influential implementation of OpenPGP, you could certainly make it an
additional cipher to OpenPGP.
With saying all of this, I would like to ask if you are now considering to add
ChaCha20-Poly1305 itself to the OpenPGP standardization?
I thank you for any responses to send back to me.
I actually first emailed Werner Koch directly and has given me permission to
reiterate his response:
-------------------------------------------------------------------------------------------------------------------------
Werner Koch's Response Below:
Hi!
Thanks for the long writeup but you should better direct this mail to
the IETF WG list: openpgp(_at_)ietf(_dot_)org which is the appropriate place for
such requests.
The set of cipher algorithms in OpenPGP is long and actually longer than
we like it. Most of the extra cipher algorithms are there for political
reasons (e.g. Camellia) and in practice not used. We have settled long
ago for AES because that is a the best block cipher algorithm we have
and main stream CPUs provide hardware acceleration for it.
Regarding encryption modes, we are using CFB+MDC and are preparing to
move on to OCB and EAX (with the latter only there for political/patent
fears). This allows us keep on using AES. Changing to a stream cipher,
as you propose is very unlikely.
You may however use the experimental range of algo identifiers for
ChaCha but that won't be useful for production. Replacing algorithms
takes years and we are not even there to enable OCB or EAX modes.
Shalom-Salam,
Werner
ps.
if you want to post to the WG list, feel free to include this mail.
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
So Mr. Koch admits that there are political problems and technical issues with
adding ChaCha20-Poly1305. Political in the sense that many implementations will
be offended if the switch was made from AES to ChaCha20-Poly1305. I am not
saying we should necessarily switch the official standard from AES to
ChaCha20-Poly1305. Just to add ChaCha20-Poly1305 as an alternative. The
technical challenge was that even the OCB and EAX mode meant to improve AES
performance were not even added yet.
Finally, I have one more additional question.
According to the Autocrypt website, it would be great if Argon2 and SCrypt key
derivation functions to OpenPGP as well. But Autocrypt admitted that this is
yet to be done. (https://autocrypt.readthedocs.io/en/latest/faq.html)
So will the IETF be trying to add support for both key derivation functions in
the current draft for RFC 4880bis?
I thank the IETF for updating OpenPGP and taking the time to send back any
replies to me.
Sincerely,
Tanveer Salim
Sent with ProtonMail Secure Email.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp