OID Value

[dlegaultbbry]

Currently I use this fake OID value (next available one after blake2 family) but we probably need an official one to be defined

1 3 6 1 4 1 1722 12 2 3 8 : BLAKE3 : blake3

Reference: http://www.oid-info.com/cgi-bin/display?oid=1+3+6+1+4+1+1722+12+2&action=display

[oconnor663]

Apologies for leaving this one hanging for so long. Does anyone know who did this for BLAKE2?

[xnox]

http://www.oid-info.com/cgi-bin/display?oid=1.3.6.1.4.1.1722&action=display

Implies that 1.3.6.1.4.1.1722 was registered to Kudelski SA by Éric Chaubert

if blake3 is no longer associated with above entity, you can ask anybody else to regiester a new oid under their own org.

For example Debian Project has an OID and I guess could register an OID for blake3 if one asks nicely http://oid-info.com/get/1.3.6.1.4.1.9586.100

[xnox]

I think without OID, I will not be able to contribute blake3 to libgcrypt and thus use it for Apt by default.

[xnox]

Is there a draft RFC submitted for blake3 to IETF?

[xnox]

Apperantly it is trivial to apply for oids. I.e. instructions on https://ldapwiki.com/wiki/How%20To%20Get%20Your%20Own%20OID imply that it's just a short form, and then one can have a BLAKE3 oid.

[xnox]

@veorq Hi, would you be able to assist us in allocating / registering / publishing the O.I.D for BLAKE3 under the same O.I.D. as blake2?

Specifically we are hoping to allocate something similar to the BLAKE2 O.I.D. http://oid-info.com/get/1.3.6.1.4.1.1722.12.2.1.8

I.e. http://oid-info.com/get/1.3.6.1.4.1.1722.12.2.3.8 which would then stand for {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) 1722 Kudelski SA cryptography(12) hashAlg(3) for BLAKE3 and 8 for BLAKE3-256 as specified at blake3.io

I hope continuation of keeping the OIDs next to each is ok with you.

Thank you for your time.

[xnox]

I have now submitted http://oid-info.com/get/1.3.6.1.4.1.1722.12.2.3.8 which is pending oid-info review.

Will submit a pull request to the spec document too.

[xnox]

https://github.com/BLAKE3-team/BLAKE3-specs/pull/4/files

[xnox]

http://oid-info.com/get/1.3.6.1.4.1.1722.12.2.3.8 is now live, I think this issue can be closed now.

[oconnor663]

Apologies for not chiming in on this sooner. There isn't a lot of established practice on this yet, but I've argued for avoiding labels like blake3-256, in favor of just calling it blake3 as much as possible. I wrote out a longer version of my reasoning here: BLAKE3-team/BLAKE3-specs#3. Here's a shorter version:

• "BLAKE3-128" is not domain-separated from "BLAKE3-256". The former is just a truncated version of the latter. This is in contrast to BLAKE2, where shorter output lengths are domain-separated.
• "BLAKE3-512" offers no additional security over "BLAKE3-256". This is in contrast to BLAKE2b-512, which does offer more security than BLAKE2b-256. (Note that BLAKE3 is derived from BLAKE2s, and there is no such thing as BLAKE2s-512.)

The vast majority of applications using BLAKE3 should stick to the default output length. I think truncated BLAKE3 should be about as common as truncated MD5. Extended outputs are useful in niche applications, like deriving long or oddly-sized keys for uncommon algorithms, but again not something most applications should think about using. (And because different output lengths aren't domain separated, there's no real sense in which different lengths represent different hash functions.)

As far as I can tell, sets of hash functions with multiple labeled sizes are only as common as they are because of old government standards. BLAKE3 tries as much as possible to remove unnecessary choices. We've avoided concerning the caller with details like the word size or the parallelism degree, and it would be nice not to concern them with output size either.

[xnox]

Apologies for not chiming in on this sooner. There isn't a lot of established practice on this yet, but I've argued for avoiding labels like blake3-256, in favor of just calling it blake3 as much as possible. I wrote out a longer version of my reasoning here: BLAKE3-team/BLAKE3-specs#3. Here's a shorter version:

• "BLAKE3-128" is not domain-separated from "BLAKE3-256". The former is just a truncated version of the latter. This is in contrast to BLAKE2, where shorter output lengths are domain-separated.
• "BLAKE3-512" offers no additional security over "BLAKE3-256". This is in contrast to BLAKE2b-512, which does offer more security than BLAKE2b-256. (Note that BLAKE3 is derived from BLAKE2s, and there is no such thing as BLAKE2s-512.)

The vast majority of applications using BLAKE3 should stick to the default output length. I think truncated BLAKE3 should be about as common as truncated MD5. Extended outputs are useful in niche applications, like deriving long or oddly-sized keys for uncommon algorithms, but again not something most applications should think about using. (And because different output lengths aren't domain separated, there's no real sense in which different lengths represent different hash functions.)

As far as I can tell, sets of hash functions with multiple labeled sizes are only as common as they are because of old government standards. BLAKE3 tries as much as possible to remove unnecessary choices. We've avoided concerning the caller with details like the word size or the parallelism degree, and it would be nice not to concern them with output size either.

Cool, so it's blake3. But that doesn't change the oid numbers right? cause it's just 1.3.6.1.4.1.1722.12.2.3.8 no? and that's the only id registered so far, which i guess should be refer to as just BLAKE3. Or do you dislike that OID number too somehow? I think we do need to specify a child number of .3 and .8 is just as good as any other number.

I guess i should update https://github.com/BLAKE3-team/BLAKE3-specs/pull/4/files to not mention -256, and just call it blake3 there too.

[oconnor663]

I'm unfamiliar with how OIDs work in general, so I might be misunderstanding things. It looks like 1.3.6.1.4.1.1722.12.2.3 is registered as blake3 and 1.3.6.1.4.1.1722.12.2.3.8 (one extra number on the end) is registered to blake3-256. I guess I was hoping that only the former would exist? But if that clashes with how other hashes are defined, I suppose it's really not a big deal. Also am I seeing correctly that no OIDs are defined for any hash other than BLAKE2 and BLAKE3? Maybe this system is less widely used than I assumed from my initial impression?

[xnox]

I'm unfamiliar with how OIDs work in general, so I might be misunderstanding things. It looks like 1.3.6.1.4.1.1722.12.2.3 is registered as blake3 and 1.3.6.1.4.1.1722.12.2.3.8 (one extra number on the end) is registered to blake3-256. I guess I was hoping that only the former would exist? But if that clashes with how other hashes are defined, I suppose it's really not a big deal. Also am I seeing correctly that no OIDs are defined for any hash other than BLAKE2 and BLAKE3? Maybe this system is less widely used than I assumed from my initial impression?

There are OIDs for all hash algos under the sun. You are looking at only those registered by a single private company with 1722. All OIDs are scoped by company IDs.

[xnox]

It seems there is mish mash of OIDs and we can do whatever, i.e.:

• SHA1 http://oid-info.com/get/1.3.14.3.2.26
• SHA256 http://oid-info.com/get/2.16.840.1.101.3.4.2.1
• SHA3 http://oid-info.com/get/2.16.840.1.101.3.4.2.9

So yeah, we can drop 1.3.6.1.4.1.1722.12.2.3.8 and just have 1.3.6.1.4.1.1722.12.2.3 as "blake3" hash algorithm.

But I now wonder if we should allocate OID for every mode of BLAK3 and if more modes might be added later (unlikely). Cause 1.3.6.1.4.1.1722.12.2.3 means hash(input) mode right? What are the OIDs for keyed_hash and derive_key modes? Just use the same ones? or have like 3.1, 3.2, 3.3 for them? Or move the keyed_hash to be under hmacs somewhere under http://oid-info.com/get/1.3.6.1.4.1.1722.12.3?

[xnox]

I'm unfamiliar with how OIDs work in general, so I might be misunderstanding things. It looks like 1.3.6.1.4.1.1722.12.2.3 is registered as blake3 and 1.3.6.1.4.1.1722.12.2.3.8 (one extra number on the end) is registered to blake3-256. I guess I was hoping that only the former would exist? But if that clashes with how other hashes are defined, I suppose it's really not a big deal. Also am I seeing correctly that no OIDs are defined for any hash other than BLAKE2 and BLAKE3? Maybe this system is less widely used than I assumed from my initial impression?

re 256 => blake produces arbitrary length output, but in keyed_hash mode requires a 256-bit key. Hence 3.8 kind of makes sence as a catch all for all three modes of blake3, no?