我目前正在检查NaCl库由DanielJ.Bernstein编写,我注意到这个库硬编码西格玛:
static const unsigned char sigma[16] = "expand 32-byte k";在所有salsa流实现中:
crypto_stream_xsalsa20
crypto_stream_salsa20
crypto_stream_salsa2012
crypto_stream_salsa208以及crypto_box库包装器:
static const unsigned char sigma[16] = "expand 32-byte k";
static const unsigned char n[16] = {0};
int crypto_box_beforenm(
unsigned char *k,
const unsigned char *pk,
const unsigned char *sk
)
{
unsigned char s[32];
crypto_scalarmult_curve25519(s,sk,pk);
return crypto_core_hsalsa20(k,n,s,sigma);
}据我从纸了解到,常量用于扩展流密码。
现在:
实现可以在文件中找到:
crypto_box/curve25519xsalsa20poly1305/ref/before.c
crypto_stream/salsa2012/ref/xor.c
crypto_stream/salsa2012/ref/stream.c
crypto_stream/salsa20/ref/xor.c
crypto_stream/salsa20/ref/stream.c
crypto_stream/salsa208/ref/xor.c
crypto_stream/salsa208/ref/stream.c
crypto_stream/xsalsa20/ref/xor.c
crypto_stream/xsalsa20/ref/stream.c编辑:我在上面引用的文章中发现了对这个常量的引用为"Salsa20“常量:
(x0;x5;x10;x15) = (0x61707865;0x3320646e;0x79622d32;0x6b206574);换句话说,(x0;x5;x10;x15)是Salsa20常数。
这是考虑到endianness的“展开32字节k”。
发布于 2013-10-21 14:26:14
Salsa20具有较强的旋转对称性。这些常数的要点是,它们在旋转时不是不变的,这就引入了一个不对称。精确的值并不是很重要,只要它足够不对称。
伯恩斯坦- Salsa20 20安全说:
关于对角线常数的注释,每个Salsa20列圆形以相同的方式从对角线开始影响每一列。每个Salsa20行圆以从对角线开始的相同方式影响每一行。因此,沿对角线移动整个Salsa20哈希函数输入数组对输出的影响完全相同。Salsa20扩展函数通过限制攻击者对哈希函数输入的控制来消除这种移位结构。特别是,输入对角线总是0x61707865,0x3320646e,0x79622d32,0x6b206574,这与其所有重要的移位不同。换句话说,具有这种对角线的两个不同的阵列在移位组下总是处于不同的轨道上。类似地,Salsa20哈希函数操作几乎与每个输入字的旋转(例如10位)兼容。旋转改变了跨越旋转边界的载具的效果,但它与所有其他载具以及除加法以外的Salsa20操作是一致的。Salsa20展开函数也消除了这种旋转结构。输入对角线不同于它的所有非平凡移位及其所有非平凡旋转和非平凡旋转的所有非平凡移动。换句话说,具有这种对角线的两个不同的阵列在移位/旋转组下总是处于不同的轨道上。
另一个相关的文档是有点粗糙的对“关于Salsa20 20核心函数”的响应。
SipHash与Salsa20共享一些设计原则,并且具有类似的常量。SipHash纸解释了价值观的选择:
常数的选择。初始状态常数对应于大端编码的ASCII字符串“state orandomlygenerated字节”。这个值没有什么特别之处;唯一的要求是一些不对称,因此初始的v_0和v_1不同于v_2和v_3。这个常量可以设置为“个性化字符串”,但我们还没有评估它是否可以安全地选择为“调整”。请注意,两个非零字的初始化常量应该和4个一样安全。
保持不变。在某些罕见的情况下,自定义常量可能很有用,但通常不应该这样做。
在回答CurveCP邮件列表中的一个问题时,伯恩斯坦:
是否建议为每个应用程序定制西格玛?不是的。
https://crypto.stackexchange.com/questions/11182
复制相似问题