Score:2

Questions: Argon2, its internal state and security of it when generating keys larger than 256/512 bits

pf flag

Let's suppose I want to use a cipher with a large key size, such as ISAAC that supports 8192 bits ogf key.

I can hash with sha-256 or sha-512 and iterate until reaches the key size but I won't get 8192 bits of security as the internal state of this hash functions are capped to 256 or 512-bits.

I can hash with a XOF (eXtendable Output Function) such as Skein, SHAKE, KangarooTwelve, Blake3 or Blake2x but again the problem is the internal state wich is small and based iterations in the compression function, they don't give a security more than 256/512 bits even if the output is arbitrarily chosen.

Maybe a specialized KDF function can be used such as Argon2 or Scrypt.

My question is specific about Argon2.

The documentation of it says it accepts large inputs for message, salts and its digest size can be arbitrarily chosen.

I compiled a argon2 runtime program to hash files in the terminal such as photos and I can't see difference in timings when the output size is small or large.

$ time cat ~/some_file | argon2-static 00000000 -d -t 2000000 -m 3 -p 1 -r -l 32 &>/dev/null

real    0m6.334s
user    0m6.329s
sys 0m0.004s

$ time cat ~/some_file | argon2-static 00000000 -d -t 2000000 -m 3 -p 1 -r -l 1024 &>/dev/null

real    0m6.455s
user    0m6.443s
sys 0m0.008s

Both 32 byte (256-bits) and 1024 (8192-bits) output sizes have almost equal timings when hashing with Argon2.

This let me doubts.

Has the internal state of Argon2 the same size of output? Or maybe its only iterations on the hash function?

I'm asking this because Argon2 uses Blake2b as a hash function and it has 512-bits of internal state, not 8192 which I want.

Will I have 8192-bits of security if some high entropy input (equal or larger than output) is processed to this output size in Argon2?

Maarten Bodewes avatar
in flag
The question is why you would want more than 256 bits of security.
kelalaka avatar
in flag
And, if you have uniform random 8192-bit key then you don't need any KDF. Besides, let $h_0 = SHA-256(yourRandom)$ than $h_i = SHA-256(yourRandom||h_{i-1})$ is simple solution to mix them. For Argon2, read [the paper](https://www.password-hashing.net/argon2-specs.pdf) and see how it mixes all.
Score:3
cn flag

The vast majority of time in Argon2 is spent filling the vector (or vectors) in memory and iterating over it. The output is generated by hashing the final block. If the output is longer than 512 bits, then only Blake2b is executed a few times. This does not matter at all in terms of time compared to the previous steps. Therefore you don't notice any time difference.

I would say Argon2 can't actually achieve 8192-bit security, only Blake2b's 512 bits. However, this is not really relevant. Currently, 256 bits are considered secure, even when quantum computers appear. I think that won't change for a long time. A time when 512-bit security is no longer sufficient is something none of us will see.

In the case of passwords, we cannot apply the usual standards of bit security anyway. Unless passwords are randomly generated and used once, their bit security cannot be measured unambiguously.

kelalaka avatar
in flag
Yes, that is true that one can only consider the 512-bit input to Blake2's to attack, of course, that is meaningless.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.