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
