John Jiang
John Jiang
目前看，主要是s_server不支持设定多个主机证书，但s_client可以指定server name。
为什么要尝试别的cipher suite？ CertificateVerify验证与密码套件没有关系吧，是与signature scheme有关。 换了密码套件，还是得失败。
现在看，应该主要是最后那段信息比较误导人。 ``` New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256 Server public key is 256 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent...
既然连接失败了，是不是就不应该显示上面那段信息了？
如果不使用`-groups`或`-curves`，由s_client生成的`ClientHello`中的`supported_groups`扩展中并没有包含SM2的曲线。 ``` extension_type=supported_groups(10), length=12 ecdh_x25519 (29) secp256r1 (P-256) (23) ecdh_x448 (30) secp521r1 (P-521) (25) secp384r1 (P-384) (24) ``` 这是否说明，`TASSL`还不能支持基于`curveSM2`的`ECDHE`密钥交换算法？ 或者，只是`s_server`/`s_client`这两个工具不支持？
我是在测试RFC 8998。 > 这两个套件签名算法默认使用SM2_SM3 ``` CipherSuite TLS_SM4_GCM_SM3 = { 0x00, 0xC6 }; CipherSuite TLS_SM4_CCM_SM3 = { 0x00, 0xC7 }; ``` 根据`TLS 1.3`的规范，应该不能认为上述两个国密套件就必须与签名机制`sm2sig_sm3`绑定在一起。 它们可以与其它的签名机制，如`ecdsa_secp256r1_sha256`，共同工作。`TASSL`好像也是支持这种组合的。 > 密钥协商算法使用的标准EC，都没有用到这个id，所以我们的实现中没有加。 https://datatracker.ietf.org/doc/html/rfc8998#section-2 ``` * The SM2...
@lovelxc > 我所知的密码学程序验证手段（非协议级别而是具体到实现程序）就是 fuzzing test 以及提取中间语言进行形式化验证 你能否了解到有针对国密的fuzzing test？ 关于“提取中间语言进行形式化验证”，你是否指的像CodeQL这类的工具？
刚才试了一下，看起来是支持的 ``` $ tongsuo genpkey -algorithm ec -pkeyopt ec_paramgen_curve:SM2 -pkeyopt ec_param_enc:named_curve -out test.key $ tongsuo req -new -key test.key -subj "/CN=test" -sm3 -out test.csr $ tongsuo x509 -req -CAcreateserial -in...
但进一步，查看生成的PKCS#12文件，有如下内容， ``` $ tongsuo pkcs12 -info -in test.p12 -password pass:testpassword MAC: sm3, Iteration 2048 MAC length: 32, salt length: 8 PKCS7 Encrypted data: PBES2, PBKDF2, SM4-CBC, Iteration 2048, PRF hmacWithSHA256...