New Argument in Forced-Decryption Case: Defendant’s Memory Is Ticking Clock | Hacker News Reader

New Argument in Forced-Decryption Case: Defendant’s Memory Is Ticking Clock

wired.com

20 pointstlrobinson26 comments

Oh dear. It would appear that his defence lawyer doesn't really understand encryption at all, and is unfortunately likely to use specious arguments as a result.

“Some encryption effects erasure of the encrypted data (so it ceases to exist), in which case decryption constitutes re-creation of the data, rather than simply unlocking still-existing data,” Shellow wrote in a court filing.

I can't think of any way of interpreting this to make it true.

Encrypt a message with a one time pad and destroy all copies of the original message. You can literally "decrypt" the ciphertext into anything that matches the same length. The only way to recover the message is to know what the pad was.

I am not sure how well the idea translates down to more practical forms of encryption though, but I can understand the idea in the case of perfect encryption -- you can just make up a different one time pad and decrypt the data to whatever you want it to show, and there is no way to prove if it is really what was originally encrypted.

Edit: I meant to point out that this is in the "what color are my bits?" sense; multiple pieces of data can be "encrypted" to the same result differing only in the "key" (one time pad) used to "decrypt" it. There is no true message in the "encrypted" block without interpreting it in terms of a specific key; how you made the encrypted data tints your bits to the "proper" decryption. It's not a property of the block of data itself.

If the data can be reconstituted meaningfully - i.e. the term "decryption" refers to more than simply making up data, such as the application of a specific one-time-pad or any other method that recovers the original message - then by definition it was not destroyed.

It's a bit ambiguous what it means to erase an abstract entity like "data". Usually, I would accept it to mean that there are no physical copies of the plain text remaining -- e.g. no copies in terms of bits on a hard disk or strokes of ink on paper. If you've overwritten the sole copy of the original plain text with the ciphertext on a hard disk, then I think it's fair to accept that as erasure of the original data.

Philosophically, of course, all strings of data that will ever be written exist in some abstract mathematical sense -- I can write a program that will eventually generate every single combination of bits that can be ever be stored on a given computer (should you care to wait long enough) including novels that don't exist yet (in the conventional sense that a human author hasn't put pen to paper), and the plaintext that was overwritten by the cryptography program.

“The Court can reduce this risk by requiring Feldman to provide the Court with the decrypted contents of his hard drives now, ex parte and under seal, so that they can be securely retained pending the adjudication of the Fifth-Amendment question.”

Am I the only one who does not believe they would honor the 'Fifth Amendment adjudication' and that they would not seek new and different evidence for new and different crimes?

Depends on the judge and how good he is in resisting political pressure.

But here is the thing. Producing the content is self incrimination according to the defense (and reasonable people worldwide). So the situation becomes - admit you are guilty and hope higher court lets you off the hook while your name is trashed anyway.

Is there an encryption method that renders my password only valid for <frame>? And I am only able to set a new password and reset <frame> when authenticated? That is, if I do not authenticate and reset in time, the volume has no known password? Unlike a dead man's switch, I don't actually want the volume to be touched -- anything destroyed.

Pedantically, no. An encryption method can't depend on time, as you could just make up a date to send through the encryption/decryption function.

The encrypted volume handler could do this if you could guarantee it had an active agent running, and no-one powered down the system and/or copied the disk before the timeout. Which I guess is practically "no", as:

1. If someone arrests you and confiscate your equipment, they are going to switch it off immediately.

2. They would try to extract data directly from the disk instead of booting up your system.

3. I can't imagine a scenario in which you want the deadman switch to go off before you are arrested.

For instant messaging, I suggest using one-time keys which aren't stored and not keeping any logs. In effect, once your client is switched off, any data collected is impossible to be decrypted, since the keys are lost and you never knew them yourself in the first place. For data you want to hide, use TrueCrypt (or similar) to encrypt most of your hard-drive and set up two keys - one which unlocks the illegal data and one which unlocks the legal data. It is important that you keep as much of your mostly legal data under the first key and only store truly problematic data (like pirated mp3s, the map to your secret hideout, etc) in the other. It's really hard to fabricate a ton of clean data and I think it's best if you simply encrypt everything you can and keep a tiny portion hidden.

Maybe we can design one using https://www.btproof.com/ ? That system lets us permanently store timestamps with roughly hourly precision along with 160 bits of arbitrary data. This would let us, for example, find the (earliest) time a password was set, so we could know if it is too old. But there's still a lot to be figured out here, and I'm no cryptanalyst. For starters, can the decryption system know it is seeing the "real" Bitcoin blockchain and not that of an interloper?

If someone has a copy of the encrypted file on hardware they control then there's absolutely no way to prevent them from modifying the software/RAM to fool the decryption routines into using a fake timestamp/blockchain/whatever. You'd need tamper-proof hardware.

I reckon you could make hardware tamper-proof by setting the hardware in a booby-trapped container that would self-destruct if tampered with. Make sure that the only two connections coming out of the booby-trapped container are power and a data connection over which the memory of the device cannot be accessed, such as ethernet.

You could build something where the human never had the actual key. The human has a passphrase which goes to a piece of hardware with the actual key, either tamper-responding physical hardware with a clock, or some kind of network service (e.g. a .onion service) which takes the user's passphrase and returns a key. As long as the user (or subverted hardware) doesn't retain the actual key each time, it's probably ok, and protected from this particular case of compelled disclosure.

The ideal is to use some kind of tamper-responding hardware to process the data (as well as decryption), though. And probably locally -- I don't think I'd trust an .onion service to stay up if it disappearing meant I would no longer have access to my files.

If the police want to search your apartment, do you need to hand over the key? You can't actively prevent them from doing the search, but do you need to aid them?

Furthermore, good encrypted data is indistinguishable from random data, how do you prove in court in that the data on your drive is just random?

If the police have a warrant to search your apartment and you refuse to hand over the key they can just break the door down (18 USC § 3109) and they often do. For an example, see United States v. Banks. There's no analogy to this with decrypting encrypted files - you can't kick a TrueCrypt volume open. And one of the main constitutional objections to the police breaking down your door is that they damage your property by breaking your door, and that isn't reasonable - but read-only access to your encrypted files doesn't damage your property.

I guess what I'm saying is the police searching your apartment isn't a very relevant analogy.

It is good analogy - nobody prevents them from bruteforcing the AES-Twofish-Serpent volume. That is equivalent to breaking the front door.

> “Some encryption effects erasure of the encrypted data (so it ceases to exist), in which case decryption constitutes re-creation of the data, rather than simply unlocking still-existing data,” Shellow wrote in a court filing. (.pdf)

If I understand this correctly, the claim is that without the password the data does not exist, so by entering the password the data is recreated.

This is an interesting argument I can imagine a lawyer making to a judge or jury that doesn't know any better, but it's totally bogus.

The data exists, it's just encrypted. Claiming that is doesn't exist and is recreated by the password is disingenuous.

Actually I agree with him. Let's say you encrypt a jpeg. You end up with a blob of bits that doesn't contain anything resembling jpeg data - the specific arrangement of bits that make what would be recognised as a jpeg file doesn't exist. It's recreated by decrypting the file - you make a new blob of bits arranged in the way a jpeg file looks. Technically speaking, the encrypted data is not a jpeg, but an input to a function that creates a new file which itself is a jpeg.

You and I both know that the encrypted data is only useful for generating the decrypted jpeg and in that sense the two could be the same thing, but I definitely see the sense behind his argument.

Sorry, but, "force"? How? Use the rubber hose until he speaks or dies?

Put him in jail for contempt until he speaks or dies.

Put him in jail for contempt of court, which has the benefit of being effectively indefinite and doesn't require finding him guilty of anything other than contempt of court.

Well ... seems the ante will go up once again if this takes traction. A person should keep its encryption keys on a separate server in a separate jurisdiction with dead man's switch. Also stuff your PC full of thermite to melt the thing when the feds knock on your door.

Yep. Just don't try to board an airplane with that laptop!

Yes, the battery is more dangerous than a bottle of water after all~

If you have sensitive info at all moving laptop cross border is stupid worldwide.

It is much better to buy something in the home country or use custom build linux on the raspberry pi as a RDP station to connect home.

It is illegal here in the UK to not decrypt. I've always wondered how anyone could prove I knew what the key was. Would saying "too late, I have a dead man's switch that tripped while I was in custody" and showing that mechanism be enough?

If so, I could just build a bogus mechanism.

It's not really a situation one should play at :)

Reply on news.ycombinator.com