Well, kinda. A RIPA s.49 notice can be defeated with s.53 defenses.

Some people have failed to pass the test of "reasonable doubt" for s.53 (3) / (4) defenses e.g. ( http://www.alphr.com/news/361693/teenager-jailed-for-refusin... ) but in other cases they have succeeded (e.g. Lauri Love had his hdd's taken and the NCA couldn't decrypt them but had to release him on bail; http://www.bbc.co.uk/news/uk-england-suffolk-31544346 and subsequently returned some of the storage (before arresting him again))

There are also people out there working to help the reasonable doubt argument; https://brasshorncommunications.uk/projects/s53/

NB: Lauri is now facing three parallel extradition request to the USA as an indirect consequence of failure to comply with a court order to facilitate decryption.

This is not ideal, but will probably fail, hopefully with some precedent set.

[http://theconversation.com/hactivists-arent-terrorists-but-u...]

It's fun, in Argentina we've had a case were a criminal releasing the key nullified the evidence, because the criminal's lawyer argued that (under Argentinian law):

* He was forced ("tortured" was the word used) to disclose the key by the police.

* You can't accuse yourself or direct relatives, and disclosing an encryption key that resulted in incriminating evidence was argued to be a form of "self incrimination".

* "Best" thing about this was that the evidence led to finding a body, but as it was nullified, legally the status of the deceased person changed from "deceased" to "missing" -- because the evidence they had used to find the body had been nullified, then also the finding of the body had to be null (I'm not kidding, people went nuts over this "technicallity").

* Eventually a more reasonable judge turned the previous statement and accepted that the person was deceased indeed.

Working in forensics (I do digital forensics) is weird some times...

The rule against self-incrimination is a very important part of Roman law - the government can't force you to do anything that would lead to your conviction.

That's why the Brazilian police has a hard drive that is known to have tons of incriminating evidence against a number of bankers but they can't do anything about it because, well, TrueCrypt.

It sounds ridiculous that the discovery of a body would be nullified because the evidence leading to it was nullified but this is important because it forces the prosecution to comply with the law. It helps avoid the violation of a fundamental right.

I don't necessarily find that Roman Law is superior to Common Law but all of the silliness about people being forced to type passwords could be avoided with this very reasonable provision. Common Law allows you to incriminate yourself by forcing you to prove your innocence by assuming guilt unless you can prove your innocence via decryption - let's hope we can all remember all of passwords!

Is there any scheme which permits a data to be encrypted such that there are two passwords\keys which can decrypt it - one which unlocks the real data and the other to some dummy\innocuous stuff?

Indeed there is, it is called plausible deniability [1]. With Truecrypt, you can nest a hidden volume within another volume, so you can decrypt the latter and it will only show innocuous files, while another password (using other parts of the volume) would provide other (incriminating) files.

I wonder what is in a judge's mind when the encrypted evidence turns out to be kitten pictures and the defendant claims that he does not have any other password to provide.

[1]: https://en.wikipedia.org/wiki/Plausible_deniability#Use_in_c...

edit: clarification

That is not what OP is talking about. You cannot get different information out of the same chunk of encrypted data. That would basically make infinite compression.

What the methods you mentioned are doing, is hiding information in places which are marked as: random data no information here. But in reality there is information there. You then need to have dummy information somewhere else.

This would be trivial to do with one-time-pads. A bit bulky, but simple. But in a way, you'd still be right. The "dummy information" is (encoded into) the second key.

Storing the different information in the same place is impossible. You could use stenography but then anyone with access to the program/source will immediately discover the deceit.

You can use what hiq is suggesting, https://news.ycombinator.com/item?id=10097533, but that is a different method.

I'm sure it was just a typo, but it's 'steganography'.

Thank you. Yes, I meant steganography.