w-naf can effectively reduce the time consumption of point multiplication. In sm2, we set the width of the window to 5, and the except time consumption is 50A+257D where the origin time consumption is 128A+256D.

我尝试为sm2算法中的ecc.rs代码内，为测试test_add_double_neg增加以下测试，该测试希望验证点加法和点倍增的结果是否相同：

        let double_g = curve.double(&g);  //  2 * g
        let add_g = curve.add(&g,&g);     // g + g
        assert!(curve.eq(&add_g,&double_g));

但是测试结果告诉我没有通过测试：

thread 'sm2::ecc::tests::test_add_double_neg' panicked at 'assertion failed: curve.eq(&add_g, &double_g)', src\sm2\ecc.rs:595:

~~查看了一下实现点加法和点倍增的算法，发现算法和我之前学习的算法有所出入。例如，点倍增算法中引入了参数a：~~ ~~而论文中实现点倍增并没有参数a的参与（雅可比坐标系下）~~ 经过学习，了解到此处点倍增利用的似乎是dbl-1998-cmo-2中的方法，抱歉。点加法似乎是使用了add-2007-bl中的算法？

想请问点加法和点倍增计算结果为何不一致的原因，以及计算点加法和点乘法时使用到的算法名称。个人水平有限，难免在理解上会出现错误，烦请多多指教

The point add(PA) and point double(PD) algorithms in libsm are named add-1998-cmo and double-1998-cmo. The time consume of these algorithmS are 10M + 5S + 4cubic = 23M and 3M + 3S + 2^4 = 12M . According to website https://www.hyperelliptic.org/EFD/g1p/auto-shortw-jacobian.html#addition-add-1998-cmo-2, the fastest PA and PD named add-1998-cmo-2 and double-1998-cmo-2 only need 16M and 9M.

After replacing new algorithms, the time consume of PA and PD decreased by 35% and 15% respectively. I use criterion to compare the speed before and after the improvement. It must be noted that the optimization efficiency will be different when PA and PD calculate different points

PA:

Ecc add time: [1.3219 us 1.3611 us 1.4074 us]
change: [-47.407% -45.710% -43.853%] (p = 0.00 < 0.05) Performance has improved.

Test code:

fn ecc_add(c: &mut Criterion) {
    let curve = EccCtx::new();
    let g = curve.generator();
    let neg_g = curve.neg(&g);
    let double_g = curve.double(&g);
    c.bench_function("Ecc old add ", move |b| {
        b.iter(|| curve.add(&double_g, &neg_g));
    });
}

PD:

Ecc double time: [1.1666 us 1.1969 us 1.2322 us]
change: [-19.976% -18.640% -16.936%] (p = 0.00 < 0.05) Performance has improved.

Test code:

fn ecc_double(c: &mut Criterion) {
    let curve = EccCtx::new();
    let g = curve.generator();

    c.bench_function("Ecc double ", move |b| {
        b.iter(|| curve.double(&g));
    });
}

https://github.com/citahub/libsm/blob/3ead619a180deb93474634584791b02561ca9a70/src/sm2/encrypt.rs#L142-L153

如上代码示例， 加解密时 klen 为要加密码信息的长度，我尝试使用固定值（E.g. 1024）会报错。 由于加密与解密可能在不同流程中使用，加密时可以知道原始数据的长度，但解密时只有密文，无法获取到原始数据的长度。请问要如何处理？

The implementation of SM2 public key encryption, decryption algorithm and key exchange protocol is mainly finished here.

Additional usage has been written in doc, in which the markdown format is also optimized for syntax highlighting in rust code.

However, my test cases may not be exhaustive enough to cover all situations. Hope my code can be well-reviewed, and any suggestions are welcomed.

First. I created a private key and return hex.

let ctx = SigCtx::new();
let (pk, sk) = ctx.new_keypair();
format!("0x{}", hex::encode(sk.to_bytes_be()))
// 0x11a8571fe8ee79990db44379aac8d67606a783ac73f52113d563dce7f38fdf

Next, the data is signed with the private key

let ctx = SigCtx::new();
let privk = hex::decode("0x11a8571fe8ee79990db44379aac8d67606a783ac73f52113d563dce7f38fdf")
let sk = ctx.load_seckey(&privk).unwrap();
// this painic. result returns Err(true)

The length of a valid private key that doesn't include 0x should be 64, it's only 62.

version: git commit 5cc6f4d251456347f17ad836a00c8248c3563cbf rust: rustc 1.31.0-nightly (8c4ad4e9e 2018-10-04)

In the original code, the g_mul function pre-computes 512 values and then uses these values to calculate base_point multiplication, which requires 31 point additions and 16 point double.

Inspired by #37, I think we can extend the precomputation table to accelerate g_mul operation. In the new model we have designed, the precomputed table has a total of 256*32 = 8192 items. When calculating the gmul calculation, we slice the BigUint k into 32 pieces k0-k31 and then call the precomputed table to get their multiplication with G. Finally, the 31 results are added together to obtain the final result.

In the new model, 16 point double operations have been removed, which can improve the speed of gmul. I write a bench function to compare two functions:

test sm2::ecc::internal_benches::bench_gmul_new ... bench: 58,823 ns/iter (+/- 9,798) test sm2::ecc::internal_benches::bench_gmul_old ... bench: 86,592 ns/iter (+/- 13,441)

However, the ability to save precomputed results to a file is not yet available. Hope my code can be well-reviewed, and I will add more commit to implement it.

#[cfg(test)]
mod tests {
    use super::Sm2Error;

    #[test]
    fn test_debug() {
        let e = Sm2Error::InvalidPublic;
        println!("{:?}", e); // thread 'sm2::error::tests::test_debug' has overflowed its stack
    }
}

This is because {:?} will call the Debug impl itself.

impl ::std::fmt::Debug for Sm2Error {
    fn fmt(&self, f: &mut Formatter<'_>) -> ::std::fmt::Result {
        write!(f, "{:?}", self)
    }
}

i see the test code for encode and decode like this

#[test]
    fn test_sig_encode_and_decode() {
        let string = String::from("abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd");
        let msg = string.as_bytes();

        let ctx = SigCtx::new();
        let (pk, sk) = ctx.new_keypair();

        let signature = ctx.sign(msg, &sk, &pk);
        let der = signature.der_encode();
        let sig = Signature::der_decode(&der[..]).unwrap();
        assert!(ctx.verify(msg, &pk, &sig));

        let signature = ctx.sign(msg, &sk, &pk);
        let der = signature.der_encode();
        let sig = Signature::der_decode_raw(&der[2..]).unwrap();
        assert!(ctx.verify(msg, &pk, &sig));
    }

but i need a methods to encrypt plaintext.

The new w-naf point_mul method has been tested and merged in #30 , so the old method can be removed now.

Modify bench function error because of the interface change in #41 .

For the BigUint , the shift right operation (>>) takes only 25% of the time of the division operation, and replacing the right shift operation with the division operation can effectively improve the speed of calculating the multiplication inverse.

You can use this crates in WebAssembly. Currently, you only need to add dependencies:

# Cargo.toml
getrandom = { version = "^0.2", features = ["js"] }

See getrandom#WebAssembly support. But it still needs improvement for the first time #47

pr #45 and issues #37 both mention that loading gmul_table from disk is an elegant way. In this pr, I modify the g_table function, introduced Serde crate to serialize the table, and store it in the file gmul_table. When the gmul function needs to use g_table, it can easily load the file and deserialize it as a table struct.

Benchmark tests have found that the performance improvement of the gmul function using the load approach is not significant (about 2-5%), probably because a large number of gmul operations amortizes the precomputed gtable time. In any case, loading gtable from the hard disk is effective in reducing warming time, and the loading time is nearly zero( 300mb/s for serde deserialize procedure)

Hope my code can be well-reviewed, and I will add more commit to implement it.

Test result:

test sm2::ecc::internal_benches::bench_gmul ... bench: 50,762 ns/iter (+/- 791) test sm2::ecc::internal_benches::bench_gmul_load ... bench: 48,357 ns/iter (+/- 1,143)

pub fn decrypt(&self, cipher: &[u8]) -> Sm2Result<Vec<u8>> 方法

转 c_1_point 时，如果遇到异常能否“透传”出来？ 最好 let c_1_point = self.curve.bytes_to_point(c_1_bytes).unwrap(); 这里可以不要直接 unwrap()， 能把这里的异常也 return 出来。

现在，这里面的 Sm2Error::InvalidPublic Sm2Error::NotOnCurve 等，外层好像没法处理。