Cryptography Success Story
From Brazil: the moral, of course, is to choose a strong key and to encrypt the entire drive, not just key files.
Comments
uk visa • June 30, 2010 9:53 AM
The moral from the other perspective is to have laws in place to deal with such situations.
Chris • June 30, 2010 9:55 AM
Very nice. I use TrueCrypt too, primarily against corporate theft of sensitive materials, with a sufficiently large random password. Although protection against government officials peeking is an added bonus.
I’m glad to see an example where such encryption proves effective.
The USA has the Fifth, although it doesn’t always apply, iirc a case related to password is currently still in appeal.
Matt • June 30, 2010 9:56 AM
I just have to say this: we all know about deniable encryption and even “duress keys” that reveal a completely innocent, second, separate set of data.
Doesn’t that make the UK RIP Act and “rubber hose cryptanalysis” useless?
CristianTM • June 30, 2010 10:08 AM
In Brazil this case got a lot of repercussion. The public opinion can’t understand how can it be that something is unbreakable. They see movies, FBI should break anything in some secs, they think.
A famous journalist (Paulo Henrique Amorin) published a article, based on “knowledge” of an unidentified friend of his that was identified only as an “specialist”, giving a lot of suggestions on how to break any criptography and suggesting brazilian police was not trying hard enough, probably for political reasons. This article even suggests, between many technics not applicable to this case, that Brazilian Police should try to find the factorization of prime numbers of the key, in the case the encryption was based on RSA algorithms. I’m not kidding, the “specialist” said this! And was not joking!
I guess we need in Brazil some laws like this one that makes the denial to provide the key a prove of guiltness, but… what can we do about plausible denial that truecrypt offers (considering the criminal took care of not leaving any tip that he is using it outside of the truecrypt container)
Mailman • June 30, 2010 10:18 AM
Unfortunately, the aftermath of this story in Brazil is more likely to be cryptography being demonized as a crime enabler than it coming out as a having saved the day by protecting an individual’s security and privacy.
Frank Ch. Eigler • June 30, 2010 10:31 AM
From a broader point of view, a criminal may get away with it. Defeating police investigations may be a pyrrhic victory for technologists in the long run.
cloudy • June 30, 2010 10:35 AM
In the court documents supporting the warrants for the 11 alleged illegals, it was asserted that the steganography program needed a 27-character password. The way the FBI document is written, it is ambiguous just what the password is doing–enabling the program to decrypt the messages hidden in the pictures, or allowing access to the program on an encrypted disk. But the correlative is that the alleged perps had the password written down on a piece of paper (if it was a random string…). One wonders if the implication that no one in the USG could brute force the codes is true or whether the document skates over that to preserve the fiction that the USG can’t break the codes with brute force. Certainly in the documents the FBI only provided messages which were decrypted using the photographed password.
Is a 27 character random password the new de facto standard?
Roy • June 30, 2010 11:10 AM
TV taught people that any encryption can be broken before the next word from our sponsor. Hollywood writers believe one can partly decode something quickly, and fully decode it soon after. The few times a script reveals a password, it is always a short weak one.
The media popularizes the idea that cryptography’s only function is to hide secrets.
Encryption gives excellent protection against people stealing your work. If they cannot read it, they cannot steal it. Yes, you are keeping it secret, but anything less than total secrecy opens you to the risk of theft, and to undetected theft.
Encryption also prevents subtle sabotage, forcing any saboteur to resort to crude measures, such as deleting your file and overwriting the storage space, or replacing your encrypted file with another encrypted file or a dummy file read out of /dev/random, or overwriting part of your file with digital gibberish. If they don’t have your password, they cannot fool you into accepting their doctored file as your original file.
Theft and sabotage are crimes. We need to popularize encryption as a crime prevention tool. Encryption is used to sell services, so the masses know it affords protection. They need to have the dots connected for them.
Clive Robinson • June 30, 2010 11:27 AM
@ cloudy,
“Is a 27 character random password the new de facto standard?”
Not from where I sit, arguably each char is only worth between four and five bits.
Thus only giving between 108 and 135 bits, however these 27 chars are very unlikley to be truley random so it could be way way less entropy maybe as little as 60 bits equivalent.
And 60bits is close to being in reasonable brut force territory (DES 56 bit was brut forced in three days several years ago so possibly as little as 5 or 6 days for AES).
As Bruce and others have said in the past practical crypto security is about margins and personaly I don’t think 27 chars is enough.
AlanS • June 30, 2010 11:30 AM
@Cloudy: “Is a 27 character random password the new de facto standard?”
I think it depends on what you are trying to protect and from whom. A random 27 character password using the 95 available characters on a standard keyboard would have a keyspace of around 2.5× 10^53 (I think). Are the NSA’s supercomputers even capable of brute forcing something that big in a reasonable amount of time? It’s probably overkill for most people. And if you use such a monster you have to figure out a secure way to store it. They had it written down on a piece of paper. I guess the guy in Brazil was a little smarter.
AlanS • June 30, 2010 11:47 AM
NIST has some good documents dealing with password strength. There’s a general discussion in SP800-118. Entropy is discussed in SP800-63 (esp. Appendix A).
Poul-Henning Kamp • June 30, 2010 1:08 PM
@Matt: In re: Deniable crypto.
If you use a multi-space crypto solution, like STEGfs, you, personally, are in a much worse situation than you would be with regular encrypted filesystem or disk.
The authorities/attackers/terrorists/mafia will find out that it is STEGfs you are using, and they will keep asking you for more passwords, until they find what they are looking for.
In the event they have unfounded expectations, you have no way to prove that you actually have handed over all the passwords, because STEGfs does not support that operation, in fact, it goes out of its way to prevent it.
In the vast majority of organizations, data is worth much less than the lives of the persons involved.
Therefore an intelligent deployment of crypto would never leave the users in a situation where they are not be able to prove their compliance, should they desire to do so.
Poul-Henning Kamp
(Author: GBDE disk encryption, http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf)
trsm.mckay • June 30, 2010 3:34 PM
In a break with traditional Hollywood a recent Leverage episode (TNT – http://www.tnt.tv/dramavision/?cid=44212&oid=62281) called the Reunion Job actually had an uncrackable password. The bulk of the episode was showing how they tried to obtain the password. I thought the parts about the password were rather well handled.
Fair warning: Leverage’s past history is more typical when it comes to computer security and password cracking. Of course other parts of the show require ample suspension of disbelief too, but that has not kept me from enjoying it.
Bryan • June 30, 2010 3:40 PM
“Not from where I sit, arguably each char is only worth between four and five bits.”
You’re assuming that the pass-phrase is actually used as the key; which would be a implementation mistake. A good implementation would generate the full 256 bit encryption key by hashing the pass-phrase with random salt with as much entropy as your PRNG can generate, which is then stored as part of the cipher-text.
And of course, we’re not talking about an MD5 hash here, we’re talking about something VERY computationally expensive because from the defender’s point-of-view, we only have to do it once.
Assuming the attacker hasn’t found a problem in the encryption algorithm, (in which case he wouldn’t bother brute-forcing the key) the attacker’s job becomes trying to re-generate the encryption key. Yes, he still needs to identify the same 60 bits, but we can make that process very slow.
For reference, take a look at the OpenPGP specification: http://www.faqs.org/rfcs/rfc2440.html
Section 3.6.1.3. – Iterated and Salted S2K
BF Skinner • June 30, 2010 3:41 PM
A candidate for an @home app?
One thing that surprises me is that the commonly used key derivative functions do nothing to make cracking with specialized hardware more difficult.
The defender typically uses a few core CPU and has a at least a few hundred MB of RAM.
The attacker uses a more parallel architecture where each individual part is much smaller and cheaper. (A graphics card for low end attackers, a fpga or specialized hardware for a high end attacker).
But if he wants to keep each part cheap he can’t afford much RAM per part. So I think we should switch to KDFs which require significant amouts of RAM which drives the cost(in circuit size and thus money) of the attacker up.
@Roy
“The media popularizes the idea that cryptography’s only function is to hide secrets.”
What other function does it have? Hiding information that needs to be kept secret is pretty much the definition of cryptography.
“We need to popularize encryption as a crime prevention tool.”
Agreed, but it prevents crime BY hiding data that should be kept secret.
Richard • June 30, 2010 7:08 PM
“encrypt the entire drive”
This can be done in software (e.g. PGP) or in hardware using encrypted disks that are becoming common.
Hardware is, presumably, faster and does not load the CPU.
Software offers additional features like requiring a USB token to boot, encrypted email etc.
Does anybody have an opinion on whether either option is preferable to the other?
Henning Makholm • June 30, 2010 9:09 PM
@Bryan: PRNGs do not generate any entropy. That’s what the P stands for. If you put 27 characters worth 5 bits each in, you still only get 135 bits of entropy out.
Which, however, strikes me as being plenty, given that the relevant task is just to make brute-forcing more cumbersome for your enemies than surreptitiously installing a keylogger on your machine.
Remembering a 27-character random password sounds nontrivial. I’d prefer a 100-character nonrandom passphrase myself.
Robert • June 30, 2010 9:51 PM
I’m surprised that no one has suggested that the Brazilian police possibly “took the bait” and happily walked off with the “easy to find” hard drives. These drives use Truecrypt to encrypt random data stored in file structures which mirror the file structure of the real drive.
I’ve always thought this would be a good way to keep law enforcement busy for a Looooong time, giving you time to arrange for the real drives / data to properly disappear. (sledge hammer plus deep sea fishing trip)
Even when they force you to reveal the drive key, it just reveals that these drives were an intentional ruse. It seems to me that as long as you don’t ever say that these are the real drives then the police have nothing to charge you with.
Nick P • June 30, 2010 9:52 PM
Well, it’s a nice story. I’m glad it worked. It goes to show the open source TrueCrypt doesn’t have any implementation flaws that the FBI knows how to exploit with only an encrypted hard drive to use. I have an old technique for deniable work: a Incognito Linux live distro on USB or mini-CD (sleep with it); USB drive with encrypted TrueCrypt volume or CBC-mode image; put it into computer, boot into Linux, copy files directly into RAM disk, close cryptainer, work, open/save/close cryptainer, and then shut down with Incognito automatically erasing memory. The dual-USB stick solution means you can use a random (or well-hidden) computer with minimal data leakage. If you can hide it or stand sleeping with it, there’s tiny embedded boards that can be made into read-only computers with decent interfaces.
Of course, a truly paranoid person would prefer to isolate the encryption keys from the CPU by using an inline-media encrypter. An embedded board with two IDE’s, DMA disabled, can serve this purpose. The BIOS, RTOS, and crypto are easier to verify, with the secrets stored in a space easily overwritten randomly upon pressing of the erase button. To those who missed Clive and I’s conversation on a secure IME drive, the Erase feature would have to overwrite key storage, data buffers, and everything else, but it would overwrite keys first.
Hey Clive, if I build another one I was thinking about supporting more than one partition with read-write-execute attributes. I think an Australian IME product does this, but mine is a bit different. One partition might be the main system for personal use, one read-only for web browsing, one for work, and another be used for strictly confidential data. Each partition would contain a user-mode OS that was verified during load. The BIOS would load a heavily verified OS that would load the others as usermode Linux or whatever VM’s. Basically, much like a MILS or hypervisor system but each partition is protected by the hard drive’s crypto mechanism and the MILS kernel ensures a trusted path to hard drive and sanitization of RAM before a new VM uses it. If one wanted to build it, Dell’s Secure Consolidated Solution gives us a board support package (for INTEGRITY RTOS) to start with, then COTS embedded boards and chips with crypto acceleration do the rest.
Tom T. • June 30, 2010 11:51 PM
@ Nick P.: I’m suddenly reminded of our conversation a few months back, in which I suggested TrueCrypt files, CDs (hidden amongst your Michael Jackson collection, etc.), and related tactics as reasonable means for average home users, as well as techies, to protect material at relatively low cost in time, money, hardware, and knowledge.
IIRC, you emphasized what you just said above: Additional hardware precautions, beyond the reach of the majority of users, but worthwhile for those who can do them and have data worthy of the effort.
It was kind of nice to see the Brazilian case bear me out, though of course you’re right that the more secure the platform, the better. Most home users have no choice but to trust their home machine, rightly or wrongly.
As far as protecting criminals, surely the police must have other evidence (else how did they get the search warrant?) There once was a saying in the US, “It is better to let a thousand guilty men go free than to convict one innocent man (ok, or woman, to modernize it). I’ll add — and better to protect the privacy and rights of 300,000,000 Americans, and whatever number of the rest of the world, against government overstepping its powers, illegal search and seizure, eavesdropping, wiretapping, etc. ad nauseam, even if one criminal goes free once in a while.
AC2 • July 1, 2010 1:25 AM
@ Nick P
Very interesting post indeed…
Hadn’t heard of Incognito Linux before, but browsing on their site I see that the two key elements therein are:
“1. all outgoing connections to the Internet are forced to go through the Tor network;”
“2. no trace is left on local storage devices unless explicitely asked. ”
The 1st one is nice to have but not required, strictly speaking, for the issue under discussion on this page.
The 2nd one can be done with most LiveCD implementations, like Ubuntu, with a boot param (which for the life of me I can’t recall right now) that prevents any access to the hard drives (including for swap) unless you explicitly mount them after startup.
Is there anything else special about Incognito? Of course for the Ubuntu LiveCD I would use one of the late LTS versions (say 8.04.3 LTS) in order to make sure I have most of the critical patches in place…
I could go the whole hog and rebuild a new LiveCD/ USB bootable from the latest fully patched system, if I knew how! Of course this problem is also shared by Incognito…
So, in the end, why Incognito instead of a standard late LTS version of something like Ubuntu? Would also be easier to rebuild and verify (match CD ISO checksum with that on Ubuntu website) so no need to sleep with it.. Lastly I would trust a standard distro like that instead of one I have not heard of before, but that is, of course, down to my ignorance.
Beyond that I completely lost you from “… using an inline-media encrypter. An embedded board with two IDE’s, DMA disabled …” onwards… Clearly I have no data that is worth all the remaining points in your post!
moz • July 1, 2010 3:05 AM
@Cloudy: “Is a 27 character random password the new de facto standard?”
No, the smart people moved onto long passphrases a long time ago. Good luck to the keylogger when the password is “hey bob, good night liast night eh? wanna do it agin?dir c:\program data\textpad\scrilenny you got a tick want to run something past pts /b you!”
I mean, sure, they just have to scan the log for repeated strings up to, say, 200 characters and they’ll eventually find it. But you’ve made it that little bit harder. Especially if the password typist loves the MS character map tool or something similar.
Nick P • July 1, 2010 3:28 AM
@ AC2
I used Incognito for the 2nd reason you found: it’s designed to leave all traces. I didn’t know enough about the Linux kernel to make it traceless myself and even you don’t recall the parameters you mentioned. Add the differences among distro’s and I just decided to find others who knew more.
Ingcognito was designed from Gentoo, a source distro. They dug through the kernel, tweaked it, and did their best to ensure it didn’t leave any traces. The kernel even overwrites RAM upon shutdown. I used it or Ubuntu in offline mode depending on my needs. I also figured disabling Tor rules in Incognito was easier than securing the Linux kernel from data leakage. Less to figure out. 😉 Read-only media, RAM only operation and the usual lack of an internet connection reduced risks from less patching.
As for IME, that’s an inline media encrypter. It sits between a computer and it’s hard drive, transparently applying crypto either way. The key is [ideally] a carefully mixed combo of user input (via input device on IME itself) and onboard data generated from a true random number generator. In one of my schemes, a strong user password is converted into a key that encrypts drive passwords generated by the system and/or additional random data by the user. If you want to see a nearly ideal one, look up the NSA’s IME. Anything that runs through it is considered unclassified at rest. To build a cheap (lower assurance) unit, I was suggesting a COTS embedded board with two drive connectors, no DMA (prevents device/driver attacks), security-focused real-time OS and possibly crypto-accelerated processor. One button could be used to erase all onboard keys if it came to that. Putting everything under the control of a small, dedicated, simpler unit greatly reduces attack surface and improves confidence. This device is also seemless to user, except for password or key fob.
Peter A. • July 1, 2010 6:53 AM
@Poul-Henning Kamp
Let’s rule out mafia as they can do bad things to you regardless of your compliance and concentrate on “legal mafia” in the disguise of an overzealous government that has passed “password or prison” law.
A agree that multi-crypto puts you into risk in such a situation. What about this:
Have multiple separate physical storage devices – a hardware disk array or maybe just a server PC with many disks and sofware RAID or similar thing – with more disks that you actually use. Have many encrypted filesystems (or groups of them) for various purposes, e.g. one for your regular daily use, one for work related tasks, one for your digital collection of (legally obtained or self-made) photos, music and movies, one for semi-confidential data like your personal health/property/financial records etc. etc. – and one filesystem for your really confidential data. The last one would sit on a separate disk or two.
When the police sizes your disk array you just happily give them keys to all filesystems – except the last one. When they ask you for the access keys to these disks, just say there used to be another crypto FS on them but you didn’t need it anymore so you destroyed the keys without bothering to overwrite the data – and you keep the disks as spares. You can even put them in the hot spare pool, at some risk to your data. Have another fresh-from-factory disk or two in the spare too, to show your dedication to redundancy :-).
The problem here is a way to cover your tracks when you actually use this “abandoned” FS, so no trace is left of mounting and using it anywhere else – or maybe even leave some carefully made-up evidence (logs etc.) of using it at some point in the past and then removing it from your configuration, to support your words.
You should be very sure not to leave anything in the logs, swap space and other storage – maybe using the Incognito Linux mentioned above to run this FS after booting your PC from an USB stick – or if you use multiport hardware array, just connect some computer to the other (normally unused) port.
But there are more things to consider, e.g. S.M.A.R.T. data kept on the drives themselves, possibly controller local storage (array configuration/data cache) if you use hardware array etc. This is the tricky part.
The last part of the plan is to have a good lawyer 🙂 IANAL, but the general rule is that the court can’t request you to do the impossible – in this case decrypt data without having the key. Otherwise the “password or prison” law could be used to throw in jail anyone that ever used some piece of crypto before – like encrypting a file or email message – and than stopped using it for whatever reason, e.g. forgot the passphrase, lost the key, sent the encrypted data along with the key to someone, without intent to retain the key, but having left the message in the “sent” folder etc.
Of course this applies to data at rest – which is most often the case: the police gets a warrant, sizes your data and then analyzes it. If they spied on you before that, they could figure that your “abandoned” FS were used recently (e.g. by taking snaphosts of the data) and you’re lying.
What do you gyus think of this strategy? And the legal part of it?
HDD guy • July 1, 2010 9:20 AM
“S.M.A.R.T. data kept on the drives themselves”
Indeed, that data isn’t encrypted even on Full Disk Encryption drives, and I am sure that TrueCrypt can’t help with that either.
So basically, there is no way (short of figuring out how to modify the SMART without leaving a trace every time you write to/access the drive) to plausibly deny using the drive.
Peter A. • July 1, 2010 10:26 AM
@HDD guy
I had a cursory look at S.M.A.R.T. readings on two rather old disks in my private PC and they differ a lot in what kind of information they report – or at least what the tool I have used shows. However none of these statistics I have seen would indicate when the drive was actually used lately, as opposed to beeing powered up. There were such things like number od spindle starts, total drive uptime etc. but nothing actually related to reading/writing data.
But as the set of parameters reported by the two differed a lot – and one reported some information elements unrecognized by the tool – it may be different from drive to drive. So one should carefully choose drives to use for secret data…
Paul Bobby • July 1, 2010 1:34 PM
The moral? The hard drives have defeated the attempts to decrypt. Sounds to me the banker had already learned his morality lesson from another source and used it wisely this time around.
packet • July 1, 2010 6:59 PM
Schneier has covered it before: power line fluctuations (differences on the wire in keys pressed).
There’s thermal attacks against cpus and temp, also:
ENF (google it)
A treat (ENF Collector in Java):
sourceforge dot net fwdslash projects fwdslash nfienfcollector
No single antimalware scanner exists which offers the ability to scan (mostly proprietary) firmware on AGP/PCI devices (sound cards, graphics cards, usb novelty devices excluding thumb drives), BIOS/CMOS.
If you boot into ultimate boot cd you can use an archane text interface to dump BIOS/CMOS and examine/checksum.
The real attacks which survive disk formats and wipes target your PCI devices and any firmware which may be altered/overwritten with something special. It is not enough to scan your hard drive(s) and thumb drives, the real dangers with teeth infect your hardware devices.
When is the last time you:
Audited your sound card for malware?
Audited your graphics card for malware?
Audited your network card for malware?
Google for:
- AGP and PCI rootkit(s)
- Network card rootkit(s)
- BIOS/CMOS rootkit(s)
Our modern PC hardware is capable of much more than many can imagine.
Do you:
- Know your router’s firmware may easily be replaced on a hacker’s whim?
- Shield all cables against leakage and attacks
- Still use an old CRT monitor and beg for TEMPEST attacks?
- Use TEMPEST resistant fonts in all of your applications including your OS?
- Know whether or not your wired keyboard has keypresses encrypted as they pass to your PC from the keyboard?
- Use your PC on the grid and expose yourself to possible keypress attacks?
- Know your network card is VERY exploitable when plugged into the net and attacked by a hard core blackhat or any vicious geek with the know how?
- Search out informative papers on these subjects and educate your friends and family about these attacks?
- Contact antimalware companies and urge them to protect against many or all these attacks?
Do you trust your neighbors? Are they all really stupid when it comes to computing or is there a geek or two without a conscience looking to exploit these areas?
The overlooked threat are the potential civilian rogues stationed around you, especially in large apartment blocks who feed on unsecured wifi to do their dirty work.
With the recent news of Russian spies, whether or not this news was real or a psyop, educate yourself on the present threats which all antimalware scanners fail to protect against and remove any smug mask you may wear, be it Linux or OpenBSD, or the proprietary Windows and Mac OS you feel are properly secured and not vulnerable to any outside attacks because you either don’t need an antivirus scanner (all are inept to serious attacks) or use one or several (many being proprietary mystery machines sending data to and from your machine for many reasons, one is to share your information with a group or set database to help aid in threats), the threats often come in mysterious ways.
Maybe the ancients had it right: stone tablets and their own unique language(s) rooted in symbolism.
Nick P • July 2, 2010 12:04 AM
“maybe the ancients had it right: stone tablets and their own unique languages rooted in symbolism”
Actually, even those are being broken. A serious amount of time must pass with little residual data before the obscurity benefits. I think it’s the skeptics who had it right: you can never be sure of anything.
Steve • July 5, 2010 3:53 AM
Pardon my paranoia but…. Nice story that Truecrypt and a big enough key can’t be bust by the Feds. Hmm, good sales pitch for anyone who want this to be more widely used. Usage should go up. Strange they don’t mention giving the NSA a bash at the data (or don’t the FBI and the NSA ‘play nice ?). Could the story be being played up as ‘they’ have found a hole and just want people to jump down it ? If it really is Fed proof you would think the Feds would have at least tried to assist the help of the real code busters otherwise they face this being a widespread occurrence. That would be quite debilitating to them imagine.
Of course if you carry on down that path then maybe they haven’t found ‘a hole’ and this post is damage limitation.
Sheesh, best to stick to the techno and leave (most of) the spin to ‘them’ .
Nick P • July 6, 2010 2:44 AM
@ Steve
Lots of implications, little evidence. The NSA does their own thing and doesn’t talk much about success or failure. The FBI might still admit to failure on a good tool because the tool usually isn’t an issue: failures in other areas are almost inevitable and let them around the tool. So, what are you talking about? Do you have any evidence to your claim or is your paranoia just getting the better of you?
Lisa • July 8, 2010 7:18 AM
TrueCrypt still does not support FULL DRIVE ENCRYPTION for the MAC. I have a MacBook, and there does not appear to be any trusted “opensource” solution for the Mac that does offer full drive encryption. (I don’t trust private close source alternatives like PGPdisk.) So I am forced to only encrypt the home directory on my MacBook, but cannot encrypt my swap, which means that my TrueCrypt decryption keys are likely accessible to anyone.
Dr. T • July 8, 2010 12:38 PM
If the only way the police and prosecutors can get a conviction is by decrypting a criminal’s hard drive, then their case was damn weak. It’s like claiming that you cannot convict a serial murderer because you couldn’t decode his handwritten diary. If the police have enough evidence to point to a single suspect, then they should be able to build a case without the hard drive data. The only cases I heard of where a decrypted drive was the primary piece of evidence were for possession of illegal pornographic images.
Lisa • July 8, 2010 6:50 PM
Personally I am sick and tired of the argument that the public should be denied access to privacy, technology, crypto, etc. because the terrorists and criminals might also benefit. Thats like saying we should deny ourselves of Oxygen since the terrorists and criminals use & require it. Why can’t the public make a proper risk benefit analysis for these things?
KIm • December 13, 2010 10:23 AM
I always use CC Cleaner after I have opened an encrypted file, this is to clear logs Etc. I am not as knowledgable as most of you when it comes to IT but am I wasting my time? I also use the older version of Eraser sometimes to erase the unused space on the Hard Drive. Does this help? In the UK the Police are using ‘terrorism’ as an excuse for everything. They are taking away all of our human rights. I actually legally need to keep a data base and I prefer to encrypt it. Yet the Police think it is their right to crawl all over it and use other peoples data for their own uses.
Subscribe to comments on this entry
Leave a comment
Sidebar photo of Bruce Schneier by Joe MacInnis.
Mike Curran • June 30, 2010 9:44 AM
I’m forced to wonder that if this case was “really important” that those drives would have been decrypted due to an error in the encryption caused by the a misconfiguration by the criminal.