Re: sha256 in "AF hash" despite using sha512 during luksFormat

Hi Milan,

I appreciate your reply.

Note that I don't have a very good knowledge in crypto.

I prefer sha512 over sha256 only because I've read that it is slightly
more difficult for GPUs to brute force, because they normally have
32bit operations.
Links to two sources (same author, "Thomas Pornin"):
https://security.stackexchange.com/questions/86082/hashing-algorithm-for-cryptsetup
https://security.stackexchange.com/questions/40208/recommended-options-for-luks-cryptsetup

I don't mind the relatively minor performance impact for read/write operations.

> it is much
> faster to try to decrypt some sector where you can detect correct plaintext
> than to use slow digest PBKDF2 here.

Do you mean that in the given scenario it is much faster to find the
LUKS master key by decrypting a plaintext sector which is encrypted
with AES rather than trying to find the LUKS master key via PBKDF2?
Which means that in the given scenario AES is "weaker" than PBKDF2?
Also, I assume it is difficult to find an encrypted sector which has a
high chance to be plaintext when it is decrypted.
I assume that plaintext sectors probably are the least common type of
sector (there are images, videos, executables etc. which easily take
space on the storage )

Best regards,
David.






On Sat, Sep 10, 2022 at 8:25 AM Milan Broz <[email protected]> wrote:
>
> On 10/09/2022 00:50, [email protected] wrote:
> > Dear cryptsetup/LUKS Team,
> >
> > I was using sha512 in the luksFormat command.
> > Later I used luksAddKey while thinking that it should be using the
> > sha512 hash that I defined in luksFormat.
> > But, when I did luksDump, then I noticed that the field "AF hash" for
> > the second key (which was added via luksAddKey ; its keyslot is #1)
> > contains the value "sha256".
>
> The digest hash remains the same. it is changed only if the digest
> is recalculated later (reencryption).
>
> (In LUKS1 there was only one hash algorithm used for everything,
> in LUKS2 you can have different algorihms per keyslots, digest and AF but
> for digest and AF there is no API co change it later.)
>
> BTW SHA512, specially for AF, is overkill, it will not help anything.
> Why do you want to use it there? The whole idea for AF is just to
> diffuse the key on a larger area - any hash algorithm here works ok.
>
> For digest it has no security improvement either, as the input is
> randomly generated key and if you want to run bruteforce on it, it is much
> faster to try to decrypt some sector where you can detect correct plaintext
> than to use slow digest PBKDF2 here.
>
> m.



-- 

Best regards,
David.