> David and I have already been discussing this point and agreed to > default to the recommende IV algorithm in all cases. For this particular > choice (and probably also the hash algorithm), we've considered to > change the priority of the question so that it would not be shown in > default installs but only in expert mode. I'm not sure if this can be > accomplished by simply changing the priority, will need to check. So > normal users shouldn't need to see this template at all. Yes, this definitely pertains to expert installs. So "low" priority question (even "medium" would be overkill, imho) and you don't need to change anything except the priority. > Different algorithms exist to derive the IV (Initialization vector) > for each sector. This choice is consequential for the security of the > encryption and there is usually no reason to change this from the > recommended default, except for compatibility with older systems. Probably to be checked by a native speaker but sounds fait to me. > > Proposal: > > > > The encryption key can be provided as a "hash" which is a one-way > > encryption of the key itself. Different hash algorithms can be > > used to create a hash. > > Most of the remarks on IV algorithm apply to this question too. There > is always one hash function that can reliably be used by default, so I > think this too should get lower priority and only be shown in expert > mode. Choosing a non-default hash function can actually decrease the > security of the encryption if the output size of the hash function and > the expected key input size of the cipher don't match. > > I would propose: > > The encryption key is derived from the passphrase by applying a > one-way hash function to it. There is usually no reason to change > this from the recommended default and doing so in the wrong way > can lead to lower-security encryption. > > (Hmm.. not very well worded) Same comment > This template might need further changes in the future, because we > should really try disable the swap space automatically and only show > an error in case that could not be done. I would recommend to have it > remain as-is for the moment until this gets implemented. > > I agree with and like the other changes you've commited, thank you. OK. We leave some time for the comments and I propose that the new templates file is put in place.
Attachment:
signature.asc
Description: Digital signature