As of 12w17a, minecraft implements SSL-like encryption.
- Client connects to server
- C->S 0x02 handshake
- S->C 0xFD encryption request - server sends its public key
- Client generates symmetric key (shared secret)
- Client pings minecraft.net
- C->S 0xFC encryption response - client encrypts shared secret with server's public key and sends
- Server decrypts shared secret with its private key
- Server pings minecraft.net
- S->C 0xFC encryption response - empty payload
- Server enables RC4 stream encryption
- Client enables RC4 stream encryption
- C->S 0x01 login
- S->C 0x01 login
- see Protocol FAQ to get information about what happens next.
The server generates a 1024-bit RSA keypair on startup. The key, when packed into a 0xFD packet, is in PKCS#1 DER format. If you're struggling to import this using a crypto library, you can convert this to common PEM by base64-encoding and wrapping in '-----BEGIN PUBLIC KEY-----' and '-----END PUBLIC KEY-----'.
On receipt of a 0xFD from the server, the client will generate a 16-byte shared secret, to be used with the RC4 stream cipher. It then encrypts it with the server's public key (PKCS#1 padded), and sends it to the server with a 0xFC.
The server decrypts the shared secret using its private key. It then sends a 0xFC to the client with an empty payload, and enables RC4 encryption. Similarly, the client will also enable encryption upon receipt of the empty 0xFC. From this point forward, everything is encrypted.
Both server and client need to make a request to minecraft.net if the server is in online-mode.
After generating the shared secret, the client generates the following hash:
hash := sha1(concat(a, b, c)) where: a = serverId from 0xFC b = server's public key c = shared secret
And sends an HTTP request to
If it returns OK then continue, otherwise stop
As above, after decrypting the shared secret in 0xFD.
If the response is YES then the client is authenticated and allowed to join. Otherwise the client will/should be kicked (unencrypted) with "Failed to verify username!"