5 ms·

Maybe it's time for a new type of email service. Something along the lines of two way auth, private key on cell phone, public on server. Cell phones have camera

Maybe it's time for a new type of email service. Something along the lines of two way auth, private key on cell phone, public on server. Cell phones have cameras now, so you could generate a QR code or something which your auth app could look at and generate a response in order to generate a unique token to gain access to your message(s). On the server side guys could have a deadman switch which would purge all data if not heard from administrators for 12 hours. That way they could delete data and not be in jeopardy of obstructing any government or whomever is seeking to gain access. Bonus points could be had for not hosting in US too.

tootie 13y ago
I don't think the encryption thing is the problem. I honestly have a hard time accepting that he was unable to provide decrypted content even with a warrant. That pretty much makes this a Swiss bank account for data and you better believe criminals would be all over it. I'd rather go through legal channels to end violations of due process.
- e12e 13y ago
  I've tried reading: http://wayback.archive.org/web/20130530023856/http://lavabit.com/secure.html But I'm still not entirely clear on what lavabit used to do to encrypt email once it arrived on its servers. As far as I can tell, they still store an encrypted version of the private key, that they can't decrypt with the other data they store: but would be able to decrypt as soon as a user logs in, and supplies them with the password (again). So while they don't store enough information to decrypt information, at any point when you log in; you provide enough information for them to decrypt all the stored emails. Additionally, they could store a plaintext copy of all new email. If the mail you receive is already encrypted with something like GPG, the cannot read it, of course.
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.
    - 13y ago

tootie 13y ago

I don't think the encryption thing is the problem. I honestly have a hard time accepting that he was unable to provide decrypted content even with a warrant. That pretty much makes this a Swiss bank account for data and you better believe criminals would be all over it. I'd rather go through legal channels to end violations of due process.

e12e 13y ago
I've tried reading: http://wayback.archive.org/web/20130530023856/http://lavabit.com/secure.html But I'm still not entirely clear on what lavabit used to do to encrypt email once it arrived on its servers. As far as I can tell, they still store an encrypted version of the private key, that they can't decrypt with the other data they store: but would be able to decrypt as soon as a user logs in, and supplies them with the password (again). So while they don't store enough information to decrypt information, at any point when you log in; you provide enough information for them to decrypt all the stored emails. Additionally, they could store a plaintext copy of all new email. If the mail you receive is already encrypted with something like GPG, the cannot read it, of course.

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.
  - 13y ago