Repository navigation
Missing block ciphers #1
Description
List of "would be nice to have" block ciphers:
- ARIA (aria: initial implementaion of the ARIA cipher (RFC 5794) #340)
- Camellia (Add implementation of Camellia #293)
- CAST5 (feat: implement CAST5 based on RFC 2144 #36)
- CAST6 (cast6: initial crate #384)
- DES (Implemented DES #2)
- IDEA (Add IDEA cipher #35)
- Kalyna
- Kuznyechik
- Magma
- RC2 (RC2 cipher #4)
- RC5 (initial rc5 impl #346)
- RC6
- Rijndael (additional key/block sizes beyond AES)
- Serpent (Added Serpent #60)
- Simon (feat: Implement Simon #523)
- Speck (speck: initial crate #297)
- Threefish (Added threefish #5)
- Twofish (Twofish cipher #7)
- XTEA (XTEA implementation #422)
Activity
tvladyslav commentedon Jan 6, 2017
What about SPECK?
https://en.wikipedia.org/wiki/Speck_%28cipher%29
newpavlov commentedon Jan 7, 2017
Missed it for some reason while compiling the list. Added Speck and Simon to it.
k3d3 commentedon Jan 11, 2017
Is Rijndael/AES being covered?
newpavlov commentedon Jan 11, 2017
AES is present in the rust-crypto codebase, so it's already "implemented", this is why I haven't included it into this list. But it's not the easiest code to work with and better implementations exist (e.g. one in the ring), so for now it's not a highest priority for me.
gsingh93 commentedon Jan 18, 2017
I'm claiming DES, just need a bit of time to finish up Grostl over in the hashes repo before starting it.
Trojan295 commentedon Apr 17, 2017
I started to work on the RC2 cipher.
Trojan295 commentedon Apr 18, 2017
BTW. What about modes of operation for the block ciphers (CBC, OFB, etc.)? In this repo we have only the raw block ciphers. How do we progress to make them usable in different modes?
newpavlov commentedon Apr 19, 2017
@Trojan295
Sorry for the late answer. They will be implemented generically, though not sure if they should be placed here or in the traits repo, also I haven't yet decided on how exactly API should look like. We will probably need some kind of generic trait which will unite block ciphers under different modes of operation and stream ciphers.
Trojan295 commentedon Apr 28, 2017
I will start working on the Serpent implementation.
link2xt commentedon Jun 12, 2017
Working on twofish, PR #7
It is used in passwordsafe password manager, I wanted to port it to Rust but twofish package on crates.io seems to be reserved for this project and there is no implementation yet.
dignifiedquire commentedon Nov 8, 2018
Implemented Cast5 in #36
WildCryptoFox commentedon Sep 20, 2019
OCB3, a solid single-pass high-performance CAESAR candidate, could do with a Rust implementation.
The ciphertext is expanded by a variable length tag (whose tag length is committed). Only slightly slower than unauthenticated CTR, OCB3 could make a useful alternative when the costs of nonce-misuse resistance of HCTR or SIV are too high for an application (doubtful but nice to have). OCB3 does not resist nonce-misuse, nor does it aim for beyond birthday bound security.
The biggest issue harming OCB's deployment is its patent; but Rogaway has public free licenses available since 2013 and is open to negotiating additional licenses if needed.
tarcieri commentedon Sep 20, 2019
Unfortunately Rogaway's patents aren't the only ones that matter:
https://web.cs.ucdavis.edu/~rogaway/ocb/patent-jutla-1.pdf
https://web.cs.ucdavis.edu/~rogaway/ocb/patent-jutla-2.pdf
https://web.cs.ucdavis.edu/~rogaway/ocb/patent-jutla-3.pdf
https://web.cs.ucdavis.edu/~rogaway/ocb/patent-gligor-1.pdf
WildCryptoFox commentedon Sep 21, 2019
"may or may not" uh. When even the authors of the mode doesn't know. :/
5 remaining items
tarcieri commentedon Apr 7, 2021
AES is effectively a subset of Rijndael, so if we were to support it, it would probably make sense for it to either be part of the
aescrate or reuse parts of it (e.g. making some of the private API public under a special feature flag)However, it's a bit tricky because our implementation is currently heavily specialized to AES and there are multiple backends, all of which would need to be modified to support a more general Rijndael. As an example, the number of rounds varies only with the key size in AES, whereas in the more general Rijndael it varies with either/both the key size and block size.
It's something we could potentially do although I would want to be careful that we don't overcomplicate or otherwise harm the AES implementation by doing so, which might be tricky.
sorairolake commentedon Dec 15, 2021
Implemented Camellia in #293.
lumag commentedon Oct 5, 2022
ARIA implementation: #340
sorairolake commentedon May 14, 2024
@newpavlov @tarcieri Why isn't
speck-ciphercrate (Speck) published yet?tarcieri commentedon May 16, 2024
@sorairolake unfortunately only @newpavlov currently has access to publish it.
I would suggest we publish a v0.0.1 based on 8b1499c, since the current
masteris on the newest prereleaseciphercrate.newpavlov commentedon May 16, 2024
Oh, we have indeed forgot to publish the Speck crate (I think we were hoping for potential transfer of the
speckname). I've added the block ciphers group to owners of thespeck-ciphercrate.tarcieri commentedon May 16, 2024
It's released: https://crates.io/crates/speck-cipher/0.0.1
XTEA implementation (#422)
OctopusET commentedon Feb 17, 2026
https://en.wikipedia.org/wiki/LEA_(cipher)
Can we add
LEA? I'm working on thatnewpavlov commentedon Feb 18, 2026
@OctopusET
There is an existing implementation: https://github.com/sitd2813/lea-rust I will ask whether the owner is open to transferring it to us.
sorairolake commentedon Feb 25, 2026
I implemented Simon in #523.
sorairolake commentedon Apr 13, 2026
I think it would be good to add an implementation of the CLEFIA block cipher as described in RFC 6114 to this project in the future. This block cipher is the one of three 128-bit block ciphers listed on the Candidate Recommended Ciphers List by the Japanese Government's CRYPTREC as of April 2026.
However, as of 2012, this block cipher was protected by intellectual property rights and could not be implemented royalty-free.12 In other words, at least at that time, it was not licensed under a royalty-free, reasonable and non-discriminatory license to all implementers. I'm unaware of the current intellectual property rights status of it.
I previously implemented the Camellia block cipher as described in RFC 3713 and the KCipher-2 stream cipher as described in RFC 7008 in pure Rust. Before implementing these ciphers, I confirmed that they were licensed under royalty-free, reasonable and non-discriminatory licenses to all implementers.3456
Therefore, I believe that this block cipher can only be implemented as FOSS after it has been definitively confirmed that all intellectual property rights to it have expired.
Footnotes
Sony Corporation's Statement about IPR related to RFC 6114 ↩
知的財産権の使用の権利に係る確認書 ↩
Intellectual Property Information ↩
知的財産権の使用の権利に係る確認書 ↩
KDDI Corporation's Statement about IPR related to draft-kiyomoto-kcipher2-06 ↩
知的財産権の使用の権利に係る確認書 ↩
tarcieri commentedon Apr 14, 2026
@sorairolake we probably want to avoid any constructions with IPR concerns
randombit commentedon Jun 20, 2026
Any interest in SHACAL2? Approved by NESSIE and the best known attack breaks 44 of 64 rounds using 2^223 related key chosen ciphertexts with 2^497 complexity. Any realistic attack on it probably implies a break of SHA-256. Admittedly a bit obscure but has many good points - 256 bit block (so birthday problem type issues that can apply to 128-bit ciphers are a complete non-issue), ARX style ciphers are trivially constant time and easy to run as SIMD, can use SHA-256 instructions (SHA-NI/ARMv8) for the encryption direction, and even a baseline scalar version is quite fast.