[Folks, I don't seem to be getting messages from zfs-crypto-discuss so I am reading the web archives of zfs-crypto-discuss and replying.]
in http://mail.opensolaris.org/pipermail/zfs-crypto-discuss/2009- November/002951.html Darren Moffat wrote: > SHA256 truncated to 192 bits. You know, I've thought about this sort of thing quite a lot for Tahoe- LAFS and there's a very good reason not to truncate SHA-256 at all. That reason is: now you've got to do your own cryptanalysis work. Suppose open cryptographers publish better and better attacks on SHA-256 in the future. As the attacks get better and better, we'll have to decide how urgent it is to upgrade from SHA-256 to (hopefully by that time) SHA-3. If you're using a truncation of SHA-256 then you might need to jump sooner than other people, and you won't know whether or not this is the case unless you study the attacks yourself! It is possible that a cryptographer will publish an attack on SHA-256 which is evaluated as "not a realistic threat", but which *is* a realistic threat on SHA-256-trunc-192. None of the open cryptographers will be checking or publicly mentioning whether SHA-256-trunc-192 is vulnerable because SHA-256-trunc-192 isn't on their radar. > I have to store the IV because of other features coming in the future. Originally I was calculating the IV based on: object set, object, blockid and transaction group (unsigned 64bit ints). I still do calculate the IV based on those but it needs to be stored. > "Version" of the block doesn't really make sense in ZFS in that way because ZFS is copy on write. Or maybe you can think of the birth transaction id as the version because the other things like the object set, object, level and block id identify the logical filesystem location. I don't understand the last sentence there. Does this mean that you'll never be asked to encrypt more than one plaintext under a different birth transaction id? If, so then perfect! -- use the birth transaction id as the IV! What other features coming in the future would need to know the IV and would not already know the birth transaction id? Something that I still don't understand is: why do you have a MAC tag at all if you already have a SHA-256 hash of the ciphertext? David- Sarah Hopwood suggested a good reason that you might want one [1], but is that your reason? Because how big the MAC tag needs to be is probably determined by why you need it. Regards, Zooko Wilcox-O'Hearn [1] http://www.mail-archive.com/cryptography at metzdowd.com/msg11034.html --- Your cloud storage provider does not need access to your data. Tahoe-LAFS -- http://allmydata.org
