Ok that is good info. What about just doing file level encryption.
As an example you have a disk with a bunch of files, and it is
only those files you would want encrypted, and the issue is more
a confidentiality is required / media loss issue then a tamper issue?
We are looking to use AES-256 for this.
David Gianndrea
Senior Network Engineer
Comsquared Systems, Inc.
Email: [EMAIL PROTECTED]
Web: www.comsquared.com
Victor Duchovni wrote:
On Tue, Oct 18, 2005 at 10:40:21AM -0400, David Gianndrea wrote:
Sorry I forgot to state that it is to encrypt file data on storage
devices such as disks, and tapes. I agree with your statement of
appearance, but im trying to get the folks the resources that they
need to do it correctly. They are currently in the design, and spec
phase of this, so now is the time to make sure there going down
the right track. I forgot about Schneier's "Applied Cryptography"!
I will point them to it as well. Any other words of wisdom would
be a big help.
Look at the design of the CGD crypto-disk driver in NetBSD. Standard
practice in this space for disks is to use CBC with the number encrypted
to yield the IV for the block. For tapes this may be harder, because
tape records may not have a natural index.
It is important to distiguish between the "media loss" threat model
(where only confidentiality is required) and the "media tampering"
threat model (where the attacker might borrow the disk and change the
data). For media-loss confidentiality it is enough to avoid ECB (because
it fails to mask repeated blocks).
Because of atomicity requirements for disk I/O, unless you can
reformat the disk for larger sectors for extra room for a MAC (usually
impractical), you cannot tamper-proof the disk, but you can try to make
it difficult for the attacker to make predictable changes to the disk.
CBC (as used with EGD) is not enough, because one can XOR selected
content into a (cipher) block and jumble the previous (cipher) block.
If one can predict where sensitive content lies on the disk, one may
be able to compromise the system in an undesirable way.
To prevent tampering you need a mode with global error propagation,
I don't have a specific suggestion. None of the standard modes are good
for this, but some are especially bad (avoid ECB and the keystream modes
CFB and OFB).
This is not a simple problem. Plenty of bad designs have been proposed
and implemented (e.g. FreeBSD).
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
