问题标签 [ecdsa]

我想在我的 Java Card 上签署一些数据（MESSAGE 字节数组），然后在响应 APDU 中返回签名。我的代码在没有apdu.sendBytes(BAS, sSignLen)行的情况下工作正常（或者至少我认为它可以正常工作并且它返回 9000），但是当我取消注释它时，我得到一个未知错误（0xC000002B (Unknown error.)）。

当我尝试在响应 APDU 中发送其他数据时，它可以完美运行。

这是我的代码。我做错了什么或错过了什么？谢谢！

最近，我一直在尝试了解二进制扩展欧几里得算法在处理器级别的工作原理。这个问题是关于在具有多项式基础的 GF(2^m) 中找到一个逆元素。

一般来说，我遇到了用于评估逆元素的扩展欧几里得算法，但事实是它涉及太多的加法和乘法运算。二进制 EEA 算法只需要位移操作（相当于除以 2——逻辑右移）。该算法在此链接中，第 8 页。

在该算法的第 3 步和第 5 步中，每次迭代都会将参数向右移动 1 位，同时将 MSB 加零u。b循环结束时u == 1并返回b。我的问题是处理器（例如 32 位处理器）在每次迭代的第 3 步或第 5 步中执行多少原始操作？

我遇到了桶式移位器，我对移位发生的速度感到非常困惑。我真的应该考虑这些原始操作，还是因为转移可能更快而忽略它们？

如果有人能展示大小u为 194 位的情况的原始操作，那真的会对我有很大帮助。

如果您可能想知道x算法第 3 步和第 5 步中的分母，它是多项式表示，x仅表示10二进制，参数u是 N 位二进制数。

我们使用 SWIG 为 Perl 提供了一个 C 加密实用程序库。我们能够生成密钥、创建摘要，但签名代码会导致分段错误，我们认为这可能在 OpenSSL 代码本身中，但很难确定。

此问题仅在使用 SWIG 运行代码时出现，本机 C 代码有效。

在 Perl 中，我们称之为：

在 .i 文件中调用此代码：

调用此 C 代码：

并返回Segmentation Fault。我们得到的信息最多的错误是perl crashed with SIGSEGV in EC_KEY_get_key_method_data()

完整代码在这里：https ://github.com/aleitner/bitpay-perl/tree/stack-overflow-question

这是 SSL 的错误，还是我们做错了？

我已经测试了一个验证 ECDSA 签名的解决方案（如何从 EC 公钥字节中获取 PublicKey 对象？），它与给定的数据完美配合。

这是数据：

这是代码（打印true）：

当我将签名和数据更改为来自已实现系统的示例输入时，我的问题就出现了：

新数据输出此错误：

我认为问题在于安全消息附带的签名，因为：

• 密钥对的长度和格式与示例相同。并且是正确的，因为它来自签署消息的证书。
• 消息本身（有效负载）不应影响安全过程。

最后值得一提的是，我的文档说签名之前必须有一个名为“R”的字段，该字段“包含由生成器元素乘以临时私钥得到的椭圆曲线点的 x 坐标”，其长度必须是与签名相同（32 字节）。

有人可以指出我在这里缺少什么吗？

编辑：解决方案

正如 Peter Dettman 在他的回答中指出的那样，该方法的signature格式不正确（内容也不正确）以便通过该verify()方法进行计算。这是一个很好的解释，主要是说：

在 DER 中编码时，此（签名）变为以下字节序列：

0x30 b1 0x02 b2 (vr) 0x02 b3 (vs)

在哪里：

• b1 是一个单字节值，等于剩余字节列表的长度（以字节为单位）（从第一个 0x02 到编码结束）；
• b2 是一个单字节值，等于 (vr) 的长度，以字节为单位；
• b3 是一个单字节值，等于 (vs) 的长度，以字节为单位；
• (vr) 是最小长度的值“r”的有符号大端编码；
• (vs) 是最小长度的值“s”的有符号大端编码。

应用该更改，signature增长到 70 个字节，并且执行没有错误输出。

我有椭圆曲线的所有参数。以及点Q和P的坐标。我想通过测试所有可能的k来解决Q=k*P（其中k是未知数）。

所以我用了这个类

然后：

这是解决这个问题的正确方法吗？

我正在尝试使用 Pollard rho 求解椭圆曲线离散对数（找到k其中G=kp），因此我在 c 中搜索了实现，并在main我得到的函数 中添加了特定于问题的数据后找到了一个segmentation fault (core dumped)

这是导致segmentation fault

如何在 Java Card 上对 ECDSA PublicKey 进行编码，以便我可以在另一个平台上对其进行解码（例如，在响应 APDU 中发送编码的密钥并在标准 Java 应用程序中处理它）？keyPair.getPublic().getEncoded()在 Java 上使用 PKCS#8 编码可以解决问题，但据我所知getEncoded()，在 Java Card 平台上不可用。

我有一个原始 (r,s) 格式的 ECDSA NIST P-256 公钥。似乎没有简单的方法可以将其加载到实现 java.security.interfaces.ECPublicKey 的对象中。

加载 64 字节公钥以便用于检查签名的最简洁方法是什么？

我是 ECC 加密编程的初学者。有没有人向我解释使用 ECDH 进行共享密钥交换和使用 ECIES 通过用接收者的公钥加密共享密钥的区别？我觉得只要私钥保密，ECIES 也可以为我提供安全的密钥交换。谢谢你。

我需要使用 ECDSA 算法对消息进行签名并在 java 中发送给接收者。然后，接收方应验证发送方的签名。

因此，为此，接收方拥有发送方的公钥，但在java.security.PublicKey通过以下命令转换为字节数组后采用字节数组格式：

ECDSA算法中公钥的格式（转换为字节数组前）如下：

公钥：

但是，问题是将此字节数组转换为可用格式以验证java.security.PublicKey接收者的签名。

一般来说，是否有任何解决方案来验证签名而不将其转换为字节数组？换句话说，问题是通过发送者的公钥，使用任何方法来验证签名。