Nicolas Williams wrote: > On Wed, Jan 03, 2007 at 02:57:42PM -0800, John Plocher wrote: >> Re: Using the filesystem's underlying block/sector/whatever info as part >> of the crypto chain >> >> Naive question: Won't this break in situations where the encrypted data >> file is moved between dissimilar filesystems? Or am I misunderstanding that >> part of the conversation? > > I imagine two approaches: > > 1) let lofi read/write from the backend in some specified block size, > but use 512 byte (or whatever other appropriate constant) blocks for > encryption
lofi always does the read/write in DEV_BSIZE (512) chunks and we always use the same size for crypto. > 2) let the lofi block size be as specified Not this case, it isn't needed for this case and I don't believe it has ever been needed for anything else. If you need variable size "records" use a ZVOL and when ZFS gets crypto you will get encrypted ZVOLs as well. > (2) would have to be kept constant at all times for any one lofi device, > else decryption will fail. This is what I meant by more options -> > worse UI. Indeed and that would mean adding a "header" to the file and then we go down the slippery slope of "well we might as well store other things in there". lofi never had a header and this case can do what it needs without one. Note that the existence of a header with security relevant information in it is part of what lead to the brute force attacks on Apples File Vault in MacOS X being easier than they would otherwise have been. > If (1) can be done automatically, so much the better. That what the code for lofi does today and what the current prototype for crypto does. It always DEV_BSIZE operations. -- Darren J Moffat
