4 ms·

The whole problem with email is the asynchronous thing. You want to be secure, then it needs to be in such a way that there's minimum reliance on a central ser

by sigkill 13y ago

The whole problem with email is the asynchronous thing. You want to be secure, then it needs to be in such a way that there's minimum reliance on a central server. But in that case, what happens if your local machine (which is both your mailserver and an end client) is offline? Should the email bounce around in the network (like bitmessage does)? Or should you notify the sender with the standard "Mail Subsystem Delivery failure" that we all know and love. Actually after reading this, I want to seriously sit down and write a spec but if I include the assumption that there is a chance for the end-server/recipient to be offline, it throws everything into chaos.

samstave 13y ago
How about a client that does the following, but still uses email: A secure attachement creation client. You type your email into the app, which is just a word processor. When you send it - it saves an encrypted attachment, attaches it to the message and sends via email. The other party will need the client to read the attachment, and their client will need to connect to a secure central ID entity to confirm they are the recipient client which can open the message.
- sigkill 13y ago
  This is something which I did not think. It's basically like sending truecrypted packets between people. But this doesn't solve one problem - metadata. I still know you sent an email at time X to person P2. Tor's method of onion routing looks quite nice though.
  - samstave 13y ago
    I don't think we can solve meta-data issue any time soon. But I am really disturbed by the slide in the NSA XKeyScore ppt that said "Show me all word documents sent [emailed] from Iran that contain X" -- This is NOT something I can accept any intelligence agency having the capability to do.
  - josho 13y ago
    Ok, what about a new email spec. That as a part of it sends random noise at random intervals. This makes it hard to determine if you actually sent a mail, or if it was just the noise part of the spec. ... Wait, that's so wrong. Why don't we just fix our laws. ... Wait, we will always have bad actors or regimes, do we just design for that?
    - saraid216 13y ago
      When you're worried about things at this level, laws are just an external dependency not under your control, i.e. a security hole waiting to be exploited.
  - Amadou 13y ago
    I still know you sent an email at time X to person P2. We need a giant public "mailstore" where everybody (or at least a large pool of people) put the encrypted messages with encrypted recipient information. Everybody who uses this mailstore gets a copy of every message posted to it, but unless they are the intended recipient with the right private key they can't make heads or tails of it. Maybe usenet could be drafted into handling it. Usenet already handles terabytes of encrypted data on a regular basis nowadays.
Keyframe 13y ago
Indeed, the nature of email transport is such that security should be somehow enforced while it's not in your domain of total control. It should be presumed all sorts of eyes are looking at your package and should be dealt with accordingly. One approach is to write locally, encrypt and send it. Likewise for receiving - receive encrypted and decrypt locally. Thing is how to make this happen to work unobtrusively for users as well as how to make it work with current infrastructure of users not using encryption. That's the challenge. NB: All presuming NSA or whoever doesn't have capability to break your encryption scheme. Great addition would be if attempt of breaking in to your package could notify you, but that's not technically possible as far as I know.
Spearchucker 13y ago
This is really the crux of it for me. Peer to peer is no good because it requires both parties to be online. The best I've been able to come up with is multiple servers, which work a bit like command and control servers for malware. Sync from client to server. Server replicates to other known servers. When a server is threatened, shut it down. Update server list on remaining servers to let clients know a server is gone. Add a new server and similarly let clients know. This requires at least 3 servers to be online at any time. It also assumes client-side key gen and encryption. There are a few more subtleties I'm building in, but that's my thinking so far.

by sigkill 13y ago

samstave 13y ago

How about a client that does the following, but still uses email: A secure attachement creation client. You type your email into the app, which is just a word processor. When you send it - it saves an encrypted attachment, attaches it to the message and sends via email. The other party will need the client to read the attachment, and their client will need to connect to a secure central ID entity to confirm they are the recipient client which can open the message.

sigkill 13y ago
This is something which I did not think. It's basically like sending truecrypted packets between people. But this doesn't solve one problem - metadata. I still know you sent an email at time X to person P2. Tor's method of onion routing looks quite nice though.
- samstave 13y ago
  I don't think we can solve meta-data issue any time soon. But I am really disturbed by the slide in the NSA XKeyScore ppt that said "Show me all word documents sent [emailed] from Iran that contain X" -- This is NOT something I can accept any intelligence agency having the capability to do.
- josho 13y ago
  Ok, what about a new email spec. That as a part of it sends random noise at random intervals. This makes it hard to determine if you actually sent a mail, or if it was just the noise part of the spec. ... Wait, that's so wrong. Why don't we just fix our laws. ... Wait, we will always have bad actors or regimes, do we just design for that?
  - saraid216 13y ago
    When you're worried about things at this level, laws are just an external dependency not under your control, i.e. a security hole waiting to be exploited.
- Amadou 13y ago
  I still know you sent an email at time X to person P2. We need a giant public "mailstore" where everybody (or at least a large pool of people) put the encrypted messages with encrypted recipient information. Everybody who uses this mailstore gets a copy of every message posted to it, but unless they are the intended recipient with the right private key they can't make heads or tails of it. Maybe usenet could be drafted into handling it. Usenet already handles terabytes of encrypted data on a regular basis nowadays.

Keyframe 13y ago

Indeed, the nature of email transport is such that security should be somehow enforced while it's not in your domain of total control. It should be presumed all sorts of eyes are looking at your package and should be dealt with accordingly. One approach is to write locally, encrypt and send it. Likewise for receiving - receive encrypted and decrypt locally. Thing is how to make this happen to work unobtrusively for users as well as how to make it work with current infrastructure of users not using encryption. That's the challenge. NB: All presuming NSA or whoever doesn't have capability to break your encryption scheme. Great addition would be if attempt of breaking in to your package could notify you, but that's not technically possible as far as I know.

Spearchucker 13y ago

This is really the crux of it for me. Peer to peer is no good because it requires both parties to be online. The best I've been able to come up with is multiple servers, which work a bit like command and control servers for malware. Sync from client to server. Server replicates to other known servers. When a server is threatened, shut it down. Update server list on remaining servers to let clients know a server is gone. Add a new server and similarly let clients know. This requires at least 3 servers to be online at any time. It also assumes client-side key gen and encryption. There are a few more subtleties I'm building in, but that's my thinking so far.