商用密码应用安全性评估——openHiTLS初识

admin
admin
admin
0
文章
0
评论
2026-07-03 05:34:54 网络安全文章 来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文介绍商用密码应用安全性评估(密评)的困境与openHiTLS开源密码套件的解决方案。openHiTLS由华为等15家单位联合开源，采用模块化架构支持国密算法(SM2/SM3/SM4)和TLCP/DTLCP协议，通过形式化验证和ISO19790认证保障安全性。文章还提供了openhitls-0.3分支在KaliLinux上的编译与TLCP通信实操步骤，为密评建设提供可落地的开源密码产品选型方案。 综合评分： 85 文章分类： 安全建设,解决方案,技术标准,安全工具

cover_image

商用密码应用安全性评估——openHiTLS初识

原创

利刃信安 利刃信安

利刃信安

2026年7月2日 20:00 北京

在小说阅读器读本章

去阅读

商用密码应用安全性评估——openHiTLS初识

摘要

随着《密码法》《商用密码管理条例》等法规落地，商用密码应用安全性评估（简称”密评”）已成为政企信息系统合规的刚性门槛。然而，密评整改过程中，”密码产品选型封闭、算法切换成本高、自研密码模块安全性难以验证”三大痛点始终困扰从业者。openHiTLS作为业界首款面向全场景的开源密码套件，通过模块化架构、国密全栈支持和形式化验证能力，为密评建设提供了全新解题思路。

一、密评困境与openHiTLS破局

密评的核心要求可归纳为四点：密码算法合规、密码协议合规、密码产品合规、密钥管理合规。在实际落地中，常见困境包括：

  • • 选型受限：商用密码产品多为闭源交付，用户无法审查底层实现，与密评”自主可控”导向存在张力。
  • • 迁移困难：从国际算法（RSA/AES）向国密算法（SM2/SM4）迁移时，应用层需大幅改造，接口不兼容。
  • • 验证成本高：自研密码模块要分别通过功能正确性、侧信道安全性等多维度验证，中小企业难以负担。

一套算法丰富、接口统一、安全可验证的开源密码套件，是破解上述困局的可行路径。

2024年12月，由华为、西安电子科技大学、山东大学等15家单位联合宣布openHiTLS正式开源，定位为面向全场景数智安全、独立创新的开源密码套件。它由五个松耦合组件构成：

| 组件 | 职责 | 密评关联度 | | — | — | — | | Crypto | 密码算法库（国密/国际/PQC） | ★★★★★ | | TLS | 安全传输协议（TLS 1.2/1.3/TLCP/DTLCP） | ★★★★★ | | PKI | 公钥基础设施（证书解析、验证、CRL管理） | ★★★★ | | Auth | 认证协议（Privacy Pass/SPAKE2+等） | ★★★ | | BSL | 基础支撑层（内存管理、错误栈、平台抽象等） | ★★ |

组件高度解耦，可按需裁剪——单算法场景可精简至不足10KB，这意味着它既能跑在云服务器上，也能嵌入物联网终端设备。

二、国密全栈：算法、协议与安全验证

密评最核心的诉求是密码算法和协议必须采用国家标准，openHiTLS的覆盖全面：

算法层面：

  • • SM2：椭圆曲线公钥密码算法（GB/T 32918），支持加解密、签名验签、密钥交换
  • • SM3：密码杂凑算法（GB/T 32905），支持完整性校验和HMAC
  • • SM4：分组密码算法（GB/T 32907），支持CBC/GCM/CTR/CFB/OFB/XTS等多种工作模式

协议层面：

  • • TLCP（GB/T 38636-2020）：国密传输层密码协议，基于SM2双证书体系（签名证书+加密证书）
  • • DTLCP（GM/T 0128-2023）：数据报传输层国密协议，UDP承载的TLCP

同时支持国际算法（AES、RSA、ECDSA、Ed25519、X25519）和后量子算法（ML-KEM、ML-DSA，需编译时启用），一套代码即可覆盖国密+国际+抗量子三套密码体系。

丰富算法之外，密评对密码模块的安全性同样有硬性要求（参考GB/T 39786），openHiTLS提供了多层次安全保障：

  • • KAT测试（Known Answer Test）：确保密码算法实现的数学正确性
  • • 形式化验证：对核心算法进行数学证明级别的正确性验证
  • • 侧信道防护：对时序/功耗/电磁泄漏等侧信道攻击实现有效防护
  • • FUZZ测试：通过模糊测试发现边界条件与内存安全问题
  • • ISO 19790认证：与国际认证机构（DEKRA、SGS、BSI等）共建认证生态

目前openHiTLS已通过ISO 19790密码模块认证，在密评场景中可以作为合规的密码模块引入。

三、编译与集成：openhitls-0.3 分支实测流程

版本说明：以下流程基于实测验证可用的 openhitls-0.3 分支（HEAD: ab0d11e1）。本构建环境为 Kali Linux x86_64，GCC 15.3.0 / CMake 4.3.4 / Python 3.13.14。

3.1 环境准备

# Ubuntu/Debian/Kali
sudo apt update && sudo apt install -y cmake gcc make python3 git tcpdump

# 确认版本（本手册实测版本如下，非强制最低要求）
gcc --version     # 实测: gcc 15.3.0
cmake --version   # 实测: cmake 4.3.4
python3 --version # 实测: Python 3.13.14

3.2 获取源码

# 1. 克隆仓库
git clone -b openhitls-0.3 https://gitcode.com/openHiTLS/openhitls
cd openhitls

# 2. 确认版本（关键：HEAD 必须是 ab0d11e1，含 -noverify 修复）
git log --oneline -3
# ab0d11e1 fix:The command line parameter "noverify" has been added to app_server.c
# 0b41641b fix: harden file permissions for sensitive data and add input validation
# 33d9b653 Fix the issue where the failure branch of ReferencesInit does not reinitialize references

# 3. 核对分支
git branch -vv
# * openhitls-0.3 ab0d11e1 [origin/openhitls-0.3] ...

3.3 使用 configure.py 生成 CMake 工程

configure.py 自动完成 Secure_C 安全库编译（39个C文件→libboundscheck.a），无需手动编译。

cd /home/kali/M/openhitls

python3 configure.py \
    --system linux --bits 64 --asm_type x8664 \
    --build_dir build --output_dir build \
    --enable all --executes \
    --add_options="-DHITLS_TLS_PROTO_TLCP11 -DHITLS_TLS_SUITE_ECDHE_SM4_CBC_SM3 -DHITLS_TLS_SUITE_ECC_SM4_CBC_SM3 -DHITLS_TLS_SUITE_ECDHE_SM4_GCM_SM3 -DHITLS_TLS_SUITE_ECC_SM4_GCM_SM3 -DHITLS_CRYPTO_PROVIDER_DEFAULT_SM -DHITLS_TLS_SUITE_AUTH_SM2"

密钥参数说明:

  • • --enable all --executes: 启用所有非国密模块并编译hitls命令行工具
  • • --build_dir build --output_dir build: 编译输出到build/目录
  • • --add_options: 额外传递7个国密编译宏（国密模块不在--enable all范围内，必须显式启用）

configure.py 内部执行流程:

1. 检查 Secure_C 依赖 → 未找到 → 自动编译 39 个 securec C 文件 → libboundscheck.a
2. 生成 feature_config.json（各模块 C/ASM 源文件清单）
3. 生成 compile_config.json（-D 宏定义和链接参数）
4. 生成 CMake 辅助模块文件

3.4 CMake 配置 + 编译

cd build
cmake -DCMAKE_BUILD_TYPE=Debug ..
make -j$(nproc)

编译耗时约 2-3 分钟（8核）。SM3/SM4 使用 x86-64 汇编优化（.s 文件）。

3.5 产物验证

$ file hitls
hitls: ELF 64-bit LSB pie executable, x86-64, dynamically linked,
       with debug_info, not stripped

$ ldd hitls
    libhitls_tls.so => .../build/libhitls_tls.so
    libhitls_crypto.so => .../build/libhitls_crypto.so
    libhitls_pki.so => .../build/libhitls_pki.so
    libhitls_bsl.so => .../build/libhitls_bsl.so

$ ls -lh libhitls_*.so hitls
-rw-r--r-- ... libhitls_bsl.so     934K
-rw-r--r-- ... libhitls_crypto.so  6.3M  ← 含 SM2/SM3/SM4 汇编优化
-rw-r--r-- ... libhitls_pki.so     1.0M
-rw-r--r-- ... libhitls_tls.so     5.7M
-rwxr-xr-x ... hitls               906K

3.6 环境变量

# 每个运行 hitls 的终端必须先执行
export LD_LIBRARY_PATH=/home/kali/M/openhitls/build:$LD_LIBRARY_PATH

# 验证
hitls help

3.7 编译宏说明

| # | 编译宏 | 作用 | 必须? | | — | — | — | — | | 1 | HITLS_TLS_PROTO_TLCP11 | 启用 TLCP v1.1 协议栈（含 DTLCP over UDP） | 是 | | 2 | HITLS_TLS_SUITE_ECDHE_SM4_CBC_SM3 | 注册 ECDHE_SM4_CBC_SM3 密码套件 | 是 | | 3 | HITLS_TLS_SUITE_ECC_SM4_CBC_SM3 | 注册 ECC_SM4_CBC_SM3 密码套件 | 是 | | 4 | HITLS_CRYPTO_PROVIDER_DEFAULT_SM | 将 SM2/SM3/SM4 加载到默认 Provider（必要条件） | 是 | | 5 | HITLS_TLS_SUITE_AUTH_SM2 | 启用 SM2 证书身份认证 | 是 | | 6 | HITLS_TLS_SUITE_ECDHE_SM4_GCM_SM3 | 注册 ECDHE_SM4_GCM_SM3（备用） | 否 | | 7 | HITLS_TLS_SUITE_ECC_SM4_GCM_SM3 | 注册 ECC_SM4_GCM_SM3（备用） | 否 |

关键: 宏 #1~#5 是 TLCP/DTLCP 工作的充分必要条件。--enable all 仅启用非国密模块，国密必须通过这5个核心宏显式启用。

四、实操：使用 hitls CLI 完成 TLCP/DTLCP 通信

以下命令基于 openhitls-0.3 分支 (ab0d11e1) 编译产物，使用源码内置的 SM2 测试证书。

注意：①本文所有操作均使用最新编译的 hitls 命令行工具。②必须指定 -cipher 参数明确选择密码套件，否则可能使用错误默认值导致握手失败。

4.1 测试证书说明

路径: /home/kali/M/openhitls/testcode/testdata/tls/certificate/der/sm2_with_userid/

实际文件清单（ls -lh 实测）:

| 文件 | 大小 | 格式 | 用途 | | — | — | — | — | | ca.crt | 843B | PEM | CA根证书 | | inter.crt | 794B | PEM | 中间CA证书（证书链第二级） | | sign.crt | 2.2KB | x509文本转储 + PEM | TLCP签名证书 | | sign.key | 316B | EC PARAMETERS + PRIVATE KEY (PEM) | TLCP签名私钥 | | sign.der | 534B | 纯二进制DER | 签名证书（供cert callback使用） | | enc.crt | 2.2KB | x509文本转储 + PEM | TLCP加密证书 | | enc.key | 316B | EC PARAMETERS + PRIVATE KEY (PEM) | TLCP加密私钥 | | enc.der | 532B | 纯二进制DER | 加密证书（供cert callback使用） | | enc.key.der | 122B | 纯二进制DER | 加密私钥（供cert callback使用） | | sign.key.der | 122B | 纯二进制DER | 签名私钥（供cert callback使用） |

格式说明: .crt 文件不是纯 DER 格式。其内部结构为 “OpenSSL x509 -text 人类可读输出 + PEM证书块”。hitls内置PEM解析器（hitls_bsl/pem.c）自动跳过前缀文本并解析PEM块。命令行无需指定 -certform/-keyform。

TLCP 双证书体系（GM/T 0024）:

| 证书 | Subject标识 | 用途 | | — | — | — | | sign.crt | OU=testsign | 签名证书 — ServerKeyExchange SM2签名 | | enc.crt | OU=testenc | 加密证书 — 密钥交换 SM2加密/解密 |

4.2 统一环境变量

export LD_LIBRARY_PATH=/home/kali/M/openhitls/build:$LD_LIBRARY_PATH
export C=/home/kali/M/openhitls/testcode/testdata/tls/certificate/der/sm2_with_userid
HITLS=/home/kali/M/openhitls/build/hitls

每个新终端必须先执行前两行export。服务端和客户端需在不同终端运行。

4.3 TLCP 双向身份鉴别（ECDHE_SM4_CBC_SM3）

预期：握手成功。双方均提供双证书，ECDHE密钥交换正常。

服务端（终端1，先启动）:

$HITLS s_server \
    -tlcp -accept 127.0.0.1:4433 \
    -cipher TLS_ECDHE_SM4_CBC_SM3 \
    -CAfile $C/ca.crt -chainCAfile $C/inter.crt \
    -tlcp_sign_cert $C/sign.crt -tlcp_sign_key $C/sign.key \
    -tlcp_enc_cert $C/enc.crt -tlcp_enc_key $C/enc.key \
    -provider default -state

预期输出:

ACCepting connections at 127.0.0.1:4433
Negotiated cipher suite: TLS_ECDHE_SM4_CBC_SM3
TLS handshake completed successfully
Handshake state: connected

客户端（终端2）:

echo "Hello World" | $HITLS s_client \
    -tlcp -host 127.0.0.1 -port 4433 \
    -cipher TLS_ECDHE_SM4_CBC_SM3 \
    -CAfile $C/ca.crt -chainCAfile $C/inter.crt \
    -tlcp_sign_cert $C/sign.crt -tlcp_sign_key $C/sign.key \
    -tlcp_enc_cert $C/enc.crt -tlcp_enc_key $C/enc.key \
    -provider default -state

预期输出:

Negotiated cipher suite: TLS_ECDHE_SM4_CBC_SM3
TLS handshake completed successfully
Response: Hello World!

4.4 TLCP 单向身份鉴别（ECC_SM4_CBC_SM3 + -noverify）

重要说明: ECDHE 单向不可行（协议级限制，不是Bug）。ECDHE密钥交换强制客户端提供加密证书参与密钥派生（见源码 send_server_key_exchange.c L305-308），即使使用 -noverify 也不例外。

解决办法: 使用 ECC_SM4_CBC_SM3 密码套件 + -noverify 参数。

服务端（终端1，-noverify + ECC密码套件）:

$HITLS s_server \
    -tlcp -accept 127.0.0.1:4433 \
    -cipher TLS_ECC_SM4_CBC_SM3 \
    -CAfile $C/ca.crt -chainCAfile $C/inter.crt \
    -tlcp_sign_cert $C/sign.crt -tlcp_sign_key $C/sign.key \
    -tlcp_enc_cert $C/enc.crt -tlcp_enc_key $C/enc.key \
    -provider default -state -noverify

预期输出:

-noverify mode: client certificate verification disabled
Negotiated cipher suite: TLS_ECC_SM4_CBC_SM3
TLS handshake completed successfully

客户端（终端2，不提供自身证书，仅CA根证书验证服务端）:

echo "test" | $HITLS s_client \
    -tlcp -host 127.0.0.1 -port 4433 \
    -cipher TLS_ECC_SM4_CBC_SM3 \
    -CAfile $C/ca.crt -chainCAfile $C/inter.crt \
    -provider default -state

预期输出:

Negotiated cipher suite: TLS_ECC_SM4_CBC_SM3
TLS handshake completed successfully
Response: test

如果错误地使用 ECDHE 密码套件做单向鉴别，预期结果如下（握手失败）:

client: TLS handshake failed: 0x20c0029  ← 客户端无加密证书，编码失败
server: TLS handshake failed: 0x2040017  ← 服务端未收到对方证书

错误码详解见 §五[1]。

4.5 DTLCP 双向身份鉴别（ECDHE_SM4_CBC_SM3，UDP承载）

服务端（终端1，端口4444，避免与TCP冲突）:

$HITLS s_server \
    -dtlcp -accept 127.0.0.1:4444 \
    -cipher TLS_ECDHE_SM4_CBC_SM3 \
    -CAfile $C/ca.crt -chainCAfile $C/inter.crt \
    -tlcp_sign_cert $C/sign.crt -tlcp_sign_key $C/sign.key \
    -tlcp_enc_cert $C/enc.crt -tlcp_enc_key $C/enc.key \
    -provider default -state

客户端（终端2）:

echo "Hello DTLCP" | $HITLS s_client \
    -dtlcp -host 127.0.0.1 -port 4444 \
    -cipher TLS_ECDHE_SM4_CBC_SM3 \
    -CAfile $C/ca.crt -chainCAfile $C/inter.crt \
    -tlcp_sign_cert $C/sign.crt -tlcp_sign_key $C/sign.key \
    -tlcp_enc_cert $C/enc.crt -tlcp_enc_key $C/enc.key \
    -provider default -state

预期：握手成功。DTLCP over UDP，无TCP三次握手，握手消息含序号和分片偏移量。

4.6 DTLCP 单向身份鉴别（ECC_SM4_CBC_SM3 + -noverify）

服务端（终端1，ECC + -noverify）:

$HITLS s_server \
    -dtlcp -accept 127.0.0.1:4444 \
    -cipher TLS_ECC_SM4_CBC_SM3 \
    -CAfile $C/ca.crt -chainCAfile $C/inter.crt \
    -tlcp_sign_cert $C/sign.crt -tlcp_sign_key $C/sign.key \
    -tlcp_enc_cert $C/enc.crt -tlcp_enc_key $C/enc.key \
    -provider default -state -noverify

客户端（终端2，无自身证书）:

echo "test" | $HITLS s_client \
    -dtlcp -host 127.0.0.1 -port 4444 \
    -cipher TLS_ECC_SM4_CBC_SM3 \
    -CAfile $C/ca.crt -chainCAfile $C/inter.crt \
    -provider default -state

预期：握手成功（与TLCP ECC单向相同原理）。

4.7 抓包分析

# 终端3：tcpdump 抓包（在客户端启动前开始）
mkdir -p captures

# TLCP（TCP，端口4433）
sudo tcpdump -i lo -w captures/tlcp_ecdhe_two_way.pcap port 4433

# DTLCP（UDP，端口4444）
sudo tcpdump -i lo -w captures/dtlcp_ecdhe_two_way.pcap port 4444

# 测试完成后 Ctrl+C 终止抓包

用 Wireshark 打开 pcap 文件，关键分析点:

| 分析项 | TLCP/DTLCP 关键字段 | 说明 | | — | — | — | | 协议标识 | ClientHello 中版本 TLS 1.1 + TLCP 扩展 | TLCP使用0x0002扩展类型 | | 密码套件 | ServerHello 中 Cipher Suite 字段 | 确认 ECDHE_SM4_CBC_SM3 或 ECC_SM4_CBC_SM3 | | 双证书 | Certificate 消息 | 单向鉴别时无客户端Certificate消息 | | ECDHE握手 | ServerKeyExchange内SM2签名值 (r,s分量) | ECDHE专有 | | 单向标记 | 是否存在 CertificateRequest 消息 | ECC+无验证 无CR，ECDHE 始终有CR | | 加密切换 | Change Cipher Spec + Encrypted Finished | 2组 CCS+Finished |

4.8 常用参数速查（openhitls-0.3 分支 ab0d11e1 实测可用）

| 参数 | 说明 | | — | — | | -tlcp / -dtlcp | 协议类型：TLCP (TCP) / DTLCP (UDP) | | -cipher <val> | 密码套件标准名称（大小写敏感） | | -tlcp_sign_cert <file> / -tlcp_sign_key <file> | SM2 签名证书与私钥 | | -tlcp_enc_cert <file> / -tlcp_enc_key <file> | SM2 加密证书与私钥 | | -CAfile <file> / -chainCAfile <file> | CA 根证书 / 中间CA证书链 | | -accept host:port | 服务端监听地址和端口 | | -host <host> / -port <uint> | 客户端连接地址和端口（分开指定） | | -noverify | 单向鉴别核心参数 : 不验证对端证书 | | -provider default | 指定密码Provider（必须指定） | | -state | 输出握手状态信息 | | -accept_once | 服务端完成一次连接后退出 |

密码套件常用值:

| -cipher 参数值 | 密钥交换 | 单向支持 | | — | — | — | | TLS_ECDHE_SM4_CBC_SM3 | ECDHE + SM4-CBC + SM3 | 不支持 | | TLS_ECC_SM4_CBC_SM3 | ECC + SM4-CBC + SM3 | 支持 | | TLS_ECDHE_SM4_GCM_SM3 | ECDHE + SM4-GCM + SM3 | 不支持 | | TLS_ECC_SM4_GCM_SM3 | ECC + SM4-GCM + SM3 | 支持 |

五、常见错误码

| 错误码 | 十进制 | 宏名称 | 含义 | 典型原因 | | — | — | — | — | — | | 0x27 | 39 | (外层封装错误) | Failed to create config and connection | 聚合错误，查看下层更具体错误码 | | 0x20c0029 | 34340873 | HITLS_CERT_ERR_ENCODE | Failed to encode the certificate （证书编码失败） | ECDHE单向鉴别：客户端无加密证书，EncodeEncCert() 收到NULL | | 0x2040017 | 33816599 | HITLS_MSG_HANDLE_NO_PEER_CERTIFIACATE | Not receive the peer certificate （未收到对端证书） | 对端未发送Certificate消息（或发送了空Certificate） | | 0x20a000c | — | — | 不支持的密码套件 | SM算法未集成到默认Provider（检查编译宏 HITLS_CRYPTO_PROVIDER_DEFAULT_SM） | | 0x20c001f | — | — | 证书链验证失败 | -CAfile /-chainCAfile 路径错误或证书格式不匹配 |

错误码位结构: 0x2 0c 0029 = 错误级别(2=ERROR) + 模块ID(0c=HITLS_CERT) + 模块内错误号(29)

0x20c0029 深入分析（密评中常见）

调用链（从客户端收到 ServerKeyExchange 到返回错误）:

parse_server_key_exchange.c:495 &nbsp; SAL_CERT_ClntGmEncodeEncCert() &nbsp;← 尝试编码客户端加密证书
&nbsp; &nbsp; ↓
cert.c:736 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;EncodeEncCert(ctx, peerCert->encCert, useLen)
&nbsp; &nbsp; ↓ &nbsp;peerCert->encCert == NULL &nbsp;（客户端未提供加密证书）
cert.c:679 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;if (cert == NULL) return NULL;
&nbsp; &nbsp; ↓
parse_server_key_exchange.c:497 &nbsp; → HITLS_CERT_ERR_ENCODE (0x20c0029)

六、面向未来的敏捷架构与开源生态

当前能力只是起点，openHiTLS更大的价值在于面向算法演进的前瞻设计。随着后量子密码标准化推进，基于椭圆曲线的SM2面临量子计算威胁（Shor算法可在多项式时间内破解ECC），SM4则需应对Grover算法带来的等效密钥长度减半问题。openHiTLS通过以下机制应对：

  • • Provider插件机制：算法以插件形式挂载，切换算法无需改动应用层代码
  • • PQCP密码创新仓：承载国产后量子算法的工程化落地
  • • 配置驱动：通过配置文件指定算法，避免硬编码

这套设计使得密码标准演进时，应用层仅需少量配置调整即可完成算法迁移，大幅降低了密评整改的长期成本。

生态层面，openHiTLS由社区技术委员会治理，10+产学研组织共建，已形成”高校创新算法设计 + 社区工程化实现 + 企业规模化应用”的协作链条。社区定期举办开源实习活动，面向高校学生提供密码学实践机会，为密评领域持续输送人才。

七、结语

对于密评从业者而言，openHiTLS的价值不仅在于它是一个”免费的密码库”，更在于它提供了一套可审查、可裁剪、可演进的密码基础设施。从国密算法到安全协议，从编译集成到抗量子迁移，它为密评建设提供了从当下合规到未来演进的全链路支撑。在合规要求趋严、技术迭代加速的当下，拥抱开源密码套件或许是比采购黑盒产品更可持续的选择。

参考资源

  • • 官网：https://openhitls.net
  • • 源码仓库：https://gitcode.com/openHiTLS/openhitls
  • • 文档中心：https://docs.openhitls.net
  • • API 参考：https://apidoc.openhitls.net

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：利刃信安 利刃信安 利刃信安《商用密码应用安全性评估——openHiTLS初识》

版权声明

本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。

ZONE.CI 全球网 | 安全领域涉猎者-乌云独行地带
ZONE.CI 全球网
安全领域涉猎者-乌云独行地带
ZONE.CI 全球网 | 安全领域涉猎者-乌云独行地带
安全领域涉猎者-乌云独行地带
ZONE.CI 全球网
评论：0   参与：  0