Opened at 2013-09-30T13:59:24Z
Last modified at 2016-10-12T16:50:51Z
#94 new enhancement
add ChaCha
| Reported by: | zooko | Owned by: | dawuud |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Version: | 0.5.29 | Keywords: | |
| Cc: | Launchpad Bug: |
Description
The ChaCha cipher (http://cr.yp.to/chacha.html) is very promising. It is a close relative of Salsa20, served as the core of BLAKE and BLAKE2 hash functions, and is currently a candidate for a standard cipher for TLS: http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-01
Let's include an implementation of ChaCha in pycryptopp, so that Tahoe-LAFS has the option of using ChaCha for the Hundred Year Crypto project: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/OneHundredYearCryptography
It would be great if Wei Dai wanted to implement and maintain ChaCha in Crypto++, but he has been minimally active on Crypto++ for a long time now and I don't expect him to do that. It would also be great if Jack Lloyd wanted to implement it in Botan http://botan.randombit.net/ and help us use it. That would be great, because Jack is actively maintaining Botan and he has helped us out in the past with this project. Another implementation of ChaCha: DJB's reference implementation: http://cr.yp.to/chacha.html
We don't need high optimization for this release! A portable, well-written, well-examined, well-tested implementation would be far preferable for deployment and safety reasons over an optimized implementation.
Change History (11)
comment:1 Changed at 2013-09-30T14:16:26Z by zooko
comment:2 Changed at 2013-09-30T14:44:19Z by nickm
You can also use the XSalsa20 construction (the nonce extender that makes Salsa into XSalsa) with ChaCha.
As for implementation choice, I had occasion to look around for one recently. For a simple obvious C implementation, the "merged" implementation from SUPERCOP is a good choice. The "krovetz" implementation from SUPERCOP is a good C+SIMD implementation; it gives good performance on Intel, ARM, and PowerPC chips with vector instructions. (It's competitive with the assembly implementations on those systems where it runs.) These both need a little glue code to work, but only a little. Both are public domain.
In libottery, I wrote a minimal pure-Python ChaCha implementation as part of the tests; you might want to grab that for testing, though I wouldn't recommend it for real cryptography.
comment:3 follow-up: ↓ 4 Changed at 2013-12-03T19:39:56Z by lally
I put together a binding against DJB's reference implementation this past weekend. Hopefully, expect a pull request this weekend on this. If there's another impl you'd prefer, let me know.
comment:4 in reply to: ↑ 3 Changed at 2013-12-03T21:56:34Z by zooko
Replying to lally:
I put together a binding against DJB's reference implementation this past weekend. Hopefully, expect a pull request this weekend on this. If there's another impl you'd prefer, let me know.
Awesome! Thanks. DJB's reference implementation sounds good to me. Note that nickm later pointed out in a Tahoe-LAFS Weekly Dev Chat conference call that we don't need the extended nonce since we use a unique key for every encryption. So we can just use standard ChaCha20.
comment:5 Changed at 2016-07-06T15:37:39Z by zooko
Now that ChaCha20 is in Crypto++ (https://github.com/weidai11/cryptopp/blob/433f2d65669d85e9745e32e584c569699c44297c/chacha.cpp) and Jeffrey Walton is doing a lot of maintenance work on Crypto++ (http://cryptopp.com/release563.html), I recommend we use that implementation.
comment:6 Changed at 2016-08-02T11:47:43Z by dawuud
in another ticket https://tahoe-lafs.org/trac/pycryptopp/ticket/100 i've gotten pycryptopp to build and pass tests using the latest stable tag of cryptopp. in order to use cryptopp's latest chacha20 should i simply build pycryptopp with that commit id? or tip? or cherry-pick it into the stable branch?
comment:7 Changed at 2016-08-03T13:33:43Z by dawuud
here's my latest progress:
https://github.com/tahoe-lafs/pycryptopp/pull/30
it builds and passes all tests. that dev branch includes the latest crypto++ master branch and i've added the files for chacha20 and blake2.
all we have to do now is write the c glue so blake2 and chacha20 are accessible from python.
comment:8 Changed at 2016-08-03T13:37:24Z by dawuud
- Owner set to dawuud
comment:9 Changed at 2016-08-11T17:00:44Z by dawuud
here some more progress; derived the c/python glue from the salsa20 source files by search/replace strings. anyhow it currently appears to be working and needs the python tests to be fixed:
comment:10 Changed at 2016-08-12T00:59:49Z by dawuud
in PR 31 i've pushed some more commits that fix the tests. i've also verified using pysodium that the python unit test outputs match that of pysodium's chacha20
ready for review and merge ;-)
comment:11 Changed at 2016-10-12T16:50:51Z by dawuud
rebased onto upstream master in a new pull-request here:
https://github.com/tahoe-lafs/pycryptopp/pull/34
I forced a buildbot build and it fails on some of them:
looks like it fails on platforms that build with -DDISABLE_EMBEDDED_CRYPTOPP=1
The ticket to add XSalsa20 into LAFS is Tahoe-LAFS ticket #1164. I'd like to use ChaCha instead of XSalsa20, now. (Because, since we chose XSalsa20 a while back, the BLAKE2 project and the include-ChaCha-in-TLS proposal have come along.)