I don't think you've addressed my point. I don't hand my private key to anyone, including the service operator, so there's nothing they can cough up to make anything happen.
If you go back to the original backpack encryption model -- I leave my padlocks out in public and tell people to send me messages at some dropoff spot (alt.wesley.crusher.die.die.die for example) and collect my encrypted (padlocked) messages whenever I see fit, which I then unlock with the key I have never given out.
This could obviously be dressed up like email if necessary. E.g. set up a mail server that bounces all unencrypted incoming messages to me with a "try again using this public key".
Yes, the authorities can track my attempts to access the server (but guess what, they already can). And because my inbox requires no password to access they can't tell me from any random person or bot trying to access my mail.
The authorities (and anyone else) can also deluge me with encrypted spam (including spam I can't decrypt :-)). It's not perfect.
That is not how the POP or IMAP protocols work. To make the system work with existing clients, the server needs to have the plain text when it is sending to the client. Surely this is also how they complied with valid warrants (wait until user logs in, then execute warrant).
Asymmetric encryption on the server means that an intruder can't read the content (except possibly for those accounts where the private key passphrase is still in memory) and nobody can search old mails until a user logs back in.
Um huh? What the heck are you talking about? Imap and pop can't tell if the body text of a message is plaintext or not beyond poop left by encoding /encrypting engines. Certainly my proposed system would allow plaintext messages disguised as encrypted messages to be sent to the end user, but so what?
I am not talking about how lavabit worked, I am asking why not design a system where the service provider need hold no private keys and thus have no way to comply with requests for keys. Yes, they can help the government track users and they can try to install malware on your machine, but fundamentally they don't know whether you're reading your email on a mac, pc, raspberry pie, or microwave oven.
Here's a pgp encrypted message. What can't I send by conventional email? (Or simply post on usenet, as my earlier post.) "They" can try to track every person who inadvertently downloads messages left for me.
the "persistent component that doesn't automatically update itself" that tptacek was talking about is the software used to generate keys, do encryption etc.
the safe alternative is that each user has to go find and install reliable third party software themselves. this is already possible with gpg et al and it is not used.
so instead someone needs to package the crypto code. and as soon as you do that, if there's any kind of update process, the code package can be forced (apparently) to modify the code to leak information.
so sure, you can do this securely. it's already possible, but it's not popular. and anything easy enough to be popular appears unreliable.
If you go back to the original backpack encryption model -- I leave my padlocks out in public and tell people to send me messages at some dropoff spot (alt.wesley.crusher.die.die.die for example) and collect my encrypted (padlocked) messages whenever I see fit, which I then unlock with the key I have never given out.
This could obviously be dressed up like email if necessary. E.g. set up a mail server that bounces all unencrypted incoming messages to me with a "try again using this public key".
Yes, the authorities can track my attempts to access the server (but guess what, they already can). And because my inbox requires no password to access they can't tell me from any random person or bot trying to access my mail.
The authorities (and anyone else) can also deluge me with encrypted spam (including spam I can't decrypt :-)). It's not perfect.