我希望（或创建）基于椭圆密钥加密的串行密钥。我想要做的是对序列中的信息进行编码，这些信息可以公开验证，但只能由我创建。最初的想法来自http://www.ssware.com/cryptolicensing/cryptolicensing_net.htm，在那里他们可以创建信息加密的连续出版物。但是，这是基于RSA导致的大量数据。因此，我想自己建立类似的东西。
但是，我认为没有好处：他们选择需要应用和创建者知道的域参数。公钥用于加密（生成串行），而私钥在应用程序中并用于解密。但是，知道域参数和私钥，很容易派生出ECIES的公钥，对吗？
下一个想法是只对信息进行任意编码，并将基于ECDSA的签名附加到其中。但这导致序列号很大。
我真正需要的是类似于http://ellipter.com的解决方案，他们使用正确的概念：生成序列的私钥和验证它们的公钥。它们在屏幕截图中显示的密钥非常短：128位密钥只有大约30个字符。
这样做的正确方法是什么？我错过了正确的方案吗？它不能是ECDSA，也不能是ECIES。还有什么呢？
答案 0 :(得分：4)
您需要的是椭圆曲线digital signature scheme，例如ECDSA。
基本上，您的密钥生成服务器将保留密钥对的私有一半，而您分发的软件将包含公共一半。您的序列密钥将包含一个简单的序列号，以及使用私钥的该号码的签名。当用户输入号码时，软件会使用其公钥检查签名是否有效。
您还可以对产品激活密钥使用相同的方案;在这种情况下，您要签名的数据不仅仅是序列号，而是某种识别用户的摘要字符串，以及他们正在安装软件的系统的某些功能。
现在，坏消息是，不幸的是，对于许可证密钥而言，具有非平凡安全级别的ECDSA签名仍然很长。您可以通过降低安全级别来减少签名长度，但随后可以通过强力伪造签名。基本上，您将在安全性和可用性之间进行权衡。您还可以尝试其他具有短签名的签名方案，例如Schnorr signatures或可能类似McEliece-based signature scheme described in this paper的签名方案，但即使这些方案也可能非常适合用户可键入的许可证密钥。
首先遇到RSA签名形式的数字签名的人通常会感到困惑的是，RSA cryptosystem有点不寻常，因为两者都可以使用相同的基本算法 { {3}}对于数字签名，并且在较低级别，这两个操作是双重的，这样RSA签名操作可以被视为“使用私钥加密”，签名验证可以被视为“使用私钥进行解密”。公钥“（与正常的公钥加密相反）。
然而，对于大多数其他公钥密码系统而言，没有这样的二元性：一般来说，数字签名方案与公钥加密方案完全不同（尽管它们通常基于类似的数学问题）。实际上，即使对于RSA，一旦您开始考虑public-key encryption之类的详细信息，签名和加密操作就会变得不同，如果您想将基本的“教科书RSA”算法转换为可以实际用作安全的内容，这些内容是必不可少的。和实用的密码系统。