是否可以在非对称加密中使用纯加密和解密密钥来代替私钥和公钥?
是否可以使用纯加密和解密密钥来代替私钥和公钥?据我所知,在.Net非对称RSA实现中,私钥RSAParametersparameters = (new RSACryptoServiceProvider()).ExportParameters(true)
是公钥的超集。使用私钥我们可以加密和解密我们的数据。但是我只需要密钥来解密数据。怎么做呢?
我尝试将 RSAParameters 字段清空,但 RSACryptoServiceProvider 对象无法导入此类参数。
Is it possible to use pure Encrypting and Decrypting keys instead of private and public keys? As I know in .Net asymmetric RSA implementation private key RSAParameters parameters = (new RSACryptoServiceProvider()).ExportParameters(true)
is a superset of public key. And using private key we can both encrypt and decrypt our data. But I need key only for decrypting data. How to do it?
I experimented on nulling RSAParameters fields, but RSACryptoServiceProvider object can't import such parameters.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
为了解码数据,您需要公钥或私钥。取决于它是如何编码的。
坚持使用标准模式,并且小心永远不要分发您的私钥。
从您的评论(到各种答案),您只需要签名(数据的哈希值)。使用每个人都拥有的密钥来加密数据是没有用的。
有标准的签名功能和模式。
For decoding data you need either the public or the private key. Depends on how it was encoded.
Stick with the standard patterns, and just be careful never to distribute your private key.
From your comments (to various answers), you just need signing (of a Hash of your data). It is no use to encrypt data with a key that everybody can have.
There are standard functions and patterns for signing.
我认为您需要使用私钥进行解密,使用公钥进行加密。
接收者(解密者)将其公钥发送给发送者(加密者)。因此每个人都可以发送消息,只有接收者可以阅读它们。这是你需要的吗?
如果需要确定消息来自某个发送者,则需要使用自己的私钥添加签名。接收方可以使用发送方的公钥来验证这一点。
I think you need to use the private key for decrypting and the public key for encrypting.
The receiver (decrypter) sends it's public key to the sender (encrypter). So everyone can send messages, only the receiver can read them. It this what you need?
If you need to make sure that the message come from a certain sender, it needs to add a signature by using its own private key. The receiver can verify this by using the senders public key.
如果您想确保私钥持有者无法加密某些内容,从而导致结果与公钥持有者发送的消息无法区分,那么您可以简单地对数据进行双重包装。
只需有两个密钥对即可。
A 方获得密钥对 1 的私钥和密钥对 2 的公钥。
B 方获得密钥对 1 的公钥和密钥对 2 的私钥。B
方首先使用密钥对 1 的公钥加密,然后使用私钥加密来发送他/她/它的消息密钥对 2 的密钥
对。A 方使用密钥对 2 的公钥和密钥对 1 的私钥(按顺序)解密结果。
A方可以生成密钥对1的公钥,但无法生成密钥对2的私钥,因此A方无法生成有效的消息。
反之亦然。
缺点:如果您有一个中心人(或服务器),每个其他人(或计算机)都与之通信,则各方都需要自己的私钥,并且他们需要与中心人(或服务器)共享相应的公钥)他们正在沟通。
If you want to make sure that the private key-holder cannot encrypt something such that the result is indistinguishable from a message sent by the public key-holder, then you could simply double-wrap your data.
Simply have two key-pairs.
Side A gets the private key of key-pair 1, and the public key of key-pair 2.
Side B gets the public key of key-pair 1, and the private key of key-pair 2.
Side B sends his/her/its message by first encrypting it with the public key of key-pair 1, and then the private key of key-pair 2.
Side A decrypts the result using the public key of key-pair 2, and the private key of key-pair 1 (in that order).
Side A can generate the public key of key-pair 1, but cannot generate the private key of key-pair 2, so side A cannot generate a valid message.
The inverse works in the other direction.
Down-side: If you have a central person (or server) that every other person (or computer) is communicating with, each party needs their own private key, and they need to share the corresponding public key with the central person (or server) they are communicating with.
如果您问我认为您在问的问题,那么您正在解决这样的问题:
加密一些数据。您将其发送给客户,并希望他们能够解密它,但您不希望他们能够加密任何内容,因为这样他们就可以说服其他客户他们就是你。
很接近吗?您能告诉我们您正在解决什么问题吗?
对于线程中的其他人来说,听起来很明显OP想要一个仅解密密钥,而不是通常的仅加密公钥。
编辑:评论是正确的,因为私钥不能用于加密,但是给定私钥生成公钥并不困难。如果您拥有私钥,则实际上可以同时拥有两个密钥。
编辑 2:OP,您可能应该查看 数字签名。您可以(使用私钥)签署消息,然后使用公钥确认签名,我认为这正是您所要求的。
If you're asking what I think you're asking, you're solving a problem like this one:
You encrypt some data. You send it to clients, and want them to be able to decrypt it, but you do not want them to be able to encrypt anything, because then they could convince other clients that they're you.
Is that close? Can you tell us what problem you're solving?
For the rest of the folks on the thread, it sounds pretty clear the OP wants a decrypt-only key, instead of the usual encrypt-only public key.
Edit: the comments are correct in that a private key can't be used to encrypt, but it's not that difficult to generate the public key given the private key. If you have the private key, you effectively can have both keys.
Edit 2: OP, you should probably look into digital signatures. You could sign a message (using the private key) and then confirm the signature with the public key, which I think is exactly what you asked for.