我正在开发一个简单的软件,可以进行 aes256-cbc 文件加密。该软件是在 GNU/Linux 上使用 libgcrypt-1.5.0 开发的。
我想使用上述函数,将 GCRY_KDF_PBKDF2
作为 algo
和 SHA512
作为子算法。
gcry_kdf_derive( const void *passphrase, size_t passphraselen, int algo, int subalgo,
const void *salt, size_t saltlen, unsigned long iterations,
size_t keysize, void *keybuffer )
此函数从密码
派生 key 。 keysize
给出了请求的 key 大小(以八位字节为单位)。 keybuffer
是调用者提供的缓冲区,成功时用派生 key 填充。输入密码取自passphrase
,它是passphraselen 八位字节的任意内存缓冲区。 algo
指定要使用的 KDF 算法;见下文。 subalgo
指定 KDF 算法内部使用的算法;这通常是一种哈希算法,但某些 KDF 算法可能会以不同的方式使用它。 salt
是长度为 saltlen 八位组的盐,这是大多数 KDF 算法所需的。对于大多数 KDF 来说,迭代次数是一个正整数参数。
我不明白如何使用此功能的三件事:
salt
必须随机生成,因此它必须不加密地放入输出文件中,不是吗? (IV-密文-盐-MAC)saltlen
有一个正确的“加密”值,或者我可以选择我喜欢的值吗?比如10、20、30...- key 大小(在本例中)必须是 512,对吗?
最佳答案
1) salt must be generate randomly so it must be put not encrypted into the output file, isn't it? (IV-CIPHERTEXT-SALT-MAC)
正确,尽管更合乎逻辑的形式是某种容器格式的 SALT-IV-CIPHERTEXT-MAC。这将是另一方需要组件的顺序
- 计算 key
- 验证数据
- 解密数据
2) saltlen has a correct "crypto" value or can i choose whatever i prefer? Like 10,20,30...
最低限度(对于高度安全的系统)为 64 位或 8 字节,但由于您使用的是高端加密原语,为什么不选择 256 位安全随机,以匹配您的 key 大小。
3) keysize (in this case) must be 512, right?
这是正确的, key 大小以位为单位必须为 512。API 期望 KEYSIZE 参数以八位位组为单位,因此为 64 个八位位组。您似乎想要执行 MAC 签名/验证。这需要与用于加密/解密的 key 不同的 key 。因此,您需要两个 256 位 key ,幸运的是它与 SHA-512 算法的输出相匹配。我说“幸运”是因为你真的不希望 PBKDF2 计算另一个 block - 它会再次经历所有迭代。
IV值最好单独计算,放在密文前面。您应该在 MAC 计算中包含 IV 值(否则第一个纯文本 block 将不会被验证)。 IV 应该是一个随机数据 block ,因此对于 AES 来说,这将是 128 位或 16 字节的安全随机数据。
关于c - 在 C 中使用 libgcrypt 导出 key ,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/14583733/