| Leonard Rosenthol on Sun, 10 Dec 2000 19:37:50 -0500 |
|
At 1:54 PM -0500 12/10/00, Tracy Nelson wrote: > Compressed file systems are HARD to do right, and are alsocovered by a number of patents in that area. You don't want to go there. What's the difference? If the data is compressed by the disk driver then it's a "compressed file system" even if it ALSO happens to do encryption. The issues have to do with the fact that compression chances the size of data, while encryption does not, which means that blocks and byte offsets are no longer static across the driver boundary. > No it's not! The right thing to do, as they do it on otherplatforms, is that crypto goes into the device driver. That appears to be ONLY on Linux. On Mac OS and Wintel, they don't have such problems - which may be due to the fact that companies are willing to spend the money to invest in them there. (and even make the source open!). No, seriously. There are *lots* of ways you can do simple encryption, and without the right tools codebreaking, you're stuck. I'd estimate at least three days, probably more like a week. In some cases it's also a factor of the quality of the passphrase. If we assume that most folks trying to break crypto will run a brute-force dictionary attack on it first (ie. try decrypting using each word in the dictionary), then the less common your passphrase (ie. use of spaces, non-letters, etc.) you're already off to a good start. The second is the use of obscurity in the documentation of the algorithm - ie. security through obscurity. If the encryption algorithm used is not known OR there is no "quick & dirty decryptor too" then the above attack is not going to happen and so you've put another roadblock into play. (of course, NO ONE serious about crypto is going to use a product whose algorithm isn't documented and preferably crypto-reviewed). What sort of PD/OS code is available for codebreaking, anyway?
Or do security consultants generally have their own private bag of tricks? Yes!
|
|