[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
Wed Apr 27 00:49:54 EDT 2011


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 at gmail.com>
To: Mike <mike at deadliestwebattacks.com>
Cc: Michal Zalewski <lcamtuf at coredump.cx>; "websecurity at webappsec.org" <websecurity at 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 at 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 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/5501877e/attachment-0003.html>


More information about the websecurity mailing list