back to article Armouring up online: Duncan Campbell's chief techie talks crypto with El Reg

I think I was about 15 or 16 when PGP was making headlines for being classified as munitions by the US government and was (supposedly) banned from export. While I wasn’t a subversive type at the time, I got a very strong sense that any software that scared the mighty USA so badly was something I ought to play with and try to …

  1. Anonymous Coward
    Anonymous Coward

    Ouch! How prescient...

    http://www.theregister.co.uk/2000/11/20/echelon_discoverer_gives_masterclass/

  2. Anonymous Coward
    Anonymous Coward

    Such little time is given over by the media to the Espionage actions of the NSA...

    http://news.bbc.co.uk/2/hi/europe/820758.stm

  3. g e

    Completely open to the agencies

    Which is why I suspect MS paid that hefty sum for Skype... they got a contribution from the NSA toward the purchase on condition they neutered it, as wasn't it previously untappable before then ?

    1. streaky

      Re: Completely open to the agencies

      "as wasn't it previously untappable before then"

      No it's always been open to the alphabets, by design, basically from day one.

  4. The Man Who Fell To Earth Silver badge
    Thumb Up

    My only comment

    Is I've switched from Truecrypt to Bestcrypt. Bestcrypt isn't free, but you can examine their source & and it is maintained & improved.

    1. JosephSecurity

      Re: My only comment

      BestCrypt is not a good alternative: thanks to the sources, one can see that it uses 256 iterations for key derivation with a ridiculously small salt (8 bytes) which is irresponsible to say the least! Even iPhone uses 10000 iterations. You should ask them why they made such suspicious choices.

      TrueCrypt uses 1000 iterations which is low by nowadays standards (in 2001, 1000 was the norm) but it is still secure if you use a long and complex password thanks to its long salt (64 bytes). Its fork VeraCrypt uses stronger values and corrects some issues found so far in TrueCrypt but nothing critical.

      1. Charles 9 Silver badge

        Re: My only comment

        I'm curious about VeraCrypt, but the fact it's hosted on CodePlex, a Microsoft site (and using a Microsoft-based license), raises a cautious eyebrow. Why here and not, say, SourceForge?

        I'm currently trying DickCryptor on and off. It specializes in whole-volume encryption, but it's not as well-rounded. I may give VeraCrypt a test spin.

  5. Anonymous Coward
    Anonymous Coward

    really?

    Other than the "don't use skype" this article could have been written many times over the last decade and is p useless in view of the recent revelations from Mr Snowden.

    As alluded to in the article itself you are still running into "why Johnny can't encrypt" (from 1999!) and you miss the point that email/comms metadata means that relationships between journalists and sources are still completely exposed.

    "hmm, he just got an encrypted email and now he is going outside to make a call on his mobile"

    RIPA has already been used to send people to jail for not handing keys to encrypted volumes over.

    And to disagree with steve gibson once again (why break a good habit), using a security package that isn't being maintained any more is not the most clever move.

    I had hoped for better from a reg article but even Cory Doctorow's Little Brother is a much better description of opsec than is portrayed in here (other than the fictional x-net).

    How about Tails or OTR or pointing us towards invisible.im

    What about don't use RSA, aim for ECC but avoid the NIST curves?

    Signal/redphone/silent circle?

    I hope Mr Campbell isn't going to be going up against anything 5eyes related without some other advice because whilst the NSA clearly didn't practice any real internal opsec themselves (all those docs on a sharepoint server with password authentication only...why thank you kindly) their ability to monitor all the things makes "encrypt your email and your HD" look a bit(very) weak.

    1. Michael Shelby

      Re: really?

      I found nothing wrong with the article. It is called "Crypto Toolbox Part I". As the first article in a series, it was intended as a simple introduction to the most common tools and pointed to a few helpful tutorials. I expect the rest of the series of articles to be more advanced...

    2. Anonymous Coward
      Big Brother

      Re: really?

      quote: ...there's no specific problem with allowing The Man to eavesdrop on that conversation.

      Well, yes, there is, as was stated above, it definitively links the two individuals and gives the evil powers a reason to dig. A year ago, I'd have said you should store your private key on a /relatively/ easy to destroy USB key, but after the revelations about the firmware on the keys themselves, I wouldn't advise it.

      1. Pascal Monett Silver badge

        Linking two individuals from electronic communication is something any agency can do (with a warrant) since ages. All any agency needs to do is call the telephone/ISP provider, show the warrant and request a list of all phone numbers/IP addresses that the suspect contacted/connected to. Telephone/ISP is legally bound to comply.

        So you can put whatever encryption you want on your data, unless you only communicate face-to-face (without a smartphone on your person or in your car) there will be a government-available trace of your comms that can and will be mined if need be.

        1. Destroy All Monsters Silver badge
          Big Brother

          What about don't use RSA, aim for ECC

          Explain!

        2. Michael Wojcik Silver badge

          unless you only communicate face-to-face (without a smartphone on your person or in your car) there will be a government-available trace of your comms that can and will be mined if need be

          All you armchair security experts are aware there are protocols for blinding traffic analysis, right?

          Pro tip: In a security discussion, the person suggesting something is impossible is probably mistaken.

          1. Charles 9 Silver badge

            "All you armchair security experts are aware there are protocols for blinding traffic analysis, right?"

            And there are ways to beat the blinders, too. You don't need traffic analysis when you pwn one of the endpoints.

          2. Anonymous Coward
            Anonymous Coward

            Pro tip: In a security discussion, the person suggesting something is impossible is probably mistaken.

            Just to check, are you saying the protocols you suggest make traffic analysis impossible?

            Or are you simply saying that traffic analysis can be defeated but skilled & well resourced parties can still make traffic analysis work?

            If it is the former, your own post says you are probably mistaken. If it is the latter, you are adding less to the discussion than you might think.

    3. Gotno iShit Wantno iShit

      Re: really?

      And to disagree with steve gibson once again (why break a good habit), using a security package that isn't being maintained any more is not the most clever move.

      Why? TrueCrypt 7.1a is one of the most heavily vetted lumps of code one could choose to run. It's weaknesses are known and in the opinion of those who understand crypto deeply not significant.

      Let's look at 4 scenarios and think what would happen in each:

      1) A new vuln in TrueCrypt 7.1a is found by a whitehat; It would be publicised widely immediately, it would be headline news absolutely everywhere. Sensible folk then stop using TC.

      2) A new vuln in TrueCrypt 7.1a is found by a blackhat or TLA; they keep it quiet and use it.

      3) A new vuln in <something else> is found by a whitehat; It would be reported to the devs, some time later a new version would likely appear, there would then be full disclosure one hopes and some press coverage.

      4) A new vuln in <something else> is found by a blackhat or TLA; they keep it quiet and use it.

      2 and 4 are identical so lets discount blackhat attacks. I would know I was vulnerable far quicker in 1 than in 3 so I choose 1. It also put's the onus on me to do something should I become vulnerable rather than relying on the author of <something else> which is the way I like it.

      YMMV.

  6. Fazal Majid

    He is stunningly Naive

    If he thinks the threat model for investigating high-level corporate malfeasance should not defend against state-level actors. All evidence shows the NSA has a sideline in economic espionage, whether from deliberate policy, horse-trading for reciprocal favors or simply personal corruption of NSA leaders is irrelevant. It is highly likely big establishment firms like BP or Unilever benefit from the same chumminess from GCHQ, and so on.

  7. phil dude
    Black Helicopters

    a nice try....

    But you should have started with "Ditch windows, Mac OSX and any other OS you cannot inspect the source. They are compromised by design. The corporations who own the source code can be legally compelled to make all of your security procedures worthless - especially if you are a high value target. If is just non-state criminals you are worried about , this will probably be ok for you."

    I am under no illusion that if I became a target nothing on this Earth would stop the bad guys , except proper encryption. And even then it would only impede them. Depending on how important you were. I don't trust encryption ultimately as the mathematics are not provably hard - only the algorithms are.

    But as the saying goes, "Pretty Good Privacy(tm)", is good enough for mortals.

    If Snowden has shown the world anything it is that nothing is safe when the Govt's have no reason to follow the law as there are no consequences for them - only for us.

    P.

    1. Cipher

      Re: a nice try....

      The real answer, and it is mathematically proven secure, is the One Time Pad.

      This what a bad actor subject to state sponsored analysis should be using.

      There are rules for using a OTP, rules that cannot be broken. Additionally, a nice added trick can be found in the One Step Beyond subheading of Christoph Wille's examination of the OTP.

      There are problems with the OTP, mainly physical security of the pads, but the crypto is 100% safe. A good site: to read about the main rules.

      1. Allan George Dyer Silver badge
        Holmes

        Re: a nice try....

        @Cipher - The One Time Pad is not the answer to almost all real-world security problems. The article gave practical (but not mathematically perfect) solutions for two scenarios:

        1) Data at Rest - The OTP is as large as the encrypted data, so you've replaced the problem of securely storing the data to securely storing the OTP, no gain. The OTP was never intended for this scenario.

        2) Data in Transit - The OTP gives perfect protection to a message, provided you have previously securely shared a OTP at least as big. In other words, it allows you to time-shift the secure data transfer.

        The OTP works for pre-defined communicators with previous opportunity for secure transfer - say a Government and its embassies. It is useless for whistleblowers or ad-hoc collaborative groups.

    2. Jonathan Richards 1
      Boffin

      Re: a nice try....

      > Ditch windows, Mac OSX and any other OS you cannot inspect the source

      It's all about matching your measures to the threat. i.e. risk management. Just being able to inspect the source doesn't help, unless you do actually read all that source, glasshopper. And then personally compile what you just read. With a compiler you can trust. Which means writing a minimal bootstrap compiler yourself, probably in assembler, to compile an open-source compiler. This might conceivably protect you against OS-level attacks from The Big Boys, but I wouldn't guarantee it; you'll still be implementing protocols which may be flawed. It's massive overkill in almost any situation other than trying to protect the operations in your world-conquering volcanic lair.

      1. Trevor_Pott Gold badge

        Re: a nice try....

        "It's massive overkill in almost any situation other than trying to protect the operations in your world-conquering volcanic lair."

        Why? Because you trust your government? Because you honestly believe you're above suspicion?

        Why should we share your level of naivete?

        1. Pascal Monett Silver badge

          Re: Why? Because you trust your government?

          No, but because unless you really are a criminal/terrorist trying to protect your nefarious activities from Men In Black, it's a level of hassle to implement proper security that goes way beyond what Average Joe needs.

          Not that I'm advocating doing nothing, far from it, but if I told all my friends they have to learn and implement PGP if they want to email me the latest joke or get my latest musings about where to go for dinner, I'm pretty sure my mailbox will be suddenly barren of anything but spam.

          As for data encryption, well I don't see that my personal data is worth it. I have firewalls and AV that have protected it up to now, if The Man wants to see it, not much I'll do will keep him from it for long.

          I don't like the idea that the NSA considers my communications free range for its harvesters, but I'm not about to act like a crime lord to keep them from it. I'd rather they stop doing it, but I'd also like to win the lottery. I think I have a better chance at the latter, even without playing.

          1. Trevor_Pott Gold badge

            Re: Why? Because you trust your government?

            "if I told all my friends they have to learn and implement PGP if they want to email me the latest joke or get my latest musings about where to go for dinner, I'm pretty sure my mailbox will be suddenly barren"

            You say that like it's a bad thing.

            "As for data encryption, well I don't see that my personal data is worth it."

            But each person places a different value on their data. Also: you're presuming in this statement that "the man" isn't simply on a fishing expedition looking for reasons to throw people into the fire.

            As Cardinal Richelieu said: “give me six lines written by the hand of the most honest man, and I’ll find something in them to hang him by.”

            Better safe than sorry, mate.

            "I have firewalls and AV that have protected it up to now, if The Man wants to see it, not much I'll do will keep him from it for long."

            That's a completely wrongheaded approach to this problem. You are absolutely correct in that you have no ability to keep a dedicated state-level actor out of your data. At the end of the day they can deploy physical assets to tap your data and at that point you're right fucked.

            But the point here isn't to prevent the MIB from sneaking into your house while you're out. It's to raise the cost of fishing expeditions and automated searches for dissidence so high that they become non-feasible for state-level actors to engage in. Or, at least, that they go burn some other witch instead of you.

            You're not going to stop 007. But you might stop the local council from abusing their access to meta-ECHELON and using the fact that you put out one too many bags of garbage to hit you up with a fine.

            Or maybe you engaged in some "extreme" rumpy pumpy in front of a window with the blinds open. It's bad enough the local puritans in power could probably throw you in the brig for a lifetime. Why give them the power to slap you with an "internet pedo child molester" lifetime tatoo because you also happened to be streaming it to likeminded folks elsewhere?

            I've accidentally been e-mailed XLS dumps containing the entire customer records database for a company, including tens of thousands of credit card numbers*. In how many jurisdictions could I be burned as the witch simply for being the recipient? I can think of three off the top of my head, and that's three too many!

            By raising the bar for automated snooping by state actors I am raising the cost of automated witch hunts. As someone who qualifies as a witch to oh, so many groups, I'm very interested in keeping their costs as high as humanly possible.

            *fortunately I was the only one who got this mail, and it never left the corporate firewall so we were able to deal with it internally, but still...

        2. Jonathan Richards 1

          Re: a nice try....

          @Trevor_Pott

          I think you might not have recalled my first line at the moment you replied. I said it's all about threats and proportionate measures. What phil had suggested was ditching all closed source operating systems, and I was just pointing out that the mere act of ditching was not enough. In that instance you're only transferring your blind trust from a commercial entity to an open source community. Indeed, I know which of those I'm more likely to invest my trust in: I exclusively use Linux for my computing OSes. I attended and chaired enough security working groups to be immune to charges of naïveté, and what one learns is that some systems and channels are more threatened than others, and the measures one deploys have to be proportionate to the probability and impact of the risk.

          1. Trevor_Pott Gold badge

            Re: a nice try....

            "and the measures one deploys have to be proportionate to the probability and impact of the risk."

            The impact of the risk is going to jail for something irrelevant or that you didn't even do because the government has a new automated witch hunt. And the probability increases with every day.

            I'm sorry mate, but I can't agree with your take. You still seem to believe that anyone out there should consider themselves below some threshold where they shouldn't have to worry about state actors. I say you can't be more wrong. That whole argument is based on the faulty premise "if you have nothing to hide you have nothing to fear."

            Well sorry to burst your bubble, but if you have nothing to hide you still have everything to fear. We've automated witch hunts int he 21st century. And nobody is safe. Not one single fucking person.

            So your only hope of survival as a free/libre individual is to raise the barrier to running you to ground high enough that they target some other poor slob instead.

      2. Destroy All Monsters Silver badge
        Holmes

        Re: a nice try....

        With a compiler you can trust

        This ancient wisdom has been replaced:

        Countering "Trusting Trust"

        "You do have to trust a compiler, but you don't have to know beforehand which one you must trust. If you have the source code for compiler T, you can test it against compiler A. Basically, you still have to have at least one executable compiler you trust. But you don't have to know which one you should start trusting."

        1. Anonymous Coward
          Anonymous Coward

          Re: a nice try....

          There seems (imo) to be a big hole in that discussion.

          The whole thing seems to be dependent on an unjustified (and demonstrably incorrect) assumption: that two functionally equivalent programs produced from the same source by two different compilers will (always?) have bit for bit identical executable code.

          I don't know what planet the supporters of this assumption are on, but it seems extremely dubious to many of the respondents on Schneier's website, and I would agree with them (not that my word counts for much - but readers with a bit of knowledge about compilers will realise that two functionally equivalent programs do not have to be bit for bit identical).

          I'm not sure where that leaves Countering Trusting Trust.

          1. Charles 9 Silver badge

            Re: a nice try....

            "The whole thing seems to be dependent on an unjustified (and demonstrably incorrect) assumption: that two functionally equivalent programs produced from the same source by two different compilers will (always?) have bit for bit identical executable code."

            They get around this by making the two different compilers compile a third one. No matter the result, as long as the third compiler acts deterministically, then when you compile the third compiler using the results of your first two compiles (both of which should be functioning identically since both were built from the same source), then the end result should be two identical compilers. If not, either (a) the third compiler is nondeterministic, or (b) one or both of the first two were tainted.

            1. Michael Wojcik Silver badge

              Re: a nice try....

              If not, either (a) the third compiler is nondeterministic, or (b) one or both of the first two were tainted.

              That assumption is still too strong, since many compilers operate on input beyond the source, and the toolchain required to build an executable often involves more than just a compiler. Compilers and other build tools may embed timestamps, for example. They may need to embed references to libraries and other data that's outside both the compiler's control and the application source corpus.

              That means you're faced with either stripping down the tools to reduce those inputs, and/or accounting for the differences in the output as originating from those inputs and innocuous. Either way, the protocol as described is insufficient in the general sense.

              And, of course, vetting the compiler only means an attacker has to attack elsewhere. It prunes a branch off the attack tree; it doesn't underwrite "trust" in an absolute sense.

              All that said, it would be foolish to believe this case ought to be part of a functioning threat model for the vast majority of users. There are much better, cheaper attacks available.

              1. Charles 9 Silver badge

                Re: a nice try....

                "That assumption is still too strong, since many compilers operate on input beyond the source, and the toolchain required to build an executable often involves more than just a compiler. Compilers and other build tools may embed timestamps, for example. They may need to embed references to libraries and other data that's outside both the compiler's control and the application source corpus."

                Timestamps can be matched up, and the experiment assumes no external libraries (self-contained source) and considers any assemblers, linkers, etc. to be part of the self-contained suite. gcc IIRC is self-contained in this regard.

  8. Will Godfrey Silver badge
    Thumb Up

    Good Start

    ... but only a start.

  9. keithpeter Silver badge
    Windows

    Horses for courses

    "Consider who you're trying to keep secrets from when deciding how much extra effort to go to."

    Yup: the LUKS whole drive encryption as built into the Debian and CentOS installers (and others I'm sure) will keep the offline saved copies of my emails about students away from the prying eyes of any petty thief who pinches my old laptop (or the civilian that finds it on the bus after I've had a Senior moment). Email is sent/received ssh/tls as direct snooping about Jemima's dental appointment and Enid's childcare problems probably not happening.

    I might look at Truecrypt or similar for USB stick encrypting (read/write on windows and linux). Other suggestions welcome. 'Prying eyes' level only.

    PS: Duncan Campbell was a hero when I was a (lot) younger.

    1. Anonymous Coward
      Anonymous Coward

      Re: Horses for courses

      So ROT13 is fine to stop Big Sis' from reading my diary then?

      1. Charles 9 Silver badge

        Re: Horses for courses

        Maybe not ROT13 but perhaps something just a touch more difficult like an unpatterned substitution cypher (ROT13 is patterned). I once had fun playing with a cypher based on a #, and X, and a dot. If Big Sis is a bit smarter, perhaps something a bit more elaborate to mask spaces and punctuation.

  10. Decade
    Mushroom

    Abandon SMTP

    We should just stop using protocols that are not secure by design. Encrypted email is hack after hack on top of SMTP, and it's just not realistic to expect anybody to use it correctly, consistently.

    The problem is that I don't know of any viable alternatives. Silent Text seems nice, but niche. Any viable solution needs to be free and open-source. I don't have time myself to make such a solution.

    As for the web of trust problem, I don't think normal people can make it work. The problem tends toward centralization. I like Moxie Marlinspike's idea of Trust Agility, with certificate authorities who work for you rather than for the services who want you to trust them enough to give them money. This is a social problem more than a technical problem.

    1. streaky

      Re: Abandon SMTP

      The problem isn't SMTP, the problem is the PGP implementations are clunky. How can one prove this? Mime crypto works seamlessly over SMTP if you trust the CAs not to start putting out bullshit certs to actors. As per the article it again depends on your foe but the point is the protocol isn't really the problem.

      1. Decade
        Childcatcher

        Re: Abandon SMTP

        I disagree. The problem is SMTP. It can transmit using TLS, but that is trivially removed by ISPs. The source and destination are completely clear to the mail service, and it turns out that the metadata are important. And encryption is something that takes additional effort to add, so nobody will do so without an IT department doing it for them.

        S/MIME is nice, within its limitations, but it just proves that SMTP email is flawed. As long as email is plaintext by default, the email clients don't sound off klaxons about it being insecure. Instead, security is represented by the addition of a small checkbox in the corner. Watch for the checkbox, or else your email is just silently in plaintext.

        You can install a CA-signed S/MIME certificate for free from StartCom. So nobody does so. And even if you get one, you can't install it in the default Android email client. Because plaintext is the default. We need a new protocol where encrypted and authenticated is the default.

        1. streaky

          Re: Abandon SMTP

          "It can transmit using TLS, but that is trivially removed by ISPs"

          I think you're wildly confusing technologies. They're not decrypting emails they're pulling out STARTTLS (because it's easy). You're literally confusing email encryption with server connection encryption. One you can do because you prevent it starting, the other you can't because it's y'know, encrypted client side.

          Not for nothing but the rest of what you you say is correct but again the problem isn't the protocol - everything that is needed from secure email is doable using protocol extensions rather than screwing around inventing a square wheel. It's perfectly possible for your server to tell you it should only be talked to with TLS via the protocol as it stands completely invisibly to the client.

          If you invent new protocols people won't use them they'll just send their data in the clear. Like I said the key is extending/improving the existing protocol to the point it's fit for purpose.

          To this end I've been writing a paper on the exact subject to cut out exactly the problem as you describe it - that email interception of metadata is too easy and how to deal with it; again (I really can't reiterate this enough) using extensions to the existing protocol and doing it transparently to for end users (I can't say how without a defensive patent but it is totally possible).

          1. streaky

            Re: Abandon SMTP

            Just to add to what I said here, the disabling of STARTTLS is fairly well covered by the extension RFC - the issue is avoidable with a secure client and/or server configuration:

            If the client receives the 454 response, the client must decide whether or not to continue the SMTP session. Such a decision is based on local policy. For instance, if TLS was being used for client authentication, the client might try to continue the session, in case the server allows it even with no authentication. However, if TLS was being negotiated for encryption, a client that gets a 454 response needs to decide whether to send the message anyway with no TLS encryption, whether to wait and try again later, or whether to give up and notify the sender of the error.

            [..]

            A SMTP server that is not publicly referenced may choose to require that the client perform a TLS negotiation before accepting any commands. In this case, the server SHOULD return the reply code:

            530 Must issue a STARTTLS command first

            The docs are pretty clear about what do if STARTTLS is dropped.

    2. Anonymous Coward
      Anonymous Coward

      Re: Abandon SMTP

      Set the wayback machine to the 1980s and see how X.400 looks as a concept. An email setup designed from the ground up to support authentication, anti-tamper, encryption, and so on. Even been proven to work, on battlefields and the like.

      Anything SMTP-based is, as you rightly observe, a band-aid on an elastoplast.

      "Any viable solution needs to be free and open-source. I don't have time myself to make such a solution."

      Same here. But like you and others, I'm convinced we need a far better starting point, architecturally, than SMTP and a host of un-integrated addons. Do we need something radically different? Probably. Is there any relevant prior art? Possibly.

      Gotta be worth a serious look, surely?

      1. Charles 9 Silver badge

        Re: Abandon SMTP

        "Set the wayback machine to the 1980s and see how X.400 looks as a concept. An email setup designed from the ground up to support authentication, anti-tamper, encryption, and so on. Even been proven to work, on battlefields and the like."

        Also as I recall proven to be a right mess. It's just plain too complex, as anyone who's had to untangle a misdelivered X.400 message can attest. You need a secure solution, yes, but it has to be a SIMPLE secure solution. Otherwise, you run into the wrong end of the secure-vs.-easy to use scale. In order for something to actually be practical, it has to be in the MIDDLE of the scale: BOTH secure AND easy to use--otherwise people either end-run around the encryption or it'll be full of holes.

        1. Anonymous Coward
          Anonymous Coward

          Re: Abandon SMTP

          "You need a secure solution, yes, but it has to be a SIMPLE secure solution"

          SIMPLE for who ? End users, presumably? All they need to see is an email client with a system behind it that works and is secure, what goes on behind it is Someone Else's Problem, and if the inner workings have to be complex vs SMTPetc (and they WILL be more complex than SMTPetc) why should the end user care.

          Is it not becoming clear that SMTP-oriented solutions cannot be both simple and secure, for anybody? It's architecturally impossible, because it wasn't intended for use in that way. And apart from anything else, simplicity and trustworthiness aren't typically found together in these circumstances.

          So if someone can come up with something that's simple for the end users, whilst possibly increasing the complexity (probably inevitably) for the email sysadmins, what's not to like?

          What are the lessons that X.400 and friends can bring to the table? Those who ignore history are doomed to repeat it, etc.

      2. Michael Wojcik Silver badge

        Re: Abandon SMTP

        X.400 was an attack. Its damage was contained, fortunately, but we're still suffering from LDAP.

  11. David Roberts

    Asymetric key?

    I may be well out of date now but I thought asymetric key cryptography was slow and relatively vulnerable if used with large amounts of data.

    Isn't it mainly used for the secure exchange of one time symetrical keys which are used for bulk encryption?

    1. Matt Fowler

      Re: Asymetric key?

      David:

      That's exactly what PGP does - a single-use symmetric key is generated, used to encrypt the message itself, then that symmetric key is encrypted with the Public Key cipher and bundled up. It's called a hybrid cryptosystem.

      If you PGP-encrypt something to multiple recipient public keys, multiple encrypted copies of the symmetric key are included - one per recipient.

  12. Jonathan Richards 1
    Go

    SecureDrop

    I realise this is part 1 of n, so I hope that later there will be some discussion of SecureDrop, the successor to Aaron Swartz's DeadDrop, which is intended to mediate secure anonymous communications between whistleblowers (leakers, depending on your POV) and journalistic enterprises.

  13. Scroticus Canis
    Windows

    Oh a Windows only article, how interesting - NOT.

    An article that only considers security options for Windows based systems is hardly "up there" is it. Isn't Windows security an oxymoron of note?

    1. Anonymous Coward
      Anonymous Coward

      Re: Oh a Windows only article, how interesting - NOT.

      You should know TrueCrypt is multi-platform. And there are multiple PGP/GPG implementations for multiple platforms. The only Windows-only software mentioned is Skype...in the negative.

      PS. If you're on Linux, subsitute "/tmp" for "C:\Windows\Temp"

      1. Paul Crawford Silver badge

        Re: Oh a Windows only article, how interesting - NOT.

        Don't forget the swap space on any OS...

  14. handleoclast
    Thumb Down

    Truecrypt is a threat

    The problem with truecrypt is, and has been for at least 6 years (when I first took a look at it) that it supports hidden volumes. Sounds wonderful. If you're doing something very bad, you use a hidden volume. With just the ordinary pw you see the ordinary volume. Use a second pw and you see the hidden volume (if there is one). Wonderful! Except...

    As the documentation says, your adversary cannot prove that you're using a hidden volume, even if you are. What the documentation doesn't say is that you cannot prove that you're not using a hidden volume even if you're not. Throw in the law regarding handing over the encryption keys and you can go to prison for life.

    The police can require you to hand over your encryption keys. Fair enough, you give them the key to the ordinary volume. Then they ask for the key to the hidden volume. Which you don't have because you're not a bad guy so you're not using one. But the bad guys say that too, so the police insist. You repeat that you're not using one so you can't hand over the key. Six months (or 3 months, or whatever) in prison. Upon release they ask you for the key to the hidden volume. You repeat that you weren't using one. Back to prison you go, with no way of breaking out of the loop.

    All that was bad enough, but at least you could cover yourself by using a hidden volume even if you weren't doing anything dodgy enough to need one. The docs did NOT warn you to do that, no did occasional appeals by various people in the forums to document it achieve anything. A couple of years ago I checked again - still no warning that you MUST use a hidden volume to be safe. Plus now there's a patch, not supported by the developers but advertised on the site to have hidden volumes inside hidden volumes to any arbitrary depth. At that point no sane person would ever use truecrypt because plod will insist you have the patched version on a thumb drive and however many depths of key you give them they will insist there is one more.

    I repeat, for the hard-of-thinking, use truecrypt and you are at risk of spending a lifetime in prison.

    1. Charles 9 Silver badge

      Re: Truecrypt is a threat

      That may be true in Britan, but people in America are protected by the Fifth Amendment, where one has the right to remain silent and not self-incriminate. Even if compelled to speak by subpoena, one may simply answer, "I plea the Fifth." Not even Congress could get around that answer, not even during the famous Red Scare.

    2. This post has been deleted by its author

      1. Charles 9 Silver badge

        Re: Truecrypt is a threat

        "The prosecution have to prove on the balance of probabilities that you have not handed over the keys..."

        The argument is that TrueCrypt has deniable encryption. And the plods are well aware of TrueCrypt's ability to house a hidden volume. Which means, unless the outer volume is full (which prevents the creation of a hidden volume), you could be hiding something and you're lying (which is what anyone with something to hide would do). There's your balance of probabilities right there.

        "Also, the penalty isn't life imprisonment, but that's a side issue."

        It's an "infinite loop" punishment. Each time you refuse, you get thrown in jail and the encrypted volume is still there, unopened, meaning the moment you get out they can just ask you again, ad infinitum.

      2. Ben Tasker Silver badge

        Re: Truecrypt is a threat

        > Also, the penalty isn't life imprisonment, but that's a side issue.

        No, but the 'crime' is viewed as contempt of court (the Judge has asked you to hand over the keys and you said No), so you can be asked again and when you say 'No' you do some more time.

        Although you'd obviously hope some level of reasonableness would kick in, there's no limit to how many times you can be told to hand over the keys and then do a stretch for refusing, so it could, in theory, be used to lock you up for life.

        People have done short stretches for failing to hand over keys, though don't think there's ever been any cases of being locked up for failing to provide the key to a hidden volume that doesn't actually exist.

        1. Eugene Crosser

          Re: Truecrypt is a threat

          I am not sure how this kind of possibility is realized in real life (and IANAL), but surely, even if you don't have TrueCrypt in plain view, a prosecutor can argue that you have data steganographically hidden in your holiday photos (or free sectors on the disk) and demand that you decrypt it. There is no difference in the possibility of a hidden truecrypt volume and the possibility of secrets hidden in plain view without truecrypt.

          1. Ben Tasker Silver badge

            Re: Truecrypt is a threat

            @Eugene

            Whilst they could claim stego, they've still got to convince a court;

            Hes got a blob of random data which is unusable for anything, so we believe its an encrypted container.

            Vs

            This picture of his wife in a bikini can only be an image containing encrypted data, why else would he keep _that_.

            1. Eugene Crosser

              Re: Truecrypt is a threat

              @Ben

              I am not familiar with truecrypt, but I assume that it does not let an observer see "a blob of random data" precisely because it would be pretty convincing evidence of "hidden volume". If my assumption is true, then the mere fact that truecrypt can have hidden volume is no better proof than the fact that a bikini picture can have hidden information.

              1. Ben Tasker Silver badge

                Re: Truecrypt is a threat

                @Eugene

                > I am not familiar with truecrypt, but I assume that it does not let an observer see "a blob of random data" precisely because it would be pretty convincing evidence of "hidden volume".

                The outer container is a blob of random data, at least in appearance. Once you've decrypted the outer container, there isn't a second random blob, no.

                However, unlike with your Picture example, the very existence of the outer container demonstrates that you _are_ using crypto. It's not proof of a hidden container, but the fact you've used technology capable of it will likely be used against you.

                Part of it would likely come down to what you had stored within the outer container, if the fuzz suspect you of something henious (let's say terrorism) and you provide the key on request to reveal a bunch of fairly uninteresting emails, they'll likely try to claim it's a decoy.

                They can't prove it is, you can't prove it isn't, but the burden here isn't reasonable doubt, it's balance of probabilities. So if they can use your use of crypto and the technical capabilities of Truecrypt in front of a technically inept judge, it's not improbable that you could be on the losing end.

                On the other hand, I disagree with the OP almost entirely anyway. He's right to warn about using Truecrypt, but wrong in his reasoning. It has nothing to do with the existence of hidden containers, and everything to do with the fact the developers have _very_ publicly walked away, and whilst doing so have declared it insecure.

                The software is no longer supported, and the reasons for the developers stopping are not known. Unless it is bikini pictures you're planning on encrypting, using Truecrypt now is a bad idea, because it brings far too many unknowns with it

                1. Anonymous Coward
                  Anonymous Coward

                  Re: Truecrypt is a threat

                  Forgive me if someone has already pointed this out... and in the case of point one they have.

                  1) you can prove there is no hidden volume by keeping the main volume full. This prevents both the creation of a hidden volume and the storage of a meaningful data if one exists already.

                  2) actually create a hidden volume but don't use it, and when challenged hand over both the keys (main & hidden).

                  The hidden volume is empty, can be seen to be empty.

                  Obviously this does nothing for your privacy, but at least you don't go to prison forever.

            2. Anonymous Coward
              Anonymous Coward

              Re: Where's Worstall?

              "Whilst they could claim stego, they've still got to convince a court;"

              I suspect they'll just plant evidence and convince the courts it was always there. Now what?

    3. Destroy All Monsters Silver badge
      Big Brother

      Re: Truecrypt is a threat

      I repeat, for the hard-of-thinking, use truecrypt and you are at risk of spending a lifetime in prison.

      If you have that kind of problem, the shit has already hit the fan. In short, you are at risk of spending a lifetime in prison anyway, and you better start making either:

      * target practice innawoods with high-power automatic weapons and "cop-killer" penetrators and/or

      * death's head-adorned uniform wearing

      one of your chosen career moves.

      Oh wait....

    4. Michael Wojcik Silver badge

      Re: Truecrypt is a threat

      I repeat, for the hard-of-thinking, use truecrypt and you are at risk of spending a lifetime in prison.

      Every time I think the Reg readers have come up with the most ridiculous threat model I'm likely to see today, they impress me with yet another contribution.

      It'd be just as easy for the prosecution to claim you're using deniable encryption you implemented yourself. It's a well-understood technique. Or that you have data hidden on some other device they haven't found yet, or "in the cloud", or whatever other spurious claims they might make. Why do you believe it'd be any easier to convince a jury of the existence of one magical goblin (as far as they're concerned) than of another?

      1. Ben Tasker Silver badge

        Re: Truecrypt is a threat

        @Michael - I largely agree with you, but its not a jury that needs convincing, it's a single judge. Whether that makes it better or worse probably depends on the judge.

        The reason it'd be easier is because they can ask for something specific with legislation to cover that request rather than a rather vague "we know you have it somewhere, tell us then give us the keys"

        Your defence to the claim of self-implemented crypto would have to be along the lines of "they seem to believe I'm intelligent enough to roll my own non-trivial crypto and yet also believe I'm stupid enough not to recognise what a bad idea that is".

        Not sure it's likely to hold up, but it's probably less likely to need to in any case. Technically the law does allow for the op's point so it should be considered a threat but the probability is probably about equal to that of the Mossad pawning your edge devices

  15. Anonymous Coward
    Anonymous Coward

    "On the other hand, I disagree with the OP almost entirely anyway. He's right to warn about using Truecrypt, but wrong in his reasoning. It has nothing to do with the existence of hidden containers, and everything to do with the fact the developers have _very_ publicly walked away, and whilst doing so have declared it insecure."

    You got any alternatives? Against anything else on offer, TrueCrypt still offers the best evidence of it being secure. It's being audited, which you can't say about the alternatives. And you HAVE to pick something against the government juggernaut.

    1. Ben Tasker Silver badge

      It is currently being audited, yes, so once that's complete it can probably be considered safer.

      By alternative it depends on what exactly you're after. If it's hidden volumes I've no suggestions. If it's simply encrypted containers (as opposed to FDE) then PGP and a loopback can work nicely.

      Ecryptfs gives a good level of protection if you're primarily bothered about stopping the bloke who stole your laptop from rifling your files.

      It all comes down to what your threat model is, amd what you're wanting to implement (and the OS you're using). I've got containers encrypted with 16k keys and I've also got others where 512 is considered enough.

      Once the audit has finished there's still the possibility of holes, but Truecrypt will be in a stronger position than now. In the meantime though, using crypto software that is unsupported and has publicly been declared insecure by the devs is a bad idea - you've got a potentially false sense of security and nothing more.

      1. Charles 9 Silver badge

        "Once the audit has finished there's still the possibility of holes, but Truecrypt will be in a stronger position than now. In the meantime though, using crypto software that is unsupported and has publicly been declared insecure by the devs is a bad idea - you've got a potentially false sense of security and nothing more."

        Except, like I said, there's nothing else on offer. As for the public declaration that it's insecure, best case, they're lying so as to look like a dead canary. Worst case, that simply puts it in the same boat as every other encryption software on the market for the simple reason that we don't know enough about the alternatives. The one thing that sets TrueCrypt apart is that audit. No other encryption software has been audited, and none has a formal proof. Which means, even after the declaration, it's STILL the best on offer in a world where no encryption is not an option. Put it this way, even a false sense of security is preferable to NO sense of security. The alternative is to go offline, which for many of us is not an option at all.

        PS. Before suggesting PGP/lo, consider users who can't use a loopback device. Many people have no choice but to use Windows on systems that lack the capacity to dual-boot or use a VM (like a netbook--nice for air travelers as anything bigger draws increased security scrutiny but not very powerful).

        1. Ben Tasker Silver badge

          Put it this way, even a false sense of security is preferable to NO sense of security.

          IMHO you're wrong on that.

          If you _know_ you've got no security, then you're naturally careful about what you store. If you believe you're secure, then you feel confident storing material that otherwise you might not.

          The one thing that sets TrueCrypt apart is that audit

          Once complete, yes, it very definitely will - and it is definitely looking good so far, but it's still early days so taking the results so far as proof that it's safe would be a bad idea.

          Before suggesting PGP/lo, consider users who can't use a loopback device.

          A fair point, but for those that it is an option it's not a bad solution.

          1. Charles 9 Silver badge

            "If you _know_ you've got no security, then you're naturally careful about what you store. If you believe you're secure, then you feel confident storing material that otherwise you might not."

            Like I said, if you have NO CHOICE but to store it, then you're basically SOL either way. In which case, it's best to have the security blanket than drive yourself insane with paranoia. Remember, this is as much about psychology as it is security (that's why ease of use and security can be on opposite ends of the same scale).

  16. Michael Wojcik Silver badge

    a rather distant relation, that

    a mathematically-related pair of really massive numbers

    I know this was just an off-the-cuff remark, but really, does this sort of thing help anyone? No, and particularly not in an ostensibly technical article.

    In the RSA scheme, the "pair of really massive numbers" are not "mathematically related" except that they're both primes, and they're multiplied together. Are 3 and 71 "mathematically related"?1

    Now perhaps you're not referring to the p and q parameters used in RSA key generation, but the actual public and private keys. But the RSA public key is itself a pair of numbers (public exponent e and modulus n), while the private key is, depending on how you look at it, either a single integer or a pair of them (private exponent d and modulus n again). So that doesn't fit the description either; you have a 3-tuple or 4-tuple of numbers, not a pair.

    DSA, the other asymmetric algorithm supported by OpenPGP, is an ElGamal discrete-log variant. Its public and private keys are indeed "related", and the private key is a single number, but the public key is a 4-tuple. For DSA key generation, there are three main values; these are "related", but the generator g is related to the others only in the sense of not belonging to the relatively smaller subset of unsuitable values.

    In short: tossing out informal descriptions of algorithms doesn't provide any useful information. It'll probably be misleading and it certainly won't help anyone use software based on those algorithms. Just don't do it. Explain the consequences of those algorithms and the protocols that build on them; don't toss out nonsensical commonplaces.

    1They're also not "really massive". No integer is "really massive" in an absolute sense, since the integers go all the way up to infinity. They can only be "really massive" relative to some other integer. But I'll ignore this one as simple puffery.

  17. Tail Up
    Holmes

    "And then Edward Snowden, Laura Poitras and Glenn Greenwald changed the world" - well, the grass was greener some time ago, but it scarcely does relate to these respectable names.

  18. Ramazan

    Local storage: Truecrypt

    There's a better option: http://en.wikipedia.org/wiki/DiskCryptor

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2022