[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 01:49:36 EDT 2011


@Tasos:

> *can you justify the randomness of the key for us?*
>
I'll soon make a fine graphical representation of my original algorithm and
append the link to this thread till then @michal's thread-post does a fair
description (just I need to reverse a change back to my original
formulation)

> *Don't design your own crypto.*
>
I totally agree to this... but what I feel is it is applicable to cryptos
which are closed and believe in obscurity of algorithm and this is how new
crypto's should evolve i.e. by public post-mortem before they are put to
work.
And if no more cryptos evolve, how do we get secure-or-faster replacements
for the existing exploited cryptos.

> */dev/urandom (or /dev/random if you feel paranoid) could provide better
> entropy*
>
if I'll be paranoid (actually in designing security patterns that's the only
way)... even /dev/random ain't secure for me
secondly I'll have to depend on a kernel specifc requirement restricting
it's quality and ability to some kernels


@Michal:

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

my bad [?]... that's what happen when you prepare the algorithm in one way
during it's formation stage and make some dynamic changes while coding
feeling it'll make it more secure, in turn leave it revealing...
I'll update the repository (and this thread) today with the exact algorithm
formulated and I promise this flaw is not there within actual thing...
this is not a joke but a Lost-In-Translation moment :)
thanks a lot for pointing it out,

-- 
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20110426/cd166cb4/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 33D.gif
Type: image/gif
Size: 104 bytes
Desc: not available
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20110426/cd166cb4/attachment.gif>


More information about the websecurity mailing list