You could also use private/public key encryption, like HTTPS does. I really don't know how that works though.

TradeWars has already seen many major changes, and it's still TradeWars.

You know what's really crazy? The skeleton app you get when you create a new Android project in Eclipse or IDEA compiles to around 2.5 MB. A heap dump shows about 4,500 classes and tens of thousands of objects. All this just to print "Hello, world" on the screen.

In a nutshell, public key encryption does two things:

Alice's signature on a file proves that Alice* was in possession of the file and it was not subsequently modified; this can be verified using Alice's public key.

If a server can decrypt messages encrypted with Alice's public key, Bob knows the server he's talking to actually belongs to Alice* and the data stream has not been modified.

* = or someone with access to Alice's private key.

The problem is how Bob knows that Alice's public key is really Alice's. Alice could give Bob her public key over a side channel, like in person on a USB stick, but this isn't practical when you connect to an unknown server on the Internet. This is where a Certificate Authority (CA) comes in. The CA's public key has already been communicated to you over a side channel, namely it comes preinstalled with your OS. Alice pays the CA to sign her public key. Then you can use the CA's public key to validate the CA's signature on Alice's key. We trust the CA to verify that Alice is really Alice because they're in it for the money and their credibility would be destroyed if they didn't.

But automated head shots are so much *fun*!

I actually knew all that, but when I go to my bank account and view my check ledger, anyone with the public key and access to any router between me and the bank could de-crypt the information I requested, so there has to be more to it than that.

hmmmm bob and alice, yo must have been reading this
https://en.wikipedia.org/wiki/Public-key_cryptography

I hate you now... lol j/k

Actually my reactions are so slow that they probably don't need to cheat to kill me, but I'm going to claim those cheating bastards are anyway dammit

Yep, good summary. The thing is, you don't even need a third party CA for a game if you are just protecting communication between the game and its client. The game just needs to know what private key belongs to what client.

Long and short of it, public key encryption helps two parties who don't trust each other communicate safely through the use of a trusted third party. It doesn't solve the client server security problem, though, if your potential attacker has root level access to the client. At that point, the client can't be trusted. Which is why the client should never be trusted.

No, they couldn't. They would have to have the private keys to decypt it. When I communicate with the bank, I encrypt the message I sent them with their public key, which can only be decrypted by their private key. When they respond to me, the message is encrypted with my public key, which can only be decrypted by me with my private key. The private keys are never exchanged. That's how it works

Yeah seriously, that's even more bloat than a Java app

I know they can't I just didn't know why. I thought I was using the public key to decrypt what the bank was sending me, but it is the other way around. So my browser has to create a key pair and send the public key to the bank's web server before they can send me information?

Mr. J. Pritchett sent a reply to me, it follows:

Yes, I'm afraid TW is on hold at the moment, but only while I am working on Star Citizen. Once I am finished with that project, I fully intend to continue working on TW. I have considered whether or not it would be better to allow someone else to continue development of TW, but I definitely am not finished with it. Just busy at the moment.

John

Looks like standing still is the play of the day. I mentioned to John that most of the players are seniors and that the game is dwindling like the embers of a good fire.

cc bee... out

I have Jeff Moriarty on FB, he's a tech news reporter in Phoenix now. I may be mistaken, but I thought Gary paid Jeff to port the door version to MBBS. When Jeff stopped working on bug fixes, Gary found JP. Here's his blog: http://moriartys.net/

But you can't know that without a chain of trust linking back to a public key that was obtained via a side channel. The best you can do is record the first key you received for that client. If the connection was MITMed the first time, you'll never know.

Maybe not. Asymmetric encryption is slow, so it's normally only used to establish a secret symmetric key. A client could generate the symmetric key and send it to the server encrypted with the server's public key. Both sides would use the symmetric key for the rest of the session. I'm not sure if that's how HTTPS works in practice, because the beauty of the whole thing is that applications don't need to deal with any of this.