Start fixing issue #12. Used the static data from issue to create a test case. Have done some randomized testing with original poc without any issues. At one point included wrap around tests to make sure aes-ctr matched output of openssl, see comment.

Similar to #2, I am migrating away from rust-crypto and would like to use the Salsa20 and ChaCha20 implementations contained in stream-ciphers. Would it be possible to push them to crates.io?

I ported the NEON implementation of ChaCha from Crypto++ (public domain) to Rust with aarch64 intrinsics for a significant performance boost.

Observed performance changes on an Apple M1 Air:

 name                   chacha-soft ns/iter  chacha-neon ns/iter  diff ns/iter   diff %  speedup
 chacha12_bench1_16b    34 (470 MB/s)        28 (571 MB/s)                  -6  -17.65%   x 1.21
 chacha12_bench2_256b   477 (536 MB/s)       132 (1939 MB/s)              -345  -72.33%   x 3.61
 chacha12_bench3_1kib   1,897 (539 MB/s)     503 (2035 MB/s)            -1,394  -73.48%   x 3.77
 chacha12_bench4_16kib  30,811 (531 MB/s)    7,914 (2070 MB/s)         -22,897  -74.31%   x 3.89
 chacha20_bench1_16b    51 (313 MB/s)        47 (340 MB/s)                  -4   -7.84%   x 1.09
 chacha20_bench2_256b   777 (329 MB/s)       212 (1207 MB/s)              -565  -72.72%   x 3.67
 chacha20_bench3_1kib   3,088 (331 MB/s)     821 (1247 MB/s)            -2,267  -73.41%   x 3.76
 chacha20_bench4_16kib  50,251 (326 MB/s)    13,001 (1260 MB/s)        -37,250  -74.13%   x 3.87
 chacha8_bench1_16b     26 (615 MB/s)        19 (842 MB/s)                  -7  -26.92%   x 1.37
 chacha8_bench2_256b    335 (764 MB/s)       92 (2782 MB/s)               -243  -72.54%   x 3.64
 chacha8_bench3_1kib    1,328 (771 MB/s)     344 (2976 MB/s)              -984  -74.10%   x 3.86
 chacha8_bench4_16kib   21,184 (773 MB/s)    5,371 (3050 MB/s)         -15,813  -74.65%   x 3.94

Closes #287.

I’m not entirely certain I’ve got the flag/feature/cpuid token stuff right, and would appreciate any guidance about that. At this point the best I’ve got is that it very definitely works on my machine, an M1 Air. Also, no idea how one runs GitHub Actions on a aarch64/NEON platform. QEMU?

This implements an SSE2-based variant of ChaCha20.

I'd also be keen to help adding support for AVX2 and AVX512, but it looks like this may need larger changes (possibly in the salsa20_core crate) to allow for processing multiple blocks simultaneously?

On my machine (early 2016 MacBook, 1.1GHz M3), the SSE2 variant shows a good improvement over the scalar code, speeding up the benchmarks from 260MB/s to 327MB/s.

Aside from the core algorithm, here are some of the things I could use feedback on:

• Gating: I've only implemented compile-time feature detection for now, as that seemed easier. I could potentially add runtime detection as well, if you think that is useful? Additionally, I was considering to pull in cfg-if to simplify the detection logic, but wasn't sure if you wanted to have an additional dependency. Lastly, do we need to be backwards compatible to Rust versions before core::arch got stabilized?

• Facade: I'm currently switching between the two implementations inside the cipher module, but I wonder if there is a better way? Potentially, the block module could become a facade for block/scalar and block/sse2, which would abstract away the fact that there are multiple implementations?

• Testing: I've opted to pregenerate random inputs that I use in the tests, which seemed like an okay approach. I was considering pulling in proptest to essentially randomly test the new variant against the scalar implementation, but I wasn't quite sure if you wanted to have it as a dependency.

Before:

test bench1_10     ... bench:          48 ns/iter (+/- 22) = 208 MB/s
test bench2_100    ... bench:         392 ns/iter (+/- 15) = 255 MB/s
test bench3_1000   ... bench:       4,043 ns/iter (+/- 642) = 247 MB/s
test bench4_10000  ... bench:      38,370 ns/iter (+/- 1,619) = 260 MB/s
test bench5_100000 ... bench:     383,558 ns/iter (+/- 9,745) = 260 MB/s

After:

test bench1_10     ... bench:          40 ns/iter (+/- 3) = 250 MB/s
test bench2_100    ... bench:         317 ns/iter (+/- 20) = 315 MB/s
test bench3_1000   ... bench:       3,082 ns/iter (+/- 117) = 324 MB/s
test bench4_10000  ... bench:      30,681 ns/iter (+/- 808) = 325 MB/s
test bench5_100000 ... bench:     305,280 ns/iter (+/- 14,035) = 327 MB/s

When I provide a certain combination of key, iv and data, I get different results from the openssl and the aes-ctr encryption.

In particular, I used this wrapper:

pub extern crate generic_array;
extern crate crypto;
use aes_ctr::Aes128Ctr;
use aes_ctr::Aes192Ctr;
use aes_ctr::Aes256Ctr;
use aes_ctr::stream_cipher::generic_array::GenericArray;
use aes_ctr::stream_cipher::{
    NewStreamCipher, SyncStreamCipher, SyncStreamCipherSeek
};

use openssl::symm;

use std::fs;

use std::env;

//use crypto::aes::{ctr, KeySize};
//use crypto::symmetriccipher::SynchronousStreamCipher;
use crypto::aes;

use std::vec::from_elem;

fn transform_data(key_size: usize,nonce_size: usize, data: &[u8])
-> Result<(Vec<u8>,Vec<u8>, Vec<u8>),&'static str>
{
    if data.len() < key_size+nonce_size+1 {
        return Err("Data too short");
    }
    let key = data[0..key_size].to_owned();
    let nonce = data[key_size..key_size+nonce_size].to_owned();
    let mut crypto_data = data[key_size+nonce_size..].to_owned();
    Ok((key,nonce,crypto_data))
}

macro_rules! generate_aes_call {
    (128,$key_generic:expr,$nonce_generic:expr) => {
        Aes128Ctr::new(&$key_generic, &$nonce_generic);
    };
    (256,$key_generic:expr,$nonce_generic:expr) => {
        Aes256Ctr::new(&$key_generic, &$nonce_generic);
    }
}

macro_rules! generate_aes_openssl {
    (128) => {
        openssl::symm::Cipher::aes_128_ctr();
    };
    (256) => {
        openssl::symm::Cipher::aes_256_ctr();
    }
}

macro_rules! generate_crypto_aes_call {
    (128,$key:expr,$nonce:expr) => {
        crypto::aes::ctr(crypto::aes::KeySize::KeySize128, $key.as_slice(), $nonce.as_slice());
    };
    (256,$key:expr,$nonce:expr) => {
        crypto::aes::ctr(crypto::aes::KeySize::KeySize256, $key.as_slice(), $nonce.as_slice());
    };
}

fn main(){
    let args: Vec<String> = env::args().collect();
    let data = &fs::read(&args[1]).unwrap();
    let (key, nonce, crypto_data) = match(transform_data((128 / 8), 16, data)){
                Ok((key,nonce,crypto_data)) => (key,nonce,crypto_data),
                Err(err_str) => {println!("Err: {:?}", err_str); return}
            };
    let original_data = crypto_data.to_owned();
    let mut aes_ctr_crypto_data = crypto_data.to_owned();
    let key_generic = GenericArray::from_slice(&key);
    let nonce_generic = GenericArray::from_slice(&nonce);

    let mut cipher = Aes128Ctr::new(&key_generic, &nonce_generic);
    // apply keystream (encrypt)
    cipher.apply_keystream(&mut aes_ctr_crypto_data);
    println!("Keysize: {:?}", 128);
    let openssl_cipher = generate_aes_openssl!(128);
    let openssl_ciphertext = openssl::symm::encrypt(
                        openssl_cipher,
                        &key,
                        Some(&nonce),
                        &original_data).unwrap();
    let mut cipher_crypto_aes = generate_crypto_aes_call!(128,key,nonce);
    let mut output_crypto_aes: Vec<u8> = vec![0; original_data.len()];
    cipher_crypto_aes.process(&original_data, output_crypto_aes.as_mut_slice());
    println!("Key: {:?}",key);
    println!("Nonce: {:?}", nonce);
    println!("Key generic array: {:?}", key_generic);
    println!("Nonce generic array: {:?}", nonce_generic);
    println!("Data:\naes-ctr: {:?}\nopenssl: {:?}\ncrypto::aes: {:?}\noriginal_text: {:?}",aes_ctr_crypto_data,openssl_ciphertext,output_crypto_aes,original_data);
    assert_eq!(output_crypto_aes,openssl_ciphertext,"Opensll and rust::crypto::aes not equal!");
    assert_eq!(crypto_data,openssl_ciphertext, "Openssl and aes_ctr not equal");
    println!("All equal\n");
    // seek to the keystream beginning and apply it again to the `data` (decrypt)
    cipher.seek(0);
    cipher.apply_keystream(&mut aes_ctr_crypto_data);
    assert_eq!(aes_ctr_crypto_data, original_data, "Decrypted data not equal");
}

And caledl it like so: cargo run debug.crash (file is attached), which reveals the following difference in encryption results between openssl and aes-ctr is revealed:

aes-ctr: [108, 253, 73, 159, 41, 43, 94, 79, 15, 121, 128, 186, 135, 246, 194, 87, 210, 245, 143, 26, 252, 148, 40, 251, 221, 123, 151, 112, 198, 148, 194, 86, 112, 124, 212, 82, 16, 202, 32, 36, 21, 69, 127, 56, 201, 111, 252, 108, 123, 166, 116, 191, 155, 79, 254, 41, 214, 68, 210, 96, 235, 239, 143, 101, 236, 141, 110, 227, 88, 157, 94, 39, 237, 104, 244, 167, 255, 124, 114, 238, 9, 185, 155, 13, 123, 34, 248, 104, 110, 165, 81, 34, 14, 84, 153, 97, 166, 34, 52, 106, 75, 253]
openssl: [108, 253, 73, 159, 41, 43, 94, 79, 15, 121, 128, 186, 135, 246, 194, 87, 27, 222, 233, 216, 2, 74, 106, 79, 70, 239, 105, 93, 125, 169, 59, 243, 171, 225, 15, 165, 102, 87, 79, 1, 31, 125, 151, 72, 199, 184, 71, 14, 69, 200, 13, 5, 171, 26, 106, 86, 129, 55, 254, 219, 166, 51, 34, 105, 154, 166, 12, 108, 239, 100, 153, 125, 229, 136, 86, 30, 233, 149, 169, 77, 154, 25, 226, 107, 205, 53, 144, 233, 62, 225, 237, 218, 7, 246, 61, 146, 31, 189, 212, 178, 104, 88]

Oddly enough, if I change the nonce in the file, openssl and aes-ctr produce the same result. Is this a bug or am I misusing the library?

Attached is a zip to easily reproduce this and the input the triggers the difference: poc.zip Run like so:

cd poc/
cargo run debug.crash

...with the criterion-cycles-per-byte plugin

This unfortunately means we can no-longer run tests for chacha20 against Rust 1.27.0, since it adds 2018 edition dev-dependencies. However, we can still confirm release builds against this version work.

As we're starting to reach a microoptimization stage, I think criterion will be extremely helpful in determining if our microoptimizations are actually improving performance.

Currently I'm getting between 5.1 - 5.8 cpb across the tests on a Kaby Lake i7. Curiously -Ctarget-cpu=native seems to negatively impact performance. I'm not seeing much difference between the software and SSE2 backends: +5% on the chacha20/apply_keystream/1024 benchmark, negligible on the others (i.e. +1-2%)

There are several constructions based on stream ciphers that use a 32-bit counter:

• AES-GCM
• AES-GCM-SIV
• ChaCha20Poly1305 (IETF version, but we can implement the "legacy" version with one too)

I was thinking it would be interesting to have a Ctr32 type which is generic around the block size. If so, I could impl the ChaCha20 and Salsa20 core functions as a sort of 512-bit wide pseudo-BlockCipher, which would let us have reusable stream cipher buffer management and seeking across all three of the aforementioned ciphers. Note that pulling this off would also need for it to be generic around endianness, as I believe AES-GCM needs a big endian counter and AES-GCM-SIV and ChaCha20Poly1305 need a little endian counter.

If we had that, it would also eliminate the need for the salsa20-core crate, or rather, we could merge it into the salsa20 crate.

Notably right now the only other ctr type, Ctr128, is specialized to a 128-bit block size. This actually seems ok to me, as it seems rather unusual to use a 128-bit counter with anything other than a 128-bit block size.

This migrates the tests used by the chacha20 crate to use the new_sync_test! macro.

The "core" tests are now passing, however it appears the existing seeking implementation is broken:

    running 5 tests
    test chacha20_offsets ... ignored
    test chacha20_legacy_seek ... FAILED
    test chacha20_seek ... FAILED
    test chacha20_core ... ok
    test chacha20_legacy_core ... ok

    failures:

    ---- chacha20_legacy_seek stdout ----
    thread 'chacha20_legacy_seek' panicked at 'slice index starts at 65 but ends at 64', src/libcore/slice/mod.rs:2575:5

Now that the bug is captured, I think I have an idea of an interesting way to fix it...

This uses a CI config more like the one at:

https://github.com/RustCrypt/signatures

It runs all tests with the --release flag to ensure that crates aren't broken by release-dependent functionality after being tested in debug mode (we can add back debug mode testing if it's helpful, but it doesn't look like we have anything presently gated on debug builds). I now see @newpavlov also requested it on #20.

It also tests on a no_std platform (thumbv7) which @newpavlov requested in #18.

Finally, it tests with --all-features. This should uncover some lingering breakages (it won't in this commit, but it appears some of the conditional compilation is incorrectly gated and I intend to fix it in a follow-up commit).

See: https://github.com/RustCrypto/stream-ciphers/runs/7970722385?check_suite_focus=true#step:8:28

It occurred running the integration tests in the autodetect CI job for this dependabot PR to bump cpufeatures from 0.2.3 to 0.2.4, so that's possibly implicated: https://github.com/RustCrypto/stream-ciphers/pull/303

cc @newpavlov @str4d

We switch to a 4-block buffer for the combined SSE2 / AVX2 backend, which allows the AVX2 backend to process them together, while the SSE2 backend continues to process one block at a time.

The AVX2 backend is refactored to enable interleaving the instructions per pair of blocks, for better ILP.

Closes #262.

#219 This implementation of HC-128 does not yet have the test vectors. HC-256 was using a table size of 2660 instead of 2560, this does not cause issue with the generated key stream, but slightly lengthens the initialization time. The function h2 in HC-256 used self.ptable instead of self.qtable, this means that it does not apply linear masking when the stream is using h2. For inputs that never get output from h2 it gives the correct results, but once h2 is in use the values are incorrect.

There are two big optimizations we could do on both the chacha20 and salsa20 crates.

Avoid recomputing initial state

EDIT: both crates now have a new method to compute the initial state, and separate apply_keystream / generate methods to compute a block

• [x] chacha20 crate
• [x] salsa20 crate

RFC 8439 Section 3 describes caching the initial block state once computed as a performance optimization:

   Each block of ChaCha20 involves 16 move operations and one increment
   operation for loading the state, 80 each of XOR, addition and roll
   operations for the rounds, 16 more add operations and 16 XOR
   operations for protecting the plaintext.  Section 2.3 describes the
   ChaCha block function as "adding the original input words".  This
   implies that before starting the rounds on the ChaCha state, we copy
   it aside, only to add it in later.  This is correct, but we can save
   a few operations if we instead copy the state and do the work on the
   copy.  This way, for the next block you don't need to recreate the
   state, but only to increment the block counter.  This saves
   approximately 5.5% of the cycles.

SIMD support

Both ChaCha20 and Salsa20 are amenable to SIMD optimizations. We should add SIMD optimizations on x86/x86_64 at the very least.

x86/x86_64

• chacha20
  • [x] SSE2 (#61)
  • [x] AVX2 (#83, #87)
• [ ] salsa20
  • [ ] SSE2
  • [ ] AVX2

Other CPU architectures

• ARM?