0
$\begingroup$

I am working on a system that includes our dear friends Alice, Bob, and a server that is only partially trusted. I have spent the majority of the day reading up on various cryptography methods, but I have concluded that I need some help to decide on the ones that best fit my use case.

For starters, I do not need authentication in the traditional sense. Alice needs to be able to communicate with the server securely, and for this Diffie-Hellman combined with public/private keys should suffice. In this case, the server is of course trusted.

Secondly, Alice needs to be able to communicate with Bob, via the server, and in this case, the server is not trusted. Therefore, another set of DH+keys is generated for that particular line of communications.

Now, the reason why I do not need authentication, is because this is all up to the server. The public key offered by A and B to the server will act as their temporary identity. This identity may or may not be reused later, so it is preferrable to use stored keys. If they are unable to read packets encrypted with this public key, then their ID is not deemed valid by the server, and a new one is istablished. In this case, the server is trusted.

I was considering using TLS, but I am unsure as to how I would programatically get access to the public key used in the OpenSSL session, and rolling my own TLS implementation seems like reinventing the wheel.

So what it then boils down to is this question: Which methods of cryptography should I go for that allows easy implementation of the communication scenarios above?

$\endgroup$
  • $\begingroup$ So, if I understand correctly - Alice and Bob need to exchange message with one another through the server, without the server being able to view the plaintext messages. And the two need to know that they are indeed communicating with one another, and not some impersonator or man-in-the-middle. Correct? $\endgroup$ – mti2935 Apr 30 at 21:11
  • $\begingroup$ First part is correct. Seccond one is partially correct: The server will know, based on the public key it uses to communicate with each channel, if it's the correct person or not. For example, Alice can change her identity by generating a new set of keys, and the server will then tell Bob about the new identity. It is then up to Bob to determine if this is acceptable, for example if Alice told him beforehand "I'm about to re-key". $\endgroup$ – Jarmund Apr 30 at 21:20
  • $\begingroup$ OK. That's helpful. In that case, this sounds very similar to the solution offered by encryptedsend.com. $\endgroup$ – mti2935 Apr 30 at 21:35
  • $\begingroup$ Partially similar goal, different method, which is why I am working on implementing this via TCP sockets. $\endgroup$ – Jarmund Apr 30 at 22:37
  • 1
    $\begingroup$ @mti2935 That cannot do without the following warning: "Users concerned about such an attack are encouraged to verify the certificates or the public keys of other users on the system via some out-of-band method, such as phone, email, SMS, fax, etc. Senders can view the certificate of a recipient by accessing the recipient’s URL on the system." from the EncryptedSend website. $\endgroup$ – Maarten Bodewes May 2 at 18:58

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.