lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <200501210737.j0L7bP0Q023370@turing-police.cc.vt.edu> From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu) Subject: harddisk encryption On Fri, 21 Jan 2005 00:23:40 CST, Frank Knobbe said: > Since others are still throwing in their recommendations, let me add > mine as well. Back in the days when I used Windows, I really liked > HardDisk Encryption Plus from PCGuardian (www.pcguardian.com). It is a > full-disk encryption program (or just a partition if you like). My old > NT4 laptop was encrypted with it. No problems. Nice admin and recovery > features. But what I really liked was the transparent encryption of the > whole disk which you unlocked with a password on boot-up. > I believe they still offer eval versions. Feel free to give them a try. (Not getting on PCGuardian in particular.. it's an endemic problem) It's almost trivially easy to make a product that *looks* like it's working. Doing crypto *right* is a lot more challenging, and there's a lot of snake-oil crypto out there. Some of the people think they really know what they're doing, and some don't care that they don't.... A *partial* list of things to look at: 1) Is the basic crypto algorithm something considered secure? Or are they using their own cypher which may be totally borked? Probably still a lot of code out there using single-DES even though that's not enough these days - and a certain company brought DMCA charges against a Russian programmer for revealing their "secret sauce" was rot-13. Some even advertise their "top secret 16000-bit encryption" - any idiot can design a crypto system they don't know how to break. Building one that nobody else can break is incredibly tough (how many cryptographers have designed more than one system that stood up to more than a few years of attempts to break it?) 2) Is key management done correctly? This is the next big weak area for most systems. It may keep a copy of the key around in memory or on disk. If it uses a passphrase to scramble an on-disk private key, it may allow too-low entropy limits on the passphrase. Consider suspect anything that advertises "key recovery" so upper management can get the files back even if a key employee dies/leaves and takes the passphrase with them - the number of crypto experts that can correctly implement a key escrow or a threshold secret sharing scheme is much lower than the number of companies selling stuff that claims to do it. 3) Initialization Vectors: another tricky spot. For instance, the current Linux 'cryptoloop' is known to have an IV scheme that suffers from a watermark attack - if you store content provided by an attacker, they can insert a "watermark" in the data which allows them to conclusively prove their data is on your disk even without knowing the encryption key. This can be a *serious* issue if you are, for example, trying to use encryption to hide a pirated copy of an album from the ??AA copyright police - if they can hand you (possibly via a series of intermediaries) a .MP3 or a movie that they control the bits. they can "tag" it so they can prove it's on your disk... 4) Information leakage - is it possible to get the software to cough up any internal state information it shouldn't? That's just a *partial* list of holes that crypto software can be carrying around. And consider the only reason that anybody ever uses crypto for anything - a hidden crypto hole that you don't know about is is infinitely worse than a bug that merely renders it visibly dead and useless.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050121/01e23276/attachment.bin
Powered by blists - more mailing lists