Comment by beezle | Hacker News Reader

Comment by beezle | Hacker News Reader

Parent Full thread

A few points -

Devils advocate, travel back to the 1950s. The government searches your home and takes a letter or other document that is clearly written in code. Can/would they jail you as in the current case until you decode it? And without even charging you with any other crime first?

At what point is "I used a one time pad" or "I don'remember" sufficient? I'm sure all of us have at least once (probably many) times forgotten a password, even for something relatively important.

The 'lock' interpretation also fails. It is obfuscation, they have executed their search warrant and they possess the obfuscated data. Can they force you to translate your documents written in some obscure language because they can find nobody else willing to do so for them?

Re: Orin Kerr - his argument fails as the government can execute their own search warrant to take documents they believe you to have - they need not rely upon you to voluntarily provide them at their request.

This reminds me of Les Earnest's story (http://web.stanford.edu/~learnest/les/crypto.htm) about being investigated for espionage as a teenager during WWII.

> I remember hearing that a local grocer was secretly a Colonel in the Japanese Army and had hidden his uniform in the back of his store. A lot of people actually believed such things.

Some things never change.

That was a quite good read, thanks!

Following from this, if perfect encryption leaves a ciphertext indistinguishable from random noise, then what proof does the court expect that a given decryption is the correct decryption?

If he were to hand them an elaborately constructed fake file system, who would they be to say those weren't the encrypted contents?

(For purposes of thought exercise, mooting arguments about headers / magic fingerprints / leaky metadata)

A possibly-related topic: https://en.wikipedia.org/wiki/Deniable_encryption

How can they even be sure that the decrypted message is the real one? I assume currently they're just using human heuristics (i.e. I know it when I see it) to tell if the decrypted data is actually valid?

TrueCrypt let you encrypt your drive in a "plausibly deniable" way. One password would let you see the encrypted contents as would expect, but there was also a sort of duress password. If you mounted the drive with the second password, you would not see files added with the "true" password. You could even add files to this file system so it looked like a fully functioning file system.

How would the authorities know you have given them the correct password?

I'm not sure how effective it was, I remember there being some criticism of it.

It's not that effective against clued-up forensics, I'm pretty sure I've read of cases where prosecution successfully detected TC volumes. It does however deal with garden-variety "gun to the head" scenarios.

There are several ways to utilise TrueCrypt to truly hide data. The issue is "operational security", not the tool you use. You need to think about how the data is stored, what it will look like whilst encrypted, how will you handle that under questioning. "yes my drive is fully encrypted, get stuffed" will not suffice. It'd be nice, but the reality is that you will be required to bow down in digital obeyance to the court/man/gov

You could perfectly encrypt a hard drive such that it could decrypt to anything, but the "key" (a one-time pad) would be as big as the drive itself. All real-world crypto software uses short keys, which are just big enough that it's impossible to brute-force guess them. In general for a given encrypted drive, there is probably no other key besides the real one that would produce meaningful looking output, because the space of all possible outputs is so much larger than the space of all possible keys.

It is like splitting drive to two (interleved sectors for example) and encrypt odd sectors with key1 and evens with key2. And software can try key in first 2 sectors to figure out odds or evens to use.

If software gives you an option to use 2 keys or 1 key in the beginning ( so half data will be garbage ) you can always deny you have 2 keys

I get the one time pad size argument (as well as the analog that a shorter key is therefore a hashing function in some respect?).

The thing I found curious though is that the legal argument seems to depend not on providing your encryption key (which is generally assumed to be protected), but the act of decryption.

In the absence of the key, any plaintext produced from a ciphertext is... questionable?

Reply on news.ycombinator.com