Encrypted mail storage

[snoj]

A couple months ago there was a hackathon in my area and I wrote a little plugin for Haraka that encrypts incoming mail and forwards it on to somewhere else for storage. I was originally inspired by details of how Lavabit did their encryption and wanting to have something that did a better job. That is, the only knowledge required by the service is a public key.

It's slowly being improved when time permits with the next targets being a move away from config files for domain/user/key storage and installation via npm.

The code can be found at https://github.com/snoj/haraka-secwrap for any wishing to tear it apart.

[fugu]

I like this idea. I've been toying with another idea about an email-like system that would only permit pgp/gpg encrypted emails to enter the server. So unless the sender has the recipient's public key and uses it, the "email" doesn't even get through. I don't know if you could even call it email anymore, but it would be more end-to-end encrypted.

[snoj]

It would have its place. You can't be online all the time so letting others "dead drop" messages is necessary.

https://github.com/snoj/haraka-secwrap/issues/2

[cooper]

There's a problem with that idea: you can't use certs to verify recipient. Only using the priv key can you do that and if you store that on the server you're doing it wrong.

[snoj]

The data sent to the server is an encrypted onion (see step 1). With the sender using their private key on the outer layer. If the senders public key is known, decryping the data should result something meaningful. This is what I meant by verifying the message can be decrypted.

[cooper]

Okay, I might just be missing something here, but with PKI you can do these 2 things:

1. Sign something with your private key, meaning that anybody with your public key can verify that signature and thus prove the message must be from you and hasn't been altered.

2. Encrypt something with someone else's public key, meaning that only the person with the associated private key can decrypt it.

You can combine the two to get something only readable by the recipient and which the recipient can verify as being the original as provided by the sender.

The reason you don't encrypt with your private key (but instead only sign) is that anybody with your public key can decrypt it, and since everybody is allowed to possess your public key why bother with encrypting? I also believe it's considered a feature that your message is readable to the recipient who doesn't yet have your public key. Also, the signature can include your public key, providing proof about who you are (don't know you, but your pub cert is signed by $trustworthy_person so I'll trust this to in fact be your pub cert) which would be unavailable in an encrypted message.

Now, I didn't see anything describing a 'step 1'. Link?

[snoj]

I think I might be missing something too. Since fugu's reply, I've been talking about this github issue (also has the steps I was talking about).

That said, signing instead of doing an encryption onion would work too, maybe better.

[cooper]

Looked at it. I believe the typical order is to take your message text T and sign it with your priv key, producing message M which contains T, signature S and potentially your certificate C. This process is mostly used for MIME multipart messages, where each of those elements of M2 is its own part. This message M then gets encrypted using the recipient's public key, producing encrypted message E. E gets sent to the recipient who is the only one that can reverse E back to M and thus read the message, with the option of verifying the sender based on the signature and potentially adding the sender's cert if (s)he didn't already possess it.

The reason for this order of things is that when you encrypt a message to be sent to someone it implies you don't want prying eyes to see your message. You may very well not even want those same prying eyes to see it was you who sent it (think whistle blowing documents and such). With this order only the recipient can verify the identity of the sender. If you reverse the order, prying eyes can prove it was you who sent a message to $terrorist_du_jour or WikiLeaks or whatever which might have dire consequences for the sender.

In this message exchange between sender and receiver, your dead drop server is in fact the prying eyes you're protecting the communication against. So the server has NOTHING to determine if a message should arrive with someone, and this should be _by design_. You can't let the server filter on your behalf because this is the sort of censorship you're trying to prevent.

When you say "Allow for pre-encrypted messages to be passed between servers/clients" what do you really mean? Are we talking about something like the current mail system where mailserver A can transfer a message to mailserver B because it knows/discovers that's where the 'drop box' of the intended recipient of the message resides? I would, for now, argue against such a thing. You might need something to scale when things get really busy but for now there's no need to.

[snoj]

That's how I've understood it as well. Secwrap isn't about changing that. Or breaking those rules!

Secwrap is focused on how to hide those aspects of messages as well as the body can't (easily) be accessed by unsavory fellows or handed over to third parties. It does this by encrypting incoming messages (headers and body) using a public key provided by the recipient before storing it (e.g. attachment sent to another email address).

Or in list form.

• Email message comes into secwrap SMTP server
• Secwrap checks config for public key for recipient.
• If key is found, encrypts entire message (headers and body).
• Forwards encrypted message as an attachment to another email address or POSTs to a specified url.

Note that the original message sent could be a plain text, S/MIME, have attachments or not, it doesn't really matter.

Of course this doesn't help when the messages are intercepted before it is encrypted. Nor if the sender is using some sort of service like gmail or whatever MS is calling their's these days.

The dead drop enhancement idea is to allow for the sender to encrypt the email message (step 3 above) so secwrap doesn't have to do it itself. The idea of having the sender encrypt the message again with their private key was something to keep out unwanted encrypted messages by requiring "proof" the message was from a specific private key. Thereby allowing the recipient to filter based on knowledge of the sender's key at the server instead of later when offline. (Since the recipient probably wouldn't have the public keys of spammers or other potentially annoying sources the messages.)

Does that help clear up my goal? I'm kind of like Richard in that I can really suck at explaining my ideas.

Edited January 4, 2016 by snoj

[cooper]

I would recommend you change the "dead drop" idea to something like PasteBin:

Person A uploads something to the "dead drop" server DD providing, in this process, a subject S, an email address E and a public cert C. Once the upload completes DD sends an email to E with subject S and an encrypted part that was encrypted using C and which contains the information needed to get DD to cough up the file. This can be as simple as an https URL. When you request a non-existing URL from DD you get a randomly sized file with random data.

By going this route you can keep using the mail system for what it's intended, the recipient doesn't know the sender but does know the message was intended solely for him/her and the subject can be used for some filtering by the recipient, assuming a side channel (the mail system) is used to notify the recipient a dead drop is inbound with a given subject in case the recipient gets spammed in the hopes the dead drop mail will be discarded because of this.

For secure mail I don't yet quite see what solutions are being provided over just plain S/MIME.