3.6. Variants (变体)

确定性 (EC)DSA 规范的许多部分是相当任意的.可以定义不是 "确定性 (EC)DSA" 但在某些上下文中可能仍然有用的变体:

可以直接使用 H(m), 而不是 bits2octets(H(m)), 作为 HMAC 输入的一部分.如第 3.5 节所述, 我们使用 bits2octets(H(m)) 是为了简化集成到已经使用 (EC)DSA 签名引擎的系统中, 通过向其发送已截断的哈希值.使用整个 H(m) 不会引入任何漏洞.
可以将附加数据添加到 HMAC 的输入中, 连接在 bits2octets(H(m)) 之后:
```
K = HMAC_K(V || 0x00 || int2octets(x) || bits2octets(h1) || k')
```
一个用例可能是在没有访问高质量随机源的系统上需要非确定性签名算法的协议.只要附加数据 k' 是非重复的 (例如, 签名计数器或单调时钟), 就足以确保 "看起来随机" 的签名在密码学方式上与普通 (EC)DSA 签名无法区分.在 [SP800-90A] 术语中, k' 是可以在生成伪随机位时设置为参数的 "附加输入".此变体可以被认为是对附加数据 k' 来源的随机性的 "增强".
可以使用附加的秘密数据作为 HMAC 的输入, 而不是使用 x (私钥), 这些秘密数据与私钥一起存储并具有相同的安全措施.该附加数据的熵应至少为 n 位, 最好为 n+64 位或更多, 其中 n 是目标安全级别.拥有与私钥本身不同的附加秘密数据可以通过防止侧信道泄漏私钥的 "重放" 来帮助防御此类攻击.但是, 使用附加秘密数据会产生额外的存储要求, 并且必须保证该数据具有足够的熵.
可以使用与用于处理消息的哈希函数 H 不同的哈希函数来参数化 HMAC.这在某些上下文中可能很有用, 例如, 当签名引擎必须支持多个哈希函数但只想实现一个 HMAC 实例时.但是, 这可能会降低安全性, 因为 HMAC 使用的哈希函数的强度应该至少与用于处理消息的哈希函数一样强.

3.6. Variants (变体)​

3.6. Variants (变体)