RFC 8018 support

[ysangkok]

It would be nice if the library supported the ASN.1 structures in RFC 8018. Using the standard, it would be possible to use the salt/keyLength/prf configuration in other languages with less conversion work. This would also make it easier to verify that the Haskell implementation is correct.

[Vlix]

You want this library to support this? Do you have a rough example (pseudo code is fine too) on what this would look like?

Verifying that the KDF implementation is correct would be part of the underlying crypto library (i.e. crypton(ite)), no? 🤔

[ysangkok]

@Vlix

You want this library to support this?

Yes, I think it would make sense, since the library is already focused on emitting password hashes that contain additional metadata like iteration count. As far as I understand, this format is called PHC, even though I don't see it mentioned in the documentation. I'd be curious to know how this format was chosen, and if it's not PHC, how come it looks so similar?

Do you have a rough example (pseudo code is fine too) on what this would look like?

From a client perspective, I think usage would be the same. What RFC8018 offers is just an alternative to PHC. Instead of dollar signs, ASN.1 is more tightly packed, and not string based.

Verifying that the KDF implementation is correct

I think this is out of scope since this is just about encoding metadata, not the KDF itself.

[Vlix]

I think I have a better idea what this is about now. Please correct me if I'm wrong:

• RFC8018 is a way to represent a password hash with its accompanying parts
• ASN.1 is a way to define encodeable/decodeable types
• You're suggesting to add a way to output hashes from hashPassword in an ASN.1 type (e.g. using asn-types package?), instead of a Text, so that users of the password package have more ways to en/decode the same "result" from hashing a password?

[ysangkok]

Yes. That is the gist of it. But I am having a hard time finding implementations that actually use ASN.1. So I wonder if those structures aren't actually used by anyone. If that's the case, then this proposal makes no sense.

For now, I suppose it would make sense to document whether the returned format conforms to the PHC specification. Do you know if that's the case?

[Vlix]

From what I've read from the specification, I think yes, the Argon2(id) hash conforms to it. This is kind of how the hashes were decided:

• bcrypt: has it's pre-defined hash format
• PBKDF2: copied from 12100 | PBKDF2-HMAC-SHA512
• scrypt: backwards compatible from the scrypt library
• Argon2: copied from other implementations (which are based on PHC IIRC)

There's an issue (#11) to create/read different types of hash formats, to be more compatible with hashes from other (programming language's) implementations.

[ysangkok]

Oh, I hadn't seen that. I'll close this then, thanks for the pointer!