This is work in progress. Some questions are not yet answered, but they will,
hopefully, be in due time. If you can provide
me with answers or elaborate or update on
my answers, I appreciate that.Contents
0. About this FAQ
1. General
2. The privilege against self-incrimination
3. Legal issues
4. Technical and practical issues
5. More information
1.
General2.
The privilege against self-incrimination3.
Legal issues4.
Technical and practical issues5. More information
5.1. Where do I find offline information on the subject?
5.2. Where do I find online information on the subject?
5.3. Where do I find related information?
Back to the Table of Contents.
To encrypt data, you need a crypto program and a key. For decrypting the data, you need the decryption key, which is the same as the encryption key in "symmetric cryptography" (such as DES and IDEA), or a different one in "asymmetric" or "public-key" cryptography (such as RSA and PGP). The decryption key (which is indeed key to keeping the data secret) must be kept secret, and is generally stored safely on a diskette or a hard disk, protected by a password (or, better still, a passphrase).
For more information about cryptography, see RSA's Cryptography FAQ, the PGP FAQ, a large list of websites, or handbooks such as Bruce Schneier's Applied Cryptography or Menezes, van Oorschot, and Vanstone's Applied Cryptography.
The definition of the persons who can invoke the privilege may differ from country to country. In the European Convention of Human Rights, the privilege (and, more generally, the right to a fair trial of article 6) applies to people facing a "criminal charge". In the Netherlands, the privilege holds (or may hold) for suspects, which means that there must be circumstances which suggest a reasonable suspicion that someone is guilty of a crime. These definitions are not identical: someone can be a suspect without there being a criminal charge in the sense of article 6 of the European Convention. Note that the privilege applies to criminal cases only: if public authorities investigate under administrative rather than criminal law, the rights of the target of investigation can be radically different and generally do not include a privilege against self-incrimination (although, to make things yet more complex, the European Court may view certain administrative procedures as a criminal charge).
The Dutch Supreme Court has generally said that "it would ill be in keeping with the spirit of the DCCP" if "the suspect would be compelled to contribute to his own conviction under threat of punishment" (HR 16 January 1928, NJ 1928 p. 233), but also inclines to the opinion that "there is no unconditional right or principle that a suspect can not in any way be obliged to cooperate in the obtaining of possibly incriminating evidence" (HR 15 February 1977, NJ 1977, 557 m.nt. GEM).
The "autonomous meaning" of the term "criminal charge" means that the European Court does not only look at the classification of the alleged offence in a nation's law (criminal or otherwise), but also at the nature of the offence and the nature of the penalty threatened.
A related case, on the presumption of innocence and the right to remain silent, is
According to the European Court, the privilege "is primarily concerned, however, with respecting the will of an accused person to remain silent. (...) it does not extend to the use in criminal proceedings of material which may be obtained from the accused through the use of compulsory powers but which has an existence independent of the will of the suspect such as, inter alia, documents acquired pursuant to a warrant, breath, blood and urine samples and bodily tissue for the purpose of DNA testing." (Saunders, see 2.10).
The US Supreme Court, in Schmerber (see 2.4), ruled that the privilege against self-incrimination only protects evidence of a testimonial or communicative nature (which, in that ruling, excluded furnishing a blood sample). Under circumstances, handing over documents canbe privileged, if the act of providing them is testimonial (in that the suspect admits having them) (Fischer, Doe I, see 2.4).
The 3rd option has great explicative value. The disclosure of things which exist "outside of the will of the suspect" provides reliable evidence, whereas testimonial statements generally do not (you don't know whether the suspect tells the truth). Thus, the privilege contributes to truth-finding and shields the judiciary from "miscarriages of justice" (Murray, see 2.10). However, I think it is impossible (and unnecessary) to pinpoint a single rationale: all of the above grounds have something to say for them and explain different aspects of the privilege.
(There are other suggestions for rationales, such as privacy (the privilege protects the privacy of the mind), but I do not consider these relevant.)
For several reasons, the argument does not hold. First, the privilege against self-incrimination pertains to suspects, whereas a mandatory LEAK system is a general measure targeting citizens at large; people depositing their keys do not do so in a capacity of criminal suspect. Moreover, the concern protected by the privilege against self-incrimination is that the truth be found in criminal proceedings (see 2.12). Now, requiring people to use means that enable law-enforcement agencies to gather evidence does not threaten the fact-finding process, as people are not forced to give evidence itself. After all, people may refrain from using the LEAK system; they are not in any way obliged to use it for communicating incriminating evidence. There are plenty of parallels, for instance in the tax-law requirement of keeping verifiable books: this also is a requirement that creates the possibility for law enforcement to gather evidence, while it does not concretely push people to hand over incriminating evidence.
The Netherlands has a provision that the police can command someone to decrypt during a search, but this command cannot be given to suspects (art. 125m DCCP). A 1998 pre-draft law (Computer Crime II) initially would have introduced this possibility, but after protests from the legal community, the provision was withdrawn, respecting the privilege against self-incrimination.
Several other countries have proposed a kind of decryption command, in some cases without excepting suspects. However, none of these proposals have yet been implemented. See the entries on Belgium, Canada, Finland, and the UK in my Crypto Law Survey.
Technically, there is a big difference between these options. If you have used asymmetriccryptography (like PGP), handing over your private key will not only give access to the messages the police have a warrant for, but also to any other messages encrypted in the past or in the future with the corresponding public key. Although the police should not read messages intercepted outside of the warrant period, and should destroy the key after the warrant period, it's tempting for them to do so.
If you have used symmetric cryptography, handing over the key will only give access to the files or messages encrypted with that key, so in that case, there is not much difference.
Legally, there's also a difference. If you hand over a key or the passphrase to a key, the police can check themselves whether it's the right one. But if you hand over plaintext, and claim it corresponds to the ciphertext the police wants decrypted, why should the police believe you unless you demonstrate that the plaintext and ciphertext match? Logically, then, the police (or the judge in court) should ask you to perform the decryption before their eyes.
There's the third option, which seems to me to be a good middle way. Give your key (or passphrase) to a public notary (or the judge herself, if needs be), and let her decrypt the messages the police wants decrypted. This ensures that only messages are decrypted for which the police have a warrant, and gives the resulting plaintexts sufficient evidential value.
1. Stored data. If you store encrypted data on your computer, what is the use if you cannot decrypt? After all, you only keep them on your computer because you may want to access them sometime in the future. So, logically, you should be able to decrypt. Reality - and human frailty - of course, are not so logical. People forget passphrases every now and then, and with hard disks getting ever bigger, why bother to destroy age-old files which you will no longer need? Still, this is a relatively straightforward case. If you have stored encrypted data on your computer, you should, in principle, be able to decrypt, and if you cannot, the burden of proof is on you to explain why you cannot (compare 3.7).
Much trickier is the case with encrypted communications.
2a. Encrypted email. If you store encrypted email messages in encrypted form, the case is similar to stored data (see above). However, if the police has intercepted an encrypted email message in transit (difficult as it may be), or if they have encountered the message in a copy-to-self folder of the sender, they may ask you to decrypt. If the message has indeed been encrypted with your public key, you will be able to comply. PGP indicates in encrypted messages with whose key they have been encrypted. I do not know whether all crypto programs do that, nor whether it is feasible to tamper with this feature. (Can anyone tell me?)
2b. Encrypted phone calls or fax messages. If the police have intercepted some of your encrypted telephone communications and they ask you to decrypt, can you comply? That will depend on the crypto hardware or software you have used. I do not know whether crypto phones are able to decrypt former conversations - I suspect that generally they cannot, but I am not sure about that. The session keys used in encrypted communications are destroyed immediately the session has ended, but it may be possible that the key-exchange mechanism of the crypto phone is able to reconstruct the session key if the entire communication (including the "handshake" messages which crypto phones use to establish a session key) has been recorded. (Can anyone tell mewhether crypto phones work this way?)
If the communication was encrypted with a 'perfect forward secrecy' protocol (see 4.3), it is not possible to reconstruct the session key afterwards, and the suspect will not be able to comply with a decryption command.
If a criminal wants to prevent the police from ever asking him to decrypt, or from his having to comply if they do, there are a number of options.
First, he can hide the fact that he is using encryption at all. With steganography (hidden writing), you can hide your encrypted data (text, images, video, sound) in other data, in particular in digitized images. This will hardly alter the look of the image, and so the police may not notice that anything is hidden in the picture. (Of course, the presence on the computer of a program like "hideseek" will alert them to the criminal's using steganography.) On steganography, see Peter Wayner, Disappearing Cryptography (Chestnut Hill: AP Professional, 1996).
Second, crypto protocols and implementations are being devised which ensure "perfect forward secrecy": a characteristic which means that after a session has ended and the session key has been destroyed, there is no way to reconstruct the session key. This means that it is technically impossible for a criminal to give the key of former sessions to the police. Note that this holds only for encrypted communications, not for encrypted data storage. (Can anyone update me to what extent current crypto applications have this feature?)
Third, he may try "duress codes" or "deniable encryption", with which he decrypts the ciphertext at stake to a fake plaintext. See 4.4.
And then, there are ways to anticipate a criminal's"forgetting the password" if ever the police asks him for it, for instance, by using many key pairs at the same time or changing his key frequently. See 4.5.
In the context of the police asking someone to decrypt, it is possible that the person complies and decrypts the ciphertext.... but that he uses a different key which does not yield the original (incriminating) plaintext, but another (innocent) one. I call this a "duress code".
Say you want to send the message: "twelve tons of dope" using a Vigenere system (addition of letters: A+B=B, C+D=F, etcetera). With Hamlet's monologue as a key, this yields the ciphertext:
| plaintext | TWEL VETO NSOF DOPE |
| key | TOBE ORNO TTOB ETHA |
| ciphertext | MKFP JVGC GLCG HHWE |
When forced to decrypt, instead of giving the real key, you might give the key BWSJ YNLY NEGQ NDSR instead, which decrypts the message as follows:
| ciphertext | MKFP JVGC GLCG HHWE |
| key | BWSJ YNLY NEGQ NDSR |
| plaintext | LONG LIVE THEQ UEEN |
This way you can decrypt the ciphertext to any plaintext you choose: from the ciphertext and the desired plaintext, you can compute the key you need to 'decrypt' to the desired plaintext.
Although this is technically feasible, I do not consider this a serious option. Most modern cryptography does not work with Vigenere systems or One-Time Pads. If you do, I think you would have to explain to the police why you are using this system; the fact that you use it will likely alert them to the possibility that you are performing this trick (although, to be sure, they have no way of ascertaining this).
Other cryptographic protocols are being developed which ensure this possibility. For instance, Canetti and others have proposed "deniable encryption". This is a scheme in which "the sender can generate 'fake random choices' that will make the ciphertext 'look like' an encryption of a different cleartext, thus keeping the real cleartext private." (Ran Canetti, Cynthia Dwork, Moni Naor, Rafail Ostrovsky, 'Deniable Encryption', in: B.S. Kaliski (ed.), Advances in Cryptology - CRYPTO 97, Berlin: Springer 1997, pp. 90-104) I don't know whether this has ever been implemented, but tend to think that it will be an exotic scheme for some time to come.
A key issue here is who has the burden of proof (see 3.7). I tend to incline that if you claim you have forgotten the passphrase, the burden of proof is on you to argue why. If you provide evidence for some of the above arguments (especially if the data were encrypted a long time ago or if you by now are using another key pair), the burden of proof shifts to the police. They will then have to show that, for instance, you still used the key to sign a message the other day, or that you are a computer-security expert who at his office has never yet forgotten his passwords.
© Bert-Jaap Koops, 1999. All rights reserved.
Updated on 13 August 1999.
home | help | address | mail | links
research | crypto law
survey | publications | personal | amnesty