small security glitches

[brian m. carlson]

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 "CCCCC" 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: </pipermail/attachments/20120303/1d50053d/attachment-0001.pgp>