用于Ed448的公钥派生

Question

这里还有一个可能很傻的问题，但我似乎已经开发出了隧道式的愿景，我错过了一些非常基本的东西。

在RFC 8032中，可以为Ed488找到许多测试向量--例如：

SECRET KEY:
   c4eab05d357007c632f3dbb48489924d
   552b08fe0c353a0d4a1f00acda2c463a
   fbea67c5e8d2877c5e3bc397a659949e
   f8021e954e0a12274e

   PUBLIC KEY:
   43ba28f430cdff456ae531545f7ecd0a
   c834a55d9358c0372bfa0c6c6798c086
   6aea01eb00742802b8438ea4cb82169c
   235160627b4c3a9480

   MESSAGE (length 1 byte):
   03

   SIGNATURE:
   26b8f91727bd62897af15e41eb43c377
   efb9c610d48f2335cb0bd0087810f435
   2541b143c4b981b7e18f62de8ccdf633
   fc1bf037ab7cd779805e0dbcc0aae1cb
   cee1afb2e027df36bc04dcecbf154336
   c19f0af7e0a6472905e799f1953d2a0f
   f3348ab21aa4adafd1d234441cf807c0
   3a00

以编码格式表示的公钥大小为57字节。现在，我的理解是，公钥是通过计算私钥的标量乘积(如RFC 8032中所描述的)乘以基点来获得的。这些操作的执行方式是:素数p= 2^448 - 2^224 - 1，长度为56字节。

如果所有的操作都是56个字节长的，那么公钥怎么能有57个字节长呢？确实，公钥不是上面的标量产品，因为该产品必须按照RFC 8032中的描述进行编码。但是，这种编码非常简单，不能添加额外的字节。

我一定是错过了一些很明显的东西--但我看不出来是什么。

Answer 1

如果你阅读所有的射频8032，你会看到有一个点的压缩(端编码)。

def point_compress(P):
    zinv = modp_inv(P[2])
    x = P[0] * zinv % p
    y = P[1] * zinv % p
    return int.to_bytes(y | ((x & 1) << 255), 32, "little") 

压缩只存储符号并用以下信息还原它

def point_decompress(s):
    if len(s) != 32:
        raise Exception("Invalid input length for decompression")
    y = int.from_bytes(s, "little")
    sign = y >> 255
    y &= (1 << 255) - 1

    x = recover_x(y, sign)
    if x is None:
        return None
    else:
        return (x, y, 1, x*y % p)

以上是为Ed25519定义的，正如我所看到的，在RFCs中没有Ed448的代码。然而，NIST.FIPS.186-5-draft为两者都定义了它；

对于在范围内具有坐标的曲线点(x,y)，0 \leq x, y < p,首先将y-coordinate编码为32辛特for Ed25519的小端点字符串，对于57 448则编码57辛特。对于Ed25519，最后八进制中最重要的部分总是零，while表示Ed448，最后一个八进制总是零。要形成点的编码，copy是x-坐标中最小的一个到最后一个八进制中最重要的位

如我们所见，x-coordinate的LSB放置在y坐标的最后八进制(字节)的MSB中。因此，公钥的总大小是57个字节.

虽然压缩在存储/传输方面具有耗时和很少的优势，但它在点验证中也有帮助。第二和第三选项在解压过程中得到验证。

1. x和y坐标P，x(P),y(P)是字段的有效元素。
2. P满足曲线方程-对抗扭转攻击。