yogcrypt/yogcrypt

A fast, general purpose crypto library in pure Rust.

YogCrypt

A fast, general purpose crypto library in pure Rust.

YogCrypt is designed to be a high-performance, general purpose crypto library.

YogCrypt currently provides three cryptographic algorithms in Chinese National Standard, namely the SM2 cryptographic asymmetric algorithm, the SM3 cryptographic hash algorithm, and the SM4 block cipher algorithm.

Contributing

YogCrypt is maintained by @liuwenling, @Messjer, @romangol, and @mssun. Please see CONTRIBUTING.md for more information.

License

YogCrypt is distributed under the terms of both the MIT license and the Apache License (Version 2.0).

See LICENSE-APACHE and LICENSE-MIT for details.

yogcrypt's Issues

Improve readme

The REAME.md file is extremely simple. We should include more information such as: introduction, roadmap, usage, performance stats, license.

Make `U64x4` and `U64x8` struct consistent with SIMD's version

How about this?

pub struct U64x4 {
     pub value: [u64; 4],
 }

pub struct U64x8 {
    pub value: [u64; 8],
}

===>

pub struct U64x4(u64, u64, u64, u64);
pub struct U64x8(u64, u64, u64, u64, u64, u64, u64, u64);

These are consistent with Rust SIMD's definition.

• u64x4: https://doc.rust-lang.org/std/simd/struct.u64x4.html
• u64x8: https://doc.rust-lang.org/std/simd/struct.u64x8.html

Support `#![no_std]`

It's reasonable to provide the crypto library as a "no std" library.

Improve testcases

Current test cases are very simple and do not cover corner cases. We can improve this situation by:

• using doc tests
• add more unit tests

Improve API of `sm3`

The current API of sm3 requires users to explicitly provide message length. This might lead to potential misuses. For example, the following code wrongly computes the digest (due to incorrect length input) without informing the user.

        let msg = [0x61_626300u32];

        let hash = sm3_enc(&msg, 512);
        // this assertion fails
        assert_eq!(
            hash,
            [
                0x66c7f0f4, 0x62eeedd9, 0xd1f2d46b, 0xdc10e4e2, 0x4167c487, 0x5cf2f7a2, 0x297da02b,
                0x8f4ba8e0
            ]
        );

Another problem of the API is that it awkwardly requires user to pad the message with 0's to fit in the u32 blocks, which is error-prone. For example, the following code gives the digest of 0x0061_6263 instead of 0x6162_63.

        let msg = [0x61_6263u32];

        let hash = sm3_enc(&msg, 24);
        // this assertion fails
        assert_eq!(
            hash,
            [
                0x66c7f0f4, 0x62eeedd9, 0xd1f2d46b, 0xdc10e4e2, 0x4167c487, 0x5cf2f7a2, 0x297da02b,
                0x8f4ba8e0
            ]
        );

One possible fix could be to modify the API so that it accepts a string as input, then after manually finding the length, this wrapper function may split the string into &[u32] for use of the core functions.

Unit tests are too general

Unit tests should be more specific. It is a good practice to test a specific case for one unit test, instead of test all together.

For example, this test just randomly tests. We should point out what this unit test is designed for.

yogcrypt/src/sm2/mod.rs

Lines 201 to 215 in 2702f0b

	#[test]
	fn test() {
	for _ in 0..10000 {
	let d_a = rand_u64x4();
	let msg = [0x01234567, 0x89ABCDEF, 0xFEDCBA98, 0x76543210];
	let q = get_pub_key(d_a);
	let mut m = sm2_gen_sign(&msg, d_a, q, 4);
	let t = sm2_ver_sign(&msg, q, 4, m.0, m.1);
	assert!(t);
	}
	}

Also, we can consider doc test later. (but that's another story)

Consider using SIMD primitives to accelerate computation

Since the basics of SIMD has arrived in Rust 1.27 stable: https://blog.rust-lang.org/2018/06/21/Rust-1.27.html#simd, we should consider to replace our basic::cell::U64x4 with std::simd::u64x4. Although std::simd is still in nightly, I think it will be stabilized very quickly.

Pros:

• SIMD is fast
• it also in the core library which means "no-std
• it provides handful APIs, and we don't have to maintain these by ourselves

Cons:

• still not stabilized, we should use nightly Rust to compile
• not sure it's compatibility
• we should rewrite some code

Add API: U64x4::random(), FieldElement::random()

This can help use to simply code. E.g.,

    let mut k = U64x4::new(
        random::<u64>(),
        random::<u64>(),
        random::<u64>(),
        random::<u64>(),
    );
    while greater_equal(k, MODULO_P) {
        k = U64x4::new(
            random::<u64>(),
            random::<u64>(),
            random::<u64>(),
            random::<u64>(),
        );
    }

====>

    let mut k = U64x4::random();
    while greater_equal(k, MODULO_P) {
        k = U64x4::random();
    }

This is used in a lot of places including sources and tests.

Only make nescessary functions/structs public

We need to think about what should be public and what are not.

Use the criterion crate for benchmarking intead of test::Bencher

I found that the criterion crate is a good replacement for the test Bencher.

• it doesn't require Rust nightly
• it supports more benchmark customization
• even, it can draw graph
• etc

Also, the curve25519-dalek project uses it too, which means that this crate can be used as a benchmark util for crypto library.

Reference:

• https://github.com/japaric/criterion.rs
• https://github.com/dalek-cryptography/curve25519-dalek/blob/develop/benches/dalek_benchmarks.rs

Make functions of `U64x4` and `U64x8` consistent

The new functions of U64x4 and U64x8 are not consistent:

This is U64x4 .

     pub fn new(x0: u64, x1: u64, x2: u64, x3: u64) -> Self {
         Self {
             value: [x0, x1, x2, x3],
         }
     }

     pub fn from_u32(x: [u32; 8]) -> Self {
         Self {
             value: [
                 (u64::from(x[1]) << 32) + u64::from(x[0]),
                 (u64::from(x[3]) << 32) + u64::from(x[2]),
                 (u64::from(x[5]) << 32) + u64::from(x[4]),
                 (u64::from(x[7]) << 32) + u64::from(x[6]),
             ],
         }
     }

This is U64x8 .

impl U64x8 {
    pub fn new(x: [u64; 8]) -> Self {
        Self { value: x }
    }
}

Continuous Integration (CI) for building/testing/fmt/clippy

We can use Travis CI for building/testing/fmt/clippy to ensure the quality of the code.

Improve documentation

There no documentation for any APIs. Consider write extensive documentation, doc test, etc.

The curve25519_dalek project (https://doc.dalek.rs/curve25519_dalek/) is a good example.

Accept user-defined ID input in sm2

The computation of z in sm2/mod.rs assumes some fixed user ID. I believe this is not in accordance to the standard of sm2 and so we need modification.

fn get_z(q: PubKey) -> [u32; 8] {
    let _len: usize = 2 + 14 + 6 * 32;
    let mut s: [u32; 52] = [0; 52];

    s[0] = 0x00D00102;
    s[1] = 0x03040506;
    s[2] = 0x0708090A;
    s[3] = 0x0B0C0D0E;
    ...
}

E.g., in the example shown in the document, ID is [email protected](in hex 414C 49434531 32334059 41484F4F 2E434F4D).

Reference

• sm2 standard