flat assembler
Message board for the users of flat assembler.
Index
> Main > Philosophizing about cryptography... Goto page Previous 1, 2, 3 Next 
Author 

r22
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 passtime. I apologize for totally ruining the "mystery" of security/encryption for everyone. (At least everyone too naive to do the math) 

04 Mar 2008, 03:45 

bitRAKE
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.)


04 Mar 2008, 03:58 

revolution
@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.
http://en.wikipedia.org/wiki/The_Magic_Words_are_Squeamish_Ossifrage wrote: Ron Rivest estimated in 1977 that factoring a 125digit number would require 40 quadrillion years, even with the highly conservative assumption that modular multiplication could be carried out in a nanosecond; he therefore then believed that RSA129 could never be broken in practice. What he failed to take into account was the possibility of progress in factoring algorithms, and quite a lot of progress was made in the following decades. Atkins et al. used the quadratic sieve algorithm invented by Carl Pomerance in 1981. While the asymptotically faster number field sieve had just been invented, it was not clear at the time that it would be better than the quadratic sieve for 129digit numbers. The memory requirements of the newer algorithm were also a concern. @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. 

04 Mar 2008, 04:35 

bitRAKE
[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. 

04 Mar 2008, 05:52 

daniel.lewis
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 

05 Mar 2008, 00:00 

AlexP
r22: The key for GrandCru isn't 256bit, 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 256bit 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.bezSznessiezSzreportszSzphase1zSzkulwp30061.pdf/afirstreporton.pdf [/url] (pg. 4) 

05 Mar 2008, 00:05 

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

05 Mar 2008, 00:51 

f0dder
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 AES256 though.


05 Mar 2008, 00:57 

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

05 Mar 2008, 00:57 

r22
re: alex
I'll reiterate another section from my post that you refused to read but felt it necessary to comment on Quote:
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 x8664. re: f0dder Good point, but I'd use 384 or 512bit in 200yrs your secret pr0n collection might get hax0red. lol 

05 Mar 2008, 01:24 

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


05 Mar 2008, 01:27 

AlexP
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 quantumness 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. 

05 Mar 2008, 01:42 

r22
re: revolution
2^(2561) 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^(2561) in my calculations it would of just made the outcomes more ridiculously huge. 

05 Mar 2008, 01:44 

AlexP
Wow.. r22 is so nearsighted .


05 Mar 2008, 01:49 

revolution
r22 wrote: ... but it only proves my point (25[6]bit keys are statistically uncrackable for the foreseeable future) further. 

05 Mar 2008, 01:56 

AlexP
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!


05 Mar 2008, 02:19 

revolution
AlexP wrote: is there such [uncrackable] algo that exists? 

05 Mar 2008, 02:21 

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

05 Mar 2008, 02:22 

AlexP
Quote: Sure, there are a few, the most well known is OTP 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 25 instructions per loop, and I can either use: Code: add edi,4 stosd ; or: mov [constant],eax I need one or the other for every iteration, was wondering which one would work better. Last edited by AlexP on 05 Mar 2008, 02:36; edited 1 time in total 

05 Mar 2008, 02:30 

Goto page Previous 1, 2, 3 Next < Last Thread  Next Thread > 
Forum Rules:

Copyright © 19992020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.
Website powered by rwasa.