This page is for David's testing of Wikipedia editing. David's personal sandbox so to speak.
Encrypted connections negotiation
This is a list of different cases of what a client and a server node knows and what then is the best possible encrypted negotiation and connection they can do.
"Stealth" means that someone scanning your ports and not even an eavesdropper should be able to detect what protocol you are using.
"Forward secure" means that even if the client's and/or server's keys later on get compromised old messages still can not be read by an attacker. This is usually done by also using some kind of temporary asymmetric keys that both nodes delete after the session ends. Thus those temporary keys can never be compromised.
For most methods below:
- If possible the client should talk first and the server should only respond after the client told what protocol it wants to talk and only if the server supports the protocol the client wants to use. This is part of stealth and makes it harder for automatic port scanning tools to determine what kind of server you are running.
- IVs should be sent in both directions to prevent replay attacks and man-in-the-middle attacks. Note that the server in most cases should not send its server IV until after it has understood what protocol the client wants to talk. Both IVs should be included in the final shared session secret.
Nothing
Client does not have any keys or user names what so ever. Server knows no keys or user names what so ever. No protocol is pre-agreed.
Best method seems to be:
Protocol negotiation in clear text. The client should talk first and the server should only respond after the client told what protocol it wants to talk and only if the server supports that protocol.
Then the two nodes can do a Diffie-Hellman crypto negotiation. (Note that this can also be done by using temporary RSA keys.)
This is not stealthy and not man-in-the-middle secure but at least passive eavesdropper secure. It also kind of gives forward secrecy.
Almost nothing
Client does not have any keys or user names what so ever. Server knows no keys or user names what so ever. Client expects the server to understand the stealthy Diffie-Hellman crypto negotiation protocol.
Best method seems to be:
Do a stealthy Diffie-Hellman crypto negotiation to agree about a shared secret, then turn on encryption. Then send a first encrypted standard string to show it is the Diffie-Hellman method and that it succeeded.
This is fairly stealthy and it is eavesdropper secure but not man-in-the-middle secure. It also kind of gives forward secrecy.
Note that this can also be done by using temporary RSA keys but then it is less stealthy.
Symmetric key
Client has a user name and a symmetric key (for instance a password or passphrase). Server knows the user name and the user's symmetric key. Client expects the server to understand the stealthy negotiation protocol.
Best method seems to be:
Protocol negotiation using some stealthy method that encrypts from the first byte using the user name + user password as key to encrypt/hide data from the first byte. (Negotiation about what protocol to be used actually can be done encrypted from the first byte.)
Method 1:
For instance use Rik's hashed method or a symmetrically encrypted method. In these methods the server has to test hash or test decrypt for each key it knows and then for each protocol it knows. Then turn on first encryption.
This is stealthy, eavesdropper secure and man-in-the-middle secure. But it is not forward secure.
For added security (and to get forward secrecy) then also do a Diffie-Hellman key negotiation. (Note that this can also be done by using temporary RSA keys.) Then combine the DH negotiated shared secret with the user name and key to get a new stronger shared secret. Then turn on the second stronger encryption.
Now we are stealthy, eavesdropper secure, man-in-the-middle secure and forward secure.
Method 2:
Or slightly less good: First do a Diffie-Hellman crypto negotiation to agree about a first shared secret, then turn on first encryption. Then send a first encrypted standard string to show it is the Diffie-Hellman method and that it succeeded.
Then do more protocol negotiation and tell which user it is and do challenge response on the user key. Then combine the Diffie-Hellman negotiated shared secret with the user name and key to get a new stronger shared secret. Then turn on the second stronger encryption.
This is fairly stealthy, eavesdropper secure, man-in-the-middle secure and forward secure.
Server certificate
This is the normal case on the web today. Client does not have any keys or user names what so ever. Client is aware of CAs and can thus check certificates. Server knows no user keys or user names what so ever. Server has an asymmetric key pair and has a certificate for them. No protocol is pre-agreed.
Best method seems to be:
Protocol negotiation in clear text. The client should talk first and the server should only respond after the client told what protocol it wants to talk and only if the server supports that protocol.
Method 1:
Then the server sends its certificate to the client. The client now creates a random session key, encrypts it and sends it to the server by using the server's public key. Turn on encryption.
This is not stealthy and not forward secure, but it is passive eavesdropper secure and man-in-the-middle secure.
Note that the client here knows for sure what server it talks to but the server does not know who the client is.
Method 2:
First step is the same as for method 1: The server sends its certificate to the client. The client now creates a random session key, encrypts it and sends it to the server by using the server's public key. Turn on first encryption.
Then the two nodes can do a Diffie-Hellman crypto negotiation. Combine the Diffie-Hellman negotiated shared secret with the client created random session key to get a new stronger shared secret. Turn on second stronger encryption.
This is not stealthy, but it is eavesdropper secure, man-in-the-middle secure and forward secure.
Server asymmetric key
Client does not have any keys or user names what so ever. Client knows the server's public key or at least the ID (the hash) of the server's public key. Server knows no user keys or user names what so ever. Server has an asymmetric key pair. Client expects the server to understand the stealthy negotiation protocol.
This is slightly similar to the normal case on the web today but no certificates are used instead the client has knowledge of the server's public key. This allows us to add full stealth to the connection.
Best method seems to be:
The ID (the hash) of the server's public key is used as the "semi-secret key".
Use the semi-secret key together with Rik's hashed method or a symmetrically encrypted method. In these methods the server has to test hash or test decrypt for each semi-secret key it knows (usually just one) and then for each protocol it knows. Then turn on first encryption.
We are now stealthy but not especially secure.
If the client only know the ID of the server's public key the client now asks the server for the full public key and gets it. The client then hashes the public key and checks that that becomes the ID it already know.
The client now creates a random session key, encrypts it and sends it to the server by using the server's public key.
For added security (and to get forward secrecy) then also do a Diffie-Hellman key negotiation. (Note that this can also be done by using temporary RSA keys.) Then combine the DH negotiated shared secret with the random session key to get a new stronger shared secret.
Then turn on the second stronger encryption.
Now we are stealthy, eavesdropper secure, man-in-the-middle secure and forward secure.
Note that the client here knows for sure what server it talks to but the server does not know who the client is.
Client and server asymmetric key
Client has an asymmetric key pair and for some methods also has a client certificate. Client knows the server's public key or the ID (hash) of the server's public key. Server knows the users public key or the ID (hash) of the users public key or is CA aware and thus can verify the users certificate.
Client expects the server to understand the stealthy negotiation protocol.
Best method seems to be: