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.

Page:

  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?

Page:

This topic is closed for new posts.