[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 Apr 26 12:37:38 EDT 2011

I've updated the aQikCipher Repository, and there is no more data leakage...


now here XORing have been switched to
*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

Abhishek Kumar


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

More information about the websecurity mailing list