flat assembler
Message board for the users of flat assembler.

 Index > Main > Philosophizing about cryptography... Goto page Previous  1, 2, 3  Next
Author
 Thread
AlexP

Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP 04 Mar 2008, 02:34
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.
04 Mar 2008, 02:34
r22

Joined: 27 Dec 2004
Posts: 805
r22 04 Mar 2008, 03:45
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)
04 Mar 2008, 03:45
bitRAKE

Joined: 21 Jul 2003
Posts: 3977
Location: vpcmipstrm
bitRAKE 04 Mar 2008, 03:58
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.)

 Description: PRNG + XOR Download Filename: not-OTP.rar Filesize: 10.82 KB Downloaded: 349 Time(s)

_________________
¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup
04 Mar 2008, 03:58
revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20215
Location: In your JS exploiting you and your system
revolution 04 Mar 2008, 04:35
@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 125-digit 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 RSA-129 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 129-digit numbers. The memory requirements of the newer algorithm were also a concern.
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.
04 Mar 2008, 04:35
bitRAKE

Joined: 21 Jul 2003
Posts: 3977
Location: vpcmipstrm
bitRAKE 04 Mar 2008, 05:52
[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.

_________________
¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup
04 Mar 2008, 05:52
daniel.lewis

Joined: 28 Jan 2008
Posts: 92
daniel.lewis 05 Mar 2008, 00:00
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

Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP 05 Mar 2008, 00:05
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)
05 Mar 2008, 00:05
r22

Joined: 27 Dec 2004
Posts: 805
r22 05 Mar 2008, 00:51
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

Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 05 Mar 2008, 00:57
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.
05 Mar 2008, 00:57
AlexP

Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP 05 Mar 2008, 00:57
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

Joined: 27 Dec 2004
Posts: 805
r22 05 Mar 2008, 01:24
re: alex

I'll reiterate another section from my post that you refused to read but felt it necessary to comment on
Quote:

So, do we really need new encryption ? NO

But researching more efficient and secure algorithms is a novel pass-time.
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
05 Mar 2008, 01:24
revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20215
Location: In your JS exploiting you and your system
revolution 05 Mar 2008, 01:27
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).
05 Mar 2008, 01:27
AlexP

Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP 05 Mar 2008, 01:42
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.
05 Mar 2008, 01:42
r22

Joined: 27 Dec 2004
Posts: 805
r22 05 Mar 2008, 01:44
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.
05 Mar 2008, 01:44
AlexP

Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP 05 Mar 2008, 01:49
Wow.. r22 is so near-sighted .
05 Mar 2008, 01:49
revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20215
Location: In your JS exploiting you and your system
revolution 05 Mar 2008, 01:56
r22 wrote:
... but it only proves my point (25[6]bit keys are statistically uncrackable for the foreseeable future) further.
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.
05 Mar 2008, 01:56
AlexP

Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP 05 Mar 2008, 02:19
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
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20215
Location: In your JS exploiting you and your system
revolution 05 Mar 2008, 02:21
AlexP wrote:
is there such [uncrackable] algo that exists?
Sure, there are a few, the most well known is OTP.
05 Mar 2008, 02:21
r22

Joined: 27 Dec 2004
Posts: 805
r22 05 Mar 2008, 02:22
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

Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP 05 Mar 2008, 02:30
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 2-5 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
 Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First

 Jump to: Select a forum Official----------------AssemblyPeripheria General----------------MainTutorials and ExamplesDOSWindowsLinuxUnixMenuetOS Specific----------------MacroinstructionsOS ConstructionIDE DevelopmentProjects and IdeasNon-x86 architecturesHigh Level LanguagesProgramming Language DesignCompiler Internals Other----------------FeedbackHeapTest Area
Goto page Previous  1, 2, 3  Next

Forum Rules:
 You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum

Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.