Guilhem Moulin wrote: > cryptsetup ≥2:2.7.0~ has new default default cipher and password hashing > algorithms for plain mode, which might break some existing setups and > therefore should be mentioned in the release notes. The following text > from cryptsetup=2:2.7.0~rc0-1's NEWS entry can probably be copied > verbatim. > > --8<--------------------------------------------------------------------->8-- > > Default cipher and password hashing for plain mode have respectively > been changed to aes-xts-plain64 and sha256 (from aes-cbc-essiv:sha256 > resp. ripemd160).
"Resp." is a red flag. There is no generally recognised abbreviation for "respectively", because native speakers of English rarely use the word, and especially never ever use it as a conjunction like this. I already said this in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070314#10 but I gather you didn't see that. My suggested version was The default cipher has been changed to aes-xts-plain64 (from aes-cbc-essiv:sha256), and the default hash to sha256 (from ripemd160). If "plain mode" is worth mentioning here, we need to explain what it means. Assuming I'm understanding cryptsetup(8) correctly, maybe: In cryptsetup's "plain" (non-LUKS) mode, the default cipher [...] > The new values matches what is used for LUKS, but the change does NOT > affect LUKS volumes. Number agreement: the values "match" what is used for LUKS. > This is a backward incompatible change for plain mode when relying on > the defaults, which (for plain mode only) is strongly advised against. > For many releases the Debian wrappers found in the ‘cryptsetup’ binary > package have spewed a loud warning for plain devices from crypttab(5) > where ‘cipher=’ or ‘hash=’ are not explicitly specified. The > cryptsetup(8) executable now issue such a warning as well. The opposite number agreement error: the executable "issues" a warning. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
