Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:18:56 ADT
Greg Rose (ggr@qualcomm.com)
Wed, 24 Jun 1998 16:23:02 +1000
mgraffam@mhv.net writes:
>First, though, how about some ideas about my proposed method..
>I base it on a strong hash. Take some hash function H, and hash the
sector
>number you want to access, concatenated with the user's key. This will
>yield some hash output, H'. XOR H' with the contents of the sector to
>encrypt/decrypt. Simple and fast. The whole system is as strong as the
>hash.. since that is basically all it is. If you need more bits for a
>sector than H' has, generate more bits with H(key+sector_number+H')
>where + is concatenation.
I have a few comments on your proposed use.
1. You are basically using the hash function to create a stream cipher.
There's nothing theoretically wrong with this, except a real stream
cipher could probably outperform a hash function for this purpose. (Some
of the attacks hash functions have to worry about don't apply to stream
ciphers.) That's assuming you are using something like SHA-1 as your hash
function. If you were thinking of coming up with your own hash function,
don't.
2. Using a stream cipher where the key can be repeated is generally a bad
idea. In this case the key is effectively the user's secret plus the
sector number... and since the user's secret will be used to decrypt the
filesystem, we assume it doesn't change much. The sector number doesn't
change much either! It is different for every sector, but sectors can be
reused. So an attacker who can get your machine (and that is the threat
you are worried about for an encrypting filesystem) can use known
plaintext, or can write sectors, to recover the "stream" for that sector;
later, when you've filled the disk with kiddie-porn or whatever, they can
easily recover the contents of the previously mapped sectors. (Of course
they could have planted a trojan horse on your machine while they had it
the first time... so perhaps this is a bit far-fetched.) Alternatively,
if your backup tapes are an image of the (encrypted) drive, by XORing the
old and new contents of a particular sector together, they get the stream
out of the equation and can solve the running-key cipher.
3. An adversary can make changes to the contents of a sector, without
mangling it entirely, by just flipping bits.
As a gross generalisation, stream ciphers are fine for communication but
use block ciphers for storage.
>You could also use a block cipher to encrypt the sector contents with
>the sector number and userkey as the cipher's key. The problem here is
>that you still need a hash algorithm around to hash down the passphrase
>and sector number to some random bits so that eats kernel memory, and
>the function itself will take time. Then you still have to do the actual
>block cipher crypto, which will take some more time. XORing the hash and
>the sector contents can shorten that time considerably, since you need
>to have the hash either way.. this is my main reason.. I'd like disk
>access to be as fast as possible, and all the sectors should be encrypted
>independantly so that any sector can be decrypted without needing to
>appeal to previous state.
>
>The other problem with using a block cipher like this is that most block
>ciphers have long key schedule set up routines, designed to help thwart
>brute force.. since we need to change keys every time we access a sector,
>we will have a time penalty that way.
>
>Any suggestions for a better way to do this?
With a block cipher, you want to use something like Cipher Block Chaining
mode. Now you can do your key setup once, using the user's secret (hashed
or whatever) as the key, then use the sector number as the initialisation
vector, encrypting the sectors independently. This is arguably the
"correct" way to do it.
Block ciphers are also generally faster than hashes, given the way you
were going to use them. I think your appeals to speed are misplaced. When
you say you will "generate more bits" above, you should be aware that
most existing hash functions will take 128 bytes of input, padding to
ensure that they have that much, to produce the 16 or 20 bytes of output.
This is a lot of processing...
Greg.
Greg Rose INTERNET: ggr@qualcomm.com
QUALCOMM Australia VOICE: +61-2-9181 4851 FAX: +61-2-9181 5470
Suite 410, Birkenhead Point http://people.qualcomm.com/ggr/
Drummoyne NSW 2047 B5 DF 66 95 89 68 1F C8 EF 29 FA 27 F2 2A 94 8F
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:18:56 ADT