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

Mike mike at deadliestwebattacks.com
Tue Apr 26 16:54:52 EDT 2011


It also looks like your approach suffers from weakness like block ciphers in ECB mode. (http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation)


Perhaps you should recommend that the secret key length be the same length as the file to be encoded/decoded?

It seems strange that avoiding PRNGs, salts, and IVs (to say the least) are espoused as a positive property of this approach. Otherwise, why not just use ROT13? Or two rounds of ROT13 to be doubly secure?




________________________________
From: Abhishek [ABK] Kumar <abhikumar163 at gmail.com>
To: Michal Zalewski <lcamtuf at coredump.cx>
Cc: websecurity at webappsec.org
Sent: Tuesday, April 26, 2011 9:37 AM
Subject: Re: [WEB SECURITY] a new 'Secret Key' Cryptographic Algorithm ~ any analysis/suggestions/weakness will be helpful ~ Variation of One-Time Pad


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--------------------

-----------------------------------------------------------
~=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/61f7086a/attachment-0003.html>


More information about the websecurity mailing list