A new crypto library

LuoZijun · November 11, 2020, 12:37pm

Why is a trusted, feature-complete crypto library not a top priority for the Rust community?

I read this article a long time ago, and unfortunately the Rust community still doesn't have a good solution today.

A few months ago, I wrote this crypto library, and it supported all AEAD crypto-algorithms. And both the X86 and ARM64 platforms have good performance.

Currently, there is no official release, and you can find the code here: https://github.com/shadowsocks/crypto

Compare performance with Ring, OpenSSL, RustCrypto, Crypto: https://github.com/LuoZijun/crypto-bench

H2CO3 · November 11, 2020, 1:37pm

What does "feature-complete" mean for you? I wouldn't say that good crypto libraries are "not a priority" for the community. Maybe most people don't use crypto in the same context as you do. For example, I usually want crypto for the communication between my smartphone apps and server backends – for that, I've found libsodium and sodiumoxide to be the go-to solution, as it's an audited, cross-platform library with bindings to several other laguages.

bascule · November 11, 2020, 6:22pm

FYI, there are already two projects called "Rust Crypto":

The original https://crates.io/crates/rust-crypto crate
The GitHub organization: https://github.com/RustCrypto (disclosure: I'm a maintainer for it)

It'd be quite confusing if there were a third.

As far as an omnibus crate like this goes, ring is both mature and widely used within the Rust ecosystem.

I took a quick look at the source code to your crate. It seems to contain a copy-and-paste version of my zeroize crate without acknowledgement, rather than using the upstream crate. I'm not sure why it doesn't just use the upstream crate?

The AES implementation is based on lookup tables:

github.com

shadowsocks/crypto/blob/master/src/blockcipher/aes/generic.rs#L302-L333


#[allow(dead_code)]
#[inline]
fn sub_word(x: u32) -> u32 {
    // SubWord([b0, b1, b2, b3]) = [ SubByte(b0), SubByte(b1), SubByte(b2), SubByte(b3) ]
    let mut bytes = x.to_le_bytes();
    bytes[0] = FORWARD_S_BOX[bytes[0] as usize];
    bytes[1] = FORWARD_S_BOX[bytes[1] as usize];
    bytes[2] = FORWARD_S_BOX[bytes[2] as usize];
    bytes[3] = FORWARD_S_BOX[bytes[3] as usize];
    u32::from_le_bytes(bytes)
}

#[inline]
fn sub_bytes(state: &mut [u8]) {
    debug_assert_eq!(state.len(), AES_BLOCK_LEN);

    state[0]  = FORWARD_S_BOX[state[0] as usize];
    state[1]  = FORWARD_S_BOX[state[1] as usize];
    state[2]  = FORWARD_S_BOX[state[2] as usize];
    state[3]  = FORWARD_S_BOX[state[3] as usize];

This file has been truncated. show original

This is widely recognized as problematic due to cache timing attacks and other microarchitecture sidechannels. See for example:

LuoZijun · November 11, 2020, 2:02pm

This means that there is good support for popular and some not so popular crypto algorithms.

For example, you mentioned the libsodium project, which only supports AES-GCM and Chacha20-Poly1305. It does not support other crypto-algorithms such as Camellia, Aria, AES-CCM, AES-GCM-SIV.

In the real world, some services are beyond your control, such as some HTTPS sites that use cipher suites that aren't so popular or even have weaknesses. If you use libraries like rustls built on top of ring, you won't be able to connect to those HTTPS services.

Finally, I agree that a strict code security audit is required for a cryptographic library.

LuoZijun · November 11, 2020, 2:05pm

I know that problem. But I don't want to make some changes to that, because the existing hardware already supports AES instructions, so in X86 and ARM64, the code for AES-NI is actually used, not a software implementation.

LuoZijun · November 11, 2020, 2:11pm

Yes, the code for 'zeroize' comes from 'zeroize' crate. But because I personally dislike Procedural Macros.

So I decided to make a copy. If you don't want to, I can delete the code.

bascule · November 11, 2020, 6:22pm

The proc macros are disabled by default, and only included if you enable the zeroize_derive feature.

I would appreciate you using the upstream crate or at least crediting the vendored code, including the original copyright information.

It would be better if you didn't include code with known vulnerabilities, rather than providing an insecure fallback.