Don’t know how that happened.
It's like they've got a mind of their own...
Assuming that the government is interested in you
And also assuming Keith's assumptions....
In this case, that the Police can get a search warrant and seize your computers and your devices, and upon discovery of an encrypted hard drive, can compel you to give up the password. It’s a VERY specific adversary. It’s not unlimited, it doesn’t involve rubber hosing or extraordinary rendition, or indefinite detention, or supercomputers brute forcing your shit, or the TAO using custom exploits to target whatever.
Against this specific threat, the measures I suggested would give you a comparable level of protection. I'm not advising this, just disputing the claim:
For journalists, obscurity is not an option.
The problem with OTPs is that their use requires an initial secure distribution channel, which really limits their use for communications between people who have never met.
Yes. but for people whom you have met, it's a not unreasonable system these days, considering how compactly we can store a huge key, and how secure it is. Also the algorithm is so simple that you can have a very high degree of certainty that it doesn't have a bug or exploit.
OTP is the only encyption system that's been mathematically proven to be unbreakable.
But how it's practical to encrypt a stash of documents is very questionable. You need a key as big as your document set - where are you going to keep it? If you bury a memory stick with it on in the garden, you could equally bury the documents in the garden (I suppose you could bury both in different gardens).
But how it’s practical to encrypt a stash of documents is very questionable. You need a key as big as your document set – where are you going to keep it? If you bury a memory stick with it on in the garden, you could equally bury the documents in the garden (I suppose you could bury both in different gardens).
It's for secure transmission, not storage.
Yup, and it’s not secret by definition if there are thousands of publicly available copies of it floating around. Hence, that is not a one-time-pad. That’s a thousands of times pad, and really insecure.
It is generally accepted that it is sufficient to keep secret the fact that something is being used as a key. It is not necessary to keep the existence of the thing secret in it's entirety. Of course if an adversary is aware that both parties have the same CD (or book or whatever) they would be very suspicious, so one or both parties should dissociate themselves from whatever they are using to source the key.
The "one-time" in OTP refers to single use which is one of the critical requirements of the system. It doesn't imply that the key must be destroyed. A bigger problem with using something like a CD is that a OTP really needs to be perfectly random.
If it doesn’t get the password of the hidden volume, it doesn’t know anything about it, and won’t necessarily avoid it. Presumably you have to mount the hidden volume when you’re using the system a lot, or you risk overwriting some of it.
That's correct. Truecrypt is unaware of the inner volume when accessing the outer volume unless you provide the inner volume key. It's not necessary to mount the inner volume as there is a mode which simply protects the sectors used by the inner volume.
BTW, the documentation is all online, we don't need to speculate about how it works.
If I were designing it, I’d make the hidden volume data go from the end of the data space backwards, and all the other data go from the front, forwards, so that such overwriting would be unlikely until both volumes together were nearing the partition capacity, in case you wanted to work for extended periods without mounting the hidden volume (say you thought you were being observed). In that case, the avoidance of the end would be automatic and normal for the system anyway, and no proof of anything.
If you're designing a system that will use existing filesystems you don't have the luxury of deciding which sectors the outer filesystem will decide to use. Aside from that, with your design, if there is a hidden volume that you're using then the data at end of the partition is going to change regardless of how full outer volume is. Thus changing data at the end of the partition is prima facie evidence of a hidden volume. As I said before, Truecrypt's hidden volumes are also not secure if an adversary has access to the outer volume at multiple points in time, but your system would make it particularly easy to detect the hidden volume.
The “one-time” in OTP refers to single use which is one of the critical requirements of the system.
I beg to differ. It refers specifically to the fact that pages of the pad were burned after one use. Not put in the bin, or scribbled on, or copied out a thousand times. The physical destruction of the key was built into the system, indeed it was why the key was on a pad with small pages, so that this could be done.
It is generally accepted that it is sufficient to keep secret the fact that something is being used as a key.
That may practically work, against a weak attacker, but it's not a one time pad.
Of course if an adversary is aware that both parties have the same CD (or book or whatever) they would be very suspicious, so one or both parties should dissociate themselves from whatever they are using to source the key.
There would be no reason at all to keep the CD or book. You'd extract the key from it, and keep only that, which is a far more convenient thing to have, not least because you can one-time as much of the key as you have in your possession. Then at least the obscurity part would be there. The attacker would have to find the original key to crack any intercepted communication, even if they got their hands on what was left of your key.
A bigger problem with using something like a CD is that a OTP really needs to be perfectly random.
That is a problem. A sneakier trick I read in an encryption book some time ago is to rip the CD and alter the LSB to be your random key string. The music will still sound the same. But this is only useful during the transport of the key, if it is believed that you may be intercepted and taken to task for carrying a key. This book hailed from the days, not so long ago, when moving encryption stuff around was technically illegal across a lot of borders.
If you are actually physically in contact with the intended recipient, you might as well just give them a key in convenient form.
Or stick to PGP, it's simpler and if you're trying to protect against people who can break it, then good luck, see you in another life.
If you’re designing a system that will use existing filesystems you don’t have the luxury of deciding which sectors the outer filesystem will decide to use.
No, but I'm in complete control of the organization of the virtual sectors within the system.
Aside from that, with your design, if there is a hidden volume that you’re using then the data at end of the partition is going to change regardless of how full outer volume is. Thus changing data at the end of the partition is prima facie evidence of a hidden volume.
If I'm using the data, then I'm logged into the volume and its existence is not even in question. Do you mean "if someone could take a secret snapshot before and after"? Or are you referring to the outer file system's timestamping?
It’s not necessary to mount the inner volume as there is a mode which simply protects the sectors used by the inner volume.
Which is pretty much evidence for the existence of the inner volume, and its upper size limit, which is why I suggested the way I'd do it. There's further tweaks possible, to get around the outer file system noting when the last sector access was, depending on the OS you're on.
an unhealthy Obamanation...
I thought this sounded interesting - Obamacare computer code riddled with typos, Latin filler text, desperate programmer comments and disastrous architecture - especially if they have ground the country to a halt, partly to implement something that has been rushed into use before it is ready...
Was Healthcare.gov designed to fail?
It's almost as if the entire system has been designed to fail. There is no rational justification for writing code like this. It's like someone held a contest to find out "who can write the most inefficient, wasteful computer code" and Healthcare.gov won the top prize!
hmmm, sounds familiar...
In case you weren't aware, TrueCrypt is no longer recommended by its own developers. They recommend using the built-in functionality in Windows and OSX instead.
WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues
This page exists only to help migrate existing data encrypted by TrueCrypt.
The development of TrueCrypt was ended in 5/2014 after Microsoft terminated support of Windows XP. Windows 8/7/Vista and later offer integrated support for encrypted disks and virtual disk images. Such integrated support is also available on other platforms (click here for more information). You should migrate any data encrypted by TrueCrypt to encrypted disks or virtual disk images supported on your platform.
They recommend using the built-in functionality in Windows and OSX instead.
That's annoying. The problem is less that the USA can break both of those, as that the techniques they use might be accessible to others. There doesn't seem to be a similar cross-platform FOSS solution just yet but I'm going to have to find one. Bugger!
I heard they were hacked and that message may be bogus.
If not, the source code is available, so I imagine others will take up development and patching.
Apart from any suspicion of closed source crypto, the built in encryption on Windows/OSX is awkward to use and doesn't have the hidden volume feature.
I heard they were hacked and that message may be bogus.
Honestly, who knows!
Good discussion on ArsTechnica
This rather strange Github repo has all the pre-takedown Truecrypt source and binaries:
(Strange because having one branch with all the files alongside in zips is an unusual use of Github. It would be useful to unzip these files into a conventional git repo. I could do this, but I think I'd use a burner account to do so).
for a repo of 7.1a (which apparently hasn't been touched for a year).
There's a fork of TrueCrypt for Linux called RealCrypt, but I'm not sure how maintained it is. A co-worker who mostly uses linux is excited to have found it: http://wiki.mandriva.com/en/RealCrypt and some notes/links on installing http://www.robotgoblin.co.uk/blog/2011/12/15/encryption/