Author Topic: State-based RNG (linear-congruential)  (Read 2884 times)

It's not that it's hard to code, it's that it takes a long time to process things for big integers.

You see, RSA works on the premesis that factoring a large number is a difficult task.

In general, here's the backbone of RSA:



Where m is the message and k is the key.
The thing that makes this difficult for a language like TorqueScript to evaluate is that, bluntly put, for a large message (and hence a large m of say 5kb or 40,000 bits), and a half decent key of say 2048 bits, that's raising a 12,000 digit number to a power of a 600 digit number.

Even with a decent modular exponentiation implementation that would still take unreasonably long to calculate.

arbitrary precision arithmetic isn't inherently hard though, right? it's basically just implementing normal addition and subtraction algorithms manually, right?

Correct, it's basically doing calculations the way you learned them in first grade. Starting from the right, add digits individually, shifting the leftover to the next digit.

There's a couple bignum libraries floating around the forums somewhere.

Even with a decent modular exponentiation implementation that would still take unreasonably long to calculate.

Not necessarily. Just include a GUI with a progress bar and your users will be like "cool, it's doing something". Break the work down into chunks so that the game doesn't stop responding.
« Last Edit: November 10, 2013, 10:43:18 PM by Greek2me »

yes yes i know how rsa works (aes i understand the basics, never actually implemented it)

but like, suppose we used aes and elliptic curves, or even diffie hellman

forget, diffie hellman and a one time pad

suppose we do that and we do it through string based math or arbitrary precision arithmetic, which runs on a recursive schedule loop so it doesn't make blockland not responding (threading, essentially)

how absolutely terribad would this even be
the one time pad would be spectacularly trivial to calculate, we just have to get a decently sized number agreed upon
Correct, it's basically doing calculations the way you learned them in first grade. Starting from the right, add digits individually, shifting the leftover to the next digit.

There's a couple bignum libraries floating around the forums somewhere.

Not necessarily. Just include a GUI with a progress bar and your users will be like "cool, it's doing something". Break the work down into chunks so that the game doesn't stop responding.
wait there is some bignum (couldn't remember this name) libraries for torquescript? i have to find these
chunks and a schedule loop
stuff would work great

There's a couple bignum libraries floating around the forums somewhere.

Not necessarily. Just include a GUI with a progress bar and your users will be like "cool, it's doing something". Break the work down into chunks so that the game doesn't stop responding.
Yes I know, I wrote one of them and even made optimized Karatsuba multiplication which will work faster on larger integers. (Which I still have to upload mind you, I keep forgetting)

Using binary modular exponentiation, you're still doing at least 2000 multiplications of incredibly large numbers which may take 6-8+ seconds each to complete because torquestuff, even with an optimized multiplication method. Yes, it's going to take an unreasonably large amount of time. But again, that's just for RSA.

http://forum.blockland.us/index.php?topic=231452.msg6593379#msg6593379

found the list

why can't we use something like elliptic curves??? seriously, NSA says 384 bits is sufficient for that, compared to 2048 for rsa
that's a loving gigantic improvement

then, convert the thing into a string of ones and zeroes and pump it through aes, the same way SSH does it (asymmetric key exchange followed by symmetric algorithm)

honestly with numbers that size it wouldn't take absolutely forever. generate the public/private keys on your own time, then somehow agree on who's computer is stronger, then have it decide on a big key, encrypt it, then send it back to the first guy. decryption is easier, right?

i'm really thinking this is feasible with the right optimizations and algorithms

edit: can't download the one on scatteredspace without an account
... for a dead forum. :(
« Last Edit: November 10, 2013, 11:02:12 PM by Lugnut »

http://forum.blockland.us/index.php?topic=231452.msg6593379#msg6593379

found the list

why can't we use something like elliptic curves??? seriously, NSA says 384 bits is sufficient for that, compared to 2048 for rsa
that's a loving gigantic improvement
You coulda just looked in the coding resources thread where mine is posted and,
if you are able to coach me on how elliptic curve cryptography works and how it is implemented then please do so because I have no idea and I'm 100% willing to implement it if someone can teach me. Steam maybe?

EDIT: I have an account on the scatteredspace forums for some reason, so I downloaded the math library. It seems the only thing it has that mine doesn't is modulus, but here's the pastebin:
http://pastebin.com/qwYRZB0N

I'll be editing mine tomorrow to combine the features that this one has into the ones that mine has. (Exponentiation by squaring, fast multiplication)
« Last Edit: November 10, 2013, 11:20:27 PM by Ipquarx »

honestly with numbers that size it wouldn't take absolutely forever. generate the public/private keys on your own time, then somehow agree on who's computer is stronger, then have it decide on a big key, encrypt it, then send it back to the first guy. decryption is easier, right?

i'm really thinking this is feasible with the right optimizations and algorithms

edit: can't download the one on scatteredspace without an account
... for a dead forum. :(

Decryption is normally much faster.

Yes, this is definitely feasible. If somebody starts working on this, they should set up a bitbucket or something so everybody can review the code and contribute.

Here, I put the SS one on pastebin: http://pastebin.com/BsMn8ryz
« Last Edit: November 10, 2013, 11:11:08 PM by Greek2me »

i already have

https://github.com/Tungul/Script_Crypto

i have two of the three libraries up there already, i'll toss this one in there now

on the downside i haven't got much time in my life to actually work on it
« Last Edit: November 10, 2013, 11:20:52 PM by Lugnut »

Guys, we need to agree on a library to use and build on. SS's, Lugs, or mine?

https://github.com/Tungul/Script_Crypto
Shouldn't it be Support_Crypto? Maybe we should stop derailing Port's thread and make a new one for this.

Guys, we need to agree on a library to use and build on. SS's, Lugs, or mine?
I'm voting against Lug's because it creates an object for each number. EDIT: As does McTwist's.
« Last Edit: November 11, 2013, 12:33:54 AM by Greek2me »

And mine does not, it just works on regular numbers as strings and uses plain named functions.


Holy hell, what in the world is going on here?

Holy hell, what in the world is going on here?

Lol, I'm wondering the same.

is this thing limited to creating numbers limited by torquescript's stuffty 7 digit limitation?

edit: that was a dumb question. you have nothing to make it work with bigger numbers so duh

:/
« Last Edit: November 19, 2013, 01:57:25 AM by Lugnut »