Re: XOR without repeated key

From: Guy Macon (http://www.guymacon.com)
Date: 08/28/04 

Date: Sat, 28 Aug 2004 11:59:52 -0700

Jeff Williams <frostback@canada.com> says...

>If you have a ciphertext composed of a plaintext xored with a key, where
>the key is at least as long as the plaintext, and you know nothing about
>the plaintext and nothing about the key (i.e. how it was generated) -
>barring a trivial key, such as a text from a book or, heaven help us,
>the same character - how is this substantially different from using a
>truly random key?

The (pardon the pun) "key" phrase is "you know nothing about the
[data that is XORed with the plaintext] (i.e. how it was generated)."
That's the whole point of stream cipher cryptography; figuring out
how the data that is XORed with the plaintext was generated. The
XOR with the plaintext makes it slightly harder to figure out, but
not much harder than it would be to directly figure out how the data
that is XORed with the plaintext was generated.

>My thinking is this: you come along and "decrypt" my incriminating
>ciphertext. I turn around and say "no, no, no, here's the real key" and
>produce a key that yields a non-incriminating ciphertext. Given that we
>are dealing with XORed data, and you have no foreknowledge of either the
>key or the plaintext, how can you prove yourself correct and me a liar?

I would have to have knowledge about how the key was generated which I
got through cryptography. Once I have that, I show that a certain
key fed into a certain encryption algorithm decrypts your ciphertext
into a readable incriminating plaintext. You would have to show that
a certain key fed into a certain encryption algorithm decrypts your
ciphertext into a different readable (but this time non-incriminating)
plaintext to show your innocence.

That being said, if you are using a one-time-pad (do a web search on it)
instead of a shorter key and an encryption algorithm, it is easy to make
two OTP decryption keys, one giving you your incriminating plaintext and
the other giving you your non-incriminating plaintext. very nice if
someone who doesn't know this trick decides to beat the location of your
OTP decryption key out of you. The disadvantage is that you can't make
up the fake OTP decryption key ahead of time - you need the ciphertext
to generate it. 

-- 
Guy Macon <http://www.guymacon.com>

Relevant Pages

  • Vigenere++ Proposal of a (new?) cipher
    ... additional ciphertext shuffling phase. ... which is a fast hash function with a low collision rate and the Mersenne ... plaintext, "C" to indicate the i-th letter of the ciphertext and ... For each character of index "i" of the plaintext: ...
    (sci.crypt)
  • Re: How to cryptanalysis of Japanese PURPLE cipher machine.
    ... I have a question about PURPLE. ... > PURPLE ciphertext in September 1940 and intervals revealed the ... already completely broken the "sixes" -- early-on frequency counts ... great deal of matched plaintext and ciphertext. ...
    (sci.crypt)
  • Re: The Ultimate - A No-Numbers Dsplacement Cipher -Adacrypt.
    ... What is the relation in bytes between plaintext ciphertext given. ... What size of keys can the cipher use/handle? ... As you can see the ciphertext has 23 or maybe 24 characters to the ...
    (sci.crypt)
  • Re: Countering chosen-plaintext attacks
    ... > Paul Pires wrote: ... One way would be to eliminate the property that the attack ... Choosing the plaintext or ciphertext. ...
    (sci.crypt)
  • Possible trapdoor in DES and AES
    ... DES-like block ciphers are equivalent to mixed alphabet monoalphabetic ... One would simply analyse the frequency of the ciphertext, ... plaintext message and determine the alphabet on that basis. ... The thing about a brute force attack on DES type ciphers is that it only ...
    (sci.crypt)