可以用私钥加密/用公钥解密吗？
[免责声明：我知道，如果您对加密有任何了解，您可能会告诉我为什么我做错了 - 我已经做了足够多的谷歌搜索，知道这似乎是典型的反应。]
假设以下情况：您有一个想要为给定域发布登录 cookie 的中央机构。在此域中，您不一定信任每个人，但您有一些应该能够读取 cookie 的关键端点。我说了一些，但实际上，“值得信赖”的合作伙伴的数量可能很大。 cookie 不包含太多信息 - 用户名、时间戳、到期日、随机数。当然，出于性能原因，即使在加密之后（在合理范围内），它也应该保持很小。现在，存在两个安全问题：
1）我们不信任该域上的每个网络服务器都拥有用户数据。因此，读取 cookie 的能力应仅限于这些值得信赖的合作伙伴。 2) 虽然我们相信这些合作伙伴能够保护我们用户的数据，但我们仍然希望中心授权点不可伪造（同样，在合理范围内）。
现在，如果我们为权威机构生成一个 RSA 私钥并保密，并将公钥仅分发给“可信合作伙伴”，那么我们应该能够使用私钥进行加密，并让拥有公钥的任何人都可以读取它。我不清楚的是，是否仍然需要对消息进行签名，或者解密行为是否可以证明它是使用私钥生成的？与将对称密钥传播给所有相关方并使用它进行加密，而仅使用私钥进行签名相比，该方案是否会更好或更差？当然，请随意告诉我这是一个愚蠢的想法，但请记住，实际的论据可能比重复爱丽丝和鲍勃更有说服力。
哦，欢迎提供实现指针，尽管可以在 Google 上找到基础知识，如果涉及任何“陷阱”，那将很有用！
[Disclaimer: I know, if you know anything about crypto you're probably about to tell me why I'm doing it wrong - I've done enough Googling to know this seems to be the typical response.]
Suppose the following: you have a central authority that wants to issue login cookies for a given domain. On this domain, you don't necessarily trust everyone, but you have a few key end-points who should be able to read the cookie. I say a few, but in practice this number of "trusted" partners may be large. The cookie doesn't contain much information - a username, a timestamp, an expiry, a random number. It should remain small of course, for performance reasons, even after encryption (within reason). Now, there are two security issues:
1) We don't trust every webserver on this domain with user data. For this reason, the ability to read the cookie should be restricted to these trusted partners.
2) While we trust these partners to protect our user's data, we'd still like the central point of authority to be unforgeable (again, within reason).
Now, if we generate a private RSA key for the authority and keep it secret, and distribute the public key only to the "trusted partners", we should be able to encrypt with the private key and have it readable by anyone with the public key. What I'm unclear on is, would it still be necessary to sign the message, or would the act of decrypting be evidence that it was generated with the private key? Is this any way in which this scheme would be better or worse than disseminating a symmetric key to all parties involved and using that to encrypt, while using the private key merely to sign? And of course feel free to tell me all the ways this is a stupid idea, but bear in mind that practical arguments will probably be more convincing than rehashing Alice and Bob.
Oh, and implementation pointers would be welcome, though one can find the basics on Google, if there are any "gotchas" involved that would be useful!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
Nate Lawson 解释了此处和< a href="http://rdist.root.org/2007/05/03/rsa-public-keys-are-not-private-implementation/" rel="noreferrer">这里为什么你可以'不要安全地使用公钥作为保密的解密密钥（这是一个微妙的点，并且在您之前很多其他人都犯过一个错误，所以不要感到难过！）。
只需使用您的公钥来签署真实性，并使用单独的对称密钥来保密。
我已经阅读了足够多关于针对公钥系统（尤其是 RSA）的有趣攻击的文章，我完全同意这个结论：
（这意味着：用公钥加密，用私钥签名，其他任何事情都是在玩火。）
附录：
如果您有兴趣减少生成的 cookie 的大小，您应该考虑使用 ECDSA 而不是 RSA 来生成签名 - ECDSA 签名比同等安全系数的 RSA 签名小得多。
Nate Lawson explains here and here why you can't securely use the public key as a closely-held secret decryption key (it's a subtle point, and a mistake plenty of others have made before you, so don't feel bad!).
Just use your public key to sign for authenticity, and a separate symmetric key for the secrecy.
I've read enough on interesting attacks against public key systems, and RSA in particular, that I agree absolutely with this conclusion:
(That means: Encrypt with the public key, sign with the private key, and anything else is playing with fire.)
Addendum:
If you're interesting in reducing the size of the resulting cookies, you should consider using ECDSA rather than RSA to produce the signatures - ECDSA signatures are considerably smaller than RSA signatures of an equivalent security factor.
在密码学中，你就是你所知道的。在您的场景中，您有一个能够发布 cookie 的中央机构，并且您不希望其他实体能够执行相同的操作。所以中央当局必须“知道”一些私人数据。此外，您希望“受信任的 Web 服务器”能够访问 cookie 的内容，并且您不希望任何人都读取 cookie。因此，“可信网络服务器”也必须拥有自己的私有数据。
正常的方式是，权威机构对 cookie 应用数字签名，并使用可信 Web 服务器已知的密钥对 cookie 进行加密。您的想法如下所示：
尽管这样的方案可能可行，但我发现其中存在以下问题：
目前正在研究同类型中保证机密性和可验证完整性的问题。您可以查找signcryption。目前还没有既定的标准。
基本上，我认为您会对更经典的设计感到更满意，数字签名仅用于签名，并且（对称或非对称）加密用于机密部分。这将允许您使用现有的库，并使用尽可能少的自制代码。
对于签名部分，您可能需要使用 DSA 或 ECDSA：它们产生更短的签名（对于安全性相当于 1024 位 RSA 签名的 DSA 签名，通常为 320 位）。从中央机构的角度来看，ECDSA 还可以提供更好的性能：在我的 PC 上，使用单核，OpenSSL 每秒处理超过 6500 个 ECDSA 签名（在 P-192 NIST 曲线中），并且“仅”每秒处理 1145 个 RSA 签名。第二个（带有 1024 位密钥）。 ECDSA 签名由两个 192 位整数组成，即需要编码 384 位，而 RSA 签名则为 1024 位长。 P-192 中的 ECDSA 被认为至少与 RSA-1024 一样强大，甚至可能更强。
In cryptography you are what you know. In your scenario, you have a central authority which is able to issue your cookies, and you want no other entity to be able to do the same. So the central authority must "know" some private data. Also, you want the "trusted web servers" to be able to access the contents of the cookies, and you do not want just anybody do read the cookies. Thus, the "trusted web servers" must also have their own private data.
The normal way would be that the authority applies a digital signature on the cookies, and that the cookies are encrypted with a key known to the trusted web servers. What your are thinking about looks like this:
Although such a scheme may work, I see the following problems in it:
The problem of ensuring confidentiality and verifiable integrity in the same type is currently being studied. You may look up signcryption. There is no established standard yet.
Basically I think you will be happier with a more classical design, with digital signatures used only for signing, and (symmetric or asymmetric) encryption for the confidentiality part. This will allow you to use existing libraries, with the least possible homemade code.
For the signature part, you may want to use DSA or ECDSA: they yield much shorter signatures (typically 320 bits for a DSA signature of security equivalent to a 1024-bit RSA signature). From the central authority point of view, ECDSA also allows better performance: on my PC, using a single core, OpenSSL crunches out more than 6500 ECDSA signatures per second (in the P-192 NIST curve) and "only" 1145 RSA signatures per second (with a 1024-bit key). The ECDSA signatures consist in two 192-bit integers, i.e. 384 bits to encode, while the RSA signatures are 1024-bit long. ECDSA in P-192 is considered at least as strong, and probably stronger, than RSA-1024.
您应该使用某种数字签名方案或其他某种机制来解决您的场景的完整性问题。
加密本身还不够。
你怎么知道解密的消息就是它应该是什么？
解密使用正确密钥加密的 cookie 肯定会提供“有效”cookie，但是当您解密使用错误密钥加密的 cookie 时会发生什么？或者只是一些无意义的数据？好吧，你可能会得到一个看起来有效的 cookie！ （时间戳在您认为有效的范围内，用户名合法，随机数是......呃......一个数字，等等）。
在我所知道的大多数非对称加密算法中，没有内置验证。这意味着使用错误的密钥解密消息不会“失败” - 它只会给您一个错误的明文，您必须将其与有效的明文区分开来。这就是完整性发挥作用的地方，最常见的是使用数字签名。
顺便说一句，RSA 经过长期研究，并且有几个“陷阱”，因此，如果您计划从头开始实现它，您最好提前阅读如何避免创建“相对容易破解”的密钥。
You should use a digital sigantures scheme of some sort, or some other mechanism that is aimed to solve the integrity problem of your scenario.
The encryption itself isn't enough.
How would you know that the decrypted messege is what it should be?
Decrypting a cookie encrypted with the right key will surely provide a "valid" cookie, but what happens when you decrypt a cookie encrypted with the wrong key? or just some meaningless data? well, you might just get a cookie that looks valid! (the timestamps are in the range you consider valid, the username is legal, the random number is... uh... a number, etc.).
In most asymmetric encryption algorithms I know off, there is no built-in validation. That means that decrypting a message with the wrong key will not "fail" - it will only give you a wrong plaintext, which you must distinguish from a valid plaintext. This is where integrity comes to play, most commonly - using digital signatures.
BTW, RSA is long studied and has several "gotchas", so if you plan to implement it from scratch you better read ahead on how to avoid creating "relatively easy to break" keys.
根据定义，公钥是公开的。如果您使用私钥加密并使用公钥解密，那么就无法避免窥探。它都说：“这些数据来自持有私钥 X 的人 X”，任何人都可以验证这一点，因为密钥的另一半是公开的。
如何阻止你不知道的人不信任将公钥 X 放在您不信任的服务器上？
如果您希望在两个服务器之间建立安全的通信线路，则需要让所有这些受信任的服务器都有自己的公钥/私钥对，对于一台这样的服务器，我们将使用密钥对 Y。
然后，服务器 X 可以使用私钥 X 和公钥 Y 加密消息。这表示“服务器 X 发送了一条只有 Y 可以读取的消息，并且 Y 可以验证它来自 X”。
（该消息应包含一个短期对称密钥，因为公钥加密非常耗时。）
这就是 SSL 的作用。它使用公钥加密来设置会话密钥。
话虽这么说，使用图书馆。这东西很容易搞砸。
Public keys are by definition, public. If you're encrypting with a private key and decrypting with a public key, that's not safe from prying eyes. All it says: "this data is coming from person X who holds private key X" and anyone can verify that, because the other half of the key is public.
What's to stop someone you don't trust putting public key X on a server you don't trust?
If you want a secure line of communication between two servers, you need to have all of those trusted servers have their own public/private key pairs, we'll say key pair Y for one such server.
Server X can then encrypt a message with private key X and public key Y. This says "server X sent a message that only Y could read, and Y could verify it was from X."
(And that message should contain a short-lived symmetric key, because public key crypto is very time-consuming.)
This is what SSL does. It uses public key crypto to set up a session key.
That being said, use a library. This stuff is easy to screw up.
对于您的问题的答案“解密行为是否可以证明它是使用私钥生成的”，如果接收者可以对数据进行简单的验证，答案是肯定的。假设您有“用户名：John，时间戳：，到期日：dd/mm/yyyy”。现在，如果使用错误的公钥进行解密，您将有可能得到“用户名：<一些字母>，时间戳：<仅数字>，过期时间：??/??/????”为零。您可以使用正则表达式 (regex) 进行验证，例如“用户名：[a-zA-Z]+，时间戳：[0-9]+，过期时间：...”，然后删除验证失败。您甚至可以检查日期是否在 1 到 31 之间，月份是否在 1 到 12 之间，但您无法使用它，因为如果使用错误的公钥，正则表达式通常会在“用户名：”处失败。如果验证成功，您仍然需要检查时间戳并确保没有重放攻击。
但是，请考虑以下事项：
如果您仍然想使用这种方法，并且能够仅将公钥分发给“受信任的合作伙伴”，您应该生成一个随机会话密钥（即对称密钥），并使用私钥对其进行加密密钥并发送给所有拥有公钥的接收者。然后，您使用会话密钥加密 cookie。您可以定期更改会话密钥。更罕见的是，您还可以更改公钥：您可以生成新的公钥/私钥对，并使用会话密钥对公钥进行加密，然后将其发送给所有收件人。
The answer to your question "would the act of decrypting be evidence that it was generated with the private key", the answer is yes if the recipient can do simple validation of the data. Say you have "User name : John, timestamp : <number>, expiry : dd/mm/yyyy". Now if a wrong public key is used to decrypt, the probability that you will get "User name : <some letters>, timestamp : <only numbers>, expiry : ??/??/????" is zero. You can validate using a regular expression (regex) like "User name : [a-zA-Z]+, timestamp : [0-9]+, expiry : .... " and drop it validation fails. You can even check if the day is between 1 and 31, month is between 1 and 12 but you won't get to use it as regex will typically fail at "User name : " if wrong public key is used. If validation succeeds you still have to check the timestamp and ensure that you don't have a replay attack.
However, consider the following:
If you still want to use this approach, and are able to distribute the public key only to the "trusted partners", you should generate a random session key (i.e. symmetric key), encrypt it using the private key and send to all recipients who have the public key. You then encrypt the cookie using the session key. You can change the session key periodically. More infrequently you can change the public key also: you can generate a new public/private key pair and encrypt public key with the session key and send it to all recipients.
我假设您信任“可信合作伙伴”来解密和验证 cookie，但不希望他们能够生成自己的 cookie？如果这不是问题，您可以使用更简单的系统：将密钥分发给所有各方，并使用它来加密 cookie 并为其生成 HMAC。不需要公钥加密，不需要多个密钥。
I presume you trust the 'trusted partners' to decrypt and verify the cookie, but don't want them to be able to generate their own cookies? If that's not a problem, you can use a much simpler system: Distribute a secret key to all parties, and use that to both encrypt the cookie and generate an HMAC for it. No need for public key crypto, no need for multiple keys.
作为密钥分发方法的替代方法（可能适合也可能不适合您的应用程序），请考虑使用 Kerberos，它使用对称密钥加密、控制所有密钥材料的单一高度保护的堡垒服务器以及一组巧妙的协议（请参阅李约瑟协议)
As an alternative to your key distribution approach, which may or may not be suitable in your application, consider using Kerberos, which uses symmetric key encryption, a single highly protected bastion server that controls all the keying material, and a clever set of protocols (See the Needham-Schroder protocol)