为什么我们不应该在非对称加密系统中使用私钥进行加密?
在非对称密码系统的标准使用中,使用公钥进行加密,使用私钥进行解密。
反过来,“用私钥加密”就称为“签名”。
尽管存在术语并且缺乏直接工具,标准工具仍允许实现使用私钥进行加密的加密系统。
谁能清楚地解释为什么这样的解决方案容易受到攻击?
用户案例:
考虑爱丽丝想以非传统方式向鲍勃发送一些东西:
爱丽丝和鲍勃曾经见过面,爱丽丝给了鲍勃一个从她创建的私钥生成的“公钥”,但她警告鲍勃保守秘密。她对私钥保密,并且从未将公钥提供给其他任何人。
鲍勃能否确定他从爱丽丝收到的消息(假设这些消息是由爱丽丝私钥加密的)只能由他读取(假设他确实对爱丽丝公钥的副本保密)?
如何将这种加密可靠性与传统方式(在我们的例子中,鲍勃向爱丽丝发送消息(由爱丽丝的公钥加密))进行比较?
问题是什么
非对称密钥被命名为“私有”和“公共”这一事实无助于理解我的问题。密钥具有基础属性,是我广播“公钥”,赋予它“公共”属性。在回答之前请明确这一区别:我不是考虑这些密钥的“公共”和“私有”属性,而是考虑“私钥”加密与“公钥”加密的可靠性。
我不能使用其他术语,即使它在这种特殊情况下会产生误导。
我知道这种情况是非传统的,可能会导致一些不一致,或者不是非对称加密系统的重点,因为鲍勃和爱丽丝在这里共享某种共同的秘密,这不是非对称加密的重点。
我看到几个 Stackoverflow 答案表明“私钥”和“公钥”是可以交换的(只需阅读下面的答案)。对于 RSA 来说情况并非如此,因为从秘密密钥生成公钥很简单,并且保证反过来在计算上不可行。对于非信徒来说,openssl 使用 RSA 生成密钥的过程是:
- 生成密钥,
- 从密钥中提取公钥。
如果“私钥”和“公钥”之间存在如此大的差异,那么“私钥”加密与传统的“公钥”加密之间是否存在可靠性差异?
长选答案的简短回答
对“私钥”到底是什么的误解对我没有帮助。 “私钥”有两种不同的定义。 “实用私钥”和“理论私钥”。
RSA 理论中的理论私钥与公钥具有数学对称性:
- 您无法从另一种中推断出任何
- 一种加密方法都同样可靠
来自 RSA 工具(如 openssl)的实用私钥实用私钥 )出于效率原因包含附加信息,并且通常,公钥的一部分甚至是按惯例设置的。这些假设打破了对称性:
- 从“实用私钥”获取公钥是微不足道的,
- 但加密仍然同样可靠
有关更多详细信息,请参阅所选答案!如果仍然存在误解,请发表评论...
编辑说明:
- 非对称加密系统密钥对经常被宣传为可交换(即使在当前的 stackoverflow 答案中),我尝试反思这可能是危险的误解这一事实因为现实生活中的工具并非如此。
- 添加了用户案例,我希望这能澄清我的问题
- 添加了最终的“简短答案”
In standard use of asymmetrical cryptographic system, encryption is done with public key, decryption with private key.
Inversing the process, "encryption with private key" is called "signing".
Standard tools, despite terminology and lack of direct tools, allows to implement encryption system that would use the private key for encryption.
Could anyone explain clearly why such solution is vulnerable?
User Case:
Consider that Alice wants to send to Bob some stuff in a non-traditional way:
Alice and Bob once met and Alice gave Bob a "public key" generated from a private key she created BUT she warned Bob to keep it secret. AND she kept secret the private key, and didn't ever give to anyone else the public key.
Could Bob be sure that messages he receives from Alice (provided these are encrypted by Alice private key) are only readable by him (provided he really kept his copy of Alice's public key secret)?
And how compares this encryption solidity to the traditional way, which would, in our case, be Bob sending messages (encrypted by the public key of Alice) to Alice?
What the question is about
The fact that asymmetrical keys are named "private" and "public" doesn't help understanding my question. Keys have underlying properties, and it's me broadcasting the "public key" that gives it its "public" property. Please make this distinction clear before answering: I'm not considering the "public" and "private" properties of these keys but the solidity of the "private key" encryption versus "public key" encryption.
I cannot use another terminology even if it is misleading in this special case.
I know that this case is non-traditional, and could lead to several inconsistency, or is not the point of the asymmetrical crypto systems as Bob and Alice here share some sort of a common secret and that's not the point of asymmetrical crypto.
I saw several Stackoverflow answers which suggest that "private key" and "public key" are exchangeable (just read below answers). This is not true for RSA as it is trivial to generate the public key from the secret key and this is guaranteed not to be computationally feasible in the other way round. For non-believers, the process of key generation in openssl with RSA is:
- generate a secret key
- extract the public key from the secret key.
If there are so big differences between "private key" and "public key", is there a solidity difference between "private key" encryption versus traditional "public key" encryption?
Short answer from long selected answer
Misunderstanding on what exactly is the "private key" wasn't helping me.
There's two different definition of "private key". The "practical private key", and the "theoretical private key".
Theoretical private key from RSA theory shares mathematical symmetricity with public key:
- You cannot deduce one from the other
- Encryption is equally solid in either way
Practical private key from RSA tools (like openssl) contains additional information for efficiency reason, and often, a part of the public key is even set by convention. These assumptions breaks the symmetricity:
- It is trivial to get public key from "pratical private key"
- But encryption remains equally solid
For more detail, see the selected answer ! Please comment if misconceptions remains...
Edit note:
- Asymmetrical crypto system key pairs are frequently advertised as swappable (even in current stackoverflow answers), I try to bring reflexion around the fact that it could be dangerous misunderstanding as it isn't the case in REAL life tools.
- Added the user case, I hope this will clarify my question
- Added final 'short answer'
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
这取决于谁在做什么。假设爱丽丝想要向鲍勃发送一条只有鲍勃可以解码的消息。 Alice 使用 Bob 的公钥(根据“公钥”的标准定义,即除其所有者之外的人所知的密钥)对消息进行加密。现在只有知道 Bob 私钥的人(大概唯一知道 Bob 私钥的人实际上是 Bob)才能解密 Alice 发给 Bob 的消息。
如果 Alice 希望 Bob 知道只有她可以发送该消息,则假设 Bob 知道她的公钥,她可以在使用 Bob 的公钥加密消息之前或之后使用自己的私钥加密该消息。假设她用自己的私钥加密消息,然后用 Bob 的公钥加密结果。要读取消息,Bob 必须使用他(Bob)的私钥解密消息,然后使用 Alice 的公钥再次解密结果。如果他现在读到的是合理的文本,他就知道是同时知道 Alice 的私钥(大概是 Alice)和他的公钥(可能是任何人)的人发送了该消息。
实际上,非对称算法的计算成本很高,因此您真正要做的就是选择适当长度的随机会话密钥和商定的标准对称加密算法(例如 AES)。然后,使用(相对较快的)对称算法对主消息进行加密,并作为消息的一部分发送。消息的另一部分是加密的或双重加密的随机会话密钥。 Bob可以解密消息的会话密钥部分以获得会话密钥;然后他用它来解密消息的主要部分。
请注意,如果您要向许多人发送消息,则可以对消息使用一种适当的加密,然后使用收件人的公钥为每个收件人加密一次会话密钥。每个接收者只能使用属于他们的密钥来解密会话密钥信息,但实际上所有人都可以解密它。如果消息很大(例如 2 MB 的 PDF),那么这比使用每个收件人公钥单独加密消息要经济得多。
不;签名是一项单独的操作。如果您阅读 Schneier 的“实用密码学”,您会发现作者建议使用一种用于加密的公钥/私钥对,以及用于签名工作的第二对。例如,签名使用签名密钥中的私钥对原始消息的固定长度哈希进行加密。任何知道签名密钥的公钥部分的人都可以解密签名以获得原始消息的哈希值。据推测,同一接收者也可以解密该消息(使用签名密钥对的公钥),然后可以检查接收到的消息的散列是否与从签名导出的散列相匹配。任何不匹配都表明存在问题,并且应丢弃该消息。
有很多方法可以完成这些操作 - 取决于安全要求。
但基本点是,一个人知道非对称密钥的私钥,并且可能有很多人知道非对称密钥的公共部分(这是完全安全的)。发送者可以使用接收者的公钥对数据进行加密;发送者也可以使用自己的私钥对其进行加密。接收者可以使用自己的私钥解密收到的消息,如有必要,还可以使用发送者的公钥。
IMNSHO,即使在 2009-09-05T13:00-07:00 左右修正,这个问题也不完全连贯。
您应该阅读“实用密码学”中的第 13 章“RSA”(可能也在阅读了前面的一些章节之后 - 最值得注意的是第 3.3 节公钥加密)。
加密和解密的符号
让我们定义一些符号来讨论正统的公钥密码学。让我们从基本的对称加密开始:
到目前为止,这种表示法适用于对称加密,因为加密和解密都使用相同的 K 值。任何知道 K(以及算法,但 Kerckhoff 原理“秘密在于密钥”意味着您假设攻击者知道算法 - 任何相反的假设都是加密“万金油”)的人都可以解密该消息。
对于非对称加密系统,Ea 和 Da 是算法 A 的加密和解密方法。非对称密码的关键区别特征是密钥 K< Ea 使用的 sub>encrypt 与 Da 使用的密钥 Kdecrypt 不同。此外,为了实用,即使您知道 K加密,也必须在计算上无法推导出 K解密,反之亦然。
通过非对称加密,Alice 创建一对密钥 (Salice, Palice)。按照惯例,Salice 是秘密密钥,Palice 是公钥。请注意,爱丽丝知道这两个密钥。重要的是:
类似地,Bob 将创建一对密钥(Sbob, Pbob)。请注意:
Alice 向 Bob 发送消息
现在,当 Alice 想要向 Bob 发送消息 Malice-bob 以便 Bob 可以读取该消息(但其他人无法读取)时,她必须对其进行加密使用 Bob 的密钥 Pbob。因此,她创建了一条消息:
Bob 知道(从外部证据)消息是用 Pbob 加密的,所以他知道他必须用 Sbob 解密:
然而,此时,他所知道的有关该消息的全部信息是它来自一个知道他的 Pbob 键的人。除了通过外在证据,他不知道它来自爱丽丝。
如果 Bob 和 Alice 同意必须对他们的消息进行加密,以便他们都确信收到的消息来自对方,那么双方都必须确信除了 Alice 之外没有人知道 Salice,并且除了 Bob 之外没有人认识 Sbob。他们还必须确信鲍勃认识 Palice,并且鲍勃必须确信 Palice 确实属于 Alice,并且 Pbob > 为 Alice 所知,并且 Alice 必须确信 Pbob 确实属于 Bob。 PKI(公钥基础设施)的主要内容就是建立这些信任关系。
假设满足这些条件,那么 Alice 可以将她的消息发送给 Bob,从而让 Bob 确信只有 Alice 可以发送该消息。如前所述,该机制是双重加密:
爱丽丝将 C2alice-bob 发送给 Bob(以及一些签名或 MAC,以确认它在传输过程中没有损坏),然后 Bob 计算:
如果一切按计划进行,D2alice-bob = Malice -鲍勃。
RSA 密钥对的机制
RSA 加密算法基于以下事实:如果您有两个公开的数字(它们是一个公钥的两个部分),则指数 e 和模 n ,然后给定消息m,很容易计算c = me > mod n。然而,仅根据 c(以及 e 和 n)来推导出 m 在计算上是不可行的。但是,如果您知道另一个指数 d,那么您可以神奇地计算 r = cd > mod n,并且 r = m 如果您计算了 e、d 和 n 适当地。在不知道其他信息的情况下,从 e 和 n 计算 d 是不可行的。
在 RSA 加密方案下,您开始使用两个(大的)随机确定的素数:p 和 q,它们的乘积是 n。 RSA 算法基于以下事实:分解 n 极其困难(仅在给定 n 的情况下确定 p 和 q em>);如果有人找到一种简单的方法来分解大数,那么 RSA 算法就会立即被破解。
一旦获得n,您需要确定指数e和d,使得:
您可以选择两个值之一作为小奇数 - 例如,Schneier 和 Ferguson 建议 e = 3。然后,您可以使用他们在大约 6 页的书中介绍的一些计算来计算d。通常,d 将是一个相当大的数字。然后,您可以将这对 (e, n) 作为复合公钥发布,同时保留值 (p, q, t, d) 秘密作为私钥。给定 e 和 n,如果不首先对 n 进行因式分解,则推导出 d 在计算上是不可行的。 “实用密码学”建议使用两个不同的对 (e1、d1) 和 (e 2、d2),源自相同的值 n,其中使用 e1 用于加密消息,e2 用于数字签名;他们甚至建议使用值 3 和 5。
OpenSSL 和密钥生成
我认为您对 OpenSSL 如何生成 RSA 密钥的描述很混乱。
生成过程首先必须生成大的随机素数,即上面符号中的 p 和 q。有一些随机方法可以确定给定的大数是否(可能)是素数;计算两个这样的素数需要一些时间。总而言之,它们首先用于计算 n,然后计算 d(假设 e 是通过某种约定建立的)。您在 OpenSSL 中看到的两个阶段是确定n,然后确定d。
用户案例剖析
问题说:
到目前为止,一切都很好。 “公钥”不是很公开,但这并没有什么坏处。
如果加密技术有任何用处,那么可以;只有爱丽丝和鲍勃可以读取爱丽丝用她的秘密密钥加密的消息,因为只有爱丽丝和鲍勃知道与她的秘密密钥相关的公钥。
混乱:该部分首先讨论 Alice 向 Bob 发送消息;现在您已切换到鲍勃向爱丽丝发送消息。
当鲍勃和爱丽丝见面时,爱丽丝给了鲍勃她的 Palice 公钥。据推测,鲍勃也给了爱丽丝他的 Pbob 公钥。而且这两个公钥的公共流通量都非常有限——这很好,但对系统的安全性来说并不重要。
现在,当鲍勃想要向爱丽丝发送消息时,他可以使用她的 Palice 公钥对其进行加密,而爱丽丝(并且只有爱丽丝)可以使用她的 Salice 解密该消息。子>秘密密钥。或者,Bob 可以使用他的 Sbob 密钥加密该消息,Alice 可以使用 Bob 的 Pbob 公钥对其进行解密。两组加密和解密都可以工作。
使用正确的私钥加密并使用正确的公钥解密与使用正确的公钥加密并使用正确的私钥解密同样可靠。区别在于谁可以执行哪些操作。如果您清楚地了解谁在进行加密、谁在进行解密以及谁知道哪些密钥,那么这些方法的保密性就会变得相当清晰。
好吧,你的情况中的“公钥”并不是那么广为人知,但这就是它的不寻常之处。
非对称加密方案的要点在于,攻击者(通常称为 Eve,窃听者)是否知道公钥并不重要。只要 Alice 和 Bob 保密私钥,消息就可以安全地发送。但是,您必须了解,如果 Alice 向 Bob 发送一条仅由 Alice 的密钥加密的消息,则任何知道 Alice 公钥的人(例如 Eve)都可以读取该消息。 Eve 无法创建声称来自 Alice 的虚假消息,除非她也知道密钥 - 如果 Eve 发现了 Alice 的密钥,Eve 可以随时假装是 Alice。但她能读懂。如果爱丽丝向鲍勃发送一条仅由鲍勃的公钥加密的消息,则只有鲍勃可以读取该消息(使用他的密钥),但鲍勃无法知道该消息是否确实来自爱丽丝,或者夏娃是否假装发送该消息是爱丽丝。这就是为什么您必须努力确保鲍勃知道只有爱丽丝可以发送该消息,并且爱丽丝知道只有鲍勃可以读取该消息。
It depends on who is doing what. Suppose Alice wants to send a message to Bob that only Bob can decode. Alice encrypts the message using Bob's public key (under the standard definition of 'public key', meaning the one that is known to people other than its owner). Now only someone who knows Bob's private key (presumably, the only person who knows Bob's private key is in fact Bob) can decrypt Alice's message to Bob.
If Alice wants Bob to know that only she could have sent it, she can encrypt the message with her own private key, assuming Bob knows her public key, either before or after encrypting the message with Bob's public key. Let's assume she encrypts the message with her private key, then the result with Bob's public key. To read the message, Bob has to decrypt the message with his (Bob's) private key, and then decrypt the result again with Alice's public key. If what he reads is now sensible text, he knows that someone who knows both Alice's private key (presumably Alice) and his public key (could be anyone at all) sent the message.
In practice, the asymmetric algorithms are expensive to compute, so what you really do is choose a random session key of an appropriate length and an agreed upon standard symmetric encryption algorithm such as AES. Then the main message is encrypted with the (relatively fast) symmetric algorithm and sent as one part of the message. The other part of the message is the encrypted - or doubly encrypted - random session key. Bob can decrypt the session key section of the message to obtain the session key; he then uses that to decrypt the main part of the message.
Note that if you are sending a message to many people, you can use one encryption of the message proper, and then encrypt the session key once for each recipient, using the recipient's public key. Each recipient can only decrypt the session key information using the key that belongs to them, but all can actually decrypt it. If the message is substantial (say 2 MB of PDF), then this is much more economical than separately encrypting the message with each recipients public key.
No; signing is a separate operation. If you read Schneier's "Practical Cryptography", you'll see that the authors suggest using one public/private key pair for encryption, and a second pair for signature work. For example, a signature encrypts a fixed length hash of the original message using the private key from the signing key. Anybody who knows the public key part of the signing key can then decrypt the signature to obtain the hash of the original message. Presumably, the same recipient can also decrypt the message (using the public key of the signature key pair), and then can check that the hash of the message received matches the hash derived from the signature. Any mismatch indicates a problem and the message should be discarded.
There are many ways to do these things - depending on the security requirements.
But the basic point is that one person knows the private key of an asymmetric key, and potentially many people know the public part of the asymmetric key (and this is perfectly safe). Data can be encrypted by the sender using the recipients public key; it may also be encrypted by the sender using their own private key. The recipient can decrypt the received message using their own private key and, if necessary, using the sender's public key.
The question, even as amended at about 2009-09-05T13:00-07:00, is not completely coherent, IMNSHO.
You should read chapter 13 "RSA" in "Practical Cryptography" (probably after reading some of the earlier chapters too - most notably section 3.3 Public-Key Encryption).
Notation for Encryption and Decryption
Let's define a bit of notation for discussing orthodox public key cryptography. Let's start with basic symmetric encryption:
So far, this notation applies to symmetric encryption because the same value K is used in both encryption and decryption. Anyone who knows K (and the algorithm, but Kerckhoff's Principle that 'secrecy is in the keys' means that you assume the attackers know the algorithm - any contrary assumption is cryptographic 'snake oil') can decrypt the message.
With an asymmetric encryption system, Ea and Da are the encryption and decryption methods for algorithm A. The key distinguishing feature of an asymmetric cryptographic cipher is that the key Kencrypt used by Ea is different from the key Kdecrypt used by Da. Further, to be practical, it must be computationally infeasible to deduce Kdecrypt even if you know Kencrypt and vice versa.
With asymmetric encryption, Alice creates a pair of keys, (Salice, Palice). Conventionally, Salice is the secret key and Palice is the public key. Note that Alice knows both keys. All that matters is:
Similarly, Bob will create a pair of keys, (Sbob, Pbob). Note that:
Alice sends a message to Bob
Now, when Alice wants to send a message, Malice-bob, to Bob so that Bob can read it (but no-one else can), she has to encrypt it with Bob's key Pbob. So, she creates a message:
Bob knows (from external evidence) that the message was encrypted with Pbob, so he knows that he must decrypt it with Sbob:
However, at this point, all he knows about the message is that it came from someone who knew his Pbob key. He does not know that it came from Alice except via extrinsic evidence.
If Bob and Alice agree that their messages must be encrypted such that they are both confident that the message received came from the other, then both must be confident that no-one other than Alice knows Salice and that no-one other than Bob knows Sbob. They must also be confident that Palice is known to Bob and Bob must be confident that Palice really does belong to Alice, and that Pbob is known to Alice and Alice must be confident that Pbob really does belong to Bob. Establishing these trust relationships is a lot of what PKI (public key infrastructure) is about.
Assuming that these criteria are met, then Alice can send her message to Bob in such a way that Bob is confident that only Alice could have sent it. As outlined previously, the mechanism is a double encryption:
Alice sends C2alice-bob to Bob (along with some signature or MAC to confirm that it was not corrupted in transit), and then Bob computes:
If everything has gone according to plan, D2alice-bob = Malice-bob.
Mechanics of RSA Key Pairs
The RSA encryption algorithm is based on the fact that if you have two publicly known numbers (which are two parts of one public key), the exponent e and the modulus n, then given a message m, it is easy to compute c = me mod n. However, it is computationally infeasible to deduce m given just c (and e and n). If, however, you know another exponent, d, then you can magically calculate r = cd mod n, and r = m if you have computed e, d and n appropriately. It is not feasible to compute d from e and n without knowing some other information.
Under the RSA encryption scheme, you start work with two (large) randomly determined prime numbers, p and q, and their product is n. The RSA algorithm is predicated on the fact that it is extremely difficult to factor n (determine p and q given just n); if anyone ever finds an easy way of factoring large numbers, then the RSA algorithm is instantly broken.
Once you have n, you need to determine exponents e and d such that:
You can choose one of the two values as a small odd number - Schneier and Ferguson suggest e = 3, for example. You then calculate d using some computations that they cover in about 6 pages of their book. Typically, d will be a rather large number. You can then publish the pair (e, n) as the composite public key, keeping the values (p, q, t, d) secret as the private key. Given e and n, it is not computationally feasible to deduce d without first factoring n. "Practical Cryptography" suggests using two different pairs (e1, d1) and (e2, d2), derived from the same value n, where you use e1 to encrypt messages, and e2 for digital signatures; they even suggest using the values 3 and 5 for these.
OpenSSL and Key Generation
Your description of how the RSA keys are generated by OpenSSL is confused, I believe.
The generation process first has to generate to large random prime numbers, p and q in the notation above. There are stochastic methods for determining whether a given large number is (probably) prime; it takes a little while to compute two such prime numbers. Taken together, these are used to compute first n, and then d (assuming e is established by some convention). The two stages you see in OpenSSL are determining n, and then determining d.
Dissection of User Case
The question says:
So far, so good. The 'public key' isn't very public, but there's no harm in that.
If the encryption technology is of any use, then yes; only Alice and Bob can read the message that Alice encrypted with her secret key because only Alice and Bob know the public key that goes with her secret key.
Confusion: the section started by discussing Alice sending messages to Bob; now you've switched to Bob sending messages to Alice.
When Bob and Alice met, Alice gave Bob her Palice public key. Presumably, Bob also gave Alice his Pbob public key. And both public keys have very limited public circulation - that's good, but not crucial to the security of the system.
Now, when Bob wants to send a message to Alice, he can encrypt it with her Palice public key, and Alice (and only Alice) can decrypt the message using her Salice secret key. Alternatively, Bob could encrypt the message with his Sbob secret key, and Alice could decrypt it with Bob's Pbob public key. Both sets of encryption and decryption would work.
It is equally reliable to encrypt with the correct private key and decrypt with the correct public key as it is to encrypt with the correct public key and decrypt with the correct private key. The difference is in who can do which operation. If you understand clearly who is doing the encrypting and who is doing the decrypting, and who knows which keys, then the secrecy of the methods become fairly clear.
Well, the 'public keys' in your case are not all that widely known, but that's all that's unusual about it.
The whole point of asymmetric encryption schemes is that it does not matter whether the attackers (classically called Eve, the eavesdropper) knows the public key. As long as the private keys are kept private by Alice and Bob, the messages can be sent securely. However, you must understand that if Alice sends a message to Bob that is encrypted only by Alice's secret key, then anyone (such as Eve) who knows Alice's public key can read the message. Eve can't create a fake message that purports to come from Alice unless she also knows the secret key - if Eve discovers Alice's secret key, Eve can pretend to be Alice at any time she likes. But she can read it. If Alice sends a message to Bob that is encrypted only by Bob's public key, then only Bob can read the message (using his secret key), but Bob has no way of knowing whether it actually came from Alice or whether Eve sent it pretending to be Alice. That's why you have to work hard to ensure that Bob knows that only Alice could have sent the message, and Alice knows that only Bob can read the message.
很简单,因为当您加密某些内容时,您正在屏蔽它,以便只有一个人可以读取它(拥有私钥的人)。您不拥有该人的私钥,您拥有的只是他们的公钥。
如果你用你的私钥加密它,任何人都可以用你的公钥解密它——这就是签名的原理——他们可以知道它是用你的私钥加密的!
Simply because when you encrypt something, you are masking it so that only one person can read it (the person with the private key). You do not possess that person's private key, all you have is their public key.
If you are encrypting it with your private key, anyone can decrypt it with your public key - this is the principle of signing - they can tell that it was encrypted by your private key!
更明确地说,“使用私钥加密”意味着要解密,您需要使用公钥。这不是问题,只是任何人都可以解密您的[在此处插入项目],因为公钥就是:public。它对于保护数据没有用处,该系统用于验证数据。
例如,爱丽丝想向鲍勃发送一个文件(是的,是的,向我开枪)。 Alice 不在乎其他人是否可以读取她的文件,这不是机密,但她希望 Bob 确保她发送的内容就是他收到的内容。然后,她可以用她的私钥加密她的文件,而鲍勃可以用她的公钥解密他那一端的文件,确保该文件没有被篡改。但如果其他人正在监听该事务,他们也可以解密并读取该文件。他们就是无法改变它。
对于您提供的情况,更好的方法是在它们相遇时交换密钥,以便实际上有两个密钥对。您自己提到,如果您尝试使用公钥加密,由于算法进行了优化,RSA 实际上不起作用。如果这是其他算法的常见情况,我不会完全感到惊讶。它们被设计为以一种方式运行(私有/加密、公开/解密),并且是一种已知的“昂贵”操作,因此它们在现实中可能会被大量优化。
除此之外,我认为您的计划没有任何安全问题......只要密钥真正保密。私有/公共只是基于典型用法的通用名称。没有什么强迫您完全公开公钥。在您的情况下,您可能喜欢将它们称为“加密密钥”和“解密密钥”,但我不会将每个密钥都用于两者。事实上,我建议您在程序中如此称呼它们,原因由 Jonathan Leffler 在他的评论中给出:
To put it a little more explicitly, 'encryption with a private key' means that to decrypt you need to use the public key. This isn't an issue, except that anyone can then decrypt your [insert item here], since the public key is just that: public. It isn't useful to protect data, this system is used to verify data.
For instance, Alice wants to send a file toBob (yea, yea, shoot me). Alice doesn't care if anyone else can read her file, it's not confidential, but she wants Bob to be sure that what she sent is what he recieved. She can then encrypt her file with her private key, and Bob can decrypt the file on his end with her public key, ensuring that the file hasn't been tampered with. But if someone else is listening in to the transaction, they can also decrypt and read the file. They just can't change it.
For the case you provide, a better way would be exchanging keys when they meet so that there are actually two keypairs. You yourself mentioned that RSA in particular doesn't actually workr if you try to encrypt with the public key because of optimisations made in the algorithm. I wouldn't be entirely surprised if this is a common case with other algorithms. They are designed to be run one way (private/encrypt, public/decrypt) and are a known "expensive" operation, therefore they likely to be heavily optimised in reality.
Other than that, I don't see any security concerns with your plan... As long as the keys are truely kept private. Private/public are just common names based on typical usage. There's nothing forcing you to make a public key fully public. In your case you may like to term them 'encryption key' and 'decryption key', but I wouldn't use each key for both. Infact, I'd recommend you did term them such inside your program, for the reasons given by Jonathan Leffler in his comments:
我认为您错过了公钥/私钥加密的要点(至少据我所知)。
在您遇到的情况下,对称加密也同样有效。使用非对称加密的原因是规模问题。
假设你不仅有鲍勃和爱丽丝,还有字母表中每个字母的虚构人物。这些人希望能够向任何人发送消息,并确保只有收件人才能阅读。使用普通的对称加密,这需要每个人之间共享密钥,因此,如果我们有来自字母镇的 26 个人,即
26x25
密钥,每个人都必须记住并保护 25 个密钥秘密密钥。输入对称(也称为公钥/私钥)加密。现在每个人都有一个私钥和一个公钥,按照正常的规则。要向 Fred 发送消息,您需要查找他的(只有一个)公钥。然后你给他发消息。只有 Fred 可以阅读此消息。在此方案中,您拥有
26x2
密钥,每个人只需要记住并保护 1 密钥。还需要有公钥来源,但这很容易。按照您描述的方式使用非对称加密,每组人都有一对密钥,则需要
26x25x2
密钥。再说一次,这与可扩展性有关。对称方案所需的密钥数量为
N^2-N
,而在非对称方案中,只需2*N
。I think that you are missing the point of public/private key encryption (at least as I understand it).
In the situation you have, symmetric encryption would work just as well. The reason to use non symmetric encryption is a matter of scale.
Say you have, not just Bob and Alice, but imaginary people for every letter of the alphabet. These people want to be able to send messages to anyone, ensuring sure that only the recipient can read it. Using a normal, symmetric encryption, this would require a shared key between every person, so if we have the 26 people from the alphabet town, that is
26x25
keys, with every person having to remember and secure 25 secret keys.Enter symmetric (aka public/private key) encryption. Now every person has a private key, and a public key, with the normal rules. To send a message to Fred, you look up his (and there is only one) public key. Then you send him the message. Only Fred can read this message. In this scheme, you have
26x2
keys, and each person only needs to remember and secure 1 secret key. There also needs to be a source of public keys, but this is easy.Using asymmetric encryption the way you describe, with a pair of keys for every set of people, would then require
26x25x2
keys.So again, it is about scalability. The number of keys needed for symmetric schemes is
N^2-N
, where in asymmetric schemes, it is only2*N
.我不知道是否存在版权问题,但我会引用“Valery Pryamikov”
来自 此论坛< /a>.
I don't know if there are some copyright concerns but I'll quote "Valery Pryamikov"
from this forum.
您滥用了这里的术语。
如果密钥确实是私有和公开的,那么是的,用私钥加密的任何内容都只能通过公钥解密,但如果密钥确实是公开的,则任何人都可以解密。
让我们忽略这一点。
这里的问题是鲍勃知道什么。鲍勃真的知道爱丽丝是否将她的公钥发送给其他人吗?如果不是,他就不能确保只有他才能解密该消息。技术中没有任何东西可以确保这一点。任何用爱丽丝的私钥加密的内容都可以用她的公钥解密,因此任何拥有该密钥的人都可以解密。根据公钥的本质,该人应该是任何人。
确保鲍勃的消息只能由鲍勃解密的唯一方法是鲍勃向爱丽丝提供他的公钥,并让爱丽丝用他的公钥加密她想要发送给鲍勃的所有内容,这将使数据无法解密除了鲍勃之外的任何人。她是否也用她的私钥加密相同的数据(即对数据进行签名)不是重点。
当然,鲍勃同样无法知道爱丽丝没有向其他任何人发送完全相同的消息,并使用其他公钥对其进行加密。
You're misusing the terms here.
If the keys are truly private and public, then yes, anything encrypted with the private key can only be decrypted by the public key, but if the key is truly public, anyone can decrypt that.
Let's disregard that.
The problem here is what Bob knows. Does Bob actually know if Alice sent her public key to anyone else? If not, he can not ensure that only he can decrypt the message. There is nothing in the technology that ensures this. Anything encrypted by Alices private key can be decrypted by her public key, and thus by anyone in possession of that key. By the very nature of public keys, that should be anyone.
The only way to ensure that a message for Bob is only decryptable by Bob is for Bob to give Alice his public key, and make Alice encrypt everything she wants to send to Bob by his public key, which will make the data un-decryptable by anyone except Bob. Whether she also encrypts the same data by her private key (ie. signs the data) is besides the point.
Of course, again, Bob, cannot know that Alice did not send the exact same message to anyone else, encrypting it for others public keys.