[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
Wed May 4 03:16:17 EDT 2011


> *Your current strategy for "practicing" is a very bad one that will not
>> work out for you. *
>>
>
Now its the limit of making one simple thing clear from different
point-of-views... now, yeah I'm trying an evolving approach towards this
cipher and several other things that I mentioned... I also mentioned
(several times) that I'm going to use it in one of my personal project (from
where it all started) and it's well suited for it.
Currently it's not "Any Use-Case Cipher", and thus seems insecure... but not
if looked into the use-case I earlier referred to.


-- 
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 10:24 PM, Thomas Ptacek <thomas at matasano.com> wrote:

> If you want to practice to get better at designing ciphers, implement
> FEAL-4 (you can do it in about 30 lines of Python) and write working code
> for the various attacks on it. You can configure FEAL as a stream cipher, if
> that's the only thing you're interested in playing with.
>
> Your current strategy for "practicing" is a very bad one that will not work
> out for you.
>
> On May 3, 2011, at 4:48 AM, Abhishek [ABK] Kumar wrote:
>
> *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-----
>>
>
> _______________________________________________
> The Web Security Mailing List
>
> WebSecurity RSS Feed
> http://www.webappsec.org/rss/websecurity.rss
>
> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
> WASC on Twitter
> http://twitter.com/wascupdates
>
> websecurity at lists.webappsec.org
> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
>
>
>
> ---
> Thomas Ptacek // matasano security // founder, product manager
> reach me direct: 888-677-0666 x7805
>
> "The truth will set you free. But not until it is finished with you."
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20110504/cd2dd44e/attachment-0003.html>


More information about the websecurity mailing list