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
https://sites.google.com/site/abhikumar163/


--
--------------ABK-----mail.signature--------------------
-----------------------------------------------------------
~=ABK=~



On Wed, Apr 27, 2011 at 2:24 AM, Mike <mike@deadliestwebattacks.com> wrote:

I think my comments were misunderstood. As for ECB, try taking a look at how your OTP approach encodes a file. While you're not implementing a block cipher, you may be surprised at the periodicity of the encryption based on the secret key. This is what I was hinting at with making the secret key the same length as the input. (Similar to another comment about chosen plaintext attack.) As for ROT13, I don't think using two rounds of it would be much less secure than this new secret key algorithm. You could trivially extend it to ROT127 to deal with byte streams. As a learning exercise, a new secret key algorithm isn't bad. As a security mechanism to be relied on, it's inferior to established algorithms like AES, RC4, etc. ________________________________ From: Abhishek [ABK] Kumar <abhikumar163@gmail.com> To: Mike <mike@deadliestwebattacks.com> Cc: Michal Zalewski <lcamtuf@coredump.cx>; "websecurity@webappsec.org" <websecurity@webappsec.org> Sent: Tuesday, April 26, 2011 9:25 PM Subject: Re: [WEB SECURITY] a new 'Secret Key' Cryptographic Algorithm ~ any analysis/suggestions/weakness will be helpful ~ Variation of One-Time Pad thanks a lot to all for taking out time & responding... @ClaudioTelmon: yup... thanks @DDT: few hours after my last mail, I re-correted my code-repo {forgot updating the info to this list}... the current code in their handles that actually its XOR(Arithmetic(data,secret_as_salt), new_secret)... that both arithmetic was my effect of my eagerness @Mike: > > seems strange that avoiding PRNGs, salts, and IVs (to say the least) are espoused as a positive property I'm not outcasting PRNGs, Salt or IVs... I cannot, I'm just modifying the way to generate/use them. > > looks like your approach suffers from weakness like block ciphers in ECB as far as I've learned about BlockCiphers, I would say No. as particular to ECB, this cipher is an OTP variation, it is meant to have a SecretKey of Length of entire data to be crypted... so how it can suffer with ECB's flaws. > > you should recommend that the secret key length be the same length as the file to be encoded/decoded Then, 'SecretKey' is of the same length as of file {because that's how One-Time-Pad works}... it's just that I'm generating the 'SecretKey a.k.a. OTP' from the 'Secret a.k.a. Password' that will be provided by user, it's just that it's getting generated in runtime. > > Otherwise, why not just use ROT13? Or two rounds of ROT13 to be doubly secure? ROT13 is just a sophisticated-society Substitution Cipher, I don't think it will be applicable on Byte streams. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 https://sites.google.com/site/abhikumar163/ -- --------------ABK-----mail.signature-------------------- ----------------------------------------------------------- ~=ABK=~ On Wed, Apr 27, 2011 at 2:24 AM, Mike <mike@deadliestwebattacks.com> wrote: > > 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@gmail.com> > To: Michal Zalewski <lcamtuf@coredump.cx> > Cc: websecurity@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@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@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org > >