Quote from: 16bitgirl on July 02, 2012, 01:21 pmIt may well be best to keep all these files in an encrypted partition, and then to securely erase said partition when you're done with it (especially in countries like the UK where you can go to prison if you don't hand over your decryption keys if the police ask for them).I just read Section 49 of RIPA. Wow, that's pretty special (and by "special" I mean it's completely fucked). Now, IANAL, but (I've done a bit of digging through legislation in the past and) ...Subsection (3) is just nasty, it gives them carte blanche to invoke it whenever they damn well please.There may be some wriggle room available in Subsection (4), especially (4)(a), (4)(b) and (4)(c). More so when it is combined with Section 50(1).http://www.legislation.gov.uk/ukpga/2000/23/part/III (clearnet)It appears that the legislation demands that the notice must be delivered in writing or a a recordable form {49(4)(1)}, must describe the protected information being sought by the order {49(4)(2)} and must specify the matters the order relates to (e.g. a trial or investigation) {49(4)(3)}. Which means that if a notice is made relating to messages encrypted to a GPG key and which were intercepted or covered a particular period, then the notice must specify which actual messages they want decrypted.Plus Section 49(9) exempts keys (or subkeys) which are used to make digital signatures. While Section 50 subsections (1) and (2) indicate that a person served with a notice had the option of providing the key or providing the decrypted data. The rest of Section 50 appears to deal with situations where a key is no longer available or not available to the target of the notice.Now, let's assume that someone in this situation has all the data which LE and/or spooks want and will comply with every legal request, but otherwise wishes to minimise the damage. Let's also assume that the notice relates only to data encrypted with OpenPGP/GPG. Here's what I would try:1) Upon receipt of a notice confirm that it explicitly cites which messages or files they want (e.g. filenames, all email sent and received between dates X and Y, etc.) *and* that the specified data does actually relate to whatever reason there've given for the notice/demand.2) If the notice does not explicitly specify the messages, files or the specific issue (subject matter) that they want, then decline on the grounds that the order does not provide the right detail. This is just a delaying tactic and will not last, but the aim is to make sure that they explicitly list each file or message they want (are aware of). Everything else is off the table. Go through the first and second points here until they get it right.3) When they (finally?) do get it right, decrypt the relevant data and provide them with the decrypted data. Perhaps in conjunction with some log of the decryption process so they know the data hasn't been doctored (a video file of the screen during the decryption ought to be enough).It's still possible that this might not be enough for them, or a conspirator might still be encrypting data to the relevant public key or they might have invoked Section 51, which is probably the worst part and explicitly mentions demanding keys under certain circumstances. So let's continue where we left off.4) If the notice specifies the messages of files, but they demand doing the decryption themselves for some verification process (or whatever other reason) then provide them with a spreadsheet containing two columns: the filename or message identifier and the GPG session key for the symmetric cipher used for that specific message. Use "gpg --show-session-key" to obtain the session key for each message, the process will decrypt the file. The filth (LE/spooks) will use "gpg --override-session-key $SESSIONKEY $filename.txt" to obtain what they want. It's possible that the number of files or messages may make this painful them. If you're using gpg-agent (for passphrase caching) it should be a lot easier to extract session keys with a script than it would be for those keys to be used to decrypt the corresponding files (it can be done, of course, but with more coding time spent on that script).5) If the number of files is constantly changing as a result of others encrypting to that key then session keys won't cut it. A key will be required to decrypt the specified messages, but that key will also be able to be used to decrypt any other file or message that has been encrypted with that key. If Section 51 is invoked to demand the key the situation is the same as if the key needs to be provided instead of session keys.If the key must be provided, then only provide the encryption subkey's secret component. Details of how to do this (and keep a copy of just the encryption subkey against exactly this type of situation) is here:http://dkn255hz262ypmii.onion/index.php?topic=28859.0Once the encryption subkey (with its alternate passphrase) has been handed over, update your master copy to do the following:* Revoke the subkey that has been provided to LE/spooks.* Create a new encryption subkey.* Export the public key and disseminate it everywhere that you have previously.If using that key for encrypting local files or non-transmitted files, stop doing that and switch to a new key explicitly for that purpose which is not provided to others or use a different encryption method.Quote from: 16bitgirl on July 02, 2012, 01:21 pmEither that, or disguising an encrypted partition as a second encrypted swap partition that you "forgot" to switch on in an operating system like FreeBSD. Encrypted swap partitions should be indistinguishable from other encrypted partitions, and have the advantage that the OS generates the encryption key at random on boot, since you have no need to know what it is, and so you have a perfectly legitimate reason for being "unable" to hand over such an encryption key. As in, you "deactivated the second encrypted swap partition temporarily, meant to turn it back on but forgot to, and there's no way of retrieving the key for it". Of course, if the fake-swap partition were mounted in an app like TrueCrypt when a hypothetical LE raid happened, even if you immediately unmounted it they might be able to retrieve the key from RAM unless your encryption app overwrites that area of memory when unmounting or something.At that point you have to start looking into the feasibility of using the same trick as in _Cryptonomicon_; to build an electro-magnet into the doorway that LE will have to cart your stuff through when they seize it. I haven't even vaguely looked into whether or not it would do enough damage to the drives. RAM, however, isn't that fond of electro-magnetic fields, not does it retain data after a shutdown for long.