[WEB SECURITY] a new 'Secret Key' Cryptographic Algorithm ~ any analysis/suggestions/weakness will be helpful ~ Variation of One-Time Pad

Brandon Enright bmenrigh at ucsd.edu
Mon May 2 21:40:34 EDT 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 27 Apr 2011 09:55:36 +0530
"Abhishek [ABK] Kumar" <abhikumar163 at gmail.com> wrote:

> Making few things clear again:
> 
> First, it's a stream cipher... (though could be used as a block cipher
> like others, as every Stream Cipher works on smallest block i.e.
> bytes).
> 
> Currently it's just salted at the base and then an One-Time-Pad
> (dynamically generated from from Key&Data) is XOR-ed to it. Some more
> updates are pending to it once I'm sure with their effect.
> 
> --
> Regards,
> Abhishek Kumar


Yes, what you've built has nothing to do with one time pads (OTP).  It
is a data-dependant stream cipher.  The keying isn't salting but
seeding.

As it stands right now it's *totally broken*.  For example, if you
encrypt a file full of NULLs you get:

00000000  00 00 00 bf be b5 bf be  b5 bf be b5 bf be b5 bf  |................|
00000010  be b5 bf be b5 bf be b5  bf be b5 bf be b5 bf be  |................|
00000020  b5 bf be b5 bf be b5 bf  be b5 bf be b5 bf be b5  |................|
00000030  bf be b5 bf be b5 bf be  b5 bf be b5 bf be b5 bf  |................|
00000040  be b5 bf be b5 bf be b5  bf be b5 bf be b5 bf be  |................|
00000050  b5 bf be b5 bf be b5 bf  be b5 bf be b5 bf be b5  |................|


The reason the first three bytes of the stream are null is that you key
"ABK" is three bytes and in a loop you do:

            char new_chr = buf^new_secret[sec_idx];
            new_chr = (char)((int)new_chr-(int)secret[sec_idx]);
            new_secret[sec_idx]=buf;


So 0 ^ 'A' = A

And then A - A = 0

The same goes for B and K.  Worse, you let at attacker control how the
stream evolves by setting new_secret[] to plaintext input.

That means that after K null bytes where K is the key size, the
internal state is set to all NULLs.  At that point another K bytes will
reveal the original key.

So for example, I set the key to some unknown "secret" and I encrypt a
series of NULL bytes:

00000000  00 00 00 00 00 00 00 00  00 00 8c 98 97 8d 97 8d  |................|
00000010  8d 98 97 8c 8c 98 97 8d  97 8d 8d 98 97 8c 8c 98  |................|
00000020  97 8d 97 8d 8d 98 97 8c  8c 98 97 8d 97 8d 8d 98  |................|
00000030  97 8c 8c 98 97 8d 97 8d  8d 98 97 8c 8c 98 97 8d  |................|
00000040  97 8d 8d 98 97 8c 8c 98  97 8d 97 8d 8d 98 97 8c  |................|
00000050  8c 98 97 8d 97 8d 8d 98  97 8c 8c 98 97 8d 97 8d  |................|


As you can see the pattern "8c 98 97 8d 97 8d 8d 98 97 8c" emerges.
This is 0 - key byte.  To recover the original key either do some basic
math or set the new key to "\x8c\x98\x97\x8d\x97\x8d\x8d\x98\x97\x8c\0"
and encrypt another file full of NULLs.

Here, I have done it for you:

00000000  00 00 00 00 00 00 00 00  00 00 74 68 69 73 69 73  |..........thisis|
00000010  73 68 69 74 74 68 69 73  69 73 73 68 69 74 74 68  |shitthisisshitth|
00000020  69 73 69 73 73 68 69 74  74 68 69 73 69 73 73 68  |isisshitthisissh|
00000030  69 74 74 68 69 73 69 73  73 68 69 74 74 68 69 73  |itthisisshitthis|
00000040  69 73 73 68 69 74 74 68  69 73 69 73 73 68 69 74  |isshitthisisshit|
00000050  74 68 69 73 69 73 73 68  69 74 74 68 69 73 69 73  |thisisshitthisis|


Note that this "attack" can be done at any point in the plaintext.  So
if you encrypt a file with a long string of NULLs (say, a Windows
executable) you will reveal the original key.

Unless you are an expert (you are not), do not ever try to build
encryption yourself.  This is why.

Brandon

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iEYEARECAAYFAk2/XRgACgkQqaGPzAsl94LaMQCeNPqpxAIMOpu3Z3apTjjmPg8f
vtwAoJO0DtAvlT/SNl7mSdsj+LRSY1TH
=T+jj
-----END PGP SIGNATURE-----


More information about the websecurity mailing list