document the purpose of associated data

[vks]

Right now it is not clear what purpose the associated data serves. It would be great if it could be documented.

[bryant]

it's arbitrary data that one could include with the password and salt to compute the hash value. its value is entirely up to you. i think the phase, "optional associated data" hits the nail on its head. do you have a better suggestion?

[vks]

How is that different from the salt?

[bryant]

Salt is a nonce, AD might not be.

[vks]

Salt is a nonce, AD might not be.

This is not clear from the documentation, which does not mention a difference between the salt and the AD (besides the minimal length). Couldn't you just append the AD to the salt? If yes, why have another parameter for that?

[bryant]

why don't you have a look at the argon2 spec?

[vks]

Unfortunately the spec is not very clear on that part. The salt and the associated data enter the algorithm differently, but their conceptual difference is not explained. I opened an issue with the question in the official Argon2 repository. (See P-H-C/phc-winner-argon2#151.)

[xorxornop]

AD is a common inclusion in authenticated cryptographic constructions; it is not unique to Argon2. Usually, it would be used where you wish to have some identifier or descriptor of the encrypted contents that can be read without decryption, but is authenticated by the same system that the contents themselves are. There are variants on this, of course, so one must study the algorithm description to be sure (or find a reputable summary).

[SparkDustJoe]

The discussion on the official repository I think flushes out the idea well enough to get the point across. If you use the AD input, it produces a different result than appending to the salt due to the order of operations, but it acts like a longer salt as far as the cryptographic context is concerned. It can tie a series of operations to a constant within a given system and/or for a specific purpose, something that all operations must contain to produce the same results. The benefit of using the dedicated input is no need on the part of the programmer to manipulate the salt in order to extend it. As pointed out there, however, it can impact the encoding of the output and force the use of the CTX structure input instead of just an encoded string.

[SparkDustJoe]

See P-H-C/phc-winner-argon2#143 regarding encoded strings, the Associated Data and KeyID fields are not produced during the encoded string output, and are not parsed during input, so you are forced to use the context input method when you use either field. Implementation hurdle, but not a show-stopper.

[vitiral]

I got this comment

They quotes from here: https://github.com/P-H-C/phc-winner-argon2

The secret parameter, which is used for keyed hashing. This allows a secret key to be input at hashing time (from some external location) and be folded into the value of the hash. This means that even if your salts and hashes are compromised, an attacker cannot brute-force to find the password without the key.
The ad parameter, which is used to fold any additional data into the hash value. Functionally, this behaves almost exactly like the secret or salt parameters; the ad parameter is folding into the value of the hash. However, this parameter is used for different data. The salt should be a random string stored alongside your password. The secret should be a random key only usable at hashing time. The ad is for any other data.

Something like this would be useful in this library.