On 17/06/2019 16:39, Ard Biesheuvel wrote: >> >> In other words, if you add some additional limit, we are breaking backward compatibility. >> (Despite the configuration is "wrong" from the security point of view.) >> > > Yes, but breaking backward compatibility only happens if you break > something that is actually being *used*. So sure, > xts(aes)-essiv:sha256 makes no sense but people use it anyway. But is > that also true for, say, gcm(aes)-essiv:sha256 ? These should not be used. The only way when ESSIV can combine with AEAD mode is when you combine length-preserving mode with additional integrity tag, for example # cryptsetup luksFormat -c aes-cbc-essiv:sha256 --integrity hmac-sha256 /dev/sdb it will produce this dm-crypt cipher spec: capi:authenc(hmac(sha256),cbc(aes))-essiv:sha256 the authenc(hmac(sha256),cbc(aes)) is direct crypto API cipher composition, the essiv:sha256 IV is processed inside dm-crypt as IV. So if authenc() composition is problem, then yes, I am afraid these can be used in reality. But for things like gcm(aes)-essiv:sha256 (IOW real AEAD mode with ESSIV) - these are not supported by cryptsetup (we support only random IV in this case), so these should not be used anywhere. Milan -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
