0

I'm developing the set of applications, that provide the possibility to read encrypted data between several users using email messages.

It's rather hard... If to compare email messaging with the live chatting (IMs) through single server (for live chatting, I need just chanell with TLS). because I need to decrypt the the message, which is just saved on remote server.

Also, as I suppose the secure server mustn't keep private keys, because the user wants to be sure, that event supplier side (backend) can't decrypt content. Private keys must store on some stuff like smart-cards (which only user has).

For emails, I've found two options:

  • S/MIME
  • OpenPGP

So... the main problem (for me) is how to distribute private data, which will allow to decrypt email message for the user, which received the encrypted email message.

So, question is about correct distribution of private keys, right now I can't imagine how to deliver it in secure way.

  • 2
    I'm voting to close this question as off-topic because this is not an immediate development question, but more on the general architecture of security systems. security.SE might be a better fit, but some basic reading on public/private key and hybrid cryptosystems might be a good start. – Jens Erat Apr 28 '16 at 14:01
  • 1
    Anyway: usually, you do not create private keys and distribute them. The clients (client applications) do and distribute their public key, instead. – Jens Erat Apr 28 '16 at 14:02
  • @JensErat as I remember due Diffie-Hellman and other relative work. There is an assymetric + symmetric work. Client A and Client B exchange between them some kind of random nums, based on such nums they create a public key to encrypt chanel communication. Later, client A encrypts file and combine private key + encrypted file in message, then message in encrypted with the public key. When it's transferred, MiT can't decrypt it, later client B decrypts data with the public key, then obtain client A's private key and decrypt file. Am I right? –  Apr 28 '16 at 14:23
  • Diffie-Hellman solves another problem, establishing a secure connection (symmetric/session key) if only the server has a private key and all the client knows is the (trusted) public key/certificate. Diffie Hellmann is not about asynchronous messaging ("later decryption"). – Jens Erat Apr 28 '16 at 15:18
  • @JensErat I see, thanks. I really need to get more knowledge. –  Apr 28 '16 at 15:20

2 Answers2

0

Private keys are, well, private. You don't want to be transferring them. Never.

Instead, re-think the problem in terms of distributing the public keys in the other direction. Then you don't need to worry about eavesdropping (but you will want to be concerned with authenticity).

Toby Speight
  • 27,591
  • 48
  • 66
  • 103
Tom
  • 4,666
  • 2
  • 29
  • 48
-1

The proper approach is to use asymmetric cryptography to secure the data. In this scenario your users send each other their public key, and they can do this in any way. Private keys remain on user's side. The sender encrypts the data with the public key of the recipient, the recipient uses the private key to decrypt the data.

If you absolutely must use symmetric algorithms and keys for encrypting the data, then you still can use asymmetric cryptography to deliver symmetric keys in encrypted form (this is what S/MIME and OpenPGP would do for you, actually).

Note: when I am talking about encryption with a public key, I mean a hybrid scheme, when the data is encrypted with a symmetric session key, which is then encrypted with a public key. The data are almost never encrypted with asymmetric cryptography directly, without employing a symmetric algorithm.

Eugene Mayevski 'Callback
  • 45,135
  • 8
  • 71
  • 121