Re: Crypto in DragonFlyBSD

[Gleb Kurtsou <gleb.kurtsou@xxxxxxxxx>]

On (31/03/2010 11:11), Matthew Dillon wrote:
>     Well, I see two issues.  The first issue of course is the fact that
>     disk blocks are randomly accessed.  A single stream cipher can't be used
>     to encode the whole disk.
There is Salsa20 stream cipher by Daniel Bernstein, suggested for use by
eSTREAM. The cipher is based on hash function and allows key stream
generation from arbitrary position. Skein SHA3 candidate also proposes
similar mode of operation, as some others.

Salsa20 is used in pefs (stacked cryptographic filesystem for FreeBSD):
http://github.com/glk/pefs
Pefs also supports block ciphers in counter mode (AES, CAMELLIA).

Regarding preferring stream ciphers over block ciphers, general opinion
is that stream ciphers are not studied well enough, which was one of the
original goals of eSTREAM project. Stream ciphers are usually used in
environments with strict cpu/memory limitations, or because of being
faster then block ciphers.

>     The second issue... actually a requirement in general for both stream
>     and block ciphers, is that you need a significant amount of random
>     salt in each randomly accessible unit to protect against various forms
>     of attack.  The salt can be applied as part of the encoding/decoding
>     stream (it doesn't have to be all up-front), but the question is where
>     does one store that salt?
I'd suggest that second issues is that vast majority of disk/fs
encryption implementations completely ignore data authentication. GELI
in FreeBSD has it, there is no sign of it in most widely used TrueCrypt
and BitLocker for Windows, available for Linux, it wasn't in OpenBSD
last time I looked at it. You can generate random salt big enough in
advance and store it encrypted with meta data. How much to generate
depends on how secure you think your cipher is. (If that's what you
mean)

Thanks,
Gleb.

> 						-Matt