AES implementation should be chosen at runtime rather than compile time, otherwise it makes people very hard to ship products with this crate, because they cannot choose the environment a product would be run on.

Closes #25.

Adds an off-by-default autodetect feature which the cpuid-bool crate to detect whether AES-NI is available when compiling on i686/x86_64 architectures.

AFAICS, there is currently no implementation of AES-KW. Is that on the roadmap?

The only mention I could find was offer here to submit code for this mode.

~~Not quite ready for publishing.~~ Ready for review!

• [x] Generic over the block cipher and AXU universal hash function.

• [x] Documentation.

• [ ] Review.

• [ ] Publish to crates.io under RustCrypto

Why is Aes + ctr about half the performance of aesni w\ the ctr feature?

Because the latter benefits from XMM registers for the counter, while the former is more general and not currently checking if it can use XMM registers to boost aes in this case.

The crate feature zeroize was previously present, but unused.

This implements zeroization on drop for all aes types in the software and aesni implementations, if the zeroize feature is enabled.

This PR does not include support for the armv8 implementation. I do not have access to hardware to test it and a clean implementation is also likely blocked on the zeroize crate implementing Zeroize for the inner uint8x16_t type used.

Still I thought this might be a useful patch even without armv8 support. If you'd prefer, I can also add some documentation describing this limitation to users.

Serpent1 first implementation. Some work to do for optimization.

Bitslicing implemented. No benchmark.

Tested on 128bits, 192bits and 256bits key official vectors.

There is one panic in the code (in round and round_inverse), should it returns an Err instead?

EDIT : Bitslicing is now implemented. No more panic in the code.

The aes crate has two feature flags, both of which remove functionality:

https://github.com/RustCrypto/block-ciphers/blob/f68ad0db49c2136e9d3b3a5d3b2e098782b030a8/aes/Cargo.toml#L29-L31

This is an incorrect use of Cargo feature flags. From my comments at https://github.com/SergioBenitez/cookie-rs/pull/176#issuecomment-834028088, which focus on force-soft:

This seems like an ill-fitted, perhaps incorrect use of features. Features should only be used to add capabilities, but force-soft removes the ability to make use of AES-NI. The consequence is that a consumer of aes has little control over whether AES-NI is actually used: all it takes is a single dependency, direct or indirect, enabling force-soft to disable AES-NI completely, without recourse.

I would suggest what I would consider to be the "correct" approach: always enable AES-NI if it is known to statically exist, and otherwise, add a feature that adds the ability to dynamically detect its existence, which of course becomes a no-op if the first condition is met.

Somewhere in the codebase, you already have 2 versions of the code. Let's call them aes::ni and aes::soft.

Effectively, we want this:

fn aes() {
    #[cfg(have_aesni)]
    return aes::ni();

    #[cfg(feature(autodetect)]
    if detect(aes-ni) { return aes::ni() }

    aes::soft()
}

This structure makes it clear that autodetect is additive; it adds the ability to dynamically detect AES-NI and removes nothing otherwise; there is no not(feature(autodetect)). This is the only fully correct use of features. If the code that requires 1.49 is restricted to detect, then MSRV can remain at 1.41 as long as autodetect is not enabled.

The same reasoning applies to the compact feature. If it must exist at all, a non-feature --cfg aes_compact is the correct approach. This restores control of expected performance to the top-level binary as opposed to any crate in the transitive closure of dependencies.

See also the full comment thread in https://github.com/SergioBenitez/cookie-rs/pull/176.

When using runtime is_x86_feature_detected macro to check if I could use aesni, I had to disable the checks. Is it possible to include this little feature to allow usage of aesni without compile time checks?

The hazmat API provides access to the raw AES cipher round, equivalent inverse cipher round, mix columns, and inverse mix column operations.

This PR wires up support for these operations in the "soft" backend (or more specifically, both the 32-bit and 64-bit fixsliced backends).

It would benefit from a parallel API instead of what's currently provided, however that's left for future work.

This is an implementation of DES. The included benchmark gives 2 MB/s performance, I'm not sure if that's good or bad. Most of the trickiness with the implementation is the fact that the most significant bit is considered bit zero instead of the least significant bit. It's possible I did some unnecessary shifting/arithmetic to account for this.

Note that the crate name des is taken on crates.io, so we might have to change that name.

I'm planning on adding more test cases. I have a file of (input, key, output) tuples that I need to parse and turn into the correct format for tests used in this repo.

This is implemented based on RFC 3713 and refer to Botan. Test vectors are from NESSIE, and tested on all three key sizes of Camellia.

This partially solves #1.

Implemented RC5 based on the revised paper. Got test vector at: https://www.ietf.org/archive/id/draft-krovetz-rc6-rc5-vectors-00.txt

Core impl features a generic impl using typenum and generic array. Const generic implementation without generic expressions doesn't seem appropriate.

I was not sure what api would work best with the cipher crate so i decided to propagate the InOut ptr. Put all the core fn behind a trait to avoid rewriting generic bounds.

For now only 32, 20, 20 parametrization made public.

This pull request contains a constant-time software fixslicing implementation of the GIFT block cipher, based on the C implementation of the original authors found here.

Gift is a PRESENT based block cipher with focus on energy efficiency and a small memory footprint making it ideal for usage in resource constrained environments. It gained some popularity as part of GIFT-COFB, which is a finalist in the current NIST lightweight cryptography competition as well as SUNDAE-GIFT.

This pull request comes with an implementation of GIFT-128, meaning Gift operating on 128-bit blocks, though I am planning on implementing GIFT-64 in the future.

It passes all test vectors and performs at ~44.5 cpb on an Intel Core i7 8700k with 3.7GHz core clock, while the C version "only" performs at ~47.1 cpb on the same machine.

GOST 28147-89 and GOST R 34.12-2015 ended up using different subkeys schedule during encryption. For the non-formal description see the RFC. Please provide a way to support both of them. From my experience the easies (and most probably the most correct) way to achieve this is to specify Gost89 ciphers (original subkeys order) using all defined SBox-es (including the TC26-A one) and to specify a separate (Magma) cipher fixed to use TC26-A S-Box and using "new" subkeys order.

Based on https://eprint.iacr.org/2013/404.pdf Using testvectors from Appendix C of the aforementioned paper.

Notes:

• I implemented this based on the cipher v0.4 branch, so this should only be merged after that branch is merged.
• The crate name is currently speck, however, there's already a crate with that name on crates.io, so I think we need to come up with a different name? I've never published on crates.io before.
• The actual code itself uses a macro system similar to AES, with the code inside the macro definition based on SM4.
• I'm not very experienced in Rust, so there might be some things that could be done better. Please let me know!

This partially solves #1.

In the current fixslice implementation there is some redundancy in the way keys are stored (2x for fixslice32, 4x for fixslice64). This enables the round keys to simply be XORed in for each round.

It is possible to store the round keys in a compact format and expand them in each round, which requires a few additional instructions (prototype code for fixslice64 puts this at 10% slower; the penalty will be smaller for fixslice32). The memory saving for the key storage is then: 50% i.e. 176/208/240 bytes for fixslice32 AES 128/192/256 respectively, or 75% i.e. 528/624/720 bytes for fixslice64.

Is there a standard cfg attribute for constrained memory devices, and/or should this project support a feature making smaller memory footprint a priority?