a new 'Secret Key' Cryptographic Algorithm ~ any analysis/suggestions/weakness will be helpful ~ Variation of One-Time Pad
Hi All,
I'm working on a *new 'Secret Key' Cryptographic Algorithm *to be
incorporated in my open-source project 'n00bRAT' and a new concept that I'm
gonna initiate in some time.
Currently, its at initial stage with a single feature of
encrypting/decrypting files.
any* analysis/suggestions/weakness *will be helpful
aQikCipher ~ https://github.com/abhishekkr/aqikcipherhttps://github.com/abhishekkr/aqikcipher
It's a very low-resource consuming and easily implemented variation of
One-Time Pad (Vernam Cipher) Encryption methodology :
http://en.wikipedia.org/wiki/One-time_pad :: which is the strongest
considered Secret Key Encryption.
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.
--
Regards,
Abhishek Kumar
https://sites.google.com/site/abhikumar163/
--
--------------ABK-----mail.signature--------------------
http://www.blogger.com/profile/06276198262605731980http://abhishekkr.deviantart.com/http://www.facebook.com/aBionichttp://www.twitter.com/aBionichttp://sourceforge.net/users/abhishekkrhttp://www.youtube.com/user/1ABKhttp://in.linkedin.com/in/abionic
~=ABK=~
Hi,
I don't see how the key is generated randomly, if anything the
scheduling seems quite bad.
Maybe I'm missing something or I'm just too tired, can you justify the
randomness of the key for us?
There's also a saying that goes around crypto circles: Don't design your
own crypto.
And it's a valid and proven point since crypto is really really hard
to get right.
In your case though I think that /dev/urandom (or /dev/random if you
feel paranoid) could provide better entropy to be used as an OTP key.
Cheers,
Tasos L.
On 04/25/2011 08:18 PM, Abhishek [ABK] Kumar wrote:
Hi All,
I'm working on a *new 'Secret Key' Cryptographic Algorithm *to be
incorporated in my open-source project 'n00bRAT' and a new concept
that I'm gonna initiate in some time.
Currently, its at initial stage with a single feature of
encrypting/decrypting files.
any *analysis/suggestions/weakness *will be helpful
aQikCipher ~ https://github.com/abhishekkr/aqikcipher
https://github.com/abhishekkr/aqikcipher
It's a very low-resource consuming and easily implemented variation
of One-Time Pad (Vernam Cipher) Encryption methodology :
http://en.wikipedia.org/wiki/One-time_pad :: which is the strongest
considered Secret Key Encryption.
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.
--
Regards,
Abhishek Kumar
https://sites.google.com/site/abhikumar163/
--
--------------ABK-----mail.signature--------------------
http://www.blogger.com/profile/06276198262605731980http://abhishekkr.deviantart.com/http://www.facebook.com/aBionichttp://www.twitter.com/aBionichttp://sourceforge.net/users/abhishekkrhttp://www.youtube.com/user/1ABKhttp://in.linkedin.com/in/abionic
~=ABK=~
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
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:
-
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). -
Copy the original_secret to new_secret using strncpy.
-
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". -
Compute out_chr = in_chr ^ new_key and output it.
-
Substitute new_key[pos] with the previously calculated output, out_chr.
-
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
@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/06276198262605731980http://abhishekkr.deviantart.com/http://www.facebook.com/aBionichttp://www.twitter.com/aBionichttp://sourceforge.net/users/abhishekkrhttp://www.youtube.com/user/1ABKhttp://in.linkedin.com/in/abionic
~=ABK=~
On Tue, Apr 26, 2011 at 3:05 AM, Michal Zalewski lcamtuf@coredump.cxwrote:
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:
-
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). -
Copy the original_secret to new_secret using strncpy.
-
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". -
Compute out_chr = in_chr ^ new_key and output it.
-
Substitute new_key[pos] with the previously calculated output, out_chr.
-
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
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--------------------
http://www.blogger.com/profile/06276198262605731980http://abhishekkr.deviantart.com/http://www.facebook.com/aBionichttp://www.twitter.com/aBionichttp://sourceforge.net/users/abhishekkrhttp://www.youtube.com/user/1ABKhttp://in.linkedin.com/in/abionic
~=ABK=~
On Tue, Apr 26, 2011 at 3:05 AM, Michal Zalewski lcamtuf@coredump.cxwrote:
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:
-
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). -
Copy the original_secret to new_secret using strncpy.
-
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". -
Compute out_chr = in_chr ^ new_key and output it.
-
Substitute new_key[pos] with the previously calculated output, out_chr.
-
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
/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
The problem is, /dev/random will only provide the entropy bits available
in the system, and then stop until more bits are available. You can't
use it as source unless you either have human interaction or can wait an
unlimited amount of time. That's why /dev/urandom exists.
Regards,
- Claudio
--
Claudio Telmon
claudio@telmon.org
http://www.telmon.org
Stick to AES or any other standard symmetric cipher.
I'll explain in detail. Your cipher doesn't work with a chosen text attack.
Figure out what happens when you use an input file with all 0 inside.
Yes -> Your output file contains your key/password!
2011/4/26 Abhishek [ABK] Kumar abhikumar163@gmail.com
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--------------------
http://www.blogger.com/profile/06276198262605731980http://abhishekkr.deviantart.com/http://www.facebook.com/aBionichttp://www.twitter.com/aBionichttp://sourceforge.net/users/abhishekkrhttp://www.youtube.com/user/1ABKhttp://in.linkedin.com/in/abionic
~=ABK=~
On Tue, Apr 26, 2011 at 3:05 AM, Michal Zalewski lcamtuf@coredump.cxwrote:
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:
-
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). -
Copy the original_secret to new_secret using strncpy.
-
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". -
Compute out_chr = in_chr ^ new_key and output it.
-
Substitute new_key[pos] with the previously calculated output, out_chr.
-
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
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:
-
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). -
Copy the original_secret to new_secret using strncpy.
-
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". -
Compute out_chr = in_chr ^ new_key and output it.
-
Substitute new_key[pos] with the previously calculated output, out_chr.
-
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
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:
-
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). -
Copy the original_secret to new_secret using strncpy.
-
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". -
Compute out_chr = in_chr ^ new_key and output it.
-
Substitute new_key[pos] with the previously calculated output, out_chr.
-
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
I downloaded the code and simply tried to encode a block of zeroes... as
you can see if you look at the result with an hex editor, a clear
pattern appears in the cyphertext. See what happens instead if you try e.g.:
openssl enc -e -rc4 -in plain -out cypher
This is just to show that the fact that you're feeding the plaintext as
key, with minimal initialization, is weak and implies that both the key
and the cyphertext are almost as biased as the plaintext. BTW, I tried
to change the key from ABK to ACK, and a single bit changed as a
consequence in the cyphertext pattern. This is just to show that the
design is wrong, without going into math. Don't suppose that those
desining more complex algorythms do so because they don'y know better.
Not to be rude, but don't just try to change a couple of steps in your
code and resubmit: there's a lot of books and papers on cryptography,
this one has been recently recommended by a cryptographer on another
mailing list:
http://www.amazon.com/Cryptography-Practice-Discrete-Mathematics-Applications/dp/1584885084
Regards,
- Claudio
--
Claudio Telmon
claudio@telmon.org
http://www.telmon.org