.net core 为什么Curve25519即使参数错误也能正确计算密钥对？

NET（Core 3.1）似乎支持ECC中的自定义曲线。因此，我定义了，并通过以下代码生成密钥对：

using System;
using System.Security.Cryptography;

namespace Curve25519
{
    class Program
    {
        static void Main(string[] args)
        {
            ECCurve ecCurve = new ECCurve() // Curve25519, 32 bytes, 256 bit
            {
                CurveType = ECCurve.ECCurveType.PrimeMontgomery,
                B = new byte[] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1 },
                A = new byte[] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0x07, 0x6d, 0x06 }, // 486662
                G = new ECPoint()
                {
                    X = new byte[] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 9 },
                    Y = new byte[] { 0x20, 0xae, 0x19, 0xa1, 0xb8, 0xa0, 0x86, 0xb4, 0xe0, 0x1e, 0xdd, 0x2c, 0x77, 0x48, 0xd1, 0x4c,
                    0x92, 0x3d, 0x4d, 0x7e, 0x6d, 0x7c, 0x61, 0xb2, 0x29, 0xe9, 0xc5, 0xa2, 0x7e, 0xce, 0xd3, 0xd9 }
                },
                Prime = new byte[] { 0x7f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
                0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xed },
                //Prime = new byte[] { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1 },
                Order = new byte[] { 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                0x14, 0xde, 0xf9, 0xde, 0xa2, 0xf7, 0x9c, 0xd6, 0x58, 0x12, 0x63, 0x1a, 0x5c, 0xf5, 0xd3, 0xed },
                Cofactor = new byte[] { 8 }
            };

            using (ECDiffieHellman ecdhOwn = ECDiffieHellman.Create())
            {
                // generate the key pair
                ecdhOwn.GenerateKey(ecCurve);
                // save ECDiffieHellman implicit parameters including private key
                ECParameters ecdhParamsOwn = ecdhOwn.ExportParameters(true);
                // print key pair
                Console.WriteLine(BitConverter.ToString(ecdhParamsOwn.D) + "\r\n" + BitConverter.ToString(ecdhParamsOwn.Q.X) + "\r\n" + BitConverter.ToString(ecdhParamsOwn.Q.Y));
            }
        }
    }
}

示例输出如下所示：

90-54-A7-71-C0-03-D9-69-40-21-A4-CF-8C-81-7C-09-C4-CD-7A-44-77-2E-19-AD-B7-09-82-C9-AC-6E-AF-46
80-32-26-BD-C3-85-BC-35-17-98-B1-6C-C7-31-EF-BE-21-91-BA-CD-4A-BD-87-5B-FB-EC-4B-6B-02-C9-07-46
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

然后，我想与另一个库/平台交叉检查，即x-cube-cryptolib/stm32f103c8。给定ECDiffieHellman生成的私钥（第1行），控制库计算相同的公钥（第2行），验证该公钥对（万岁）

在进入密钥交换阶段之前，我想使用它，并修改了Curve25519的参数，如代码中注释掉的prime。我希望看到两个平台从同一私钥计算不同的公钥时出现错误。但不是，ECDiffieHellman总是计算控制库确认的密钥对。我将曲线参数修改为错误、交换或调零，我对每个参数都这样做，清理并重建了项目，但每次情况都是一样的。甚至当我进入密钥交换阶段时，ECDiffieHellman计算出与控制库相同的共享密钥材料

---

为什么ECDiffieHellman/Curve25519会以某种方式生成与控制库一致的正确密钥对和共享密钥，即使其定义参数错误，似乎忽略了它们？或者这是关于.Net Core的ECDH实现的？

我不知道您提到的libs，但我对

Curve2519

有相当多的了解

ECDH当然是取一个对应的公钥点（实际上是

k[G]

，其中

k

是它们的私钥（一个钳制的

256位
数字，
G
是曲线的生成点），然后将其乘以私钥，得到
yourK*G

此过程是可交换的，这就是当对方对您的公钥及其私钥执行相同操作时，此过程会起作用的原因

现在，关于为什么曲线参数看起来无关紧要
curve25519
是一种高度优化的椭圆曲线密码系统。优化了标量乘法（用于ECDH的标量乘法）、优化了点运算等。仅使用
X坐标
和微分加法执行乘法。有关详细信息，请参阅

X25519
（curve25519+ECDH）专门使用“仅X”标量乘法，其中点仅由其
X
坐标表示。这是在固定时间内进行密钥交换的最快和最简单的方法之一，固定时间对于侧通道定时攻击非常重要

实际需要曲线的唯一时间是执行
EdDSA
点解压缩时
EdDSA
点线格式由Y坐标和
X
坐标的符号组成

这并不是说曲线被忽略了，当然，椭圆曲线操作必须考虑它们所操作的基础曲线，事实上，定义曲线的伽罗瓦域，更重要的是，所使用的计算被定义为保持在曲线上

如果您将所有参数归零，这很奇怪，但是如果您仍然将字段（
Prime
）保留为
2^255-19
，这就足以让ECDH类知道该做什么

因此，简言之，我认为在ECDH计算中很可能没有实际使用曲线方程。
我不知道您提到的LIB，但我对
曲线25519
有相当多的了解

ECDH当然是取一个对应的公钥点（实际上是
k[G]
，其中
k
是它们的私钥（一个钳制的
256位
数字，
G
是曲线的生成点），然后将其乘以私钥，得到
yourK*G

此过程是可交换的，这就是当对方对您的公钥及其私钥执行相同操作时，此过程会起作用的原因

现在，关于为什么曲线参数看起来无关紧要
curve25519
是一种高度优化的椭圆曲线密码系统。优化了标量乘法（用于ECDH的标量乘法）、优化了点运算等。仅使用
X坐标
和微分加法执行乘法。有关详细信息，请参阅

X25519
（curve25519+ECDH）专门使用“仅X”标量乘法，其中点仅由其
X
坐标表示。这是在固定时间内进行密钥交换的最快和最简单的方法之一，固定时间对于侧通道定时攻击非常重要

实际需要曲线的唯一时间是执行
EdDSA
点解压缩时
EdDSA
点线格式由Y坐标和
X
坐标的符号组成

这并不是说曲线被忽略了，当然，椭圆曲线操作必须考虑它们所操作的基础曲线，事实上，定义曲线的伽罗瓦域，更重要的是，所使用的计算被定义为保持在曲线上

如果您将所有参数归零，这很奇怪，但是如果您仍然将字段（
Prime
）保留为
2^255-19
，这就足以让ECDH类知道该做什么

因此，简言之，我认为在ECDH计算中很可能没有实际使用曲线方程。
我猜在PrimeMontgomery类型曲线上的ECDH目前会产生曲线25519，无论参数是什么。是的，这一点很好，因为使用的所有其他曲线都是短Weierstrass，很可能是这样。还是奇怪的行为，甚至验证了曲线。建议你用LibNasdium代替这个lib，我想ECDH比PrimeMont好