Re: crypto disk
On Thu, Dec 22, 2005 at 07:32:27PM +0100, Ed White wrote: Quoting from: http://www.onlamp.com/lpt/a/6384 The biggest drawback of svnd is its lack of security in the general use case. It is vulnerable to an offline dictionary attack. That is, you can generate a database mapping known ciphertext blocks on the disk back into pass phrases that can be accessed in O(1) without even being in possession of the disk. What's even worse is that the same database will work on any svnd disk. It is possible--and perhaps even likely--that large agencies such as the NSA have constructed such a database and can crack a majority of the svnds in the world in less than a second. well, i'm not a developer nor a crypto expert, but basically that's just a way to do a brute force attack. it can work only with short keys, say with about 64 bits of entropy or less. that's about 16 random alphabets/digits. building lookup tables for larger keyspaces becomes rapidly unfeasible, so simply use a bigger key and you're safe from this type of attack The way that one prevents an offline dictionary attack is to use a salt in conjunction with the pass phrase, and this is what I did when I wrote CGD by using PKCS#5 PBKDF2. Offline dictionary attacks have been well-known since at least the '70s, and salting the pass phrase has been standard practice for over 30 years. well yes, salting should mitigate the issue Juha
crypto disk
Quoting from: http://www.onlamp.com/lpt/a/6384 The biggest drawback of svnd is its lack of security in the general use case. It is vulnerable to an offline dictionary attack. That is, you can generate a database mapping known ciphertext blocks on the disk back into pass phrases that can be accessed in O(1) without even being in possession of the disk. What's even worse is that the same database will work on any svnd disk. It is possible--and perhaps even likely--that large agencies such as the NSA have constructed such a database and can crack a majority of the svnds in the world in less than a second. The way that one prevents an offline dictionary attack is to use a salt in conjunction with the pass phrase, and this is what I did when I wrote CGD by using PKCS#5 PBKDF2. Offline dictionary attacks have been well-known since at least the '70s, and salting the pass phrase has been standard practice for over 30 years. OpenBSD's solution only supports Blowfish, whereas I wanted to ensure that CGD had the flexibility to support a small range of ciphers. This is important for a number of reasons, but mainly we want to provide our users with the ability to make cost-versus-risk decisions. Blowfish is fast, but probably less secure than AES. In some situations, users will decide that speed is more important than security, and in others the reverse will be true. Also, if security issues are discovered in one cipher that we support, then users can change their CGDs to use one of the other ciphers without needing to upgrade to a new version of the operating system. Blowfish also has a cipherblock size of 64 bits, which for sufficiently large disks might be small enough to allow some level of structural analysis. Is there any chance to see Ted Unangst's port imported?
