Cryptography Implementation Discussion

[Lugnut]

That'll work for the random seed, but we need a decent rng for the huge prime generation and the one time pad.

We need a rng that will give the same sequence of numbers for a given seed. That will allow us to agree on a key and then generate a sequence of numbers to use in the pad. I'm not sure if such a rng is cryptographically secure...

[Ad Bot]

[Greek2me]

http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf

This might have some useful info.

[Ipquarx]

Or we can say, generate a bunch of random numbers from random.org, string them together, then use a web service to find the nearest prime number.

[Lugnut]

I'm ashamed of you Ip! External random numbers?? How will we keep that secret for our secret numbers?

[Ipquarx]

Well, we could also use a bunch of different random seeds (gathered from say, periodic polls of the cursor's position) to generate digits. The more random seeds used, the better.

[Lugnut]

We still need a good rng. It just has to happen.

But yes, we need a good way to get entropy from client actions in-game as well.

[Xalos]

I really love how Ipq doesn't get the POINT of encrypting with a PRIVATE KEY THAT NO ONE ELSE CAN POSSIBLY KNOW OR INTERCEPT.

"GET YOUR RANDOM NUMBERS FROM A SITE INSTEAD OF LOCALLY SO THAT ATTACKERS HAVE EVERY CHANCE TO BREAK YOUR ENCRYPTION POSSIBLE."

[Ipquarx]

'scuse me sir
'scu- 'scuse me
SIR

I think you need to calm down sir

(I'm making a fast primality check right now, bear with me)

[Lugnut]

But I have one that's okay :(

I don't want a primality check with "levels of precision"

I never understood that bs. You want a prime number, spend the extra time making absolutely positive it's frigging prime.

[Ipquarx]

Lug, if we're dealing with 1024+ bit numbers we're going to need to use a better method than trial division.

[Lugnut]

breaking news: the diffie hellman + otp idea is essentially a stream cipher

so yeah, may as well skip that whole idea and just do a legit stream cipher.

i'll be looking into that



also we won't be using 1024 bit numbers, we'll be using 384 bit numbers. either way, fast primality check is still a good idea i guess grumble grumbleedit i'm looking at this more and more and i am not ready to do this yet. there's quite a few pieces of math i need to pick up yet, so it's safe to say that ECC is not going to be coming along any time soon.
i'll try to implement a stream cipher just for fun pretty quickly now, but ecc (the fun bit that's actually useful) will either have to wait or someone else more knowledgeable will have to do it.

presently though, we need to have a decent library (which we have, it's just missing some important features that ip is working on) and i'll keep this topic updated with stream cipher info, but ECC isn't happening any time soon (it isn't a weekend project or whatever)

[Xalos]

I think you need to calm down sir

You are trying to get a PRIVATE KEY by asking a PUBLIC SITE for your random numbers.

How the hell do you NOT GET that that is NOT SECURE?

[Ipquarx]

You are trying to get a PRIVATE KEY by asking a PUBLIC SITE for your random numbers.

How the hell do you NOT GET that that is NOT SECURE?

I get how it isn't secure assuming that the attacker can listen in on all packets being sent and received by both parties. I was saying that under the assumption that the attacker would only be able to listen on communications being sent to and from the respective parties, like how the Alice, Bob, and Eve examples are always shown.

@Port: all you would need to do is look for traffic coming from random number generating websites. It's not that difficult.

[Port]

You are trying to get a PRIVATE KEY by asking a PUBLIC SITE for your random numbers.

How the hell do you NOT GET that that is NOT SECURE?

If you had access to a byte stream of all network traffic from a specific user, cummulatively up to hundreds of gigabytes, how the hell would you figure out what part exactly is the private key?

[Xalos]

If you had access to a byte stream of all network traffic from a specific user, cummulatively up to hundreds of gigabytes, how the hell would you figure out what part exactly is the private key?

You can still tell packets apart. Find the packets to and from random.org. There's your private key.