Please add chacha20 algorithm.
It is considerably faster than AES in software-only implementations, making it around three times as fast on platforms that lack specialized AES hardware. https://tools.ietf.org/html/rfc7539
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Both Krasnov (2016) and the RFC itself (p. 3) describe ChaCha20 as an alternative to use as and when AES is broken, which hasn't happened yet. Although Google has implemented the algorthim (Bursztein 2014), and there are no known weaknesses (KDDI 2017), ChaCha20 still isn't widely-adopted. There are open questions about which variants are most effective, for example, even Bernstein, Chou and Schwabe (2013) use Salsa20 instead of ChaCha20.
There are literally thousands of algorithms out there, and implementing a non-industry standard would have little value.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It aged absolutely fine. Given the context of the time - over 5 years ago now.
Case in point, the standard referenced in the original post was updated in 2018 with the 2017 publication obsoleted by the update less than a year later.
Although ChaCha20+Poly1305 had wide adoption before 2017 via Chome+Cloudflare+OpenSSL for support for TLS connections, there was little precedent (if any) in FDE products at the time. ChaCha20 only made it into dm-crypt in December 2017 (a month after Ross J's reply) and even then with massive "THIS IS EXPERIMENTAL - DO NOT USE IN PRODUCTION" flags all over the release notes as part of version 2.0.0.
That response didn't age well ...
You don't have some 'gotcha' here. You just look like a fool.
👎
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please add chacha20 algorithm.
It is considerably faster than AES in software-only implementations, making it around three times as fast on platforms that lack specialized AES hardware.
https://tools.ietf.org/html/rfc7539
Both Krasnov (2016) and the RFC itself (p. 3) describe ChaCha20 as an alternative to use as and when AES is broken, which hasn't happened yet. Although Google has implemented the algorthim (Bursztein 2014), and there are no known weaknesses (KDDI 2017), ChaCha20 still isn't widely-adopted. There are open questions about which variants are most effective, for example, even Bernstein, Chou and Schwabe (2013) use Salsa20 instead of ChaCha20.
There are literally thousands of algorithms out there, and implementing a non-industry standard would have little value.
That response didn't age well. Now ChaCha20+Poly1305 is in widespread use.
It aged absolutely fine. Given the context of the time - over 5 years ago now.
Case in point, the standard referenced in the original post was updated in 2018 with the 2017 publication obsoleted by the update less than a year later.
Although ChaCha20+Poly1305 had wide adoption before 2017 via Chome+Cloudflare+OpenSSL for support for TLS connections, there was little precedent (if any) in FDE products at the time. ChaCha20 only made it into dm-crypt in December 2017 (a month after Ross J's reply) and even then with massive "THIS IS EXPERIMENTAL - DO NOT USE IN PRODUCTION" flags all over the release notes as part of version 2.0.0.
You don't have some 'gotcha' here. You just look like a fool.