Messages in this thread | | | Date | Thu, 19 Feb 2004 23:06:02 +0100 | From | Carl-Daniel Hailfinger <> | Subject | dm-crypt, new IV and standards |
| |
Hi,
after having read what I believe to be all dm-crypt related mails on lkml, I have a question which I could not find an answer for: (and I noticed Andrew Morton worrying about backwards compatibility)
Would it be sensible (AFAICS there is not technical limitation) to reserve 512/1024/2048/whatever bytes at the beginning of every backing device for dm-crypt so that the dm-crypt device could get some info about the used methods automatically?
So this meta-information superblock could contain the following: - A magic string like CRYPTSPACE (like SWAPSPACE2) - The key used to encrypt the device (the key would be encrypted with the password) - The IV algorithm used - The cipher used - The way the password was hashed - If some conversion was underway last time the dm-crypt device was accessed
This way, the following benefits would appear: - New dm-crypt devices can be differentiated from old cryptoloop ones - Since the password is independent of the key, you can change the password without reencrypting the entire device. - Since the key is independent of the password, you can change the key, reencrypt the entire device and still keep your old password. - You can change the default IV to something more secure than the current default one without having to fear userland breakage. - There are multiple ways to hash a password and with the current scheme we have to try all of them if we do not know which version of the tools was used to create the file. - If the device is currently being reencrypted and is halfway through and the power fails, we would know that some part of the device is old encryption and some part is new encryption. - New (more secure) crypto algorithms/ IV generation schemes/ passphrase hashing schemes could be added (or even made default) without violating the principle of least surprise.
I am not an expert in crypto, so if you tell me this would reduce security or cause other problems, I will accept that. I am aware that the more information an attacker has, the easier it is for him to break the encryption.
Regards, Carl-Daniel
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |