Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

I don't think so. There was an encryption scheme thought up and partially implemented about a decade (or two?) ago that allowed for an arbitrary number of partitions to exist in a single encrypted drive. It was called 'rubber hose' because the scheme was designed such that it was impossible to determine how many partitions existed inside the encrypted drive.

I don't think it's a scheme that's even relevant to this context, though.

Edit: source. https://en.wikipedia.org/wiki/Rubberhose_(file_system)



view as:

That is exactly what I was referring to. An HTML file has no empty space to hide something in.

For those not familiar with the terminology, "rubber hose" in a cryptography context is a euphemism for torture. I know of two approaches to counter it.

Plausible deniability, where you can give out a password that unlocks some of the data, but your adversary has no way of knowing whether that's all of it. Useful if you can expect that you'll be let go if you're 'innocent'.

A self-destruct function, e.g. you give out the wrong code 3 times and your device wipes the data. Useful for military use cases where the data is worth more than the life of the person holding it.


If the tool always makes a large blob of noise to hide the HTML in, and accepts an arbitrary number of key/html pairs it seems like this could work in the browser. Would seem to just cost disk space to be viable.

The 'empty space' is the encrypted blob. The unknown variable that the rubber hose encryption system exploits is that the interrogator doesn't know what's inside that blob, and there might be several 'partitions' inside.

Edit: I think we're on the same page. That's why I said it doesn't seem to be relevant here. I don't see how it could be pulled off conveniently within html.


Thank you. I hadn't heard of this concept before. I think it could be relevant here.

If the encryptor offers multiple inputs, one a dummy "sure, here is my password, officer" HTML and passphrase, the other the sensitive one this scheme could work. Hiding both in a single blob, plus some noise, could work in the browser too. Seems it might offer some degree of plausible deniability. Some investigation of the decrypted dummy HTML might reveal it isn't large enough to account for the size of the blob. This doesn't seem like an insurmountable obstacle though. If the tool hides an arbitrary number of inputs in blobs that are indistinguishable you'd seem to have a great deal of deniability.


One might still reasonably expect that the person who created the file has passwords that decrypt 100% of it.

Right; the point is that when you're the interrogator holding your 'rubber hose', when do you know to stop asking for more passwords? There might be 2, there might be 20. Your suspect will put up the same resistance (theoretically) for each password.

Edit: of course, sucks for the suspect if the interrogator doesn't consider their life valuable.


Legal | privacy