ECDSA算法密钥文件与签名长度问题

水一篇...起因是用 openssl 输出 ECDSA 的签名，结果发现长度是 72；当然，因为是 der 编码，所以里面肯定有一些多余的字节；但咋想也不对，签名应该是一个私钥长度加一个公钥长度才对啊？那怎么着也得 32 +64 = 96 字节以上吧？于是又去看了密钥文件，因为我对 der 也没有多深入的研究，只知道是“Type-Length-Value”格式的嵌套和组合；而用 ASN1View 工具打开也没解释各个段的含义，只能靠猜。

私钥挺好分辨的，开头就有 32 字节(因为曲线选的是256bit的一条)，那么另一部分应该就是公钥了，但公钥部分显示66字节，就离谱，我一看，开头出现个 00 04，一看就不自然。

百度了半天无果；最终还是在 Crypto Exchange 上找到了答案。

这个 04 表示后面的公钥是“非压缩格式”，也就是完整给出了(x, y) 的坐标。

这才想起来，好像基于椭圆曲线的密钥，公钥都可以压缩来着 (因为横纵坐标有一定的联系，所以好像纵坐标可以用一个字节代替...) 具体我也记不清了，可以看知乎的这篇(不是我写的)：

零知识证明前传-椭圆曲线加密体系01 - 知乎

因此，除掉这两个字节，就是64字节公钥无误，横纵坐标各32字节（如果用压缩格式的话，等于可以省31字节；另，整个密钥文件长121字节。

然后回到签名这来，我看调试控制台打印出的 72 字节，开头两个字节 30 44 直接拿掉；随后是个 20，也就是 32 字节(16进制嘛)，大概是签名中的 r 部分；跳过 32 字节，出现了 02 20 ... 哈！压缩格式！原来如此。问题解决。因此真正的签名长度是 32 + (1+32) = 65；因为签名做了压缩（压缩格式下，公钥数据会以 02 / 03 开头，否则以 04 开头，04 开头的话，后面就要跟 length 40，然后是 64 字节了...）