I asked a question awhile ago asking how to make an efficient encrypted chatroom. What I ended up doing was Making each user generate a 4096 bit RSA KeyPair, share their public Keys, and then one of the client distributes an AES 256 bit Encryption key it randomly generates.

Anyways, I was wondering. Let's say one user signs on with the name of "Austin", and signs off.

Let's say later "Austin" signs in again. I want to know if it's the same user (or at least the same computer) without using something like a password (however it could be something verified by server of some sort), how could I possibly do that?

I was thinking something like the way putty will verify what server you're connecting to, but I'm not sure I really understand that.

Thanks in advance.

3 Answers 3


Identifying users based on a public key is known as a public-key infrastructure (PKI). There are several ways of making a PKI work. The simple way is that when a user registers to your service, a key is generated for them, and your service remembers the association between the user name (or the unique account id, if user names are not necessarily distinct) and the public key. This simple way works well when all users registers to the same server; the difficulties with PKI start when the identities and authentication informations need to be synchronized between multiple servers.

SSH (the protocol you're thinking of when you say “PuTTY”) uses key pairs for two different things. SSH uses key pairs to identify the server machine to the client machine; once a client has connected once to a server, it remembers the server's public key. SSH can also use public keys to identify the user to the server machine. In both cases, the holder of the private key demonstrates its identity by proving that it knows the private key associated with the public key that identifies it. See What is the difference between authorized_keys and known_hosts file for SSH? for details.

For your application, it sounds like users should have a key pair which is generated when they register. Whether the private key should be stored on the client or on the server depends on what security and usability properties you want to achieve. The most likely setup is to generate and keep the private key on the client, and have it send the public key to the server. After that, the server can authenticate a client user by verifying its possession of the private key. Use SSL/TLS to establish a secure channel to perform the client authentication; once the user is authenticated, have the server send the session keys for the chat channels that the user is authorized to participate in.


You could have the user authenticate himself by signing the user ID or a session ID with his PRIVATE key. That value could be authenticated by anyone, using his PUBLIC key. A simple digital signature scheme.

  • Encryption with a private key is an undefined operation in most public/private cryposystems. RSA included, if I remember correctly. Oct 16, 2012 at 5:10
  • While it may not be part of the standard, it surely provides proof of the private key.. Oct 16, 2012 at 5:27
  • It's not just not part of the standard. It's undefined. There is no meaning for the term "encrypt with the private key". Public keys and private keys are not interchangeable. Oct 16, 2012 at 15:07
  • 1
    Signing with an RSA private key is a perfectly well-defined operation. Encrypting is not, and that was what your original answer recommended until edited by Jeff. Oct 16, 2012 at 20:31
  • 1
    Ahh, alright, I intended to simplify, ended up with confusion and error. You're right! Oct 16, 2012 at 20:42

For the new "Austin" to be recognized as the same entity as, or a distinct entity from, the previus "Austin", there must be something which distinguish them from each other. Everybody can buy a computer; what makes them distinct is what they know, i.e. what is stored in the memory of the computer+user system.

In your case, client systems generate key pairs, so the solution is simple: simply have Austin reuse the same RSA key pair than previously, instead of generating a new one. By virtue of using the same public key (i.e. being able to perform the operations which require the private key, such as asymmetric decryption), the new Austin can demonstrate that he is the same Austin than previously. For what it's worth, this is exactly the SSH security model: a new key exchange is performed for each connection, but the client verifies that the server uses always the same public key.

A password is another instance of the same, in which the data is stored in the brain of the user instead of the entrails of his computer. This includes some limitations, in particular a low entropy (passwords are inherently vulnerable to exhaustive search, aka "dictionary attacks") and the need for the user to type them at some point.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .