This is being down voted but is an interesting point. Is a privacy service in which public record is available for its purchases ever truly private? Maybe its extremely difficult for others to see your communications, but if someone (or some law-enforcement agency) knows you have paid for a private communications service, does that make you a candidate for further scrutinization? I think so.
Yeah, that and an alternative email is required. Too much personally identifying information is needed for a so-called privacy oriented service.
I understand an additional email is needed right now since it's basically a pre-order, but I would hope that once fully launched this requirement would be removed at least.
I wonder if there are no updates or they are simply not pushed. Similar thing happened to Telegram [1]. Client is open-source and functional, but Google Play version is not what you can build from the source.
Explain Lavabit page phrases it like Magma supports only Trusted mode: "We envision Trustful mode as the mode of choice for businesses, which have regulatory requirements, data retention practices, and unique needs like escrow keys. Lavabit’s free and open source server, Magma, supports these users." Are other modes supported?
Trustful seems like a strange way to refer to the insecure mode. It is indeed full of trust, but not in the way a normal read would suggest: it requires full trust in Lavabit's hosting provider and administrator.
If you're going to operate in "trustful" mode, lavabit isny offering any real security wins over any other mail host.
> Former Lavabit users will be able to access their accounts in “Trustful” mode
Looks like Trustful mode is how the old lavabit operated.
> If you're going to operate in "trustful" mode, lavabit isny offering any real security wins over any other mail host.
This level of security apparently was enough to protect email contents against FBI.
The reason this "insecure" mode is kept is to allow users to continue using their old accounts and restore mailbox contents: https://lavabit.com/have-lavabit.html
Well, https://lavabit.com/have-lavabit.html says: "With the help of these tutorials, you should be accessing your old Lavabit e-mail and sending new secure messages in just a few minutes." Maybe e-mail here means account, not messages.
I have some free accounts to test, but looks like imap.lavabit.com and smtp.lavabit.com don't have SMTP/IMAP/POP3 ports open.
Well, if you have not logged in since they started recording traffic and until shutdown, chances are your password is not compromised and emails are still encrypted. But no way to be sure.
Before the thing with Snowden and the cert, Lavabit simply complied with warrants, which they could since they could read everyone's email. Fundamentally, Lavabit was not in any way different than Gmail.
Any source for this? Reading everyone's emails requires them backdooring their server so that it saves plaintext password or symmetric key on login. Were they doing this?
'backdooring their server to themselves' is not 'backdooring' it's just misdesigning. The alternative is believing Lavabit always scrupulously 'looked away'.
We already know that Lavabit design was bad and that is why everyone is moving to E2E.
Still I found no evidence that Lavabit handed over anything but encrypted data and access logs. The only thing I found is [1]: "He says he's received "two dozen" requests over the last ten years, and in cases where he had information, he would turn over what he had. Sometimes he had nothing; messages deleted from his service are deleted permanently."
He has complied with warrants because he had nothing to transfer. Nothing was stored and there is no legal obligation to modify your service to store passwords. When he was asked for TLS keys, he had to shutdown the service to prevent leaking all the passwords and redesigned the server.
The difference between not looking away and Lavabit design is that nothing is exposed if the server is seized.
The design of old Lavabit was not sufficiently secure and there was no way to check if it is more secure from the users' perspective, but still no reason to call it snake oil [2]. Snake oil is a product that is advertised as secure when maker knows it is insecure. Lavabit design was correctly described on its website and source code was promptly published after the shutdown so it is possible to verify that described features existed.
The owner of Cock Mail / cock.li is at least completely realistic with what can be expected from an email provider. Goofy domain names aside, being completely frank about privacy and security realities is what you want.
A good way to regain and build trust with users would have been to acknowledge his previous mistakes. Then at least you could say "he's been around the block, done it wrong and learned how to do it right". Instead, he writes:
"In August 2013, I was forced to make a difficult decision: violate the rights of the American people and my global customers or shut down. I chose Freedom."
That isn't what happened. He chose to build and sell a supposedly secure email service that was fundamentally vulnerable to government intrusion. He then decided to play chicken with the USG over a warrant no different than ones he'd complied with previously. The completely pointless escalation forced him to compromise all of his users, something the government had not been asking for. He then shut the service down.
There are a lot of ways to describe this but 'I chose Freedom' without any acknowledgment of his previous mis-steps is both misleading and shameless. I wouldn't buy supposedly secure services from him.
He gave up the cert, there was no PFS-only configuration, plus, presumably the FBI got to do their surveillance except instead of the target's email, they could read everyone's. So no, you are not right.
I was not aware he gave up the cert in the end. Thought he just closed website without disclosing TLS cert. Now it looks way worse than I imagined.
Anyway, I really hope that it leads to adoption of backward-compatible and secure email protocols. Server encryption can't be trusted anymore anyway, we need end-to-end encryption.
The business with the cert was just the final outcome. The initial mistake was making and selling snake oil. It is possible for someone to innocently do this, out of inexperience and ignorance.
Over time, though, it's become increasingly clear Ladar Levison is just a snakeoil salesman who misled his users. He's never acknowledged he did anything wrong. Don't fall for his posturing about 'Freedom'.
From what I read, he gave up the SSL cert by printing out a hard copy in a tiny font, and when he was ordered to provide a digital copy, he shut down the service.
> At approximately 1:30 p.m. CDT on August 2, 2013, Mr. Levison gave the F.B.I. a printout of what he represented to be the encryption keys needed to operate the pen register. This printout, in what appears to be four-point type, consists of eleven pages of largely illegible characters.
And:
> On August 8th, rather than turning over the master key, Levison shut down Lavabit.
To be fair you have to acknowledge how society is essentially driven through tales of one's bolstered narrative. Many consider us in a "post facts" era given how you can watch almost any politician (some far worse than others) go on live television and say something that is completely untrue but it tells a fantastic story. Elections are won based on being able to sell a narrative.
While I agree with you I think a large amount of people will buy into the narrative of him sticking up for freedom.
The extent to which these narratives work is proportional to how much we accept them. No one can stop him from telling lies but we can make sure people know they're lies.
He was was advertising a false sense of security to people and even snowden trusted him but as moxie explains very well that it was basically not was all thought it was. The claim "we can't read your stuff" was simply wrong.
He didn't go to the mat for his users. He built a service that he knew was vulnerable to standard legal process (or if he didn't, he was amazingly incompetent) but sold it as if it were safe from the government, duping even Edward Snowden. The government, naturally, engaged in standard legal process, and found that he possessed a key that would give the government access to everything they needed, and that he was capable of turning it over. So he was ordered to turn it over, which should have surprised no one.
He did surrender the key, although by printing out the key in 4-point font (unclear if he was buying time, or just thought contempt charges sounded fun). After the government pressed him harder, he shut down the service days later. He didn't disclose that he had surrendered the key; the public found out when the court documents, including the key itself, were unsealed.
If something can't be done securely, don't tell your users that it can be done securely. If you know you can't win, there's honor in refusing to lose without a fight. But there's no honor in first promising people that you'll win, and there's quite a bit of dishonor in asking people to pay you to win.
Lavabit v1 should never have been built. Many people were technically qualified to build something like it it (it's email, which constrains the design significantly), had the resources, and chose not to. The fact that Levison built it, and that he hasn't apologized for building it, demonstrates that he's untrustworthy. This is not to say that he's a bad person; everyone makes mistakes, and I wouldn't trust myself to build a secure email service singlehandedly, because I know what mistakes I've made and what sort of personality flaws I have. It's just a statement that the required level of trust is extremely high, and Levison hasn't demonstrated it.
Lavabit v2's "Trustful" mode has all of the same flaws as Lavabit v1. He writes about his "free and open source server" and asks how you feel about "trusting our servers," when that was never the problem. If you can magically make sure that the government doesn't have access to your system, a standard unencrypted email server will do just fine. If you can't, they'll issue the exact same legal order to Lavabit v2 that they did to v1, and it'll be just as effective.
If Edward Snowden started a mail service, I'd probably trust it more. If you want to talk about "going to the mat" for people, I think Snowden has made the bigger sacrifice.
Moxie and Whisper Systems probably would get my nod too. Perhaps even DJB or Bruce Schnier.
Snowden is not a security expert nor a cryptographer. He used Cryptocat and Lavabit, for instance - he was (like most people) unable to independently assess the quality of their security guarantees and believed their claims.
he has said that he used pgp in his emails with poitras and greenwald because he knew from personal experience that, properly implemented, nsa was unable to decrypt messages protected with it
>Unlike the design of most secure servers, which are ciphertext in and ciphertext out, this is the inverse: plaintext in and plaintext out. The server stores your password for authentication, uses that same password for an encryption key, and promises not to look at either the incoming plaintext, the password itself, or the outgoing plaintext.
>The ciphertext, key, and password are all stored on the server using a mechanism that is solely within the server’s control and which the client has no ability to verify. There is no way to ever prove or disprove whether any encryption was ever happening at all, and whether it was or not makes little difference
Anyways, having good inventions doesn't equal having a secure product.
You can keep your private key private now, or, like always, just run your own server and not have to worry about ever trusting anyone with anything. Though "Paranoid" mode in DIME seems to accomplish the same thing.
Yeah but the GP was saying that Ladar Levison must have made a trustworthy system because he's Ladar Levison. However, I was pointing out that there was serious issues with the trustworthiness of the original lavabit.
> I would suggest to use https://posteo.de instead. They offer anonymous payment by post (I'm just a happy user).
I glanced at it. It may offer anonymous signup but it uses standard mail protocols. Almost every email Posteo processes for its users reveals their identities.
Not questioning you, since anon might not be your primary driver. However, this reminds of a UK survey in the early 2000's that said some crazy number (50%?) of computer users would give up their password for a candy bar :-)
If the server doesn't have access to the content of emails, then it reverts to a featureless blob store:
Search isn't possible
Previews can't be calculated
If you lose your private key, we can't recover your email
Spam checking on content isn't possible
To access mail on multiple devices, the private key needs to be shared securely between them
Search is still possible. You can stem words and store their weights without storing the actual unencrypted text. This isn't perfect security, but it's good enough that it would be difficult for the government to successfully use the search metadata in a case against you without a lot of other evidence.
This is what we do on FWD:Everyone for email threads shared within private repositories.
I've never tried it but I'd bet you could use instead use a key derived from the master somehow to salt a hash for all the stems too. I think that'd let you still do the search and possibly have a good index for it still but it'd add some hurdles to the whole thing so that you couldn't make a lot of good guesses about the actual contents of the emails. It would still leak information a out related emails (say there's a thread discussing a unique term in it), but it'd still be better than otherwise.
In theory you could HMAC all the stems, but at that point you really need to ask yourself what threat model you're trying to protect against. E.g. keeping only the stems is more than enough to prevent competitors from learning anything useful about your business if your database gets compromised, but using an HMAC probably isn't going to significantly slow down a state-level actor who has a warrant or zero day for your web servers. So on the balance I think the technical debt that would be introduced would likely make the overall system less secure, at least for most use cases.
Security is rarely good or bad in an absolute sense, but rather is judged by considering the assets under protection and the threat models you're protecting against.
Just because certain people need the sorts of protections provided by Lavabit doesn't mean that products like Gmail are bad or insecure. They're each secure for the use cases they're targeting.
Well, you could always use an old school local email client and would get search and previews for free. And some 3rd party not being able to "recover" my private correspondence sounds more like a feature than an issue.
It absolutely is, in both theory and practice. The server stores an encrypted index, and the client walks it (requesting parts as needed). It's going to little slower, and a lot more complex but it's doable.
> If you lose your private key, we can't recover your email
This is a damn feature. I had my icloud account social engineered (someone walked into an apple store claiming to be me and they couldn't get their iphone syncing to "their account"). I'll never again trust another company with my private stuff.
> Spam checking on content isn't possible
This is probably your best point. It's definitely harder to do well
> To access mail on multiple devices, the private key needs to be shared securely between them
This is a non-issue. It can easily be derived from a password
Also search that only uses email titles is still at least 70% as useful as full title+body search. So I wouldn't count this as such a terrible non-feature of e2e encrypted email.
You can mostly get rid of spam by requiring the sender to perform a proof of work if they aren't in your contacts list. I.e. whitelist of senders + proof of work or some kind of configurable per domain quota/proof of work.
Truncated to something like fvv544+user@mydomain.com that would only be valid when sent with the from-adress new-sender@example.com (along with some clever magic to avoid email loops! :-)
I think maybe it was authored by ESR (Eric Raymond) in python - but Google only turns up various dkim schemes...
New senders would have their mail held back, and get a "please reply if you are human"-message - a reply (to the "magic" reply-to alias) would release the held mail and whitelist the sender.
I'm talking about now going forward. There are plenty of ways to make a person opt-in the first time they send you something. That process gets rid of more than 99% of spam.
It wouldn't be so good if email turned into Facebook, where you can only contact somebody if the circuit has been established beforehand (i.e., both parties friend each other). What happens if this is the point of initial contact, and there's no other way to get in touch? I have to conspicuously friend this person from my otherwise dormant account and then not think about whether they're going to feel weird when I unfriend them later on?
I sent an unsolicited email a couple weeks ago. Academic-type, self published, personal webpages where I saw something that needed fixing, and so I did. There was no CMS, just a static site—and not the sort where you're running markdown sources through a generator and have a whole Git hosting service apparatus intertwined with hooks sunk into it. Plain, legacy HTML. I saved a local copy to my machine, made my changes, and mailed them in. They happened to be machine-readable patches, given the recipient, but it could have just as well been a message written in natural language. The changes were made, I was thanked, and done.
I'm still upset that in the 90s I could get in contact with almost anybody by looking in the phonebook, but when I tried doing that a few years ago for an old coworker, it was hopeless. Getting the listings for a city you've moved away from can prove to be harder than it seems, even when you know they have a landline.
These are the kinds of things you lose when you assume the world is already fixed in the form that it should maintain going forward.
From every client that a former client has sent my way. 50% of my clients introduce themselves with some variation of "Something happened, Bill gave me your name. Help!".
The interpretation of IP law, at least internally at many big software companies, does in fact work like coodies. Hence things like "clean room implementations" of algorithms, modules, API interfaces etc.
Clean room matters for copyright. It doesn't help for patents, as patents protects the idea, not the expression of it so expressing the same idea in a different way doesn't help. With a patent you want to know the specifics of the original to ensure you make yours sufficiently different to sidestep the claims.
Where not knowing helps with patents it is in that if you infringe, wilfull infringement increases damages up to threefold.
These are just minor problems. End to end encryption should not be forced upon users, but should be used selectively. You don't want to lose your entire inbox because you wanted to send a few encrypted emails.
> The server stores an encrypted index, and the client walks it (requesting parts as needed). It's going to little slower, and a lot more complex but it's doable.
How slow would this be with thousands of emails on a mobile device ?
> This is a damn feature. I had my icloud account social engineered (someone walked into an apple store claiming to be me and they couldn't get their iphone syncing to "their account"). I'll never again trust another company with my private stuff.
Most email providers don't have retail stores where this type of attack can happen.
> This is a non-issue. It can easily be derived from a password
What happens if this password got into the wrong hands or even lost? Is it possible to change? Must I re-encrypt every single email ?
Lots do, though, and the ones that don't often offer customer support over the phone. And anyway, social engineering doesn't only happen in stores or when talking to CS.
Really? Name any of the top 10 email providers that have stores, or a responsive 800 number for email support. I'll give you Apple, but they are the clear outlier. MS, Google, have stores, but not with email support, and questionable phone support at best for any non enterprise product.
AT&T? I don't have a list of top 10 email providers, but them and Verizon and Yahoo have all had people report social engineering attacks against them to gain access to accounts.
> How slow would this be with thousands of emails on a mobile device ?
Not that much slower than email is now. A B+tree index of (for example) 1 gb of total content and index is only about 1-2 gigs in size. You could just store that shit on your phone encrypted. Or 1-5 megs of index on your phone, with 2 round-trips for any email/first page search result per word.
> What happens if this password got into the wrong hands or even lost? Is it possible to change? Must I re-encrypt every single email ?
Overall yes, re-encryption is necessary. But that can be a batch process done while your phone is charging and on wifi over night. Is a drawback, but re-keying always is. But just because you got to change the keys every once in a while, doesn't mean you toss the locks.
> Overall yes, re-encryption is necessary. But that can be a batch process done while your phone is charging and on wifi over night. Is a drawback, but re-keying always is. But just because you got to change the keys every once in a while, doesn't mean you toss the locks.
Encrypted hard disks utilize a simple scheme whereby the password/key derived from the password decrypts a small set of keys or single key that's just randomly generated, and decrypts the rest of the drive. So, to change the password, all you need to reencrypt are the real keys.
Password -- decrypts --> master key -- decrypts --> rest of hard drive
^^^^^^^^^^
this is what gets re-encrypted on password change
and is small; ~a few KiB
Similar could be had for email.
The approach above also lends itself well to supporting multiple passwords. (If you share an account w/ someone, for example, though email has other tools like mailing lists that might be better suited.)
> How slow would this be with thousands of emails on a mobile device ?
This in itself is not a problem. Btrees are O(log n) for search, so thousands of emails can be looked up in 3-4 requests with the most naive way to implement remote tree walk.
The fact you're revealing the structure and index contents to the server as you search would be a bigger issue.
Regarding Apple and security, their policy via AppleCare seems to be to ASK (over the phone, for instance) for your cleartext computer administrator password before you send in your laptop for repair, without any warning whatsoever of the implications.
I spilled soda on my mac once, and took it to the repair shop. the receptionist there asked me for my password. I laughed and I said of course not. she was shocked and asked: well, how are we going to test the new keyboard. I don't know maybe try to type random things in the password field?
I thought that too, until i bought a cheap netbook that came with windows (7? Student edition? I cannot remember). I plugged in a mouse and windows said it needed to connect to the internet to download the driver for my MS optical mouse. I practically fell out of my chair laughing.
Except the mouse wouldnt work. Either the os couldnt use it, or wasnt letting me. Either way, it was funny seeing one ms product not recognize another.
They have physical access to the device. They can enter recovery mode by holding down command r when restarting. It gives them a different copy of the os with multiple apps that you can type in (like the terminal) and would allow superuser access to whatever they wanted, however your encrypted home directory would remain encrypted and they would not be able to read it. In the olden days you would stick in a recovery cd and reboot onto that... you could also (historically and presently) stick a USB drive into the thing and boot into an os on that.... NEVER give out your password.
I had this EXACT experience just this month. I went to have a screen replaced and I even explained (and apologized for the inconvenience) that I was very security focused. I set it up in advance so that would perform the repair in front of me, that the device wouldn't be plugged into any of their computers, and it wasn't to be taken out of sight.
Then, he straight up asked me for my password, "most customers write their password down so we can test that it works."
I feel a little bad because the look I must have given him was pretty absurd. I told him no, I'll just take the risk and test it myself.
> It absolutely is, in both theory and practice. The server stores an encrypted index, and the client walks it (requesting parts as needed). It's going to little slower, and a lot more complex but it's doable.
Are you suggesting that to search your mailbox, the client should download every single encrypted message in the entire mailbox and decrypt them all locally to search them?
If not, how does the server get this "encrypted index" without having your private key?
Well, the client has to fetch message once, decrypt it, and upload updates to the index (kept on server).
I guess, it is a reasonable sacrifice for privacy, unless you want searches to be able to search within attachments including documents in big archives.
The search doesn't happen on the server. The client (e.g. desktop client) indexes the messages and encrypts the index. Then, when another client (e.g. mobile client) wants to search for a message, it downloads the index, searches it, and then pulls down the appropriate message(s).
If an attacker can tell which part of the index was modified, that gives them enough information to decrypt the index and e-mails.
Clients would always have to download+upload the full index (which needs to be re-encrypted with a new IV). This is a huge problem - the index can easily be hundreds of MB for a large mailbox.
Technically if a client has a full index version X (in plaintext), it could modify X to get X+1, compute a binary diff between X and (X+1) - encrypt and upload the diff.
Another client on index version X could download the diff, and get index (X+1).
Some desktop client should probably do compaction from time to time.
You would have to re-download the index after compaction. But the index and patches would be independent - you apply the decrypted patches to the decrypted index.
I'm not quite sure what you're getting at. It sounds like you're describing a known-plaintext attack, which modern ciphers are not vulnerable to. And what you are describing makes it seem like full disk encryption would be totally useless, but we know that's not the case.
So what, you hash each word in the e-mail and search for the hash, and this returns which emails include those hashed words? Would that be horribly insecure? I guess it would be impossible to salt those hashes, and it probably risks defeating the whole crypto.
You wouldn't use a hashing algorithm to build the index. They are talking about an inverted index in a binary format, something like what lucene outputs. That binary index would be encrypted with a block cipher (AES, Blowfish) using a secret key and would then be stored on the server.
The mobile client comes along and downloads & decrypts the index in memory, searches it for some terms(s), the index returns 10 result, of which, the user selects one and the mobile client downloads and decrypts to show to the user.
Adding to the iCloud story, I forgot my security questions and I was able to have the AppleCare agent over the phone reset it for me after talking about what apps I've purchased recently.
It's icloud, not personal device storage. It has to be possible if you want recoverable content. If you don't like it, you can back up locally to itunes.
> The server stores an encrypted index, and the client walks it (requesting parts as needed). It's going to little slower, and a lot more complex but it's doable.
Going on a tangent, but do you know of any services that offer such a thing?
> > To access mail on multiple devices, the private key needs to be shared securely between them
> This is a non-issue. It can easily be derived from a password
How does that change the equation? You're still exposing the thing-that-decrypts to multiple devices, thus (many!) more threat vectors. Lose one, and you lose them all, which is the point of the claim.
No, the (implicit) point in the start of the thread is that multiple other encrypted mediums don't leak as much. Use them instead.
If you care enough to use encrypted email, you should probably seriously consider abandoning email. (signing is different - that's proof of identity and non-modification, useful in many non-private scenarios)
>I had my icloud account social engineered (someone walked into an apple store claiming to be me and they couldn't get their iphone syncing to "their account")
I would argue the biggest downside to encrypted email is the sender, recipient, date, and size are known to all intermediaries.
First of all, sometimes knowing who you talk to is more important than knowing what you say. Traffic analysis lets you draw all kinds of conclusions.
Secondly, there are two parties, so double the chances for rubber hose cryptography. An opponent can approach either party and ask for details, so both parties are trusting the other can't be broken by the opponent.
Of course, we should all be encrypting everything anyway, no point in giving out free message bodies.
If you don't trust the other party you should not be sending him sensitive data. He has to be able to see it so of course he will be able to reveal it.
It is not that you don't trust your party, but that anyone with access to the servers or network between you can learn about who you are communicating with and when. Such metadata are often more useful to use against someone than the actual content.
Oh no, you're describing the solution rather than the problem: a global search, copy, and seizure converted to a local one that happens on per-target basis. Way better than mass collection with FISA warrants and systems like QUANTUM.
It's the NSA system that operates globally that can automatically fire attacks at systems based on patterns the operations people put in. Almost all the European countries are part of a SIGINT-sharing alliance per one slide. The exceptions were Switzerland, Iceland, and one I can't remember.
I think email needs to stop being treated like a database. It should be used for sending and receiving messages, the rest should be handled by other software... like a database for example.
At the moment, encrypted spam doesn't exist. But only because there aren't enough people using encryption to make it worthwhile for the spammers to invest time doing it.
Theoretically, a spammer could scan the public keyservers for email addresses and public PGP keys and then send encrypted spam to all of those people. If ever a well targeted spam mailshot was sent, that would be it. But would you really want to get on the bad side of thousands of tech nerds?
I'm downloading my mail from POP3 servers, so I'm searching locally. I'm copying access password to my tablet and phone (K9 client) and I don't keep more than a few dozen of messages there because the POP3 mailboxes are cleaned up when I download from the laptop. I backup my mail to a remote server, encrypted with duplicity.
I understand that this is not acceptable for 99.99+% of people, even the technical ones, but I think I could use a fully encrypted mail store. No problem with the mail provider ending up as a blob store: privacy-wise it's what they should be anyway. No harm to their business, if all the money they make are from users and they're not selling data.
The only problem is centralized spam checking. Running an antispam engine locally wasn't very effective years ago and Thunderbird was sub par. Is there anything that's on par with email providers right now?
I personally think it's funny that people mix secure communication and email. Secure system should be built to be secure. Email isn't a good option for that. Most systems are designed to be insecure and email is just a great example.
The explain document doesn't describe how key distribution works. How do I get a public key for somebody that I want to email, and how can I know that I am getting the right key?
This is the hard part of an modern cryptosystem and the usual source of weakness.
If he lost control of his domain, he will tweet about it.
I guess your point is that he is using Let's Encrypt instead of CA that would verify person or Lavabit LLC identity. In this case, it is not really an issue. If you are not going to check the cert manually every day, pinned Let's Encrypt cert is not way worse given that you have other means to verify ownership.
In August 2013, I was forced to make a difficult decision: violate the rights of the American people and my global customers or shut down. I chose Freedom.
My understanding is that he was legally forced to hand over the encryption key and all the data. The FBI, then, could have read all messages that were available on the server.
He shut down so that no additional mail could be sent and read.
It's unclear to me how much mail was kept on the server. Only unread mail? Anything in your inbox? Everything?
My understanding is that the key he was forced to hand over was the TLS key that protected communications between clients and his server, and the stored emails were encrypted with a key derived from the user's password.
So whether or not the FBI could read a particular stored message or not would depend on whether they'd been able to obtain that user's password: they could if the user had logged in after the FBI had the certificate, or if they'd logged in using a non-PFS cipher suite at any time, or if their password was vulnerable to cracking or determinable by the FBI in some other way.
Whatever did or didn't happen in the past, I for one am pleased to see another organisation attempting to make email more secure. Especially when governments have gone surveillance crazy. Goodluck Lavabit
My mind tells me that it's not a large amount, but given that the USG has a track record of intercepting routers in the mail and installing surveillance software in them, my guts tell me to be very wary.
Last I looked, DIME was just org level trust. That is, your domain determines what level of verification you get as far as knowing you have the right key for the recipient.
So if you used, say Gmail and they did DIME, you'd still be trusting them totally. Am I misunderstanding?
And still no admitting he was selling a fundamentally critically flawed service in the first place. If that's not even being mentioned, it really removes confidence from their new service.
As far as hardware HSM, that's cool. I very much enjoyed reading about how an HSM, the Luna CA3, was cracked:
Also, hardware HSM is vulnerable to the "SSL added and removed here! :-)" attack, is it not?
"Dear Mr. Levison, remember that law about pen registers that you clearly hadn't heard off last time around? Well, now that you understand them, please install a pen register on the other side of your fancy FIPS 140-2 hardware security device, and have it send us everything in .pcap format. You don't need to reconfigure your HSM for this, and in fact any attempt to do so is now tampering with evidence in a federal investigation. Cheers, the FBI."
Is this the right space to ask for opinions about Fastmail and its privacy? I just switched on trial after being on Gmail. I'm happy but I switched primarily to get part of my life away from Google.
You can't export mails from Protonmail or have a local copy except within Protonmail's iOS or Android apps. This means you can't easily move out if you want to.
Sensible choices in a nutshell: If you live in a 5-eyes nation, don't use or buy services hosted or operated from a 5 eyes nation. If you don't live in a 5 eyes nation, only use services hosted and operated from Iceland or Switzerland.( Nation states are the #1 threat, and your own nation is always the most dangerous one. )
No this is completely backwards. Use services that have security properties addressing the threats that matter to you. Simply adding 'hosted in Iceland' to something that's ineffective isn't going to help you. Having a server in Iceland did absolutely nothing for DPR, for instance.
> If you live in a 5-eyes nation, don't use or buy services hosted or operated from a 5 eyes nation
The 5 eyes spy globally. U.S. citizens are the only ones with legal protection and (limited) recourse for U.S. government spying, AFAIK.
If a U.S. citizen uses a French or Icelandic mail host, I suspect the U.S. foreign intelligence agencies have free reign to spy on them. I wonder what the limits are for the FBI and other domestic agencies.
Can't talk about op, but I got bucked fucked when he shot down with no warning because I had used a nerdshack email to register my primary domain and can't move it do a different email or server.
I am in the process of signing up now, just to restore access and get the hell away from that service. Email is insecure, we know that.
What I want is an open-source proxy that I can install on localhost to provide IMAP/SMTP access on the one side, and talk to the encrypted remote data store on the other side.
All of the encrypted email services I've seen so far, including Protonmail and now Lavabit v2, require using a special client (app or webmail) instead of common email software. This fails the very first test that I apply when trying to decide whether or not to use an online service: can I get all my data out of it on short notice, in a standard format through an automated process?
For email, this means IMAP access so that I can use standard tools like imapcopy to back up and migrate my mailbox. I don't care how secure your product is if it leads to vendor lock-in. I want both good encryption and an exit strategy, and the latter is much more important because if you screw up, I can always move to someone who does it better.
239 comments
[ 3.2 ms ] story [ 227 ms ] thread>Asks for your credit card information on the same page.
Wew, at least let us use buttcoin, Levison.
I understand an additional email is needed right now since it's basically a pre-order, but I would hope that once fully launched this requirement would be removed at least.
Code for DIME (Dark Internet Mail Environment):https://github.com/lavabit/libdime
Explain Lavabit page phrases it like Magma supports only Trusted mode: "We envision Trustful mode as the mode of choice for businesses, which have regulatory requirements, data retention practices, and unique needs like escrow keys. Lavabit’s free and open source server, Magma, supports these users." Are other modes supported?
[1] https://github.com/DrKLO/Telegram
[2] https://lavabit.com/explain-lavabit.html
UPDATE: https://twitter.com/kingladar/status/822583975067713536
"The website is live, but it will take another day or so to finish deploying magma, and get the latest code into Github."
Looks like code is just not pushed yet, it was just withheld until release.
If you're going to operate in "trustful" mode, lavabit isny offering any real security wins over any other mail host.
Looks like Trustful mode is how the old lavabit operated.
> If you're going to operate in "trustful" mode, lavabit isny offering any real security wins over any other mail host.
This level of security apparently was enough to protect email contents against FBI.
The reason this "insecure" mode is kept is to allow users to continue using their old accounts and restore mailbox contents: https://lavabit.com/have-lavabit.html
Well, https://lavabit.com/have-lavabit.html says: "With the help of these tutorials, you should be accessing your old Lavabit e-mail and sending new secure messages in just a few minutes." Maybe e-mail here means account, not messages.
I have some free accounts to test, but looks like imap.lavabit.com and smtp.lavabit.com don't have SMTP/IMAP/POP3 ports open.
Update: https://twitter.com/kingladar/status/822570163547541504 Database is not deployed yet.
https://moxie.org/blog/lavabit-critique/
Still I found no evidence that Lavabit handed over anything but encrypted data and access logs. The only thing I found is [1]: "He says he's received "two dozen" requests over the last ten years, and in cases where he had information, he would turn over what he had. Sometimes he had nothing; messages deleted from his service are deleted permanently."
He has complied with warrants because he had nothing to transfer. Nothing was stored and there is no legal obligation to modify your service to store passwords. When he was asked for TLS keys, he had to shutdown the service to prevent leaking all the passwords and redesigned the server.
The difference between not looking away and Lavabit design is that nothing is exposed if the server is seized.
The design of old Lavabit was not sufficiently secure and there was no way to check if it is more secure from the users' perspective, but still no reason to call it snake oil [2]. Snake oil is a product that is advertised as secure when maker knows it is insecure. Lavabit design was correctly described on its website and source code was promptly published after the shutdown so it is possible to verify that described features existed.
[1] http://www.forbes.com/sites/kashmirhill/2013/08/09/lavabits-...
[2] https://news.ycombinator.com/item?id=13447919
There isn't any evidence of that or the contrary. He had all the data. We don't know what he did or did not turn over.
Snake oil is a product that is advertised as secure when maker knows it is insecure.
Take another look at this (and Moxie Marlinspike is being generous and sympathetic). It meets your own criteria precisely.
https://moxie.org/blog/lavabit-critique/
To my knowledge, he is one of the few that has gone to the mat for his users.
"In August 2013, I was forced to make a difficult decision: violate the rights of the American people and my global customers or shut down. I chose Freedom."
That isn't what happened. He chose to build and sell a supposedly secure email service that was fundamentally vulnerable to government intrusion. He then decided to play chicken with the USG over a warrant no different than ones he'd complied with previously. The completely pointless escalation forced him to compromise all of his users, something the government had not been asking for. He then shut the service down.
There are a lot of ways to describe this but 'I chose Freedom' without any acknowledgment of his previous mis-steps is both misleading and shameless. I wouldn't buy supposedly secure services from him.
How has he compromised all of his users? The service was shut down and emails kept encrypted. Am I missing something?
Anyway, I really hope that it leads to adoption of backward-compatible and secure email protocols. Server encryption can't be trusted anymore anyway, we need end-to-end encryption.
Over time, though, it's become increasingly clear Ladar Levison is just a snakeoil salesman who misled his users. He's never acknowledged he did anything wrong. Don't fall for his posturing about 'Freedom'.
https://www.techdirt.com/articles/20131002/17443624734/lavab...
> At approximately 1:30 p.m. CDT on August 2, 2013, Mr. Levison gave the F.B.I. a printout of what he represented to be the encryption keys needed to operate the pen register. This printout, in what appears to be four-point type, consists of eleven pages of largely illegible characters.
And:
> On August 8th, rather than turning over the master key, Levison shut down Lavabit.
That was according to this article from the New Yorker: http://www.newyorker.com/tech/elements/how-lavabit-melted-do...
While I agree with you I think a large amount of people will buy into the narrative of him sticking up for freedom.
He was was advertising a false sense of security to people and even snowden trusted him but as moxie explains very well that it was basically not was all thought it was. The claim "we can't read your stuff" was simply wrong.
He did surrender the key, although by printing out the key in 4-point font (unclear if he was buying time, or just thought contempt charges sounded fun). After the government pressed him harder, he shut down the service days later. He didn't disclose that he had surrendered the key; the public found out when the court documents, including the key itself, were unsealed.
If something can't be done securely, don't tell your users that it can be done securely. If you know you can't win, there's honor in refusing to lose without a fight. But there's no honor in first promising people that you'll win, and there's quite a bit of dishonor in asking people to pay you to win.
Lavabit v1 should never have been built. Many people were technically qualified to build something like it it (it's email, which constrains the design significantly), had the resources, and chose not to. The fact that Levison built it, and that he hasn't apologized for building it, demonstrates that he's untrustworthy. This is not to say that he's a bad person; everyone makes mistakes, and I wouldn't trust myself to build a secure email service singlehandedly, because I know what mistakes I've made and what sort of personality flaws I have. It's just a statement that the required level of trust is extremely high, and Levison hasn't demonstrated it.
Lavabit v2's "Trustful" mode has all of the same flaws as Lavabit v1. He writes about his "free and open source server" and asks how you feel about "trusting our servers," when that was never the problem. If you can magically make sure that the government doesn't have access to your system, a standard unencrypted email server will do just fine. If you can't, they'll issue the exact same legal order to Lavabit v2 that they did to v1, and it'll be just as effective.
Moxie and Whisper Systems probably would get my nod too. Perhaps even DJB or Bruce Schnier.
https://moxie.org/blog/lavabit-critique/
>Unlike the design of most secure servers, which are ciphertext in and ciphertext out, this is the inverse: plaintext in and plaintext out. The server stores your password for authentication, uses that same password for an encryption key, and promises not to look at either the incoming plaintext, the password itself, or the outgoing plaintext.
>The ciphertext, key, and password are all stored on the server using a mechanism that is solely within the server’s control and which the client has no ability to verify. There is no way to ever prove or disprove whether any encryption was ever happening at all, and whether it was or not makes little difference
Anyways, having good inventions doesn't equal having a secure product.
You can keep your private key private now, or, like always, just run your own server and not have to worry about ever trusting anyone with anything. Though "Paranoid" mode in DIME seems to accomplish the same thing.
He went to prison over pgp.
But then the mail service he was involved in (silent circle mail) shut down at the same time as lavabit.
But apparently he thought up pgp while in prison for nuclear protests.
edit: Signed up. Half off for life is a sweet deal.
Too bad imap.lavabit.com:143 is firewalled on their side.
I would suggest to use https://posteo.de instead. They offer anonymous payment by post (I'm just a happy user).
I glanced at it. It may offer anonymous signup but it uses standard mail protocols. Almost every email Posteo processes for its users reveals their identities.
I give away my name and credit card info to plenty of websites. That won't help someone crack my private key used for lavabit any easier.
From: https://blog.fastmail.com/2016/12/10/why-we-dont-offer-pgp/
What's the tradeoff?
If the server doesn't have access to the content of emails, then it reverts to a featureless blob store:
update: want->NEEDThis is what we do on FWD:Everyone for email threads shared within private repositories.
Just because certain people need the sorts of protections provided by Lavabit doesn't mean that products like Gmail are bad or insecure. They're each secure for the use cases they're targeting.
But it's still possible to fight spam based on other features: https://atscaleconference.com/videos/how-whatsapp-reduced-sp...
That's total nonsense.
> Search isn't possible
It absolutely is, in both theory and practice. The server stores an encrypted index, and the client walks it (requesting parts as needed). It's going to little slower, and a lot more complex but it's doable.
> If you lose your private key, we can't recover your email
This is a damn feature. I had my icloud account social engineered (someone walked into an apple store claiming to be me and they couldn't get their iphone syncing to "their account"). I'll never again trust another company with my private stuff.
> Spam checking on content isn't possible
This is probably your best point. It's definitely harder to do well
> To access mail on multiple devices, the private key needs to be shared securely between them
This is a non-issue. It can easily be derived from a password
Also, "What? subjects and recipients are unencrypted!?" -- Every User Ever
> This is probably your best point. It's definitely harder to do well
I think it's possible, just slower and more complex (like search) - and would have to occur upon unlocking your inbox.
base64encode(hmac("new-sender@example.com+valid-to+01012018", key))+user@mydomain.com
Truncated to something like fvv544+user@mydomain.com that would only be valid when sent with the from-adress new-sender@example.com (along with some clever magic to avoid email loops! :-)
I think maybe it was authored by ESR (Eric Raymond) in python - but Google only turns up various dkim schemes...
New senders would have their mail held back, and get a "please reply if you are human"-message - a reply (to the "magic" reply-to alias) would release the held mail and whitelist the sender.
A greylist variant of sorts.
It wouldn't be so good if email turned into Facebook, where you can only contact somebody if the circuit has been established beforehand (i.e., both parties friend each other). What happens if this is the point of initial contact, and there's no other way to get in touch? I have to conspicuously friend this person from my otherwise dormant account and then not think about whether they're going to feel weird when I unfriend them later on?
I sent an unsolicited email a couple weeks ago. Academic-type, self published, personal webpages where I saw something that needed fixing, and so I did. There was no CMS, just a static site—and not the sort where you're running markdown sources through a generator and have a whole Git hosting service apparatus intertwined with hooks sunk into it. Plain, legacy HTML. I saved a local copy to my machine, made my changes, and mailed them in. They happened to be machine-readable patches, given the recipient, but it could have just as well been a message written in natural language. The changes were made, I was thanked, and done.
I'm still upset that in the 90s I could get in contact with almost anybody by looking in the phonebook, but when I tried doing that a few years ago for an old coworker, it was hopeless. Getting the listings for a city you've moved away from can prove to be harder than it seems, even when you know they have a landline.
These are the kinds of things you lose when you assume the world is already fixed in the form that it should maintain going forward.
"stretching" the equivalent of rsa(session_key, public_key) might be feasible?
Where not knowing helps with patents it is in that if you infringe, wilfull infringement increases damages up to threefold.
> The server stores an encrypted index, and the client walks it (requesting parts as needed). It's going to little slower, and a lot more complex but it's doable.
How slow would this be with thousands of emails on a mobile device ?
> This is a damn feature. I had my icloud account social engineered (someone walked into an apple store claiming to be me and they couldn't get their iphone syncing to "their account"). I'll never again trust another company with my private stuff.
Most email providers don't have retail stores where this type of attack can happen.
> This is a non-issue. It can easily be derived from a password
What happens if this password got into the wrong hands or even lost? Is it possible to change? Must I re-encrypt every single email ?
Lots do, though, and the ones that don't often offer customer support over the phone. And anyway, social engineering doesn't only happen in stores or when talking to CS.
Not that much slower than email is now. A B+tree index of (for example) 1 gb of total content and index is only about 1-2 gigs in size. You could just store that shit on your phone encrypted. Or 1-5 megs of index on your phone, with 2 round-trips for any email/first page search result per word.
> What happens if this password got into the wrong hands or even lost? Is it possible to change? Must I re-encrypt every single email ?
Overall yes, re-encryption is necessary. But that can be a batch process done while your phone is charging and on wifi over night. Is a drawback, but re-keying always is. But just because you got to change the keys every once in a while, doesn't mean you toss the locks.
Encrypted hard disks utilize a simple scheme whereby the password/key derived from the password decrypts a small set of keys or single key that's just randomly generated, and decrypts the rest of the drive. So, to change the password, all you need to reencrypt are the real keys.
Similar could be had for email.The approach above also lends itself well to supporting multiple passwords. (If you share an account w/ someone, for example, though email has other tools like mailing lists that might be better suited.)
This in itself is not a problem. Btrees are O(log n) for search, so thousands of emails can be looked up in 3-4 requests with the most naive way to implement remote tree walk.
The fact you're revealing the structure and index contents to the server as you search would be a bigger issue.
Then, he straight up asked me for my password, "most customers write their password down so we can test that it works."
I feel a little bad because the look I must have given him was pretty absurd. I told him no, I'll just take the risk and test it myself.
> It absolutely is, in both theory and practice. The server stores an encrypted index, and the client walks it (requesting parts as needed). It's going to little slower, and a lot more complex but it's doable.
Are you suggesting that to search your mailbox, the client should download every single encrypted message in the entire mailbox and decrypt them all locally to search them?
If not, how does the server get this "encrypted index" without having your private key?
This is not the same as the content.
I guess, it is a reasonable sacrifice for privacy, unless you want searches to be able to search within attachments including documents in big archives.
Clients would always have to download+upload the full index (which needs to be re-encrypted with a new IV). This is a huge problem - the index can easily be hundreds of MB for a large mailbox.
Another client on index version X could download the diff, and get index (X+1).
Some desktop client should probably do compaction from time to time.
Yes.
> I guess it would be impossible to salt those hashes, and it probably risks defeating the whole crypto.
Exactly. (There are other problems too, but that one by itself is a show-stopper.)
You wouldn't use a hashing algorithm to build the index. They are talking about an inverted index in a binary format, something like what lucene outputs. That binary index would be encrypted with a block cipher (AES, Blowfish) using a secret key and would then be stored on the server.
The mobile client comes along and downloads & decrypts the index in memory, searches it for some terms(s), the index returns 10 result, of which, the user selects one and the mobile client downloads and decrypts to show to the user.
It should be technically impossible. If it's a matter of choice for tech support reps, it's not secure for many reasons.
Going on a tangent, but do you know of any services that offer such a thing?
> This is a non-issue. It can easily be derived from a password
How does that change the equation? You're still exposing the thing-that-decrypts to multiple devices, thus (many!) more threat vectors. Lose one, and you lose them all, which is the point of the claim.
The point is, some is better than none. More is better than some.
So many people here pointing out holes that make it worse than a theoretically perfect system even though it's leagues ahead of where we are now.
If you care enough to use encrypted email, you should probably seriously consider abandoning email. (signing is different - that's proof of identity and non-modification, useful in many non-private scenarios)
Were you using 2-factor?
First of all, sometimes knowing who you talk to is more important than knowing what you say. Traffic analysis lets you draw all kinds of conclusions.
Secondly, there are two parties, so double the chances for rubber hose cryptography. An opponent can approach either party and ask for details, so both parties are trusting the other can't be broken by the opponent.
Of course, we should all be encrypting everything anyway, no point in giving out free message bodies.
I guess it's not possible, then.
How does encrypted spam work? Spammers encrypt message with your public key?
Theoretically, a spammer could scan the public keyservers for email addresses and public PGP keys and then send encrypted spam to all of those people. If ever a well targeted spam mailshot was sent, that would be it. But would you really want to get on the bad side of thousands of tech nerds?
I understand that this is not acceptable for 99.99+% of people, even the technical ones, but I think I could use a fully encrypted mail store. No problem with the mail provider ending up as a blob store: privacy-wise it's what they should be anyway. No harm to their business, if all the money they make are from users and they're not selling data.
The only problem is centralized spam checking. Running an antispam engine locally wasn't very effective years ago and Thunderbird was sub par. Is there anything that's on par with email providers right now?
This is the hard part of an modern cryptosystem and the usual source of weakness.
Also Ladar Levison twitter: https://twitter.com/kingladar
If he lost control of his domain, he will tweet about it.
I guess your point is that he is using Let's Encrypt instead of CA that would verify person or Lavabit LLC identity. In this case, it is not really an issue. If you are not going to check the cert manually every day, pinned Let's Encrypt cert is not way worse given that you have other means to verify ownership.
Shouldn't that "or" be an "and"?
He shut down so that no additional mail could be sent and read.
It's unclear to me how much mail was kept on the server. Only unread mail? Anything in your inbox? Everything?
So whether or not the FBI could read a particular stored message or not would depend on whether they'd been able to obtain that user's password: they could if the user had logged in after the FBI had the certificate, or if they'd logged in using a non-PFS cipher suite at any time, or if their password was vulnerable to cracking or determinable by the FBI in some other way.
either violate the rights of the American people and my global customers, or shut down.
Unless you're alluding to some impropriety on Levinson's part that I'm unaware of.
Vendors also provide ways to validate HSM's
https://www.thales-esecurity.com/msrms/validate
So if you used, say Gmail and they did DIME, you'd still be trusting them totally. Am I misunderstanding?
And still no admitting he was selling a fundamentally critically flawed service in the first place. If that's not even being mentioned, it really removes confidence from their new service.
As far as hardware HSM, that's cool. I very much enjoyed reading about how an HSM, the Luna CA3, was cracked:
http://www.cl.cam.ac.uk/~mkb23/research/Unwrapping-the-Chrys...
"Dear Mr. Levison, remember that law about pen registers that you clearly hadn't heard off last time around? Well, now that you understand them, please install a pen register on the other side of your fancy FIPS 140-2 hardware security device, and have it send us everything in .pcap format. You don't need to reconfigure your HSM for this, and in fact any attempt to do so is now tampering with evidence in a federal investigation. Cheers, the FBI."
I don't think it is. See https://europa.eu/european-union/about-eu/countries_en
The 5 eyes spy globally. U.S. citizens are the only ones with legal protection and (limited) recourse for U.S. government spying, AFAIK.
If a U.S. citizen uses a French or Icelandic mail host, I suspect the U.S. foreign intelligence agencies have free reign to spy on them. I wonder what the limits are for the FBI and other domestic agencies.
I am in the process of signing up now, just to restore access and get the hell away from that service. Email is insecure, we know that.
All of the encrypted email services I've seen so far, including Protonmail and now Lavabit v2, require using a special client (app or webmail) instead of common email software. This fails the very first test that I apply when trying to decide whether or not to use an online service: can I get all my data out of it on short notice, in a standard format through an automated process?
For email, this means IMAP access so that I can use standard tools like imapcopy to back up and migrate my mailbox. I don't care how secure your product is if it leads to vendor lock-in. I want both good encryption and an exit strategy, and the latter is much more important because if you screw up, I can always move to someone who does it better.
Sitting here in West Africa, watching the news, we didn't see much peace during the rioting in the streets in (I assume) Washington