back to article Lavabit, secure email? Hardly, says infosec wizard Moxie Marlinspike

Former Lavabit proprietor Ladar Levison claims the new Dark Mail initiative he's cooking up with the team from Silent Circle will enable email that's virtually spy-proof, but according to at least one expert, the original Lavabit service was never all that secure to begin with. "After all," security guru Moxie Marlinspike …

COMMENTS

This topic is closed for new posts.
  1. Anonymous Coward
    Anonymous Coward

    If the NSA had the feed to server(s) tapped, then they would get all new emails that come in. The only emails they couldn't see would be emails from one Labavit subscriber to another. So, the NSA had all but previous emails. No matter what secure system someone comes up with, to send an email to one person from another, it will be in clear text. There are already plenty of "secure" mail services but all they do is give the means to send a notification email to someone with a link to where they can read the message via a browser. That is not really an email, just a message.

    1. Tim Parker

      "No matter what secure system someone comes up with, to send an email to one person from another, it will be in clear text."

      Errr - no. The message body can be in cipher text or clear text, or even a binary attachment. How the receiver decrypts the message text depends on what what system you're using, who has whose keys etc. All that needs to be in clear text is the recipients email address, obviously.

      1. The_Idiot

        And this, for me...

        ... suggests a possible issue.

        Let's assume, for the sake of argument, we have some form of system that works. That emails between recipients can somehow be comprehensively and reliably sent (that is, I don't have to have some form of pre-existing relationship or shared code/ client base with any potential recipient in order to send them an email, and I can have confidence it will be both received and read).

        So far, so good.

        Er - or is it?

        Whatever messages look like (binaries, non human or machine parse-able blocks of text) - then prior to 'decoding' it, I have to allow my machine to accept otherwise unknown and unintelligible blocks of 'stuff'. Because it must be OK - after all, it's 'just an email'.

        Have I just opened up a rather convenient attack vector for the types of people I _don't_ want putting 'stuff' on my machine? Whether virus makers, script kiddies - or even the very people I'm trying to protect my privacy from?

        Maybe I've created an environment where all the TLA of your choice has to do to own my machine is send me an email :-(.

        If the email coming in can be 'checked for clean-ness' in any way prior to my reading it, then it must be at least partially decode-able, I would think. Which sort of defeats the object, if true. And if it isn't?

        Well, if it isn't - buggered if I know. But then, I'm an Idiot (blush).

        1. Tim Parker

          @The_idiot Re: And this, for me...

          "Whatever messages look like (binaries, non human or machine parse-able blocks of text) - then prior to 'decoding' it, I have to allow my machine to accept otherwise unknown and unintelligible blocks of 'stuff'. Because it must be OK - after all, it's 'just an email'.

          Have I just opened up a rather convenient attack vector for the types of people I _don't_ want putting 'stuff' on my machine? Whether virus makers, script kiddies - or even the very people I'm trying to protect my privacy from?"

          No - you haven't necessarily opened up an attack vector - your crypt text doesn't need to be executed and neither the encrypted nor decrypted streams need undergo evaluation beyond simple bit operations with no side effects (i.e. typically the input streams are just read into buffers, run through a bit-manipulation engine and re-write to a new output stream). If you don't feel brave, do all that in some well embunkered sandpit to catch execution exceptions etc). You don't need to 'check' it's safe, as you never execute it, the bit manipulations have no side-effects (e.g. the output of one operation is not used as some reference or pointer to further data) - you just run the bytes through the engine and look at the result - in hex if you wish. It will either make sense or it won't.

          It might be worth looking up some simple examples of something like public key encryption to see how this actually works in a concrete case - there are plenty out there e.g. this Mozilla introduction gives enough information to start with.

    2. deeztech

      not true

      I have a secure email service almost ready for launch that utilizes truly s/mime encrypted email. Since only the public key is required for encryption we are going to be giving the user the option to download the private key to their system and delete it off the server. So all email will always be encrypted on the server with no possibility of decrypting unless the user utilizes the private key on their end. This is true encrypted email as well as encrypted attachments. The only password that gets passed is to simply authenticate the account but the email is still encrypted on the server.

      1. btrower

        Re: not true

        @deeztech:

        That is an improvement, but you need to think like a suspicious customer. If it is *possible* for you to cheat (like retaining the key) then the system is insecure. Your server should never at any time be in a position where my adversary can compel you to turn against me.

        It is conceivable that you put the system together and then get a visit from your government compelling you to keep the keys, just like they currently compel people to keep logs.

        1. deeztech

          Re: not true

          @btrowerr

          Thought about that and we include the option to import your own cert without the private key.

      2. Anonymous Coward
        Anonymous Coward

        Re: not true

        @deeztech

        When your user goes and sends an email to say Google, how does that encryption work? Either that recipient needs to access the message of your server or what was sent was in clear text so the recipient can read it. Sure third-party products can be used to encrypt the mail, but that requires all parties to have that program and some form of authentication or know the key. "Encrypted" mail is not always encrypted. I can send an email to Google over SMTPS but if Google needs to send it elsewhere and they need to use port 25, then it is all clear text. The majority of emails sent server to server use port 25 and thus clear text. So, in the case of Lavabit, email sent from the user to another email service would be unencrypted. So, the NSA having a tap into the feeds, they would have all mail sent to and received from Lavabit users to users of a different email service.

        So, how is your service going to encrypt end to end for all traffic including SMTP?

        1. Vic

          Re: not true

          > The majority of emails sent server to server use port 25 and thus clear text.

          Your inference is incorrect; port 25 does *not* necessitate cleartext.

          TLS is supported by *many* MTAs - indeed, it's often the default installation to use it. What we *don't* have is pre-shared keys (so the encryption is merely opportunistic, and prone to MITM attack), but that could be fixed between small groups of MTAs without much effort.

          Fixing the problem globally is rather harder; ISTM that the best fix would be the same fix we apply to all other sorts of criminal behaviour. It won't give us 100% privacy, but a few spooks doing jail time "pour encourager les autres" would certainly clean up their behjaviour significantly...

          Vic.

          1. Anonymous Coward
            Anonymous Coward

            Re: not true

            "Fixing the problem globally is rather harder"

            Which is exactly what I was talking about; global. Clear text is always going to be a option as a secure SMTP server will still need to talk to other SMTP servers that do not support encryption and even if you forced encryption to be tried first, a MITM attack could force it to be clear text.

            "but that could be fixed between small groups of MTAs without much effort" Exactly, it doesn't scale well at all as it takes a lot of human intervention to get it setup just between a few providers.

            So you try to invalidate my post but all you did was reaffirm it.

            1. Vic

              Re: not true

              > So you try to invalidate my post

              You appear to be inferring motives that simply are not present...

              Vic.

  2. Sebby
    Flame

    This Annoyed the Hell out of Me

    Nothing done to protect email in transit or at rest is worth doing because it isn't end-to-end, and the worst possible adversary (a government) might--just might--compel the server operator to give the data up. This despite a complete lack of enthusiasm for changing whatever laws make this possible under a gag order in the first place. What a load of tosh! Zip up your trousers, Mr. Marlinspike. It's draughty in here.

    I used to think it wasn't worthwhile to offer STARTTLS if the peer can't verify the certificate. Well, that's changed. Our attackers are doing passive attacks, so let's make the work they have to do substantially harder by just recommending people turn opportunistic TLS on. In future, we put keying material in DNS and people can, gradually and incrementally, gain end-to-end secure delivery in the common case with reputable providers who've made the decision to do TLS and DNSSEC. If people want more, they can do it themselves, with PGP, since they fundamentally don't trust anyone between sender and recipient anyway, no matter what the protocol.

    1. doronron

      Re: This Annoyed the Hell out of Me

      I have an oddity now with certs. All certificates are coming in incredibly slow.... like 30-40 seconds to get a reply from ocsp server, often timing out the connection. Secure sights are slowed way down too.

      For example, google.co.uk takes 21.6 seconds to respond on https. While on http is reponds immediately, with a 'moved permanently' followed by a temporary moved totally about 4 seconds. This is not Google, google respond in milliseconds, this is something else.

      I suspect shenanigans, but then I have been complaining about GCHQ, so its to be expected.

      11:44:23.231[21650ms][total 21650ms] Status: 200[OK]

      GET https://www.google.co.uk/?q=chocolate Load Flags[LOAD_DOCUMENT_URI LOAD_REPLACE LOAD_INITIAL_DOCUMENT_URI ] Content Size[-1] Mime Type[text/html]

      Request Headers:

      Host[www.google.co.uk]

      [snipped]

      **************On http: a 301

      11:46:52.462[173ms][total 173ms] Status: 301[Moved Permanently]

      GET http://google.co.uk/?q=chocolate Load Flags[LOAD_DOCUMENT_URI LOAD_INITIAL_DOCUMENT_URI ] Content Size[233] Mime Type[text/html]

      Request Headers:

      Host[google.co.uk]

      User-Agent[Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0]

      Accept[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8]

      Accept-Language[en-US,en;q=0.5]

      Accept-Encoding[gzip, deflate]

      DNT[1]

      Cookie[[snip]

      ****************Then a very slow 302, follow eventually by a Google page

      11:46:52.853[236ms][total 4587ms] Status: 200[OK]

      GET https://www.google.co.uk/?q=chocolate Load Flags[LOAD_DOCUMENT_URI LOAD_REPLACE LOAD_INITIAL_DOCUMENT_URI ] Content Size[-1] Mime Type[text/html]

      Request Headers:

      Host[www.google.co.uk]

      User-Agent[Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0]

      Accept[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8]

      Accept-Language[en-US,en;q=0.5]

      Accept-Encoding[gzip, deflate]

      DNT[1]

      1. doronron

        Re: This Annoyed the Hell out of Me

        Yep, reset the DSL to force a new IP, clear the cache, and repeating the test, I don't get the 301 redirect but I still get the 302. Google.co.uk is now fast again.

        Commentard or terrorist?, you say po-ta-to, and I say pot-a-to!

        Now that I've visited elReg again, I'll give it a few minutes to see if the 301 comes back. This could be the flying pig leak we heard about. That's supposed to be a redirect injected into the connection, i.e. likely a 301 response.

        http://www.scribd.com/doc/166822246/flying-pig-motivations

        After a few minutes, I still don't see the 301 only the 302 and Google uk now shows its home page in 100458 ms, i.e. 100 seconds to bring up the Google homepage.

        12:38:10.486[99886ms][total 100458ms] Status: 200[OK]

        GET https://www.google.co.uk/?q=chocolate Load Flags[LOAD_DOCUMENT_URI LOAD_REPLACE

        Seems having an opinion is terrorism now? Or did the spooks misunderstand a 'death by chocolate' ad and are grabbing all searched for 'chocolate'?

        1. btrower

          Re: This Annoyed the Hell out of Me

          @doronron:

          Strange. I had a similar experience yesterday. I chalked it up to congestion at my ISP. I don't spend too much time worrying about it being intercepted because I assume that all my communications are vulnerable.

          Re: "Seems having an opinion is terrorism now"

          I think it is worse than that. Just having them direct their attention to you, for whatever reason, is a problem. It is as if by default everyone is an 'enemy combatant' until proven otherwise.

      2. jonathanb Silver badge

        Re: This Annoyed the Hell out of Me

        My timings are for downloading https://www.google.co.uk are as follows:

        On Windows 7

        Firefox - 1 second

        IE 11 - 1 second

        Chrome - 2 seconds

        Opera (with turbo mode) 3 seconds

        Opera (without turbo mode) 5 seconds

        On Mavericks

        Safari - considerably less than 1 second, but it seems to be preloaded, other sites aren't as quick

        Chrome - 1 second

        Firefox - 1 second

        Opera (with turbo mode) 5 seconds

        Opera (without turbo mode) 8 seconds

      3. Dan 55 Silver badge
        Black Helicopters

        Re: This Annoyed the Hell out of Me

        Update Firefox to 25, there have been some improvements in how TLS is handled.

        Try the Perspectives add-on to see if it believes that your certificate is false.

        1. doronron

          Re: This Annoyed the Hell out of Me

          Today its fixed, all 301 and 302's have gone completely from Tamperdata logs.

          I can browse Google in https, Wikipedia in https, DuckDuckgo in https all without the endless redirecting to 'special servers' that are overloaded. Without the redirection https is practically as fast as http.

          Hoorah!

          I don't think its the certificates that are fake, what I'm going to do is write some software to track DNS changes and secure sites that start throwing up 301s and other redirects when they previously didn't.

    2. tom dial Silver badge

      Re: This Annoyed the Hell out of Me

      The law will not be changed to eliminate issue of sealed warrants and subpoenas that forbid disclosure. We are not talking here about a National Security Letter. (Actually, I'm not sure the highly indignant Senators or Representatives are, either).

      TLS combined with DNSSEC would seem useful, but a government agency armed with a copy of the server certificate and warrant may be able to monkey with DNSSEC.

      PGP is a bit messy, and not nice with web mail, but really not that awful. And the more you control directly, and the fewer entities you have to trust, the less open your message is to compromise.

      1. Sebby

        Re: This Annoyed the Hell out of Me

        @ tom dial: the law is the problem. I'm not stupid enough to actually believe that I'd be successful in evading a government. Here in Blighty, unless you want to spend a few years in the slammer (a few more if you tell anyone about the investigation) for failing to divulge whatever keys or passwords are needed to decrypt stuff, I think you'd be wise not to either. Of course I wish it were otherwise, but the solution is resistance by default to intercepts, and I think TLS+DNSSEC is one hell of a statement when everyone implements it and most users immediately benefit from it. We really ought to recognise that LavaBit was served with the worst possible demand by a favourite adversary, and while I wouldn't have used them either (too nationalistic for my taste), it was their false assurances that attracted (the wrong kind of) customers (and, hence, the USG) and not their "Secure by default" encrypt-at-rest technology. Any webmail provider who cares about their users as opposed to their shareholders, without the LavaBit special sauce, is doing just as good a service to its users by ensuring that traffic is being encrypted and vigorously defending their stronghold when the government comes calling. Passive attacks are now a problem that we can stand a great deal from resisting, IMHO. And if you still want to be sure your secret plans to blow up the government aren't read, you still have the option of PGP.

        As to DNSSEC itself, I think the key advantage is accountability. People who're in the DNS business shouldn't be tampering with other peoples' published keys, and if they do, they'll probably lose quite a bit more than that one customer, especially if the registry in question serves an international audience. However, that's just my speculation--we'll have to see it to believe it. Still vastly better than the current CA model for initial mediation though, since you get to choose which registry will serve you (by picking a relevant CCTLD).

        1. Vic

          Re: This Annoyed the Hell out of Me

          > People who're in the DNS business shouldn't be tampering with other peoples' published keys

          DNSSEC relies on the chain-of-trust model that is so broken - under the PATRIOT act, the US Government (or its ill-tended "representatives") can not only force a change of record (and get it signed such that almost everyone will believe it valid), but they can force those in the know to remain silent about such changes.

          It *would* be possible to check the fingerprint - but how do you tell a legitimate DNS change from a subversion?

          Fundamentally, we just can't trust the trust root any longer. It's no point saying that such trusted agents wouldn't do any of this for fear of losing that trust status - they have no choice. That's what PATRIOT means - you can be forced to do pretty much anything the Government wants you to do. Real patriotism...

          The only way to protect your assets is to sign stuff yourself, and stay away from the trust roots for anything that matters. Aside from that being a *huge* fragmentation of the Internet, it's also a trivial work-around for anyone that cares about their privacy - i.e. this will occur (and is already doing so) both in the context of "legitimate", innocent traffic as well as the nefarious stuff. The US has succeeded in nothing except breaking the trust model for the common man; the bad guys will laugh it off.

          Vic.

  3. Decade
    Paris Hilton

    The Register is way behind here

    You're well behind. Ars Technica already published both Marlinspike's critique, and Levison's official response.

    http://arstechnica.com/security/2013/11/op-ed-lavabits-founder-responds-to-cryptographers-criticism/

    1. Havin_it

      Re: The Register is way behind here

      ...An official response that, it should be observed, entirely sidestepped MM's actual point.

      That point, as the Reg makes abundantly clear, is that Levison's assertion (perhaps it was only perceived, but it was widely believed) that he could not read stored messages even if he wanted to was unfounded.

      In the Ars piece, Levison admits as much: make what you will of his defence of LavaBit's methodology and implementation, he admits that it all rested on the SSL key that he possessed.

      He then seems to say that it never occurred to him that he could be forced to surrender that key. In hindsight, if this key/certificate were issued by any of the laughably-dubbed "Trusted Certificate Authorities", then there's every reason to fear that the key was fatally compromised to begin with anyway, but I'd not beat him up over that, as few of us were that paranoid prescient back then.

      However, if he failed to recognise that it all rested on the integrity of that key, then we were sort of safe, but in the hands of a moron. If he did grok this but made any assertion that the messages at rest were safe even from him (and please note I'm not saying he did, that's simply what I and others may have inferred), then he'd be a liar. Take your pick.

      1. Anonymous Coward
        Anonymous Coward

        Re: The Register is way behind here

        I agree. It looks very much as if Lavabit made a false claim about the nature of the security they provided and are now trying to wriggle out by saying it was "all a big mistake". I don't buy it. Anyone who puts that sort of system together knows exactly what they can and can't decrypt.

        They're probably not alone. You'll find similarly misleading claims from many cloud storage providers who somehow "can't" read your data but can de-duplicate it.

        Marketing blurb isn't an acceptable way to assess product security. You need to know how it works. That probably means open source.

      2. btrower

        Re: The Register is way behind here

        @Havin_it:

        Why is it that more technical people don't say this up front? There is no possible way the current root certificates can be trusted.

        If we were serious about security, step one would be to remove the current root certs. Thereafter, we should require *multiple* signatures from independent authorities with some hope of being trusted.

        For the record, entities like banks, governments, existing CAs, Communications companies, large software vendors, etc are not in my opinion trustworthy nor can they be made trustworthy.

        1. Anonymous Coward
          Anonymous Coward

          Re: The Register is way behind here

          From Ladar's response

          "When I was designing the Lavabit encrypted storage feature in 2004, it simply wasn’t possible for an attacker to intercept and decipher a large number of SSL connections in real time. This assumption was presumed true even if an attacker managed to gain access to the SSL private key. The situation has obviously changed. Network tools now decipher SSL connections efficiently, and servers are fast enough to make this attack a reality. A theoretical weakness became practical. I missed that development."

          Problem with this is that it never mattered whether attackers could decipher a large number of SSL connections in real time, if the attacker (in this case the Feds) had the SSL private key. They just packet capture the traffic to file, and decrypt it offline. There's no need to do it in realtime whatsoever. Why would they?

          I'm surprised Ladar missed that possibility, to be honest. Wireshark (or ethereal)'s been able to decrypt SSL since at least 2006, possibly as far back as 2004, I'm not sure. Why realtime is important, I'm also not sure.

      3. Anonymous Coward
        Anonymous Coward

        Re: The Register is way behind here

        I was reading that, and finding it interesting, then you said "If he did grok this", and sadly I had to stop reading and repeatedly stab myself in the throat with a rusty nail to make it stop

      4. Anonymous Coward
        Anonymous Coward

        Re: The Register is way behind here

        "In hindsight, if this key/certificate were issued by any of the laughably-dubbed "Trusted Certificate Authorities", then there's every reason to fear that the key was fatally compromised to begin with anyway, but I'd not beat him up over that, as few of us were that paranoid prescient back then."

        When you buy a cert from "any of the laughably-dubbed "Trusted Certificate Authorities" ", you send them a certificate signing request (CSR), and you DON'T send them your private key. They don't issue you with a private key, you generate it yourself, on a machine you admin, and you keep that private key safe yourself.

        This doesn't read like you know how CAs work, not really. CAs don't issue you with a private key, fatally compromised or otherwise. They give you a public certificate.

  4. cracked

    Trust and Security

    I think what the article highlights is the sad fact that - unless you are very skilled - somewhere along the line, to - at the very least, appear to yourself to - be secure; you have to trust someone.

    Even if that someone is someone who you have never met, but on whose software/hardware/services/stuff - that you probably do not have full knowledge of - you rely for security. Whether someone is an individual, (open source) group, business or a global advertising agency.

    Once extended to privacy from governments, it becomes impossible for all but the extremely skilled to retain any certainty that any of their communications and/or data - stored on a connected device - is truly private.

    If you wanted to design a communication and dissemination system that offered privacy to the individuals using the system; you wouldn't design the internet, as it is (and is used) today. Indeed, if privacy was your overriding design aim, probably any connected-system at all.

    If we are not there already, then in the near future most of any (absolute) personal-privacy will exist only in the anonymity offered by crowds (in clouds!?).

    1. Don Jefe

      Re: Trust and Security

      You're absolutely correct and it's true of securing everything from nations to email, you've got to trust several someones. Security is 50% technical and 50% Human, if you've got no faith in the Humans you'll never approach anything resembling security.

      You're right about the Internet too. It's an inherently insecure thing simply by virtue of is being an two-way communications system. The the security products and practices surrounding it are attempts to mitigate those insecurities. You can never 'fix' Internet security, it is broken. It's that people want to do things with it that is wasn't designed for.

      1. btrower

        Re: Trust and Security

        @cracked, @don jefe

        Re "you have to trust someone"

        You have to trust, but that needn't be a single entity. Security can be spread across multiple entities such that they *all* have to defect before your secret is known.

        Here is a brute force example:

        With a one time pad:

        Take two chunks of your pad sufficient to create two keys:

        key1

        key2

        Derive a new key, key3 from both by encrypting key2 with key1

        Encrypt your plaintext on key 3 to produce ciphertext.

        Give key1 to custodian1 and key2 to custodian2

        Assuming ciphertext is stored with custodian0, gaining access to the secret requires the following pieces:

        1) ciphertext from custodian0

        2) key1 from custodian1

        3) key2 from custodian2

        To gain back the plaintext, collect key1 and key2, derive key3 and decrypt ciphertext back to plaintext.

        I use a small number of custodians to make the example easy to follow but this can be extended to an arbitrary number. There are variations on a theme here to extend to multiple custodians (n) requiring any subset (m) to gain access to the secret.

        1. Charles 9

          Re: Trust and Security

          "You have to trust, but that needn't be a single entity. Security can be spread across multiple entities such that they *all* have to defect before your secret is known."

          The thing about going against a STATE is that they could have the resources to subvert ALL of them. And even if one or more of them are foreign and outside that state's control, what about THE OTHER states? How can you establish any kind of trust when your environment has basically become DTA?

        2. Anonymous Coward
          Anonymous Coward

          Re: Trust and Security

          There are also ways of extending this to multiple ciphers. Take some random bits and XOR them with the plaintext. Encrypt the original random bits with cipher A and the XORed bits with cipher B (using different keys, of course). Now you have to break both ciphers to recover the plaintext. This also extends to more than 2 ciphers.

          I'm not sure if there's an equivalent method for key exchange so one doesn't have to rely on one algorithm - it'd be interesting to know.

          If you're not confident about the security of any part of your system, this sort of redundancy is a good way of improving it, with some overhead of course.

    2. itzman

      Re: Trust and Security

      If you wanted to design a communication and dissemination system that offered privacy to the individuals using the system; you wouldn't design the internet, as it is (and is used) today. Indeed, if privacy was your overriding design aim, probably any connected-system at all.

      The whole point of a cipher is to ensure that secure communications are transmitted over an insecure link.

      From the man, that you couldn't trust, on a horse carrying a letter, to radio and the Internet, the problem is well known and well defined.

      All it would take would be the widespread adoption of mail clients that could detect an encrypted message and decide it locally using your private key.

      1. Charles 9

        Re: Trust and Security

        The problem arises when one of the parties is a "stranger" to the other. With no prior experience, there is ABSOLUTELY no way to prove Bob is Bob to Alice because there can't be a chain of trust without an anchor. That means Mallory or Gene can pretend to be Bob and Alice has no way of knowing the difference.

        Well, that's part of the problem with the Internet. It makes it very easy to talk to strangers, and in fact a lot of e-commerce takes place between what we could qualify as strangers.

        1. btrower

          Re: Trust and Security

          @Charles 9

          We agree. I am unsure of the protocol, but my expectation is that there would need to be a lot of material passed by various means, phone, newspaper ad, in person, etc.

          Bootstrapping is a really thorny issue. Ultimately, there is no way out of the box that something or combination of things has to be trusted. This is why I say that security requires political changes as well. We need to raise the price of eavesdropping to make it prohibitive.

          One of the things that bugs me about 'treacherous computing' is that it is effectively impossible to have complete control of your equipment and in the modern environment, your machine is at the mercy of vendors making changes by remote control.

          On the upside, as long as you can trust it is random and its entropy can be used to properly modify your pad, the amount of original secret material need not be all that large. I think that the way we generate 1024 bit keys is suspect and hence it does not have the full 1024 bits of randomness. However, if you can make it so that you have a genuinely random key and must essentially guess it by brute force in a single 1024 bit chunk, it is beyond secure. I am not going to do the math, but if it is not within 1024 bits, it is certainly well within a megabyte that you run up against the visible universe, the speed of light and Planck boundaries.

          1. cracked

            Re: Trust and Security

            Replying to all of the above in this little sub-thread, but to this one specifically to keep it in "thread order". Thanks for jumping in on this strand of the discussion.

            Isn't it interesting that almost immediately two - almost - seperate discussions started from the same article? One "insisting" that personal-security can be shoe-horned into the Internet and the other suggesting - for all but the most skilled - the system itself makes that impossible (and btrower has discussed how shoe-horning might work, in this mini-thread; bringing the two discussions together).

            I wrote the bit above - and thank Don for clarifying with a better written piece - because I wanted to raise the question of whether the "privacy" offered by the Internet (to an unskilled "user" - with just the basic software/hardware) is, and/or will ever be, sufficient for them to use in the manner in which they do?

            I guess a retitle for the article might be, "Was Internet Banking ever a clever idea?"

            I'm fine with unsecured cat videos - Always have been - Cat videos are why TBL invented It in the first place (though I think if you ask him, he'll say it was academic papers; that's just embarassment, though). It's all this other stuff, from eCommerce to Internet Banking, that concerns me.

            I should make clear - I have always considered it extremely likely that governments would snoop on the traffic within It. And I do not readily see how that will ever change. We pay them to worry about us, so they do. Sending a message in a form they cannot understand - encrypted - is only a reason for them to be even more interested in you.

            So, this isn't written from the - perfectly legimate - angle of protecting the people who do have something to hide but from what it means for the people who genuinely don't ... but do need to get to their bank-branch, before it closes at 4pm this afternoon.

            People have been encouraged to do unsafe things with It. In the name of profit for those doing the encouraging. Business jumped on It the moment Jeff shipped that first book from his garage. And has just hung on for the ride ever since.

            Back in 1994/5, when I was first shown It; my initial reaction was how cool It could be, but how far It would have to go to change the planet. There was no way people would be purchasing their new car over It, in the state It was in. But twenty years later, with hardly a Change Request actioned (or even ... requested), here we are. It has Its own currencies, banks have almost no real-world branches and book shops on the high street are rarer than Apple stores (the kind that don't sell fruit).

            Isn't it time someone important stood up and rang the bell that stops the bus? Even if we don't all get off, but just sit wondering about It, while the bus driver tries to figure out who is getting the $50 fine?

            As I think the overall reaction to the original article shows, security is possibly possible. But any methodolgies used to achieve that are so far outside the knowledge of the mainstream internet user - and me! - as to make them unuseable.

            And I do not see how that can change - Neither by "idiot proofing" the technology (though that can always get better) nor educating the average mainstream user?

            So, time for the controverial question: Is It "good enough"?

            If It will never be perfect; is the "progress" It has helped bring about (e.g. know your bank balance in seconds), worth the loss of security that no longer having to have that face-to-face meeting with your bank manager, offered?

            To put it another way - and come over all superior, sadly - Is it so beneficial to society that the Shanes and Sharons (sorry, if you are reading, Shane/Sharon) get exposed to all manner of crime - both government-backed and everyday - in the name of doing things faster, better, cheaper?

            I'm not suggested it can be uninvented. That genie is going no where near it's former jail-cell. I am suggesting - maybe asking is a better way to put it - whether maybe the people supposed to be looking out for Shane and Sharon, hadn't better just pause for thought?

            The fine for ringing the bell is only $50; it's got to be worth someone agreeing to cop for it, while everyone takes a breather. Hasn't it?

            1. Gannon (J.) Dick

              Re: Trust and Security

              "I'm not suggested it can be uninvented."

              Un-invention benefits from the additional delusion that invention will be more difficult the next go around. Rather like Chemical Weapons; some of which are distressingly easy to make.

              The earth is not flat, but neither is the universe hollow.

              1. cracked
                Go

                Re: Trust and Security

                Indeed, it's probably impossible not to reinvent It.

                I read two other things here, very recently, that are possibly applicable ...?

                One that I can't find (Home Automation) ... Like I think automatically unlocking your doors as your "Personal Transport Device" hums along a couple of miles from your house - going in the wrong direction - is a "good idea"

                The other is this: http://www.theregister.co.uk/2013/11/08/google_patent_tattoo_a_mobe_microphone_on_your_throat/

                Now there is an ID system that will improve things. As the article-author notes, there appears to be an unnecessary removal function; but other than that, here is a possible "let's start all over, again" driver.

                If you want access to It, get one of these from your (accreditted) Nation's (accreditted) health professionals. No tat? Then, no tit(s) ... nor cats.

                But; want to create a Facebook profile for that 14 year old, high school girly that you always, secretly, wanted to be? ... No problem, go find a "back street surgeon" willing to rip off the original and stitch on a clone ... Your buddy (who makes those little swan ornaments out of paper/foil?) may even give you a ride there, in his electric car.

                It's either this; or finding your dinner was cooked five hours before you got home - every night - because your neighbour's kid thinks that's funny.

  5. Thomas Allen

    Secure email

    There are several open source and private projects using javascript to encode forms in pgp in the browser, so your form content is encrypted before the form is sent. It gets decrypted at the other end. For example:

    http://openpgpjs.org/

    and

    http://www.hanewin.net/encrypt/

    Also http://tectite.com offers an encoder product that you use in conjunction with the browser's https encryption. You use https to send forms from the browser to the server, then encode with tectite encoder at the server and send to an email box (where the person has the tectite decoder.)

    Both these solutions provide end-to-end encryption of form data. So email in the browser (which is usually sent as a form) can be protected by strong encryption in ways lavabit and others do not offer. Both of these solutions are used for credit card data, hippa compliance, and other secure email.

    1. Mike Pellatt

      Re: Secure email

      Doesn't protect against one vulnerability I can think of straight away..

      http://www.contextis.co.uk/research/white-papers/pixel-perfect-timing-attacks-html5/

      HTML5, insecure by design :-)

    2. Charles 9

      Re: Secure email

      But then what do you do when the recipient has to be anonymous? How do you send an email with a blank envelope?

      1. itzman

        Re: Secure email

        But then what do you do when the recipient has to be anonymous? How do you send an email with a blank envelope?

        Traditionally you put an advert in the personal columns of the Times.

        Imagine a system where you scan 100,000 headers on some website all encrypted to find the one that matches your private key and represents a message to you. It also contains the URL of your encrypted message or a further key that can be used to retrieve it.

      2. Anonymous Coward
        Anonymous Coward

        Re: Secure email

        > But then what do you do when the recipient has to be anonymous?

        You give him the password to the "sending" email account and you save the locally encrypted email as a draft, rather than actually submitting it (at least the recipient has the decryption key). This used to work up to a few years ago (maybe five) for moderate security, but is no longer advised.

        Nowadays (and back then) you don't use email at all, but other channels, not necessarily electronic.

    3. wbaw

      Re: Secure email

      Javascript encryption can never be secure because it's too easy for an active attacker to inject malicious javascript code into your web page that can intercept the plain text.

  6. tom dial Silver badge

    The article seems to say that the only effective protection Lavabit offered depended on its certificate private key. Which the FBI (not NSA) obtained a warrant for.

    PGP (or GPG) may be a bit of a pain, as is sidestepping webmail, but requires you to trust only the recipient (or the sender, if you are the recipient). And, of course, the PGP/GPG implementer, and the OS in use, and the compiler used to prepare it, and so on.

    Ladar Levison may be more trustworthy than Google or Microsoft, but I really don't know any of them, and don't have, on personal knowledge, reason to trust any of them more or less than the others.

  7. Tromos
    Joke

    The day of Ladar Levison and Moxie Marlinspike has gone by, I'm waiting to see what Naugahyde Neanderthal has to say on the subject.

  8. Anonymous Coward
    Anonymous Coward

    Levinson has responded

    At Ars:

    http://arstechnica.com/security/2013/11/op-ed-lavabits-founder-responds-to-cryptographers-criticism/

    He says Moxie is wrong about some of his assumptions, but agrees that the big issue about having only one SSL certificate was his biggest mistake.

  9. Anonymous Coward
    Anonymous Coward

    PKI

    It seems to me that the only secure email system, is email with receiver specific PKI content; it then doesn't matter who stores it, because only the receiver can decrypt it. The only snags I can see with this are maintaining security of local raw text and private keys, the requirement that both ends consistently use PKI to avoid email chain leaks, no CC or BCC support, and the sender not being able re-view content for already encrypted sent emails; however the last one could be seen as a benefit.

    It maybe that the only really secure transport is an encrypted direct end-to-end pipe, like SSL, with disposable PKI, rather than indirect messaging solutions.

  10. John Smith 19 Gold badge
    Happy

    "Dark Mall"

    A lesser known Sith lord?

  11. mike acker

    no need to build - learn to use pgp

    there is no need for anyone to build anything. for secure mail what you want is already available,-- for free.

    start by switching to Linux,-- I recommend MINT

    read and follow instructions regarding maintenance: stick to the official software store.

    switch your e/mail to a commercial supplier -- not one of the free ones like Hotmail, Google, or Yahoo. I use Charter, and CoreComm services.

    next switch your e/mail onto the THUNDERBIRD client -- that comes with Linux/MINT (also Ubuntu if you prefer ). spend a little time learning to use Thunderbird. it uses IMAP servers -- so you can share mail on your iphone (that isn't encrypted) .

    activate the ENIGMAIL plugin on Thunderbird. this uses the GnuPG version of PGP.

    use the OpenPGP dialog on Thunderbird to generate your PGP keypair. set 1 year expiration date; load your public key to the keyserver. be sure to generate and save the key revoke certificate (JIC).

    locate, dowload, and read Phil Zimmerman's essay on PGP, paying particular attention to the section on protecting public keys from tampering. learn what the Trust Model is -- and how to control it.

    find a pardner to begin exchanging PGP mail with

    remember there are 3 main advantages to PGP (ENIGMAIL) mail

    +authentication

    +integrity

    +security

    authentication allows you to ascertain with reasonable certainty that an e/mail is from the party which clains to have sent it. without this i can send you an e/mail and mark it from anyone i want -- your boss -- or Nixon or Kruschev

    integrity allows you to be reasonably sure that you have a correct copy of a message; that the message has not been modified in-transit by someone using (e.g.) a "Man in the Middle" attack. This is CRITICAL for software distributions and financial transactions .

    security allows you to encrypt messages so that you can be reasonbly sure only the intended recipient can read them . this is a lot better than putting a disclaimer in your signature block saying something to the effect "if you weren't supposed to get this please cover for me, thanks"

    NSA can still apply a traffic analysis on you: ascertain who you are talking to and this won't ever go away on public networks -- switched circuit -- or packet switched . but to get the messages now they have to hit YOU with a subpoena. hitting your ISP won't help: Your ISPcouldn't read your traffic in any reasonable timeframe or at any reasonable cost -- no matter how much they wanted to .

    remember though you are subject to the AUP you signed with you ISP. the government could tell ISPs that PGP mail traffic must not be allowed. in which case we'll come up with a new Plan .

    1. Anonymous Coward
      Anonymous Coward

      Re: no need to build - learn to use pgp

      I agree with everything you say but the biggest obstacle to this method is the "other" users you want to send the encrypted mail to.

      I tried doing just this with a few friends some years back just by sharing public keys between ourselves, and although they aren't thickos it soon became too much trouble for them to bother with. Sure if I really wanted to send them an encrypted email and have them read it it could be done, but the odd encrypted message stands out like a dogs balls so it's really necessary that ALL messages are encrypted as a matter of course. Inertia and laziness win every time, to the advantage of the snoopers.

      1. btrower

        resistance is futile

        @notauser:

        You are correct on all counts. This is empirically true from my own experience working on projects with technical people.

        For encryption to be effective, it has to be dead simple to use and on by default everywhere. Of course it also has to be resistant to attack. I think simple and ubiquitous is achievable. I am inclined to say, only half in jest, that 'resistance is futile'.

  12. Matt Bryant Silver badge
    Pirate

    LOL! Scam.

    One of the "evils" of Capitalism is that as soon as a market segment becomes big enough to identify and analyse for marketing opportunities then some clever individuals will start thinking how they can exploit the segment. And the best market of all, as any good salesman knows, is one where the customer has already convinced themselves they need the product. It seems there is a growing market made of the technically incompetent and paranoid delusional, who will happily pay for shoddy services like Lavabit simply on the word of the proprietor's "rebelliousness" and his promises of privacy. In short, IMHO, he's a scam artist, and he closed his service because the obvious next step for the US authorities if he had defied them was to leak how worthless Lavabit's promise of "secure email" actually was. Another likely example is the "secure Bitcoin service" run by TradeFortress in Oz that got magically attacked......

    Damn, I'm going to have to get my old coding books out and start writing some "secure, privacy Web products" for the sheeple. It seems the market is truly bursting with hysteria and there's money to be made!

    1. itzman

      Re: LOL! Scam.

      I think that there is a real genuine and growing market for more secure email than currently exists: Today's emails are little more secure than an analogue mobile phone was.

      Obviously we wouldn't use SMTP in its current form.

      You may joke, but its one application I WOULD think is worth coding up. Blackberry showed that there is a market for secure comms between parties. Even if they couldn't make a phone worth a damn.

    2. Destroy All Monsters Silver badge

      Re: LOL! Scam.

      This coming from a guy who thinks HP/Itanium is the dog's bollocks and Snowden is traitorous scum.

      1. Matt Bryant Silver badge
        Happy

        Re: Destroyed All Braincells Re: LOL! Scam.

        Once again you demonstrate that having no argument to make doesn't stop your whining. I guess you're so upset because you, being a prime case of paranoid gullibility, were probably taken by one of these "secure" scams and don't like the truth being shown to you. Enjoy!

  13. Anonymous Coward
    Anonymous Coward

    what the NSA were after

    I assume that the NSA were not necessarily after the mails themselves. Rather they knew that Snowden used the service and were therefore interested in catching him communicating with the service in order to track back to where he might physically be located.

    Far too much focus is being put on the security of email servers or the mail sitting on them, when the vast majority of mail sent between networks is not encrypted at all, and is trivial for the NSA to hoover up. Emails are typically assumed to be a digital equivalent of a letter, but they're really more like the digital equivalent of a postcard, because anyone en route can read the contents without any need to 'open' it, or without there being any indication to the recipient that the message was read by someone else. You should not really send anything by email that you would not send by postcard - because it's almost certainly being read and even recorded by people less honest and decent than your average postman (and in my experience, that's a pretty low bar).

  14. btrower

    Moxie was correct ...

    Exec Summary -- Moxie was right, major players are untrustworthy, practical solutions require legislation, current security is ridiculous, good security is likely possible but not likely to happen, all of us have to skill *way up* on security.

    Moxie was correct in both tone and substance. The Lavabit system was fundamentally insecure. In Levison's defense, I do not think he was either malicious or stupid. Security is like an onion with unlimited layers. There is always another weakness. Moxie could have been gratuitously unkind in his criticism, but limited himself to pointing out the one glaring weakness. Levison admits to the weakness, but obscures the admission with a lot of talk about other aspects of the system. We are only concerned ultimately with a chain breaking. If the weakest link is not strong enough to hold, the chain breaks and is no longer useful.

    All of the big players have to know that reasonable security is possible. Unfortunately, it is not in their interest to destroy valuable information about people.

    We know that a true one time pad is secure. In essence, all security is aimed at faking one-time pads. As we wander away from a pure design, security diminishes.

    In the Lavabit case, if the data was encrypted on a one-time pad before being sent to the server there is no way the mail could be read. This would still leave the matter of traffic logs, but that is a network issue that Lavabit could not solve on their own anyway.

    We need to have secure end to end communications. It is possible, but a lot more technical people have to skill up and understand the issues. I don't exclude myself from that, BTW.

    The most potent immediate cure is to make it illegal to eavesdrop on private communications, illegal to possess ill-gotten information and make any ill-gotten evidence inadmissible for any purpose. This is not perfect, but would greatly raise the cost and diminish the value of eavesdropping.

    Technically, we can secure end-to-end communications and intermediate storage by encrypting on 'effective one time pads' -- simulated one-time pads created with very large keys. To secure identity, we would need a secure push/pull 'store and forward' system whereby all traffic is posted anonymously by one party and retrieved anonymously by another. The details of such a system get complicated, but it is doable.

    It is very difficult to secure communications against a persistent and well-armed attacker. As a practical matter, provably secure communications are not possible. However, that does not mean that we have to make it easy to eavesdrop.

    As a mail administrator for many years, I have always told people that they must assume anything sent by ordinary Email will be read eventually by people other than the recipient and can always be published. As a matter of personal discipline I do not snoop on people's Email and anything I see accidentally is excised from memory. However, I know for a fact that other administrators are not so scrupulous. Despite my cautions, users send Email like it was postal mail and assume that it is secure.

    I do not consider myself a security expert, but it has been an integral part of my work for decades. I designed and built a secure communications system used by hundreds of techs and senior executives at a Canadian Bank. It passed a nominally rigorous audit and was never breached. Mine is not really a layman's opinion.

    In my opinion, the entire debate about secure communications is laughable. There are so many points of failure that no knowledgeable person could possibly trust current systems for anything important.

    - I am suspicious of people who say that current key sizes are anywhere near adequate. They need to be measured in megabytes, not bits.

    - I do not trust PKI as currently implemented. Key sizes are too small. The algorithms are suspect. The trust system is ridiculous with the least trustworthy entities bordering on criminal at the roots. Randomization is iffy and has already been subject to successful attacks. Key storage is clumsy, difficult and error prone.

    - Government has been at this a long time. If people recall, they attempted to make it so that all encryption had a government accessible back door via the 'Clipper Chip'. They do not attempt this any more. That can only be either because they gave up or they were successful some other way. It is a stretch to think they gave up.

    - We have a legal regime that makes all intermediaries untrustworthy. If information is stored in the clear at Google, Microsoft, Apple, IBM, Facebook, Twitter, the government has access. Any information that transits in the clear via a .com, .net .us or .org TLD is open to inspection, MIM attacks, etc by the government.

    - Since the entire network is insecure against inspection of routing information and things like search engine queries, that information can be collected. If it is, it can be mined for statistics. Statistical techniques are much more effective than most people realize.

    - People are much too trusting when it comes to this. We do not, in our daily life, expect to be literally dodging bullets or subject to deadly assault if we are not in a war zone. Giving your password to someone is like turning over your weapon to them. Fine if you are out hunting with your buddies, not so good if you are in armed combat. When it comes to electronic security, we are in a war zone.

    - Side channel attacks are frighteningly advanced and effective.

    - Rubber-hose cryptanalysis is both advanced and highly effective.

    - Social engineering remains a devastating attack. Thus far it appears to even defeat the government.

    I may be naive, but I am of the opinion that reasonable security is possible. One reason is that mandated key sizes are so small. The government has been persistent with this and that indicates to me that larger key sizes present a challenge to them. If modest kilobyte key sizes present a challenge to them, it means to me that they cannot break a well-formed megabyte key. Another reason is that no matter how powerful their systems, I find it doubtful that their systems are significantly larger than the aggregate size of the Internet. They would mandate that all traffic be encrypted if inspecting encrypted traffic presented no challenge to them. At some point, people will realize that all traffic must be encrypted. Another reason is that they have left the infrastructure security so weak. It is in their interest to make it easy for them to intercept communications and impossible for others to do so. It indicates to me that they cannot easily handle systems much more secure than we have now.

    I am optimistic that reasonable security is possible, but I confess to some pessimism that it will happen. Not nearly enough of the technical community is properly conversant with the issues and as above, I do not exclude myself from that.

  15. RealitySpike

    IMHO: Lavabit security was a joke

    From his rebuttal: "When I was designing the Lavabit encrypted storage feature in 2004, it simply wasn’t possible for an attacker to intercept and decipher a large number of SSL connections in real time. This assumption was presumed true even if an attacker managed to gain access to the SSL private key. "

    By 2000 hardware protection of your SSL private key was standard practice precisely because it was known you could attack historical traffic based on a compromised SSL key. The risk was made apparent with all the dot-bom web servers being sold on the 2nd hand market post bankruptcies with their hard drives intact.

    He should have been using HSM based SSL "accelerators" and then he could have told the NSA to get stuffed because he didn't have access to his private key. By 2004 these were pretty inexpensive so he had no excuses.

    1. btrower

      Re: IMHO: Lavabit security was a joke

      @RealitySpike:

      Levison put his foot in it when he tried to spin this. He should have just 'fessed up. I doubt he was really pitching to security experts, though.

      People well ahead of the curve can be compromised:

      http://www.wired.com/threatlevel/2007/11/encrypted-e-mai/

      I have a suspicion that people with enough knowledge of layers on this security onion attempt to steer clear of dealing with stuff like this. Maybe only the less knowledgeable even try their hand at it.

      There is no question he made a mistake and betrayed a due diligence issue, but I would not be too hard on him. I think that Moxie struck the right balance between making the vulnerability and deep design error clear without unduly punishing someone who at least on the face of it tried to do the right thing.

  16. cd

    Why didn't Snowden understand the vulnerability?

  17. Graeme5

    Popular secure email service is a misnoma

    If you use a well known 'secure' email provider like Lavabit used to advertise its self as then you are right in the spotlight of NSA types - shouting I have something to hide and I store my email here!

    How secure any system is is almost impossible to assess as an outsider, even with unknown private keys you couldn't know if there was an intentional weakness in the implementation, or if the provider was actually an NSA funded front.

    You'd probably be better to run your own little system on some obscure hosting provider. Sure if you were targeted you could have a problem but if you use a popular provider you can be sure you will be targeted. Even if your email is secure you will be identifiable as someone with somthing to hide.

  18. Anonymous Coward
    Anonymous Coward

    Learnt from experience?

    Was this not the person who used to run a sort of Google proxy, and could therefore, if he so chose, access its users' whole search history in the same way he claims the Lavabit owner could, if he wanted, access its users' email?

    As a smaller player, he would have certainly been more vulnerable than Google if hit with an order to rat on his customers, so is he perhaps talking from his own experience?

  19. Anonymous Coward
    Anonymous Coward

    I'm pretty much just here to say that Moxie Marlinspike is a fucking fantastic name.

    Also that complaining that email is insecure is like whining that your Ford Mondeo can't win the Dakar rally. No shit! It wasn't designed for that! You want to go rallying, you're going to have to stump up for the right ride; you want secure communication, you'd best start by engaging in it via a transport that nobody knows is communication in the first place. Stenography inserted in random people's social media pictures via botnets which the Russians you hired think you're using to spam people, say. Or you make a USB device that intercepts mouse movements and twitches the mouse in a pattern based on desired communications; you and yourcollaborator join the same TF2 server and record replays which you analyses to decode the messages hidden in the players' movements..

    There must be a million ways to do it, and I'm an idiot when it comes to security. It's hard to believe that anyone who *really cares* would rely on the say-so of an email provider who says the new fenders he put on his Mondeo have made it suitable for tackling the dunes...

  20. Anonymous Coward
    Anonymous Coward

    The network is the computer

    We used to say that an attacker who gained physical access to your computer could gain access to its contents, no matter how well protected.

    Well, these days the network is the computer (with apologies to Sun for nicking their prescient slogan). And governments and state actors have physical access. I'm sure many Reg readers have seen or heard of the special rooms in carrier hotels and other peering points.

    Therefore, a guarantee of privacy is impossible. So, you have two possible paths forward: one "in the box" and one outside of it. In the box is an arms race where you slow down the attacker and they try and get faster. You use 2048-bit keys not 1024, you use AES and not DES (are you listening, Adobe?), etc. But always understanding that the other guy will succeed eventually. The out of the box solution is to make a legal/political/commercial framework that makes spying on citizens untenable. This of course requires your political class to play along, which is always a challenge. Money tends to help a lot: witness the squealing and wounded protestations of innocence from the major US tech companies when it became apparent that they might be tarred with the same brush as the NSA.

This topic is closed for new posts.