Re: Quadruple Algorithms

On Mar 3, 10:29 am, Guy Macon <http://www.guymacon.com/> wrote:
Paul Rubin wrote:
Well, ok, but don't bet the farm on those advancements ever occurring
or being possible in the physical universe. That's all I'm sayin'.

If you examine previous posts to this thread, you will see that
the original claim was that the odds of "those advancements ever
occurring" (a fatal flaw being found in AES, a Quantum computer
that can brute-force AES being invented, and the implementation of
AES you use having a bug were mentioned) are very small but non-
zero. More than one chance in 2^128 was the estimate, and I think
that to be a reasonable lower limit.

The above "don't bet the farm" statement seems to agree with
that likelihood estimate; very small but non-zero.

These very small but non-zero odds -- especially when the person
doing the guessing as to what the odds are has little to base the
guess on -- are much larger than the odds of a successful brute
force attack on a cipher with a keysize in the 2^128 to 2^256
range, and nobody knows how much larger.

Assuming that it is *REALLY* important that your data stay
secret over a long time, you should minimize the chances of
the most likely attack on your entire system, followed by the
next most likely attack, etc, and also by addressing attacks
that are particularly easy to avoid first.


If you view the history of cyrpto you quickly learn the experts
are almost always wrong. Therefore even AES will be broken
some time. As a recent publicly known example look at the
german naval enigma machine I wont even give the estimate
of the power of two of its key space. The germans thought it
was safe they know a brute force attack randomly testing
the key space would be impossible. Even with todays super
computers it would not be possible. Yet without real computers
the English working on the results of the Polish effectively
broke it.
You could make an argument that the people working in
cyrpto today are not as smart as the world war II people and
you may have a valid point. Managers today don't want people
of interlligence working on anything. People are a dime a dozen
yet I suspect in countries on the way up they may still want
talented people so a break in crypto AES would most likely
come from the chinese or indians. AES will not be broken
but americans or europeans unless it will desingned already
broken which could be a very real possiblilty.

If you really want secure crypto use various layers of encryption
where at least all the middle layers if not all are bijective if not
for all files at least for fies longer than a few bytes.

For AES use bicom or edit the code your self to add alternate
modes but make it bijective if possible

Of course I would use some form of scott19u but hay that just
me. And would do bijective whitening transforms between the
various encryption levels.

.....

One reasonable and easy-to-do strategy to counter the above
threats would be to encrypt the data through multiple strong
algorithms with widely different designs and, hopefully, few
common weaknesses.


The problem here is the word "hopefully''. The fact is alot
of these designs may have on seen daylight because powerful
governments have allowed them too. Thats what I would do
if I ran the NSA in the old days. But also much of crypto has
been done by people of common miinds who share a common
history. You should have a few exotic layers that the crypto
community laughs at yet can't break. I would even suggest
one that experts thought could be broken by powerfu new
attacks that when tried failed. Or ones where the source code
is available yet the so called experts can't follow or at least
say its to complicated to follow. C is had it seems is beyond
the understanding of many elites. Don't take this the wrong
way I am sure many of those desgning crypto are doing the
best they can. What I am saying is that in crypto people
behind the crutain are blessing or not blessing certain results
or directions of reseach. They can quickly claim something
is snakeoil if they don't want it to see the light of day.


Here is one way to do this.

Start with four different random 256-bit keys (1024 bits).
This is too large to be contained in an easy-to-remember
passphrase, but then again, so is 128-bits.

Encrypt four times, with the output of one cipher feeding
the input of the next, using the following ciphers:

AES256.http://en.wikipedia.org/wiki/Advanced_Encryption_Standard

RC4-drop[65536] (AKA ARCFOUR-drop[65536]).http://en.wikipedia.org/wiki/Rc4http://www.users.zetnet.co.uk/hopwood/crypto/scan/cs.html

XXTEA with the block size equal to the entire message.http://en.wikipedia.org/wiki/XXTEA

GOST 28147-89http://en.wikipedia.org/wiki/GOST_28147-89

Why those four?

They are the most "different from each other" that
I could find, making it unlikely that a flaw in
one would also be in the others, and unlikely that
they share any code.

AES256 is a substitution-permutation block cipher with
a 128-bit block size.

RC4 is a stream cipher with a 2048-bit state array.

XXTEA is an unbalanced Feistel network block cipher
with the block size equal to the entire message.

GOST is a Feistel network block cipher with a 64-bit
block size

They include two algorithms that are very popular
and most looked at (AES) and an algorithm that is
not popular and not closely looked at (GOST).

Two of the algorithms (RC4 and XXTEA) are noted for
having small/simple code, thus reducing the chances
of bugs in the implementation.

Again, this is total overkill, but if any of the three
unlikely but still possible threats listed above
concern you, this is an easy-to-do countermeasure.

--
Guy Macon
<http://www.GuyMacon.com/>

I am not sure if this test would work on these but I have used on
IDEA and
such. Even doing seperate encryptions on files where the byte order
is reversed on seperate passes.

This test will NOT WORK if you have some "random data" that is
added in which initself is questionalbe,

Do your four encryptions on say a one megabyte file.
change some byte in the middle of the encrypted output file.

Now undo the encryption. I know on DES IDEA AES(CBC FORM)
that only a few bytes either side of where you messed up will be
changed. IF this happens in you test then it means the encryption
does not do a very good job of whitening the infromation through out
the file. If this is no big deal or cares. But if your as distrustful
of modern blessed crypto systems as me its a big deal.

David A. Scott
--
My Crypto code
http://bijective.dogma.net/crypto/scott19u.zip
http://www.jim.com/jamesd/Kong/scott19u.zip old version
My Compression code http://bijective.dogma.net/
**TO EMAIL ME drop the roman "five" **
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged.
As a famous person once said "any cryptograhic
system is only as strong as its weakest link"
.

Relevant Pages

  • Re: Determining the cipher when knowing the plain and the encrypted data
    ... try encrypting a fairly long plaintext consisting of nothing ... if the cipher was, say, a block cipher in ECB mode, this test would ... even if this doesn't work because the encryption process is ... if it's a closed-source crypto utility that doesn't even describe how ...
    (sci.crypt)
  • Re: An Unblinkered Analysis.
    ... A cipher can be secured by a random key-set with the caveat that the ... once in the encryption of a particular message. ... due to re-use of a portion of the key) secure by splitting it into ... My Crypto code ...
    (sci.crypt)
  • Re: Thanks for your answer, David, but I dont work the snake oilers. My question was only about pre&
    ... encryption product I would call it Oil of Black Mamba ... Now I am not sure AES is safe. ... crypto even more. ... My Compression codehttp://bijective.dogma.net/ ...
    (sci.crypt)
  • Re: encription to memory
    ... It's difficult to give you exact formula because its different depending on ... -block cipher works on whole blocks and with AES it's 128 bits ... Rijndael is not exactly AES, but an AES candidate that was chosen to ... > this way you don't need to know the encryption block size. ...
    (microsoft.public.dotnet.security)
  • Re: Triple AES (3AES)
    ... If I'm using double encryption with one encryption being AES and the ... other being simple XOR with my key the result will be as strong as AES. ... Quite obviously we would have to see the combination as a new cipher ...
    (sci.crypt)