The crux of the dispute here is whether the Government sought “testimony” within the meaning of the Fifth Amendment. The Government claims that it did not, that all it wanted Doe to do was merely to hand over pre-existing and voluntarily created files, not to testify. See United States v. Hubbell, 530 U.S. 27, 35–36, 120 S. Ct. 2037, 2043, 147 L. Ed. 2d 24 (2000) (noting that it is a “settled proposition that a person may be required to produce specific documents even though they contain incriminating assertions of fact or belief because the creation of those documents was not ‘compelled’ within the meaning of the privilege”). We agree—the files, if there are any at all in the hidden portions of the hard drives, are not themselves testimonial.Yes, it would, held the court, upholding the invocation of privilege. Comments at Prof. Kerr's post credit the op with being one of the rare ones to exhibit understanding of how encryption works—TBA will defer to anonymous professions of expertise on this subject.
Whether the drives’ contents are testimonial, however, is not the issue. What is at issue is whether the act of production may have some testimonial quality sufficient to trigger Fifth Amendment protection when the production explicitly or implicitly conveys some statement of fact. See Fisher v. United States, 425 U.S. 391, 410, 96 S. Ct. 1569, 1581, 48 L. Ed. 2d 39 (1976) (“The act of producing evidence in response to a subpoena nevertheless has communicative aspects of its own, wholly aside from the contents of the papers produced.”). Thus, we focus on whether Doe’s act of decryption and production would have been testimonial.
The op has the incidential function of being a pretty amazing advertisement for TrueCrypt, the software in question. "Endorsed by the 11th Circuit Court of Appeals"?
Slashdot reported one recently that went the opposite direction, via:
ReplyDeletehttp://news.cnet.com/8301-31921_3-57364330-281/judge-americans-can-be-forced-to-decrypt-their-laptops/
As a techie, I'm sure I'll be castigated for this one, but how does this work legally in the "real world"? Assume the government wants to see something I have locked in an impenetrable safe. Could I be forced to produce the key, or would that violate my rights under the 5th? What if it's a combination safe? What if part of the encryption is a key generator fob?
I don't know if these have ever come up, since to date the government has pretty much been able to get into whatever it wanted to get into whether you cooperated or not - that seems to be what has changed. But has anyone examined it in theory?
The op actually explains some of that. You can be forced to turn over a key, but not a combination.
ReplyDeleteI wondered at the VC thread about a key on a flash drive, but no answer.
But it turns out that the 64-character password that TrueCrypt allows can probably resist a brute-force attack for a few hundred years.
The Fricosu case you linked to is also distinguished by the 11th Circuit: there, the feds had independent evidence of what was on the computer, which is materially different from just guessing that there might be something on there.
Since you're a "techie," I'd advise reading the 11th Circuit op and thereby impressing your friends.
Well, I asked you to avoid having to read the op ;) I can stare at thousand-line blocks of source code all day, but trying to read a legal judgement makes my head hurt. I'll stick to impressing them with my voluminous knowledge of Star Wars trivia.
ReplyDeleteI have to admit, the distinction between a key and a combination strikes me as very odd. In the abstract it seems to produce the same end result - the government gains access by compelling me to do something I don't wish to. But even ignoring result, it seems that the key scenario is only an extra step removed but should end up at the same place. If the combination is a knowledge-based piece of security which cannot be compelled, why is the location of the key different? Is it just a matter of being proximate to the data - the encryption key allows direct access to the data, while the knowledge of a physical key's location only actually provides the key and not the information itself?
From a security standpoint, there are three factors of authentication: Something you have, something you know, and something you are (biometric). This is essentially saying the government can compel you on two of them - something you have, something you are - but not something you know. That inconsistency bothers me. Your question is also much more relevant than you may realize - the keys for public key cryptography are too big to remember (typically around 4096 or 8192 digits) so you have to store them on something like a flash drive. If you can be forced to turn it over because it's physical, it renders a whole swath of crpyography methods useless.
I truly, honestly don't know which side I come down on yet. More than anything, I think we're still a long way from figuring out how to adapt to this stuff.
And to return the favor on the knowledge exchange: the protection of the 64 character key is largely illusionary. If it's a true 64 character random password, yes, a brute force attack would be that bad. But 64 characters is probably too much to reasonably remember, which means that people will resort to something like a phrase or sentence, or some trick or pattern (ex: each character is keyboard-adjacent to the previous, so an f would be followed by one of ertdgcv). Any of this would reduce the state space dramatically. True brute-force attacks are really never used - even 8-character randoms are too much to guess in any reasonable time period. Intelligent, guided combinatorial attacks are much more effective, and they rely on the effective state space of the key, not just the bare character count.
Re: a physical key, try this (all quotes from the op) (which really is pretty readable btw):
ReplyDeleteSee United States v. Hubbell, 530 U.S. 27, 35–36, 120 S. Ct. 2037, 2043, 147 L. Ed. 2d 24 (2000) (noting that it is a “settled proposition that a person may be required to produce specific documents even though they contain incriminating assertions of fact or belief because the creation of those documents was not ‘compelled’ within the meaning of the privilege”).
Same logic seems to apply to a key. The location of the documents is not itself "incriminating," even if their content is.
As to the distinction you find inconsistent, it really boils down to the privilege's root in testimony. You can't be made to testify against yourself. (Which of course, before torture was outlawed, was pretty much how any crime was solved.)
Drawing out the key principles from the Court’s two decisions, an act of production can be testimonial when that act conveys some explicit or implicit statement of fact that certain materials exist, are in the subpoenaed individual’s possession or control, or are authentic. See id. at 36 & n.19, 120 S. Ct. at 2043 & n.19. The touchstone of whether an act of production is testimonial is whether the government compels the individual to use “the contents of his own mind” to explicitly or implicitly communicate some statement of fact.
Here's the analogy to the physical key:
Put another way, the Court has marked out two ways in which an act of production is not testimonial. First, the Fifth Amendment privilege is not triggered where the Government merely compels some physical act, i.e. where the individual is not called upon to make use of the contents of his or her mind. The most famous example is the key to the lock of a strongbox containing documents ..., but the Court has also used this rationale in a variety of other contexts.
Then there's the "foregone conclusion" doctrine:
an act of production is not testimonial—even if the act conveys a fact regarding the existence or location, possession, or authenticity of the subpoenaed materials—if the Government can show with “reasonable particularity” that, at the time it sought to compel the act of production, it already knew of the materials, thereby making any testimonial aspect a “foregone conclusion.”That latter is what distinguishes the existing district-court cases: the feds knew what the password was protecting.
Clear as mud?
... Thanks for explaining re: the passwords. The only way I could remember 64 characters would be to use the first letters of words in a relatively obscure passage of poetry. I suppose even that would trigger some pattern recognition (I noticed, trying this out today, that "out of the" = OOT = a likely clue). But it would still work pretty well for most purposes, I guess.
What is a "combinatorial attack"? Use of clues to narrow down the scope ("state space"?) of the password?
Also, the more I think about it, the more I can't distinguish a key kept in a laptop drive or flash drive from a physical key or a "document."
ReplyDeleteSo yes, legally, there may be quite a bit of danger in using such a huge key. You'd basically have to plead ignorance or say your dog ate it, and then very likely sit in jail for contempt until the court decided you weren't kidding.
Better perhaps to generate your 64-character random key and then compose a mnemonic to help you remember it. Good luck with that, folks. Except you child-porn people: I do not wish you luck.
Wouldn't it be possible to create an encryption program with two encryption keys. If one was entered it would un-encrypt all the documents on the computer. If the other was entered it would create myriad documents pointing to the honesty and integrity of the computer owner; you know, letters to his pastor urging prayers for the sick and so forth.
ReplyDeleteSorry for the late response - it was a busy weekend :) Thanks very much for the explanation. It still feels a little inconsistent to me, but as you point out that's probably because I'm looking at the larger issue of self-incriminating acts rather than simple testimony. But at least now I know what the distinction is :)
ReplyDeleteOn the terms: "state space" is a general terms for the number of possibilities in a problem. "Combinatorial attack" is probably not a strict security term, but it's how I describe an attack that functions by creating and testing all possible combinations for a password/key. In its simplest, this is a raw brute force effort - "aaa", "aab", "aac", etc. Those are horribly inefficient because the number of possible combinations explodes quickly. Whenever you hear someone bragging about how long it takes to crack their big password, this is what they mean. 8 random alphanumeric characters is still pretty good, but tech advances (especially in graphics cards, which are great for math-based stuff like encryption) are closing in on it. Still, it's mostly an academic difference - for an 8 character password of upper case/lower case/numbers testing a million possibilities a second, it'll take up to 7 years to crack. Include special characters (!@#? and so on), which add another 30 or so possible characters, and it's 4700 years or so.
But that's where the "guided, intelligent" combinations come in. Nobody actually uses brute force other than to brag about how big their key is ;) Realistically, 7 years is still a very long time. So, we use what we know about the way people think and make passwords to try and get at it faster. Some examples: weight common letters first to test them earlier rather than just going a-z, dictionary attacks that look for words, use knowledge about the person (family names, b-days, etc), sentences... You'd think using a long sentence might be the way to go, but even with a 30 or 40 character sentence there are only about as many possibilities as there are with a 5-character random password. Your idea of the acronym'ed poem is actually pretty decent, assuming you get it out to 30 or so characters.
So, long "I like computer security" rambling aside, here's the upshot: Use a password that's 8 characters long, as random as you can make it and includes upper case, lower case, symbols and numbers, and avoid obvious tricks (combining names/dates, @ for a, etc). Especially these days, you'll have far more to worry about from viruses, social engineering, and keyloggers than you will anyone cracking it. Most passwords are stolen or deduced by using social engineering to seriously constrain the possibilities.
And, finally...
Col Reb: Theoretically possible, but encryption algorithms are well known, and there are only a few of them. I don't need to run your encryption program to decrypt your drive, so any safety net there - whether it professes your innocence or just wipes the drive - will never be activated.
Thanks, Buhallin! Free tech advice, worth considerably more than I paid for it!
ReplyDelete