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

DDT dtillemans at gmail.com
Tue Apr 26 16:52:29 EDT 2011


Stick to AES or any other standard symmetric cipher.
I'll explain in detail. Your cipher doesn't work with a chosen text attack.
Figure out what happens when you use an input file with all 0 inside.



*Yes -> Your output file contains your key/password!*

2011/4/26 Abhishek [ABK] Kumar <abhikumar163 at gmail.com>

> I've updated the aQikCipher Repository, and there is no more data
> leakage...
>
> https://github.com/abhishekkr/aqikcipher
>
> now here XORing have been switched to
> *(char)((int)buf+(int)secret[sec_idx]+(int)new_secret[sec_idx])*
> *but this wouldn't leak any data, as I didn't find it to be capable for
> backtracking... any analysis/suggestion/flaw*
> *
> *
> *I'll be implementing rotation of "**secret[sec_idx]**" data to increase
> diffusion.*
>
> --
> 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, Apr 26, 2011 at 3:05 AM, Michal Zalewski <lcamtuf at coredump.cx>wrote:
>
>> > In this variation, entire one-time pad can be generated in a pure random
>> way just using Key and Data... no (pseudo) random number generators, salt
>> and IVs required.
>>
>> As I understand it, your algorithm can be paraphrased as:
>>
>> 1) Start with a random string as a key. For clarity, let's call it
>> original_secret. It's hardcoded as "ABK\0" in your example (I'm not
>> sure you understand ASCIZ here).
>>
>> 2) Copy the original_secret to new_secret using strncpy.
>>
>> 3) For every input character (let's call it in_chr), you calculate
>> new_key = secret[pos] ^ new_secret[pos]. The outcome of this XOR will
>> be always zero during the first pass, leaving strlen(original_secret)
>> bytes "unencrypted".
>>
>> 4) Compute out_chr = in_chr ^ new_key and output it.
>>
>> 5) Substitute new_key[pos] with the previously calculated output, out_chr.
>>
>> 6) When you hit the end of new_secret, reset pos to zero and go to 3.
>>
>> I am half-hoping that this is a joke, but if not: the first bytes of
>> your output will be identical to input, and all the subsequent ones
>> will trivially depend on the previously seen data.
>>
>> /mz
>>
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20110426/39eb6887/attachment-0003.html>


More information about the websecurity mailing list