ECIES对KDF的需求

Question

阅读ECIES算法(以及一般的elgamal算法)，一般的智慧是在使用KDF和MAC对共享秘密进行加密之前使用它来加密密文。

然而，我怀疑这是因为所使用的加密是XOR (对于比原始数据小的数据大小)。

如果您使用的是带有随机iv的AES GCM，我看不到共享秘密上KDF的值。

对于某些协议，您不希望用户用错误的密钥解密密文(选择密文攻击).所以麦克拿钥匙可能会有帮助。

但是对于随机IV，选择的密文在这里似乎是无用的，只要你不遵循共享秘密和对称部分算法的标准。

使用GCM，ECIES的mac部分似乎也没有用。我认为，也许，推迟到经过更好测试的AES/GCM进行身份验证似乎是更好的选择。

请参阅：https://en.wikipedia.org/wiki/Integrated_加密_方案

Answer 1

现在人们普遍认为在关键推导步骤中使用AES-GMAC比使用HMAC略好一些。例如:这就是苹果在其安全飞地中使用的东西。

虽然密钥的散列满足AES密钥输入的“无结构”契约--使用KDF也执行其他有用的功能。

KDF可以产生额外的字节用于AES-GCM的IV。标准的KDF为支持对称加密提供了灵活的哈希算法选择和灵活的字节数量。

最后，这减少了加密时需要传输/存储的数据量，并将更多代码转移到经过更好测试和标准化的库中。

概括地说，与大多数系统的互换性：

== ECDH -> X93KDF(SHARED_KEY，AES_LEN+IV) -> AES_GCM()

另外，使用GCM步骤的auth标记中的公钥可以提供一些可塑性防御。