Hi Arno. Thanks for the other changes =) On Mon, 2010-08-23 at 02:46 +0200, Arno Wagner wrote: > Since I typically insist on that, I should have done this in > the first place. ;-) > Diexed also for MB and kB. (No GB in there) Yeah,.. I meant of course all of them =) > > May I further suggest, that in all references to 2TB, we add "(= 2^32 * > > 512 bytes)"? > > There's always that problem that one never knows whether TB really means > > TB or TiB. > Instead changed all 2TB to 2TiB. I guess it could be still nice to show the "forumla"... so that people know how that 2 TiB come together... (guess many don't know that dmcrypt _always_ uses 512 byte blocks). btw: That might even qualify for its own FAQ entry,... that it uses always 512byte blocks, and that e.g. the number in the payload offset from luksDump are also blocks. > Well, if it comes up again, I can look at it. I will > however not start to distribute my own FUD and I am > not a good enough cryptographer for a really thorough > analysis of the issue. I am willing to read a paper on > it if somebody else provides the link ;-) Once you should add it... don't forget (which I just realised recently ^^) that it's about the written data in blocks,... not just the written data itself, at least if I understand it correctly. So say we _would_ have a hard limit on 1TB, and I'd just write 1 bit, I'd still have "used up" 512 bytes from my safety buffer, before having to re-encode, right? btw: Milan, do you know about any paper dealing with that issue? Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
