block-ciphers
block-ciphers copied to clipboard
RustCrypto
Missing block ciphers
List of "would be nice to have" block ciphers:
- [x] ARIA (#340)
- [x] Camellia (#293)
- [x] CAST5 (#36)
- [x] CAST6 (#384)
- [x] DES (#2)
- [x] IDEA (#35)
- [ ] Kalyna
- [x] Kuznyechik
- [x] Magma
- [x] RC2 (#4)
- [x] RC5 (#346)
- [ ] RC6
- [ ] Rijndael (additional key/block sizes beyond AES)
- [x] Serpent (#60)
- [ ] Simon
- [x] Speck (#297)
- [x] Threefish (#5)
- [x] Twofish (#7)
- [x] XTEA (#422)
Missed it for some reason while compiling the list. Added Speck and Simon to it.
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.
I'm claiming DES, just need a bit of time to finish up Grostl over in the hashes repo before starting it.
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?
@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.
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.
Implemented Cast5 in https://github.com/RustCrypto/block-ciphers/pull/36
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.
License 1 — License for Open-Source Software Implementations of OCB (Jan 9, 2013) Under this license, you are authorized to make, use, and distribute open-source software implementations of OCB. This license terminates for you if you sue someone over their open-source software implementation of OCB claiming that you have a patent covering their implementation.
License 2 — General License for Non-Military Software Implementations OCB (Jan 10, 2013). This license does not authorize any military use of OCB. Aside from military uses, you are authorized to make, use, and distribute (1) any software implementation of OCB and (2) non-software implementations of OCB for noncommercial or research purposes. You are required to include notice of this license to users of your work so that they are aware of the prohibition against military use. This license terminates for you if you sue someone over an implementation of OCB authorized by this license claiming that you have a patent covering their implementation.
Unfortunately Rogaway's patents aren't the only ones that matter:
Jutla (IBM)— 6,963,976, 7,093,126, and 8,107,620—and of Gligor and Donescu (VDG)—6,973,187.
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
Gligor and Donescu (VDG) and Jutla (IBM) are inventors (owners) on US patents 6,963,976, 6,973,187, 7,093,126, and 8,107,620, all which concern AE but which may or may not apply to OCB.
"may or may not" uh. When even the authors of the mode doesn't know. :/
In particular, Jutla 7,093,126, and 8,107,620 very much apply to OCB, IMO:
- 7,093,126: "Encryption schemes with almost free integrity awareness"
- 8,107,620: "Simple and efficient one-pass authenticated encryption scheme"
@newpavlov @tarcieri I think checkbox for threefish can be checked now, since https://github.com/RustCrypto/block-ciphers/pull/5 was merged, right?
Rijndael - 256-bit blocks? It seems to be similar to aes (128-bit blocks), or can you tell me how to achieve it?
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 aes crate 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.
@newpavlov @tarcieri Why isn't speck-cipher crate (Speck) published yet?
@sorairolake unfortunately only @newpavlov currently has access to publish it.
I would suggest we publish a v0.0.1 based on 8b1499cf9b9a478caee0ee7f9874fe195ae60573, since the current master is on the newest prerelease cipher crate.
Oh, we have indeed forgot to publish the Speck crate (I think we were hoping for potential transfer of the speck name). I've added the block ciphers group to owners of the speck-cipher crate.