"2b" Variant
Closed this issue · 3 comments
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.
Thank you for checking in on this. I think it's worthwhile to keep this up to date for Bcrypt and add the 2b
variant.
Spec considerations
I think you have the right idea by taking over the 0xA0
/0b10100000
scheme identifier. I had originally reserved that for the $5$
SHA-256 Crypt scheme, but it's safe to take over since $5$
was never defined for BMCF. And even if we want to define $5$
in the future, 0xA0
would be a slightly wasteful identifier for it since that scheme does not have an efficient use for the remaining 5 bits of the header byte the way Bcrypt schemes do.
For this spec, we need to keep the previous Bcrypt identifiers as they are, so 0xA0
will be assigned to 2b
. We will then have these Bcrypt scheme identifiers:
0x20 $2$ Bcrypt
0x40 $2a$ Bcrypt
0x60 $2x$ Bcrypt
0x80 $2y$ Bcrypt
0xA0 $2b$ Bcrypt
I can update this BMCF spec for this, and I recommend you update your implementation to match.
One more thing, issue #2 will potentially change the way 0x20
is used. If your implementation is based on https://www.npmjs.com/package/bcrypt , then it shouldn't affect you at all, but you might be interested nonetheless. If you have any feedback on whether #2 is a good idea or not, I'm all ears.
Thank you!
Thank you for your swift response! I'll update the codes and reference this repo once I feel confident in my code. Thanks for the spec. I wouldn't have thought to store the hashes in a compact way otherwise. Feel free to close this issue if you want to.