Or use something like GrandCru, (I couldn't get exact's on it either, I think I read that the designer died), which is Rijndael combined with several other things.

This idea of "layered cryptography" I think is better, having each round be encrypted with several ciphers, that way if one or more are broken there are still more.

A 256bit encryption key is for all intents and purposes futile to brute force. If the algorithm is secure than what is the point of layering other secure algorithms on top of it.

The "idea" of layered cryptography is nice, but it's also pointless and inefficient at this time.

I'll prove my point:

256bit Key/Password = 2^256

Birthday attack sqrt(2^256) = 3.4028236692093846346337460743177e+38
I WON'T even mutliply it by 1.25

We'll say it takes 40cycles to prove if a key is the one we want (obviously it would be more)
1 4ghz quadcore cpu = 429,496,729.6 checks / second

We'll say we have 1million of those processors.
1million * 429,496,729.6 = 429496729600000 tries / second

How many seconds will it take my omega super computer network to theoretically crack a 256bit encryption key?
3.4028236692093846346337460743177e+38 / 429496729600000
= 792281625142643375935440 seconds

How many YEARS is this?
792281625142643375935440 / 60 / 60 / 24 / 365.25 = 25,105,889,710,961,650 years

****************************************************
BUT BUT BUT cell processors and nanotechnology in 50yrs we could have 65536 core cpus running at 1024Thz (YOU THOUGHT I WAS DONE, NO I'M KILLING THIS SECURITY MISCONCEPTION RIGHT NOW) Oh, and it doesn't take 40cycles to check for a valid key in the 50yrs from now (asininely over estimated future) it just takes 1cycle!!!!
sqrt(2^256) / (1024000000000000*65536) / 60 / 60 / 24 / 365.25
= 160,677,694,000 YEARS
****************************************************

So, do we really need new encryption ? NO

But researching more efficient and secure algorithms is a novel pass-time.

I apologize for totally ruining the "mystery" of security/encryption for everyone. (At least everyone too naive to do the math)

Good Luck!

(Key is in the file - doubt anyone can crack it. To make it easier I've included the source code and exe encrypted, but I can encode additional files if you think that will help.)

@r22: Thanks for the demonstration, but that is quite pointless because we cannot make predictions about things unknown. ie. We have no idea how future advances in mathematics will affect the time needed to break encryption. eg.
AlexP's statement about layering is useful to try to help guard against a new mathematical breakthrough making a particular encryption algo insecure. If each layered scheme is sufficiently different in it's nature then there is a good chance any breakthrough won't also simultaneously break all algos.

@bitRAKE: I think you achieve nothing with this demonstration. Just because a bunch of us amateurs may not be able to break it proves nothing about it's real strength.

[quote="revolution"]I think you achieve nothing with this demonstration. Just because a bunch of us amateurs may not be able to break it proves nothing about its real strength.[/quote]Totally. Security through obscurity - more than anything else. :lol:
(although, most the source code is already on the forum)

Edit: found an error in my implementation. during debugging I deviated from original design in a negative way. the less secure files will remain posted.

The random number generator has a state space of 2058 bytes, but is seeded from a much smaller value. Knowing the PRNG does not help to determine the seed. The algorithm to determine the seed has already been proven to be very difficult to break. Then an additional step was added to make brute force attacks very difficult - assuming the seed algorithm is known. In total there are three "secrets" to the encryption which do not rely on each other.

Yeah. I don't know much about data encryption strength. I more or less found OTP and Beale Cipher right off, and kept going back to "proveably impossible to break without the key".

The fact that it's the one the superpower militaries use for transmitting major secrets says something for it.

I also liked that you could apply more than one key, reference a commonly accessible key (not have to transmit it), and mask the key(s) and the plaintext using any sequence of operations that don't lose data or overflow, which tends to kill statistical analysis.

add a, b
rcl a, 11
rcr b, 14
or b, c

bla bla bla

r22: The key for GrandCru isn't 256-bit, I believe there's four of these keys, one for each cipher used. It (in theory) provides the strength of four ciphers, but saves much time and is great in practice because all four of the ciphers are performed in each round.

GrandCru also has before- and after- processes, I'm not sure of the details but I'll link them. As good, if not more (much more) security than 256-bit AES.

https://www.cosic.esat.kuleuven.be/nessie/deliverables/D13.pdf (pg. 32)

[url] http://en.wikipedia.org/wiki/Grand_Cru_(cipher) [/url]

[url] http://citeseer.ist.psu.edu/cache/papers/cs/26801/http:zSzzSzwww.cosic.esat.kuleuven.ac.bezSznessiezSzreportszSzphase1zSzkulwp3-006-1.pdf/a-first-report-on.pdf [/url] (pg. 4)

re: alex

I think you totally missed the point of my post. So I'll sum it up.

-IF A 256BIT KEY AND 1 SECURE ALGORITHM IS STATISTICALLY UNCRACKABLE, THEN THERE IS NO POINT TO ADDING EXTRA COMPLEXITY OR LAYERING OTHER ALGORITHMS WITH MORE KEYS ON TOP.

There's no need for extra security. The current cryptographic algorithms and key lengths are sufficient WELL INTO ANY FORESEEABLE FUTURE. Adding extra security for no reason is just inefficient.

Do the math use a 512bit key there's no way any hardware will ever be able to touch it for hundreds of years to come. If you don't believe me use Moore's Law to estimate hardware in 50 years then multiply that estimate by 1million and it still won't be able to touch a 512bit key.

r22: to be fair there's still the (very remote?) possibility that a flaw could be found in one of the ciphers that would reduce the attack complexity below a full keyspace scan... theoretically, chaining two different ciphers might help against such an attack. Personally, I just stick with AES-256 though.

Intellectuals solve problems; geniuses prevent them.
- Albert Einstein

Human lives are dispensable; knowledge knows no end.
- Someone who found it.

Don't ever do what you "estimate" will be sufficient, excel. If it were not for people dedicating their lives to going beyond the norm, we would live in a simple world where everything is "sufficient and prudent".

Why would anyone ever stop when they find "what works". That's either selfish thought, or just plain laziness. What do you think.

re: alex

I'll reiterate another section from my post that you refused to read but felt it necessary to comment on
That's what I think

And not to dig on you further for not reading the thread on the last page I posted a link to an encryption thesis and algorithm that I wrote that uses a 1024bit key, a PRNG that passes the NIST randomness suite and is optimized for x86-64.


re: f0dder

Good point, but I'd use 384 or 512bit in 200yrs your secret pr0n collection might get hax0red. lol

r22: BTW I think your figures are in error, IIRC the birthday attack is only relevant to hashes. For your calculation you need 2^(n-1), not sqrt(2^n).

well, for a key size of 256 bits, you would expect to find the right key after half of the total number keys possible, right? IDK, never read about birthday parties .

r22: I had read those posts, I never said that you should implement such future algorithms, geez quit jumping to conclusions!

All: Do you believe we should continue to research and invent new algorithms (to use), even if the current are "estimated" to be unbreakable for hundreds of years?

BTW: when aliens finally land with quantum-ness on their side, they'll see our uber future ciphers and go "WTF???? WHY THE HELL WOULD YOU DO THIS???" and decide not to destroy our world.

re: revolution

2^(256-1) is MUCH greater than sqrt(2^256)
5x10^76 vs. 3x10^38
So good catch, but it only proves my point (25bit keys are statistically uncrackable for the foreseeable future) further. If I used 2^(256-1) in my calculations it would of just made the outcomes more ridiculously huge.

Wow.. r22 is so near-sighted .

The key is huge, that is for sure, but the algo is not a proved case. To this date no one has a practical algo that is also proved uncrackable via shortcut methods.

To add to revolution, is there such algo that exists? That would be nice. I think the simple structure of AES is a great starting point to finding a cipher like that!

Sure, there are a few, the most well known is OTP.

re: revolution

A secure PRNG can be proven uncrackable by shortcut methods.

Of course you'd have to run/iterate the PRNG some N times for every blcok of cipher text you encrypt.

You can trace literally every bit in a secure PRNG algorithm and map all the dependencies (from one state to the next) to make sure the computational work involved in reversing it is greater than or equal to a brute force attack on the key.

I started doing this in my thesis but I didn't have the months needed to create the proper proofs, and frankly that amount of work was beyond the scope of an undergrad course.

ALSO

Proving something UNcrackable seems illogical like proving God doesN'T exist. But that's just a matter of semantics, UNTIL fault is found in an algorithm it's uncrackable/secure. Innocent until proven guilty or guilty until proven innocent?

re: alex

My jabs at you at least had substance.

lol you know what I mean .

r22: Hey, call me in 10 years so we can argue at the same level (provided you stay in some alternate dimension where time doesn't exist).

Okay, I've got an instruction problem:

I've got a loop that runs about 50 or 60 times, between 2-5 instructions per loop, and I can either use:

I need one or the other for every iteration, was wondering which one would work better.