Openssl 在.NET内核中使用ECDSA384进行JWT签名验证（MacOS兼容性问题）

我有一个公钥，我现在不确定如何使用它来验证JWT令牌的签名。我已经尝试过使用所示的想法（用于验证），但有一点不同，我使用的是384（在示例中不是256），并且不确定应该跳过并考虑数组中的哪些字节。我也尝试过使用外部库，但也失败了，可能是出于同样的原因。我不知道如何从我拥有的公钥字节数组中提取X和Y。这些示例似乎都假设您已经知道X和Y：

string token=“EYJHBGCOIJFUZI1NIISIMN0ESI6INREHRCL3BSYWLUIN0.eyJoZWxsbyI6ICJ3b3JsZCJ9.EVnmDMlz-oi05AQzts-R3AQWVABLWVZDDWKMAHYMX5PHB2NSYI0KCPCPJJJAYO1SKB3CLIPFMXCx_obMKA”

此外，由于X和Y的大小不正确等原因，当我伪造字节数组以通过初始异常时，我发现仍然有100%的时间出现异常。 我将这个问题追溯到我使用的所有库都试图创建一个CngKey，这导致了一个“不受支持的平台异常”，因为我是在MacOS上开发的

根据信息表，我看到以下解释： 这是有道理的。然而，我希望避免仅仅为了使用

ECDsaOpenSsl

和安装OpenSSL而实现这些库的我自己的实现，我希望能够在不检查哪个操作系统正在执行代码的情况下部署到Windows环境

综上所述，有两个问题：

我不知道如何从我的公钥字节中提取X和Y坐标 大堆我链接的第一个例子来自一个知道 将跳过数组的第一个索引，并忽略数组的其余部分 它被均匀地分开。如果我 这样做了，所以我不确定哪一个索引可以跳过，如果它适用的话 在这里

我希望在验证中的签名时能够使用奇偶校验 Mac和Windows都没有滚动我自己的库

---

我只会就第一个问题发表意见：

在您链接的示例中，公钥采用未压缩格式，该格式始终编码为：

0x04 | X | Y

其中X和Y是无符号值，由对应于曲线大小的精确字节数表示（例如，256位曲线为32字节）。这就是为什么该示例跳过第一个字节，然后将其余字节平均分割以得到X和Y

---

为了帮助您使用公钥，您必须在此处发布此密钥。然后我们可以推测它的编码。

另外，需要明确的是，主要问题是Mac不兼容。这就是悬赏的目的。即使创建了有效的ecckey，所有方法似乎都会产生平台不支持的异常。（1）如何从密钥确定

x

和

y

，取决于密钥格式。你能说说格式吗，或者把钥匙贴出来？（2） CNG和ECDsaCng仅为Windows。使用

ECDSa.Create（）

，ECDSa是跨平台支持的，它实例化了特定平台使用的类型（例如Windows上的

ECDsaCng

）。您是否在.Net/macOS上尝试过此功能，另请参见和？@Topaco这些链接信息丰富，非常有用-谢谢。这里是我请求的本地密钥的临时版本：它是用secp384r1编码的base 64。发布的公钥是用X.509格式指定的，并且可以用ASN.1解析器最容易地读取，例如。最后，可以找到未压缩格式的原始公钥

04 | x（48字节）| y（48字节）：04 | ddd1…3ae7 | f01f…2314

。描述了secp384r1或NIST P-384。当我将

GetBytes（pubKey）

与我的密钥一起使用时，我得到一个包含160个元素的字节数组。你是说我需要得到64-160的范围，然后把它们分成X和Y？不完全是这样。Base64编码公钥的长度为160字节。必须首先对密钥进行Base64解码，例如。Base64解码后，密钥长度为120字节，其中最后2*48+1=97字节为原始公钥，格式为

04 | x（48字节）| y（48字节）

。但是请注意，如果Base64编码的公钥

MHYw…fyMU

存储在一个文本文件中，然后使用ASN.1编辑器打开该文本文件以读取原始公钥，则会容易得多，请参阅。

0x04 | X | Y