On Sun, Jul 20, 2008 at 12:44:04AM -0400, Ted Unangst wrote: > On 7/19/08, Tobias Ulmer <[EMAIL PROTECTED]> wrote: > > > [4] # mount -o softdep /dev/sd0a /mnt > > > [5] # dd if=/dev/arandom bs=1m of=/mnt/imagefile count=... > > > > > > prepare to wait a few days... there is known plaintext at specific > > locations anyway, disklabel, filesystem metadata,... > > very little really. especially if you create the inner > filesystem/disklabel with anything other than the default of all space > in one partition. it's easy to verify a correctly guessed key, but > probably not enough to perform any interesting attacks. > > > > 3. What are the error propagation properties of the svnd encryption? > > > That is, for example, if a disk/USB/memory error corrupts a single > > > 512-byte block in the middle of /dev/sd0a, will that show up as > > > 512 bytes of corruption in /dev/svnd0c, or will the entire > > > /dev/svnd0c be corrupted from that point onwards? > > > > > > Afaik it uses blowfish in CBC mode, so you're fscked... Otoh modern > > disks make quite some noise before they start running out of spare blocks. > > CBC only for disk blocks. Each disk block is independent, otherwise > you get the seek performance of a tape drive.
Doh, right, that wouldn't make any sense. > > > > 4. Is there any upper size limit to the size of an encrypted image > > > apart from the kernel 8TB limit and fsck time and memory usage? > > > For example, is there any problem with using the above on (say) a > > > 250GB disk? > > > > > > No problem, for the paranoid however you might want to read up on the > > birthday paradox ;) > > Not sure what you mean here. There's only 23 hard drives? :) > > Afaik there are (can be?) collisions in images bigger than ~40GB because of blowfishs block size.
