Closed py0xc3 closed 1 year ago
vojtechtrefny
commented
1 year ago We do not plan to change the default encryption algorithm. We might do something about the systems without AES-NI support (but that's tracked in the separate issue), but that wouldn't include changes for all systems.
About the SHA usage -- this default comes from cryptsetup and SHA is used only for key derivation and not for data encryption, so there is no combining of AES and SHA anywhere (see the cryptsetup FAQ).
py0xc3
commented
1 year ago About the SHA usage -- this default comes from cryptsetup and SHA is used only for key derivation and not for data encryption, so there is no combining of AES and SHA anywhere (see the cryptsetup FAQ).
I don't know if I get your point. In this case, SHA is connected with AES at two stages within the cryptographic process. The one connection related to my argument is that the SHA output is the actual encryption key for AES (thus, at the related stage, the SHA output is one of the two inputs of AES, while the actual data is the other input of AES). This SHA output has currently an overhead that does not fulfill a cryptographic purpose: this is what I was referring to above.
If your point is that changing the hash algorithm (which is used for a different operation than the PBKDF/Argon2 algorithm) does not make a strong difference since it is invoked once when the disk encryption is set up, I agree in the default use case. Yet, I do not know all use cases and thus if there is a use case where SHA is invoked more often. It's finally a flexible and adjustable technology.
Nevertheless, my major point was AES128 / AES256 anyway given its impact. However, I understand your preference to change such things upstream. I guess that makes indeed most sense. I will open a ticket upstream if I have some time.
I was testing the current preview images of the WebUI installer and saw a little issue in the encrypted devices it creates. I talked to Martin from the Anaconda team who told me that the defaults are set here. I agree that it makes sense to keep it that way.
Concerning the issue: On one hand, the performance is currently not optimal given the default settings. On the other hand, adjusting them can additionally achieve an interim solution for #1108 , whereas this interim solution is likely to be much easier to implement.
At the moment, encrypted devices are created with AES256-XTS, SHA256 and Argon2id. Argon2id is optimal but the combination of AES256 and SHA256 is not: The latter has a practical security of 128 bit given the possibility of collisions (this is not SHA256-specific but a general issue with hash algorithms). This means, in the curent default, the weakest part (SHA256) offers only 128 bit security (implying this disk encryption default offers only 128 bit security)*, and thus the computational power of AES256 (which is the one algorithm in disk encryption that uses computational power permanently) wastes a lot of resources compared to AES128.
However, AES128 is absolutely secure (just like SHA256) while the major security advantage of AES256 (because of its 256 bit) is more or less its resistance to theoretical quantum attacks using Grover's algorithm. The usability of this algorithm is much further in the future than quantum computing, and it is not even known if it can ever be implemented practically. At the same time, the cryptanalysis of AES256 could be argued to be more advanced than that of AES128. That said, both AES128 and AES256 are absolutely secure and in both cases any attack is theoretical while unknown if ever implementable.
Thus, I suggest to not replace SHA256 by SHA512** but to to replace AES256 by AES128. This means, make AES128 with SHA256 and Argon2id the default.
This will lead to a strong performance increase since the cipher (AES) is the major bottleneck in disk encryption.
Furthermore, this can be seen as interim solution for #1108 because the major issue on devices without AES-NI is (obviously) the AES algorithm: AES128 and AES256 make a difference in all cases, but when it comes to devices without AES-NI, the difference can develop to a point where encryption gets unusable with AES256 while AES128 can still offer tolerable performance.
My expectation is that changing the defaults as interim solution might be much easier than implementing #1108 .
However, one of the two possibilities (AES256->AES128 or SHA256->SHA512**) should be implemented to avoid wasting resources. Using SHA512** instead of SHA256 will not have a noteworthy performance impact (neither positive nor negative).
All constellations/constructions and algorithms I suggested/mentioned are already supported by cryptsetup/dm-crypt/luks.
To avoid misunderstandings: there is no security vulnerability. The only security-relevant point here is that one possibility can increase the number of devices that can make use of disk encryption (because of performance), which means increasing these devices' security.
* The cryptsetup/dm-crypt/luks design and its use case for SHA2 hash algorithms might differ from major cryptographic hash use cases, while traditional collision attacks are not applicable here, but allow me to be a bit simplistic at this point because the security of post-quantum / long term encryptions (and their hash functions) that intend to tackle any predictable future attack (which is the only reason to use AES256 over AES128) are expected to be reducible in future to 2^n/3 when it comes to pre-images of hashes ;) Without reading papers, you can find some indication for this in TLS and other standards, where AES256 is intended to go along with 384+ bit hashes (I changed the original comment to avoid confusion)
** because I mentioned it in "*": in this use case, SHA384 does not offer any advantage over SHA512 since SHA384 is SHA512 with 128 bit truncation, which aims to tackle an attack that is not applicable here at all, whereas performance is equal (theoretically, SHA512 is faster given that it does not need a truncation at the end). I have never checked if SHA384 is supported in cryptsetup at all.