Missing block ciphers
newpavlov opened this issue · comments
What about SPECK?
https://en.wikipedia.org/wiki/Speck_%28cipher%29
Missed it for some reason while compiling the list. Added Speck and Simon to it.
Is Rijndael/AES being covered?
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.
I started to work on the RC2 cipher.
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.
I will start working on the Serpent implementation.
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 #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, can SM4 be added to the list?
Serpent 🐍 needed! (really)
@newpavlov @tarcieri I think checkbox for threefish can be checked now, since #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.
Implemented Camellia in #293.
ARIA implementation: #340
@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 8b1499c, 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.
It's released: https://crates.io/crates/speck-cipher/0.0.1