> And not only that Argon2 provides everything needed to rehash on the fly when these setting change, which makes it really future-proof.
Argon2 itself doesn't necessarily provide this. Rather, this comes from convention and best practices implemented in various password libraries. The unix `crypt` syntax (`$id$rounds=yyy$salt$encrypted`) has been adapted for use with PBKDF2, bcrypt, scrypt, Argon2, etc. by a handful of libraries, and helps you store the algorithm and parameters in the same string so that having multiple formats and updating old ones is trivial. But it's not required for Argon2 implementers and was never mentioned in the original paper - the algorithm itself just specifies a function that returns raw bytes.
It's definitely nice to have, though. For the purpose of password hashing (which isn't necessarily the only thing Argon2 is good for), I wouldn't use a library that didn't have some sort of hash upgrade helper.
Argon2 itself doesn't necessarily provide this. Rather, this comes from convention and best practices implemented in various password libraries. The unix `crypt` syntax (`$id$rounds=yyy$salt$encrypted`) has been adapted for use with PBKDF2, bcrypt, scrypt, Argon2, etc. by a handful of libraries, and helps you store the algorithm and parameters in the same string so that having multiple formats and updating old ones is trivial. But it's not required for Argon2 implementers and was never mentioned in the original paper - the algorithm itself just specifies a function that returns raw bytes.
It's definitely nice to have, though. For the purpose of password hashing (which isn't necessarily the only thing Argon2 is good for), I wouldn't use a library that didn't have some sort of hash upgrade helper.