Thanks for your quick response,
For plain mode, user must provide the cipher, mode and keysize.
Please do not invent autodetection - you just proved it will lead
to data corruption. This is one of the reasons why LUKS was invented,
where cipher and mode is stored in metadata.
My suggestion is to ignore "aes-cbc-plain" and just use current default
(and give user option to overwrite it manually).
Milan
My tool is meant to be simple, that means the user provides only a path to encrypted volume and a passphrase .All other options are default and hard coded and a user can not change them.If a user want to use non default option then the tool is too simple for them as it will lead to unnecessary complexity.
Below is what happen when a user provides a path to an encrypted volume and a passphrase to open a volume
1. The volume is checked to see if its luks or not. If it is, it is then opened as luks with luks default as they are 1.4.1.
2. If a volume is not luks, it is then assumed to be plain and the first attempt is to open it with plain defaults as they are in 1.4.1. If that fail, it is then opened as plain with default values are they were in 1.3.0
I do not see any danger with the current design of supporting both plain modes as long as,as it currently appear to be, mount can distinguish the two. The advise to drop "legacy mode" will make sense if the mount failure is not a guaranteed way to distinguish the two(.it seem to be working so far with vfat, ext3/4 file systems). Is this what you are saying?
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
