Re: small security glitches
On 03/03/12 01:25, brian m. carlson wrote: It is not true that encryption amounts to XORing the message text against the secret key. [snip] Also, CFB mode, what is XORed is the output of a block cipher encryption of the previous ciphertext. And the paper exploits exactly this fact by interleaving original ciphertext and chosen ciphertext so they can XOR to get the original keystream for a block of original ciphertext. The paper is only 12 pages, so if the summaries Post Cartner or Tom McCune give are unclear, it won't take forever to read the actual paper to clear it up. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: small security glitches
On Fri, 2 Mar 2012 08:50, d...@fifthhorseman.net said: I believe that GnuPG had its own implementation of such an integrity check before the standardization was settled. Right, since version 1.0.2 (2000-07-12). With version 1.1,91 (2002-08-04) gpg even defaults to MDC packets if one of the modern algorithms is used (e.g. AES of Twofish). PGP is able to decrypt and check MDC packages since PGP 7. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: small security glitches
Thanks for replying again. Yes, I read Schneier's paper, which is why I am confident that even the original attack scenario on a vulnerable implementation would not apply to the use case I was originally concerned about after seeing mention of a security glitch, namely encrypted local file storage. After your message, it would seem to me we are in agreement on the state of the problem. However, regarding the disputed post below, we seem to be talking past each other somehow. The original post and response I was referring to are here: http://lists.gnupg.org/pipermail/gnupg-users/2011-November/043213.html The respondent says: Without signing the message, and only encrypting it to your public key, you have no way to verify who really sent you the message. This is true of course, but it is not the security vulnerability (glitch) referred to in the FAQ and that the original poster was inquiring about. Choosing not to use available functionality cannot be used as a basis to find a fault with that functionality. (If I don't brush my teeth, it can hardly be called the fault of Crest that I get cavities.) The originally mentioned glitch, which we agree prompted changes in the the OpenPGP spec to create the MDC, was not a vulnerability related to authentication. Indeed, it is nonsensical to say that authentication could be compromised on an unsigned message since no authentication is even proffered or purported to exist in that case! Instead, the glitch allowed a potential (and also feasible, per Schneier, since in practice not all crypto users are so well-versed as to be as responsible as might be hoped) mechanism for an attacker to *modify the ciphertext message* and *manipulate the recipient* in such a way that *some or all of the encrypted message can be decrypted* *by the attacker.* To me that is clearly an encryption vulnerability and not an authentication vulnerability. No? Ciao, Carter Anyway, my motivation for posting is that there was a question on this in November 2011 and people responded that the reason you had to sign was to authenticate the message sender. Although that is also true, it is not the point of the warning. This attack and the glitch mentioned in the FAQ are specifically an attack against the ENCRYPTION that results in potential full compromise of the message secrecy. The defect in the specification, per Schneier, was the lack of any message integrity check when the message is not cryptographically signed, allowing even the most rudimentary tampering to be undetected. I believe the original responses you're referring to were correct. I don't think that the paper you cite above suggests otherwise. Regards, --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: small security glitches
Also... I know we've both read and understand the paper, so I think we just have a terminology discrepancy here. What is a bit confusing is using the words encrypted vs. decrypted and ciphertext vs. cleartext when we're talking about an attacker inserting contents into the message. What I was trying to say was like this... 1) Let's say the original sender encryptes a message. It then looks like this where C represents some bits of encrypted ciphertext: C 2) Then, the attacker inserts some material of their own into the message, denoted here with P for plaintext since it has not been subjected to encryption. The message now looks like this: CCCPPCC 3) Next, the recipient decrypts the message. Since at its lowest level the encryption amounts to XOR'ing the message text against the secret key, it essentially results in the flipping of each class of text. C becomes P and P becomes C: PPPCCPP 4) In the attack scenario, when the recipient sends the gibberish to the sender, they are sending the now encrypted part of the message above denoted by CC: PPP --CC-- PP 5) The attacker intercepts and XOR's the gibberish CC against their original insertion PP from #2 to deduce the key. Then they can decrypt the original C contents from #1. I'm sure this is all subject to terminology debates, and I'm most likely not using the optimal words to describe the process, but my point was just that the recipient actually never themselves reveals to the attacker any of the decrypted contents of the original message that were sent by the original sender. Ciao, Carter - Original Message - From: Daniel Kahn Gillmor d...@fifthhorseman.net Sent: Friday, March 2, 2012 8:50 AM Subject: Re: small security glitches That said, the attack described does indeed rely on the victim decrypting arbitrary text sent by the attacker and sending it back in such a way that the attacker can read the cleartext. Quoting the paper: and the user is presented with the corresponding message P'. To the user, P' appears to be garbled; the user therefore replies to the adversary with, for example, What were you trying to send me?, but also quotes the garbled message P'. Thus, the user himself unwittingly acts as a decryption oracle for the adversary. Do you see how the above suggests that the victim must transfer the (apparently-garbled) cleartext to the attacker for the attack to proceed? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: small security glitches
On Fri, 2 Mar 2012, Post Carter wrote: . . . so I think we just have a terminology discrepancy here. What is a bit confusing is using the words encrypted vs. decrypted and ciphertext vs. cleartext when we're talking about an attacker inserting contents into the message. I have been reading the exchanges wondering if someone would point out what looked like unclear reference of encrypted and plaintext. (Amusing, actually. Almost like a famous, classic, American comedy joke involving baseball players' names.) [P]ost.carter's C etc below makes things clear, IMHO. And prompts me to ask a question. If the receiver of the tampered-with message sends to the presumed original sender the CC which began originally as inserted PP, but sends it encrypted eg with the original sender's public key, that should not expose the now-CC to the evesdropping attacker, right? Ie, the attack would fail if the honest people involved diligently follow the implicit lead of the original sender's email, which used encryption, so the reply to that original encrypted message gets encrypted? What I was trying to say was like this... ? 1) Let's say the original sender encryptes a message.? It then looks like this where C represents some bits of encrypted ciphertext: ? C ? 2) Then, the attacker inserts some material of their own into the message, denoted here with P for plaintext since it has not been subjected to encryption.? The message now looks like this: ? CCCPPCC ? 3) Next, the recipient decrypts the message.? Since at its lowest level the encryption amounts to XOR'ing the message text against the secret key, it essentially results in the flipping of each class of text. C becomes P and P becomes C: ? PPPCCPP ? 4) In the attack scenario, when the recipient sends the gibberish to the sender, they are sending the now encrypted part of the message above denoted by CC:? PPP --CC-- PP ? 5) The attacker intercepts and XOR's the gibberish CC against their original insertion PP from #2 to deduce the key.? Then they can decrypt the original C contents from #1. . . .___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: small security glitches
On Fri, Mar 02, 2012 at 04:55:23AM -0800, Post Carter wrote: 3) Next, the recipient decrypts the message. Since at its lowest level the encryption amounts to XOR'ing the message text against the secret key, it essentially results in the flipping of each class of text. C becomes P and P becomes C: PPPCCPP It is not true that encryption amounts to XORing the message text against the secret key. That type of encryption is not secure because it is trivial for someone to XOR two blocks (of the key size) of ciphertext together in order to get the XOR of the plaintexts. This allows trivial analysis of the plaintext. Stream ciphers usually create a key*stream* and XOR the plaintext against that. OpenPGP implementations do not use stream ciphers proper; instead, they use a block cipher in CFB mode. So by flipping bits what you get here is not only flipped bits in the data, but a corrupted next block. Also, CFB mode, what is XORed is the output of a block cipher encryption of the previous ciphertext. 4) In the attack scenario, when the recipient sends the gibberish to the sender, they are sending the now encrypted part of the message above denoted by CC: PPP --CC-- PP 5) The attacker intercepts and XOR's the gibberish CC against their original insertion PP from #2 to deduce the key. Then they can decrypt the original C contents from #1. This doesn't work, because all you get is the output of the block cipher. That doesn't tell you the key if the block cipher is secure. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: small security glitches
If Tom McCune simplified explanation isn't detailed enough, check out Bruce Schneier's original paper describing the attack: http://www.schneier.com/paper-pgp.html The idea is that the decrypted gibberish is the encrypted form of the plaintext the attacker inserted. If the naive user re-sends it to the original sender to ask, Is this what you meant to send me? then the eavesdropping attacker has a known ciphertext and plaintext. (NOTE: The recipient need not send the sender the decrypted plaintext! That would be no attack at all, just stupidity.) From the known ciphertext and plaintext, the attacker can deduce the session key and then decrypt the original eavesdropped ciphertext. Based on this attack, the OpenPGP standard was apperently modified, I believe to add a message integrity component. This attack can also be prevented by always signing messages, since then the tampering is detected in the signature validation. Anyway, my motivation for posting is that there was a question on this in November 2011 and people responded that the reason you had to sign was to authenticate the message sender. Although that is also true, it is not the point of the warning. This attack and the glitch mentioned in the FAQ are specifically an attack against the ENCRYPTION that results in potential full compromise of the message secrecy. The defect in the specification, per Schneier, was the lack of any message integrity check when the message is not cryptographically signed, allowing even the most rudimentary tampering to be undetected. Ciao, Carter On 02/29/2012 10:33 AM, Post Carter wrote: An individual intercepts an encrypted email. He places a plaintext addition within the package, in such a manner that when the originally intended recipient decrypts the message, the symmetric session key also decrypts the addition But since the plaintext addition was not encrypted (but probably looked encrypted), it is now encrypted to the symmetric session key. The above two steps are clear so far. If the originally intended recipient then sends this gibberish back to the original sender (to inquire about it), the interceptor again intercepts this, and now i'm assuming that the intended recipient sends the gibberish back to the original sender encrypted, right? if they send it in the clear, it's hardly the fault of the cryptosystem that the cleartext was exposed. has both his original plaintext addition, and the symmetric session key encryption of that plaintext. eh? how does it follow that the attacker has both of these? afaict, the attacker has: A) the original ciphertext B) the modified ciphertext (which they supplied arbitrary data for) C) a re-encrypted version of the modified cleartext (reencrypted against a different session key, presumably). From this, he is able to reverse the XOR processing of the original encryption to produce the plaintext of the originally intercepted encrypted message. I don't understand how this follows either. where does XOR come in? Which part of OpenPGP is using XOR here? At any rate, this is indeed about message integrity; if you want encrypted integrity, you need your peer to supply an MDC (gpg does this by default). If you want verifiable message provenance with message integrity, you need your peer to sign their messages. If Alice does something like take an un-verified message, decrypt it, and then post the plaintext somewhere anyone can look at it, then the cryptosystem hasn't failed; but alice has stopped using the cryptosystem. --dkg -- Original Message: I too had seen and been perturbed by this unexplained statement on http://www.gnupg.org/faq/GnuPG-FAQ.html: There is a small security glitch in the OpenPGP (and therefore GnuPG) system; to avoid this you should always sign and encrypt a message instead of only encrypting it. I use PGP for local file encryption and was concerned this applied to that as well, but I now think it seems to only apply to *messages*. I would appreciate anyone else's analysis of that. I believe I have found the actual information behind the glitch, and it *absolutely* has to do with encryption/security and not just integrity/trust. http://www.mccune.cc/PGPpage2.htm#Chosen-Ciphertext http://www.schneier.com/paper-pgp.html Tom McCune's summary from link above: Chosen-Ciphertext Attack? The report Implementation of Chosen-Ciphertext Attacks against PGP and GnuPG discusses a potential PGP vulnerability. This is my understanding of the attack: An individual intercepts an encrypted email. He places a plaintext addition within the package, in such a manner that when the originally intended recipient decrypts the message, the symmetric session key also decrypts the addition. But since the plaintext addition was not encrypted (but probably looked encrypted), it is now encrypted to the symmetric session key. If the originally intended recipient then sends
Re: small security glitches
On 03/01/2012 07:44 PM, Post Carter wrote: If Tom McCune simplified explanation isn't detailed enough, check out Bruce Schneier's original paper describing the attack: http://www.schneier.com/paper-pgp.html The idea is that the decrypted gibberish is the encrypted form of the plaintext the attacker inserted. If the naive user re-sends it to the original sender to ask, Is this what you meant to send me? then the eavesdropping attacker has a known ciphertext and plaintext. (NOTE: The recipient need not send the sender the decrypted plaintext! That would be no attack at all, just stupidity.) Have you read the paper you reference above? If not, i recommend reading it. It's a good paper, and clever cryptanalysis. That said, the attack described does indeed rely on the victim decrypting arbitrary text sent by the attacker and sending it back in such a way that the attacker can read the cleartext. Quoting the paper: and the user is presented with the corresponding message P'. To the user, P' appears to be garbled; the user therefore replies to the adversary with, for example, What were you trying to send me?, but also quotes the garbled message P'. Thus, the user himself unwittingly acts as a decryption oracle for the adversary. Do you see how the above suggests that the victim must transfer the (apparently-garbled) cleartext to the attacker for the attack to proceed? Based on this attack, the OpenPGP standard was apperently modified, I believe to add a message integrity component. Yes, the Modification Detection Code packet was formally introduced in RFC 4880 as a mechanism to defend against producing garbled decryption like that shown in the referenced paper: https://tools.ietf.org/html/rfc4880#section-5.14 I believe that GnuPG had its own implementation of such an integrity check before the standardization was settled. This attack can also be prevented by always signing messages, since then the tampering is detected in the signature validation. This attack (or class of attacs) can only be fully prevented by the victim; A responsible crypto user should only quote from encrypted messages (when replying) if the original message was signed by the person to whom the sender is replying. So the fix isn't always sign messages (though that's nice and helpful), it's don't quote when replying to unsigned encrypted messages. The clever move by Jallad, Katz, and Schneier was to show a way that a ciphertext could be modified such that its cleartext would look like gibberish to the victim, but could also provide a decryption oracle for the attacker. Since the cleartext looks like gibberish to the victim, they might be more willing to forward it to anyone (incluing the attacker). However, comparable attacks could still work in situations with significantly less cleverness than that shown by Jallad, Katz, and Schneier. For example, Alice could send Bob an unsigned, integrity-protected encrypted message which says: --- The password for our next meeting at the clubhouse is Pajamas. --- If Eve were to intercept this message (preventing it from reaching Bob), and then simply replay it to Bob with her address in the From: field instead of Alice's, and Bob decides to respond to Eve with: --- Eve wrote: The password for our next meeting at the clubhouse is Pajamas. What are you talking about, Eve, we don't even go to the same clubhouse! --- Then Eve has taken advantage of Bob's credulousness to compromise the confidentiality of Alice's original message. Note that even the MDC does nothing to prevent the above attack. If Alice wants to help Bob avoid this kind of breach of confidentiality, she can (and probably should) do all of the following when sending encrypted mail: 0) use an MDC 1) sign her messages 2) make sure the encrypted content of her messages always clearly indicates that they are coming from her (e.g. concluding the message with something like Regards, Alice) However, even if Alice always does all of those things, if Bob isn't paying attention (to the warnings from his OpenPGP implementation, to whatever warnings his MUA shows that highlight discrepancies between the message signer and message From: address, to the content of the message, to general common sense), he might well still leak the contents of the message. This is an unhappy state of affairs, but Bob might also be in the habit of reading his e-mail out loud to himself at the pub, in which case even the message interception and replay are unneeded. Eve just needs to show up at the right hour and drink a pint from a nearby stool :( For a message to remain confidential, both the sender and the recipient need to exercise care. Anyway, my motivation for posting is that there was a question on this in November 2011 and people responded that the reason you had to sign was to authenticate the message sender. Although that is also true, it is
Re: small security glitches
On 02/29/2012 10:33 AM, Post Carter wrote: An individual intercepts an encrypted email. He places a plaintext addition within the package, in such a manner that when the originally intended recipient decrypts the message, the symmetric session key also decrypts the addition But since the plaintext addition was not encrypted (but probably looked encrypted), it is now encrypted to the symmetric session key. The above two steps are clear so far. If the originally intended recipient then sends this gibberish back to the original sender (to inquire about it), the interceptor again intercepts this, and now i'm assuming that the intended recipient sends the gibberish back to the original sender encrypted, right? if they send it in the clear, it's hardly the fault of the cryptosystem that the cleartext was exposed. has both his original plaintext addition, and the symmetric session key encryption of that plaintext. eh? how does it follow that the attacker has both of these? afaict, the attacker has: A) the original ciphertext B) the modified ciphertext (which they supplied arbitrary data for) C) a re-encrypted version of the modified cleartext (reencrypted against a different session key, presumably). From this, he is able to reverse the XOR processing of the original encryption to produce the plaintext of the originally intercepted encrypted message. I don't understand how this follows either. where does XOR come in? Which part of OpenPGP is using XOR here? At any rate, this is indeed about message integrity; if you want encrypted integrity, you need your peer to supply an MDC (gpg does this by default). If you want verifiable message provenance with message integrity, you need your peer to sign their messages. If Alice does something like take an un-verified message, decrypt it, and then post the plaintext somewhere anyone can look at it, then the cryptosystem hasn't failed; but alice has stopped using the cryptosystem. --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
small security glitches
Hello. I was reading this page, http://www.gnupg.org/faq/GnuPG-FAQ.html#cant-we-have-a-gpg-library , and I found this comment near the end of it in the section entitled How does this whole thing work?: There is a small security glitch in the OpenPGP (and therefore GnuPG) system; to avoid this you should always sign and encrypt a message instead of only encrypting it. If this is still applicable, would you explain what the small glitch is? Are there any other small glitches explained elsewhere, which I may not have noticed? There is a lot of documentation, and I am hoping to absorb it as much as I can. Thanks. John A. Wallace ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: small security glitches
Am Dienstag, 1. November 2011, 13:35:11 schrieb Aaron Toponce: Now switch sides. Suppose you're sending an encrypted mail to a collegue. You're encrypting it for his eyes only. If you don't sign the message, he may or may not choose to decrypt it. If you sign the encrypted mail, then he can verify the signature, see if he trusts that key, and make a more meaningful decision. But this isn't possible with email, is it? Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: small security glitches
On 01/11/11 13:35, Aaron Toponce wrote: The glitch is that for security AND trust, messages must be both encrypted and signed. In that case, I find it to be phrased very awkwardly. Encryption provides encryption: people can't see what is in it. Period. Signing provides a form of integrity: people can see that the signer attests that the data is correct in some way. So how is it a security glitch that encryption does not provide trust? It is a glitch in someone's thinking to think that it does. PEBKAC. The advice to also sign is sound, the absolute you should always is overdoing it, IMHO. Personally, I was more thinking along the lines of the reasons to introduce the MDC. Can't remember off the top of my head how that all pieced together. In that case it might be useful to revise the text to say a few words on MDC's. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: small security glitches
On 01/11/11 12:44, Hauke Laging wrote: Now switch sides. Suppose you're sending an encrypted mail to a collegue. You're encrypting it for his eyes only. If you don't sign the message, he may or may not choose to decrypt it. If you sign the encrypted mail, then he can verify the signature, see if he trusts that key, and make a more meaningful decision. But this isn't possible with email, is it? Thunderbird + Enigmail here automatically decrypts encrypted email when you view it, regardless of whether or not it is signed. -- Mike Cardwell https://grepular.com/ https://twitter.com/mickeyc Professional http://cardwellit.com/ http://linkedin.com/in/mikecardwell PGP.mit.edu 0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: small security glitches
On 11/01/2011 05:52, gn...@lists.grepular.com wrote: Thunderbird + Enigmail here automatically decrypts encrypted email when you view it, regardless of whether or not it is signed. That's a local preference, which you can easily disable. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
