1996-09-18 - Re: Redundancy in XOR encryption

Header Data

From: paul@fatmans.demon.co.uk
To: cypherpunks@toad.com
Message Hash: 7c62305dae160f95d2c2c584f34f8865874d97f10a5dc8e52c9b88e63912c776
Message ID: <842988795.23113.0@fatmans.demon.co.uk>
Reply To: N/A
UTC Datetime: 1996-09-18 12:12:19 UTC
Raw Date: Wed, 18 Sep 1996 20:12:19 +0800

Raw message

From: paul@fatmans.demon.co.uk
Date: Wed, 18 Sep 1996 20:12:19 +0800
To: cypherpunks@toad.com
Subject: Re: Redundancy in XOR encryption
Message-ID: <842988795.23113.0@fatmans.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain


> > 
> > Compress P to get perfect compression (ie. 0 redundancy)
> > Encrypt F (the compressed text) using a repeated key XOR
> > 
> > of course this is all rather theoretical as there is no such thing as
> > perfect compression, but I just thought it might be interesting to
> > see if this is indeed strong, superficially it appears so to me...
> > 
> 
> Paul:
>    I think that if the cryptanalyst knows that F has zero redundancy
> that he can run searches from 0 to n bits for the key and have
> the computer flag solutions that have zero redundancy.  

I never though of that.
 
>    I also think that a perfectly compressed file would have a relative
> entropy value close to one also, hence the computer could flag possibles 
> that have both characteristics.

yeah, these two are reasonably unlikely to occur together (only a 
reasoned guess, anyone got any comments on this?)
so we really have a weakish system.
 
>    Hence, instead of searching for plaintext by counting coincidences,
> we are searching the decrypts for solutions that have zero redundancy
> and a relative entropy value close to one.  How many solutions will
> have both these qualities?  I don't know.  But if the compression method 
> is known, brute force will be tried, and only having to try to 
> decompress (read) data that has the resultant characteristics
> of compressed information will speed things up by quite a bit.

Yeah, this is still a form of brute force but I was thinking of this 
in terms of a smallish (sub 200 bit) key, so brute force against 
solutions with 0 entropy is a realistic possibility.

 
anyone else got a faster way to attack this highly theoretical, 
will-never-be-implemented, type system??

I`d imagine there is some sort of way to measure the entropy "mixed 
in" by the XOR thus giving a foothold in the key, but I can`t think 
of anything right now, anyone got any ideas? 


  Datacomms Technologies web authoring and data security
     Paul Bradley, Paul@fatmans.demon.co.uk
       Http://www.fatmans.demon.co.uk/crypt/
         "Don`t forget to mount a scratch monkey"

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia

mQCNAjH9j+cAAAEEAMBvREiQR0ot9dFCO0TiSCSunAYLv2g1Bc6I3bz8FzKXNH53
6mieJf/W4rD+CxJpT0q9RQaaoRtkHJLwbjfK2il3D7mEahMAyqvF/xRJNqkXfhM3
sRJM0Jh43l+W0M5vwokbEbk25/bxWWGspTsLD3YHbzKnG6pOcL5OPIRbv66xAAUR
tCdQYXVsIEJyYWRsZXkgPHBhdWxAZmF0bWFucy5kZW1vbi5jby51az6JAJUDBRAy
NwfvNkCBjDT0xHEBATQPA/9TORmN/UjNecj03q4anpvdyCLiez5sKuNbnYK50RiP
Jj4QpWWvST3smyQ0A86DrZY/re056MXwQmARESx0rFZxdnD0oORICl5r8dJLIy3b
j8rbA5olXwZwKz73/X5s13v/pvHYX4cIsbVK8NHXqh5llSKt6TBAuGgkIGF29z5k
C4kAlQMFEDI3B9mdtf/umVkv7QEBcRYD/1FBteLqsUmr81euxqqnnrpLlyHb58B/
9sdATuua4uSjX46hXDZ264YozspNrzSB4NEdrmXOWVX3fiE0ga6XkSSkIeF23V90
En37Z0BdbFzgF00FRYTFyTq8eezQrdg/+rBPUsZUmG5wpq3e12FKHQsX01i+1mB2
YmqqwCV5e95eiQCVAgUQMh8uSb5OPIRbv66xAQEqJwP/fxQyiCasjFcbDpsFfsYp
put5cCC/9pOx6X3DlbKShPMpUOS+A9HsTEmJQN8Iawv1nSwPdtc2cR/GhW6ilVjW
LSloGdMVLabm9pGpZZMkRaZlXFUkOv7VhfgsUiL+vIDryBCAwUZCzQiWycjt/cPi
mUqFH41Z7NkyO8ZFdi5GGX0=
=CMZA
-----END PGP PUBLIC KEY BLOCK-----





Thread