I'm trying to work out a somewhat anonymous secure messaging system, and was hoping someone could validate my overall approach. Keep in mind, this all takes place over HTTPS.


While the transport supports client certificate authentication at the protocol level, we don't want to have to issue certificates, and we don't want to have sign them. The mod_ssl/Apache options are none, optional, require, and optional_no_ca - unfortunately there's nothing like require_no_ca.

  1. Client generates public/private key pair - either 4096 bit RSA keys, or an EC key (using either brainpoolP512r1 or NIST P-521 curves).
  2. The client requests a challenge from the server, sending it it's public key.
  3. The server generates a challenge - a largish amount of random data (say a byte[] 8x the block size of the cipher). The server encrypts the response with the client's public key.
  4. The client takes the response, decrypts it, generates a SHA-512 hash, and passes it back to the server.
  5. The server verifies that the hash matches, and if so, the client is authenticated.

We don't need logins or passwords, just client certificates. If access control to the server is desired, client certs could be whitelisted, or more traditional username/password authentication could be used.

Client-to-Client Comms

  1. Clients exchange public keys. This has all the old problems of PKI - revocation, etc. that I really don't want to get into. So this happens manually amongst clients out of band.
  2. Client A sends the server a handshake request with an ECDH public key and the public key of the sender which is encrypted with the public key of Client B. The server doesn't have an record of the sender.
  3. Client B connects to the server, and requests any messages. The server sends the message to Client B. The client decrypts it, and checks the sender against the list of public keys it's already. If it's got the key, it generates an ECDH key pair, and sends a response to the server with it the ECDH keypair's public key, which is encrypted with Client A's public key.
  4. Client A gets the handshake response, and from their Client A&B can start communicating using their shared secret, through the server. The shared secret will be used to encrypt the message(s) via AES-256 (GCM, no padding)
  5. Further messages will generate new (and thus ephemeral) ECDH key pairs, piggybacked on top of previous messages, so the AES key for the client<->client communications have perfect forward secrecy.

The client content is all encrypted so that the server cannot see messages. It basically acts as a store and forward transport for the client messages. The cert based authentication allows us to ship messages to individual clients on request.

I'd love any and all feedback.

  • 1
    How do you handle an out of band key exchange with an anonymous party? – AJ Henderson Feb 10 '14 at 23:09
  • Ok, so you are basically talking about a server that is not anonymous being used as the center point between a number of anonymous end users? How is this different from almost any online forum? (say SE for example). Each user is still effectively talking to each other and authenticating with each other via an out of band channel, only the server doesn't know who they are. I'm failing to see what you are trying to accomplish with this and why it can't be done through traditional means. – AJ Henderson Feb 10 '14 at 23:27
  • a public key is still just as identifiable as a username or profile, an e-mail address isn't required for a traditional setup. Not needing a password on the server is even possible by using client side certificates with traditional SSL. (This is also similar to how SSH works.) – AJ Henderson Feb 10 '14 at 23:36
  • SSH was kind of what I was following, but without the need to setup an account and copy your public key over. I guess anonymous authentication isn't really required, but I wanted another layer on top of SSL (or the ability to not use SSL at all). Take a look at mywickr.com/en/index.php - but with more anonymity. – Mark Feb 10 '14 at 23:39
  • I simplified things a bit. – Mark Feb 11 '14 at 2:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.