ademarre / binary-mcf Goto Github PK

In README.md I speculated that Modular Crypt Format may have been named by the authors of the Passlib Python library (Eli Collins), but that's probably not true.

I happened upon this commit in the FreeBSD codebase by Brandon Gillespie dated 21 January 1999: freebsd/freebsd-src@0cb1c5b

That may be the introduction of the term (not the format) to the FreeBSD code, but it's not clear if it was coined by Brandon or if it was already in use elsewhere.

I don't know where the name came from, and it is probably not important to anyone, but Passlib wasn't around back then.

Hey, what about the 2b variant as used e.g. by https://www.npmjs.com/package/bcrypt ? Are you interested in keeping your specification up to date? I'd imagine that this variant is probably not the last time that changes are introduced.
I am currently in the process of implementing BMCF in TypeScript/JavaScript and I would like to conform to a consensually formed specification before publishing it.

My current crude implementation is https://github.com/Miladiir/simple-bcrypt/blob/2ca0440962eb3f6619f9020874f99c94dcd8565e/src/BMCF.ts#L30. The codes do not match yours currently and the order is also off, since b is the newest variant.

Just let me know what you think.

0x24 is the ASCII code for $, which is the first character of textual MCF hashes. We can use the 0x2 three-bit scheme identifier to identify unmodified textual MCF hashes. This way, schemes which don't have proper BMCF definitions can still be stored as valid BMCF data, albeit not compactly. And it enables the usage of compact BMCF representations in scenarios where not all schemes have BMCF definitions.

This has the side effect of introducing non-canonical encodings; for schemes with BMCF definitions there would be two legal representations: (1) BMCF and (2) MCF as BMCF. Stored hashes would need to be normalized to MCF before being compared. Lookup by hash would likewise be more complicated. But are these common use cases?

0x2 is currently defined for the original $2$ Bcrypt identifier. As far as I know, this is not in use in any modern systems.

Apparently related to the Password Hashing Competition that selected Argon2 as the winner in 2015, PHC string format can be considered a subset or profile of MCF. It is more thoroughly specified than MCF. It has nice properties that enable the creation of a BMCF definition that could be reused for all PCH string format–compatible schemes:

• it defines a concrete format with four fields: $<id>[$<param>=<value>(,<param>=<value>)*][$<salt>[$<hash>]]
• it defines the legal characters for id, param, and value
• it specifies a max length for id and param
• it designates RFC 4648 Base64 (without = padding) as the encoding to use for the hash digest
• although it does not require the same encoding for the salt, it does define the legal characters for the salt