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

Abhishek [ABK] Kumar abhikumar163 at gmail.com
Tue May 3 05:48:46 EDT 2011


>
> *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.
>> *
>
>
First of all,* serious thanks for analyzing this algorithm* and pointing out
the flaws... at least after this may be replies to this thread would
remember that...

This algorithm is currently developed with a specific scenario-based
use-case (which I've mentioned already) requirement and that scenario in no
case entertains Chosen-Plaintext(etc. etc.) attacks.* The most attacker can
do in it's use-case, at a Pattern-Based approach is collect random
cipher-text (and not a cipher to given plain-text) and analyze it.*

~~~~~~~~~~

* Unless you are an expert (you are not), do not ever try to build
>> encryption yourself.  This is why.
>> *
>
>
I never replied here as if I'm an Expert, but what I said was an enthusiast
with proper training *(that makes me non-novice not an expert... practice
would make me so, and I wouldn't leave that)* .

~~~~~~~~~~
-- 
Regards,
Abhishek Kumar
https://sites.google.com/site/abhikumar163/


-- 
--------------ABK-----mail.signature--------------------
 <http://www.blogger.com/profile/06276198262605731980><http://abhishekkr.deviantart.com/><http://www.facebook.com/aBionic><http://www.twitter.com/aBionic><http://sourceforge.net/users/abhishekkr><http://www.youtube.com/user/1ABK><http://in.linkedin.com/in/abionic>
-----------------------------------------------------------
~=ABK=~



On Tue, May 3, 2011 at 7:10 AM, Brandon Enright <bmenrigh at ucsd.edu> wrote:

> -----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-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20110503/f3e2aec7/attachment-0003.html>


More information about the websecurity mailing list