Diffie-Hellman integer size - falloff in encryption strength?
Author
Hi, not posted here before but it seems the place to do it.
Anyway, as part of the project I'm working on...
(http://www.bloodspear.co.uk)
...I'm developing a large suite of libraries to ease making a MOG. Currently I'm faffing around with authentication and encryption as part of the network layer (although the encryption may shift back to the core for data encryption).
Anyway, whilst I'm implementing a D-H key exchange to cover initial connections and internal encryption key passover (the D-H key is not used for long) it's occured to me that it could be faster using smaller integer sizes. Currently I have the protocol implemented for 128 bit integers. Is this sufficient? Passwords and user names will both be sent hashed, though I haven't decided on the hashing mechanism yet, but it's likely to be MD5.
Cheers
Winter
edit: Oh God. It's barely a question. The point is, is 128bit a large enough integer to give a reasonable strength to the D-H key, or at least keep it secure long enough so a packet sniffer can't determine what the gameplay key is? (i.e. until log-in is confirmed)
I think you have a problem in your analysis:
Even if a packet sniffer can't decrypt the DH exchanged key in time for the "real" key to be exchanged, it can still capture the packet where the real key was exchanged, and decrypt it once the broken key is discovered. Your key strength needs to cover the maximum length of any game session -- or the maximum key cycle lifetime length, if you use a key cycling protocol.
Typically, public-key cryptography isn't considered "safe" until it's at least 1024 bits in size, but I'm not enough of a math expert to tell you why. If the goal of your library is to create an industrial-strength cryptographic communications library, 128 bits sounds small.
However, why are you so worried about sniffer attacks? Anyone wishing to cheat would just attach to the client directly, and sniff out the un-encrypted data out of RAM.
Even if a packet sniffer can't decrypt the DH exchanged key in time for the "real" key to be exchanged, it can still capture the packet where the real key was exchanged, and decrypt it once the broken key is discovered. Your key strength needs to cover the maximum length of any game session -- or the maximum key cycle lifetime length, if you use a key cycling protocol.
Typically, public-key cryptography isn't considered "safe" until it's at least 1024 bits in size, but I'm not enough of a math expert to tell you why. If the goal of your library is to create an industrial-strength cryptographic communications library, 128 bits sounds small.
However, why are you so worried about sniffer attacks? Anyone wishing to cheat would just attach to the client directly, and sniff out the un-encrypted data out of RAM.
Quote:Original post by _winterdyne_
edit: Oh God. It's barely a question. The point is, is 128bit a large enough integer to give a reasonable strength to the D-H key, or at least keep it secure long enough so a packet sniffer can't determine what the gameplay key is? (i.e. until log-in is confirmed)
For game data yes IMO it might be good enough. If you use this to send a password and I'm an attacker and want to get your users password from the data stream, it might not be. An attacker could spend some time cracking your small key and get his password and then hack his account.
If you use the protocol to send credit card and personal info, then I would guess it is not. One of the big MMOs does this (uses their own protocol to send CC info) and there was a big brouhaha over it, although they use really big RSA keys so most attacks are useless.
> it can still capture the packet where the real key
> was exchanged, and decrypt it once the broken key
> is discovered.
Wouldn't a Turing Image login process avoid such a problem in this case?
-cb
> was exchanged, and decrypt it once the broken key
> is discovered.
Wouldn't a Turing Image login process avoid such a problem in this case?
-cb
Quote:Wouldn't a Turing Image login process avoid such a problem in this case?
The question I ask myself is: Wouldn't it be easier to just use OpenSSL and let it deal with it? :-)
Btw: regarding the TURing Image, not really. An attacker can be assumed to have human intelligence.
Well... Consider that the bare minimum keylength which is recommended for DH protocols is 1024 bits. For each bit a key has below that, the time to bruteforce the key is -halved-.
512 bits keys can be broken in about six weeks on a dedicated PC, from what I've heard using new methods. Halve that time 384 times, and you're left with... not much.
In that case, encryption can be worse than useless, as it'll give you a false sense of security. The only benefit I could see, is that you'd prevent the extremely theoretical attack of a hacker sniffing a hashed password and then sending a spoof on a faster line. But then, you're using a challenge-response protocol for the password, right? Right?
I'm still a bit unsure why you'd want to save time in this instance, though... It's not like your users will care overly much if there's a slight delay when they first try to login. People don't mind when visiting HTTPS pages (and yes, that's usually RSA and not DH, but the calculation time shouldn't be that far off, if memory serves).
As Hplus said, why not use OpenSSL? No need to reinvent the wheel :). When you're implementing encryption algorithms on your own for the first time, making mistakes can be very easy. Mistakes that might well cost you the whole advantage of using encryption in the first place. OpenSSL is tried and tested.
512 bits keys can be broken in about six weeks on a dedicated PC, from what I've heard using new methods. Halve that time 384 times, and you're left with... not much.
In that case, encryption can be worse than useless, as it'll give you a false sense of security. The only benefit I could see, is that you'd prevent the extremely theoretical attack of a hacker sniffing a hashed password and then sending a spoof on a faster line. But then, you're using a challenge-response protocol for the password, right? Right?
I'm still a bit unsure why you'd want to save time in this instance, though... It's not like your users will care overly much if there's a slight delay when they first try to login. People don't mind when visiting HTTPS pages (and yes, that's usually RSA and not DH, but the calculation time shouldn't be that far off, if memory serves).
As Hplus said, why not use OpenSSL? No need to reinvent the wheel :). When you're implementing encryption algorithms on your own for the first time, making mistakes can be very easy. Mistakes that might well cost you the whole advantage of using encryption in the first place. OpenSSL is tried and tested.
Author
<quote>
Well... Consider that the bare minimum keylength which is recommended for DH protocols is 1024 bits. For each bit a key has below that, the time to bruteforce the key is -halved-.
512 bits keys can be broken in about six weeks on a dedicated PC, from what I've heard using new methods. Halve that time 384 times, and you're left with... not much.
</quote>
Thanks, I understand things *so* much better with some kind of real reference.
Looking at the crypto lib in with SSL, I think I'll be adapting my crypto framework to use that - I'm developing drop-in drop-out crypto classes so an app can pick the method they want, and use a generic interface to it.
As far as the challenge on the password goes, yes, there should be one, but I've been trying to design a decentralised login process, which presents a whole pandora's box of problems, and to be honest, is starting to look like a Bad Idea security wise.
This problem is discussed in my other thread on server architecture.
I'm not so fussed about sniffers being used on a user's OWN data stream, since clients are very dumb indeed and are not sent a great amount of irrelevant information. It's more about protecting other datastreams - such as those between servers in a possibly insecure cluster - say if someone is hosting a game on a university lan and a malicious party is sitting eavesdropping at a software gateway.
Well... Consider that the bare minimum keylength which is recommended for DH protocols is 1024 bits. For each bit a key has below that, the time to bruteforce the key is -halved-.
512 bits keys can be broken in about six weeks on a dedicated PC, from what I've heard using new methods. Halve that time 384 times, and you're left with... not much.
</quote>
Thanks, I understand things *so* much better with some kind of real reference.
Looking at the crypto lib in with SSL, I think I'll be adapting my crypto framework to use that - I'm developing drop-in drop-out crypto classes so an app can pick the method they want, and use a generic interface to it.
As far as the challenge on the password goes, yes, there should be one, but I've been trying to design a decentralised login process, which presents a whole pandora's box of problems, and to be honest, is starting to look like a Bad Idea security wise.
This problem is discussed in my other thread on server architecture.
I'm not so fussed about sniffers being used on a user's OWN data stream, since clients are very dumb indeed and are not sent a great amount of irrelevant information. It's more about protecting other datastreams - such as those between servers in a possibly insecure cluster - say if someone is hosting a game on a university lan and a malicious party is sitting eavesdropping at a software gateway.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
