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 …
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.
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.
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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
@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.
> 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.
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.
"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...
@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.
"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.
With a compiler you can trust
This ancient wisdom has been replaced:
"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."
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.
"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.
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.
"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.
"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.
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.
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.
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.
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.
"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).
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.
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?
"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.
"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.
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.
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.
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"
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
