Hi, some answers below - I will be probably without access to mail for a few days so I will answer other questions next week if needed. On 11/01/2017 05:25 PM, Geo Kozey wrote: ... > What are rough estimates for space overhead of metadata? 0,5%, 5%, 15%? > What are rough estimates for writes overhead of journal? I wish I can link my paper, unfortunately it is still in review. Anyway, this is table from it - metadata per-sector overhead Metadata [bytes] Space (512 sector)[%] Space (4k sector)[%] 4 (32 bits) 0.78 0.10 16 (128 bits) 3.03 0.39 28 (224 bits) 5.26 0.68 32 (256 bits) 5.88 0.78 48 (284 bits) 9.09 1.16 64 (512 bits) 11.11 1.54 80 (640 bits) 14.29 1.92 Journal is usually ~100 MB or so per device. For the performance overhead it is more complicated, but for SSD it is quite usable. More once I can just put the pdf somewhere... > > How concerns about authenticated encryption with FDE were resolved? > i.e disk sector isn't the same size as cipher block, disk errors, see > https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/ With random IV, actually even XTS (without authenticatoin) mode performs very well, and you got all properties that are missing. (Random IV can be stored stored in per-sector metadata.) IOW every write will pseudoramdomly change the whole sector without losing XTS internal parallelization. (XTS was designed to allow internal parallel encryption/decryption of the blocks - this is not mentioned in the blog IIRC.) The same applies for all AEAD modes. And there we ARE authenticating sector data. ... > As (1) and (2) algorithms have serious flaws (speed, nonce reuse) why they are implemented at all? > I think number of supported algorithms isn't an advantage if you can't recommend them for actual usage. > Are there included only for testing and will be removed in stable release? Yes, more or less it is for testing that it can be really used. We do not "remove" anything - you can use whatever kernel crypto API provides. And these are algorithms we have now in kernel - it was used to test that this idea is usable in reality. So it is like you can use AES-ECB for FDE - you can use it, but it is stupid. Once there is something usable (and actually we have student that implements authenticated algorithms from CAESAR competition for kernel crypto API), perhaps we will go this way. For the context, why I am doing all of this - please read (preprint) of discussion I had during SPW2017 workshop (https://www.cl.cam.ac.uk/events/spw2017/) http://www.fi.muni.cz/~xbroz/spw2017-intro-auth-fde.pdf (It is in print now, so I hope I can put at least this authored preprint here...) For the keyring - Ondra can answer this better. But you can switch it off completely off and use old way of sending key through dm-ioctl. And if keyring does not work, it need to be fixed (we already hit several problems). Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
