Secure login system

Started by
33 comments, last by leeor_net 14 years, 7 months ago
How does that work? Generates some pseudo-random number? How can that help?
Advertisement
one time pad is unbreakble. litereally you and the other side share a list of random numbers. then you use that to hash your message in some way. for example, just xor your message with the next n bits of the one time pad, then the other sides xors your received messag to retreive it. unless your attacker has access to the pad you are good.
Quote:Original post by Antriel
How does that work? Generates some pseudo-random number? How can that help?


wiki.

The cheapo solution could be one time pad via mobile phone instead of separate device.
Regarding public key cryptography and man-in-the-middle, I'd like to add that this isn't a real issue here.

Man-in-the-middle attacks work because the two communicating parties don't know each other and thus don't know the respective other's public key, making a key exchange necessary. Man-in-the-middle attacks this exchange.

However, you can trivially distribute your server's public key with the game, so the game client knows the server's public key. No exchange is necessary.

A man-in-the-middle attack is thus only possible if someone manages to get malware on your computer which steals the public key and replaces it with another one. Then again, if someone can do THAT, then security is compromised in a way that concludes everything else, anyway. If I can change files on your PC, I can as well steal your passwords without having to bother about intercepting your network traffic.
Quote:Original post by Antheus
wiki.

The cheapo solution could be one time pad via mobile phone instead of separate device.


Read it.. still don't understand.. if user add some numbers to it's password.. server would have to know that numbers.. but how?

Quote:Original post by samoth
Regarding public key cryptography and man-in-the-middle, I'd like to add that this isn't a real issue here.

Man-in-the-middle attacks work because the two communicating parties don't know each other and thus don't know the respective other's public key, making a key exchange necessary. Man-in-the-middle attacks this exchange.

However, you can trivially distribute your server's public key with the game, so the game client knows the server's public key. No exchange is necessary.

A man-in-the-middle attack is thus only possible if someone manages to get malware on your computer which steals the public key and replaces it with another one. Then again, if someone can do THAT, then security is compromised in a way that concludes everything else, anyway. If I can change files on your PC, I can as well steal your passwords without having to bother about intercepting your network traffic.


This sounds good.. but when there is a method to calculate a public key, with enough time, there should be possibility to brute force the private key or not? I mean if I know what the public key is, I can generate public keys until I got the same one and I also know the private key now.
Now thinking about it.. if this would be possible then just sniffing the packets.. someone would know the public key and encrypted password.. so with enough time he would be able to do the same thing... I really should start learning math on my own.. schools are useless
"If I understand this, by using TLS I would need some third party server to authenticate certificate"

You can set up your own certificate authority. You own the server, you can create the root certificate. Users present their certificate during authentication, and you can verify it.

It's actually pretty easy to do this - there's a lot of guides on the net to setting up a CA.

Quote:Original post by samoth
However, you can trivially distribute your server's public key with the game, so the game client knows the server's public key. No exchange is necessary


Precisely.

Quote:Original post by Antriel
This sounds good.. but when there is a method to calculate a public key, with enough time, there should be possibility to brute force the private key or not? I mean if I know what the public key is, I can generate public keys until I got the same one and I also know the private key now.
Now thinking about it.. if this would be possible then just sniffing the packets.. someone would know the public key and encrypted password.. so with enough time he would be able to do the same thing... I really should start learning math on my own.. schools are useless


Pop quiz: what's 2^1024? 1024 bits is the minimum length of any asymmetric key these days. Suffice to say that even if you could test trillions of keys per second, you'd be waiting around until long after the heat death of the universe. Any notion of "brute force" becomes entirely absurd around (really before) the 128-bit mark.
Quote:Original post by drakostar
Pop quiz: what's 2^1024? 1024 bits is the minimum length of any asymmetric key these days. Suffice to say that even if you could test trillions of keys per second, you'd be waiting around until long after the heat death of the universe. Any notion of "brute force" becomes entirely absurd around (really before) the 128-bit mark.


No, brute force is very effective.
With custom hardware, you can brute force a lot more than you can on a single PC-type computer.

That's why modern encryption targets 192 and even 256 bit keys, even for symmetric ciphers. (AES supports 128, 192 and 256 bit key sizes)
enum Bool { True, False, FileNotFound };
Quote:Original post by hplus0603
With custom hardware, you can brute force a lot more than you can on a single PC-type computer.

That's why modern encryption targets 192 and even 256 bit keys, even for symmetric ciphers. (AES supports 128, 192 and 256 bit key sizes)


Per "Applied Cryptography", spending $10 trillion in 1995 on custom hardware would brute force your 128-bit key in 10^11 years. Even if we wildly overestimate the hardware progress in the last 15 years (say 1000x faster and 1000x cheaper), we're still way way off from anybody feasibly cracking a 128-bit key.

Of course, this is just brute force we're talking about. The slight practical reason for 256-bit symmetric keys and 4096-bit asymmetric keys is a bit of a hedge against a very successful attack on the algorithm, preferably combined with dramatic breakthroughs in mathematics, a few decades of technological development, and the NSA not liking you very much.

ETA: Schneier also had an amusing calculation that the energy of a supernova would be just about sufficient to flip through a physically ideal (ie, better than any technology that could possibly exist) 220-bit counter. Just the counter, no encryption or anything. Wikipedia has a similar calculation for an ideal 128-bit counter: 30 gigawatts for a year. Just to flip through the counter, nevermind doing anything with each number.

[Edited by - drakostar on September 21, 2009 11:46:11 PM]

This topic is closed to new replies.

Advertisement