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
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
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 >> 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
Using Smartcards without it's public key
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Can I use my openPGP smartcard to decrypt a file with a empty keyring ? Assuming the card's public keys are lost or unreachable at the time. Regards. -BEGIN PGP SIGNATURE- Version: APG v1.0.8 iQIVAwUBT1CXn0y6/YZf1YOeAQpSDg//UuBx2Ydaj19wmGgkoQ9P0kYmqqFXG1pk fylKDeQ6Wy51/iNkepMc4ypXKoidSvpl/0xW6lzw9yMlr3VwJ2MLJzIyqwEmxeXN UzAgk+QML3PF4mYmgN9wLhjJIXIjfKiKrakaD/Cl0nW1pEjp3QKqXEeJa8KeGHVr oNzCiwgFWkhQ+LW6t/strTTTWQuTfWAFuRFJ0u4JQVpQJ6M8QQ2KElZbsJVGLf0K W3zaIvo0zVMOy5T+JoccQre7LmURzTfmxDdfcF5QsW3thNUEAiDe9B3lW+h4BUPn PskmkXFlu/iKZJ1FkxvdNcuSA2Bfrgwn0JS6Gv12OsEimL+Nf8/nGXMGTRosoPoa MFiA12D3Dn7zhfPXSCFtluiR3LG3/qd3nOoYPc8VEflD0GrvNN/JpY704Tj6bu3Q /RwiBTWirbAIyQJB1M0MLmnEdPU5/UUjI1NpnXO2Z+IRNtDuF3cvVqI9ofcZ+rQL ht5EcEBQf8AYP+qVkmWFXKeuk+9N5e5/mirJhc0TJ7NDemzKn71Fs9tmimXWfnA8 W4Ay1a541oy/siGRVA9nDFI98/NEUO45dSq75UkbNGmjLwu2BUgjBdb8H2+7sWpG TeYNuD+rvfapUH9a3zrJf4yJctr6M7vKf6q/nHlye4DPmzeTObo/IGV0fF8TrbSl 4MaLnt498wc= =wwMR -END PGP SIGNATURE- ___ 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
