0

为了完全理解 ECIES 并使用我最喜欢的库,我自己实现了 ECIES 的某些部分。这样做并比较结果会导致我不太清楚的一点:KDF 的输入到底是什么?

ECDH的结果是一个向量,但是你用什么来做KDF呢?它只是 X 值,还是 X + Y(可能带有前置 04)?您可以在野外找到这两个概念,并且为了互操作性,哪种方式是正确的方式真的很有趣(如果有正确的方式 - 我知道 ECIE 更像是一个概念并且有几个自由度)。

解释(如果我在特定点上错了,请纠正我)。如果我谈论字节长度,这将指的是具有 256 位 EC 密钥的 ECIES。

所以,首先,大局:这是 ECIES 流程,我说的是第 2 步 -> 第 3 步:

在此处输入图像描述

接收者的公钥是向量 V,发送者的临时私钥是标量 u,密钥协商函数 KA 是 ECDH,它基本上是 V * u 的乘积。结果,您得到了一个共享密钥,它也是一个向量——我们称之为“共享密钥”。

然后获取发送者的公钥,将其与共享密钥连接,并将其用作密钥派生函数 KDF 的输入。

但是:如果您想将此向量用于密钥派生函数 KDF,您有两种方法:

  1. 你可以只使用共享密钥的 X。然后你有一个 32 字节的字节串。
  2. 您可以使用共享密钥的 X 和 Y,并像使用公钥一样在其前面加上 0x04。然后你有一个 01 + 32 + 32 字节的字节串 [3) 只是为了完整:你也可以使用 X + Y 作为压缩点)

字节串的长度并不重要,因为在 KDF(通常涉及散列)之后,您总是有一个固定值,例如 32 个字节(如果您使用 sha256)。

但是,如果您选择其中一种方法,KDF 的结果当然会大不相同。所以问题是:正确的方法是什么?

因此,我试图在文档中获取更多信息:

所以,结果是:我很困惑。谁能指出我正确的方向,或者这只是你拥有的一定程度的自由(以及在兼容性方面有很多乐趣的理由)?

4

1 回答 1

0

自己回答我的问题:是的,这是一种自由度。X 坐标方式称为紧凑表示,它在 RFC 6090 中定义。所以两者都是有效的。

它们也同样安全,因为您可以按照RFC 6090 的附录 C 中的描述从 X 中计算出 Y。

默认方式是使用紧凑表示。两种方式彼此不兼容,因此如果您偶然发现库之间的兼容性问题,这可能是一个有趣的发现点。

于 2020-07-20T05:50:46.250 回答