这种基于 RSA 的签名（带恢复）方案在加密方面是否可靠？
我正在实现一个简单的许可证文件系统，并且想知道我当前的实现行是否犯了任何错误。
消息数据小于密钥。 我使用 RSA，密钥大小为 3072 位。
许可证的颁发者生成要签名的消息，并使用简单的基于 RSA 的方法对其进行签名，然后应用类似的方法对消息进行加密。 加密的消息和签名一起存储为许可证文件。
- sha512的消息。
- 使用私钥对哈希进行签名。
- 使用私钥对消息进行签名。
- 连接并传输。
收到后，验证过程为：
- 使用公钥解密消息 对
- 消息进行哈希处理 使用公钥
- 从文件中解密哈希值，并与本地哈希值进行比较。
到目前为止，实现工作正常，并且似乎是有效的。
我目前正在对消息进行零填充以匹配密钥大小，这可能是 这是一个糟糕的举动（我想我应该使用 PKCS 填充算法，例如 1 或 1.5？）
这个策略看起来有效吗？ 是否有任何明显的缺陷或我忽略的观点？
I am implementing a simple license-file system, and would like to know if there are any mistakes I'm making with my current line of implementation.
The message data is smaller than the key. I'm using RSA, with a keysize of 3072bits.
The issuer of the licenses generates the message to be signed, and signs it, using a straightforwards RSA-based approach, and then applies a similar approach to encrypt the message. The encrypted message and the signature are stored together as the License file.
- Sha512 the message.
- Sign the hash with the private key.
- Sign the message with the private key.
- Concatenate and transmit.
On receipt, the verification process is:
- Decrypt the message with the public key
- Hash the message
- Decrypt the hash from the file with the public key, and compare with the local hash.
The implementation is working correctly so far, and appears to be valid.
I'm currently zero-padding the message to match the keysize, which is probably
a bad move (I presume I should be using a PKCS padding algorithm, like 1 or 1.5?)
Does this strategy seem valid?
Are there any obvious flaws, or perspectives I'm overlooking?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我注意到的主要缺陷：您必须在解密时验证填充仍然存在。
（如果您提前知道消息长度，那么您可能可以使用自己的填充方案，但正如您提到的那样，使用现有的填充方案可能仍然是一个好主意）。
我不确定你为什么要费心加密消息本身 - 正如你所指出的，任何拥有公钥的人都可以解密它，因此除了混淆之外，它不会添加任何内容。 您也可以只发送消息和加密的填充哈希。
我建议使用提供“签名消息”功能的高级库，例如 cryptlib 或 KeyCzar（如果可以的话）。 这些受益于比您的代码可能看到的更多的眼球，并处理所有棘手的填充问题和类似问题。
The major flaw I noticed: you must verify the padding is still there when you decrypt.
(If you know the message length in advance then you might be able to get away with using your own padding scheme, but it would probably still be a good idea to use an existing one as you mentioned).
I am not sure why you're bothering to encrypt the message itself - as you've noted it can be decrypted by anyone with the public key anyway so it is not adding anything other than obfuscation. You might as well just send the message and the encrypted-padded-hash.
I would recommend using a high level library that provides a "sign message" function, like cryptlib or KeyCzar(if you can). These benefit from a lot more eyeballs than your code is likely to see, and take care of all the niggly padding issues and similar.