You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed something odd today updating the Multihash draft for possible IETF consideration:
Multicodec has "KangarooTwelve" once, PR'd in summer of 2020, when the [non-normative] IRTF RFC was in draft 3. At the time, the consensus on the thread was that one entry sufficed, like Blake3. The Named Information Hash registry, on the other hand, added two versions of K12 a year later, when the RFC was in draft 6; I suspect the choice of 256 output length was motivated by the mention of NIST post-quantum threshhold (at 256) from the security considerations section, but I haven't chased down yet where the 512 entry came from.
There might be no action here, but since I've been trying to work roundtrip translation between the two systems into the new draft, it makes for a bit of an ugly corner case-- might make sense just to grab two sigils specifically for k12-256 and k12-516 depending on what I find out from a little more digging, if anyone expresses interest on the mailing list or in the application process. the existing registration can stay put, maybe renamed to k12-variable or k12-xof if we wanted to be extra explicit.
The text was updated successfully, but these errors were encountered:
I noticed something odd today updating the Multihash draft for possible IETF consideration:
Multicodec has "KangarooTwelve" once, PR'd in summer of 2020, when the [non-normative] IRTF RFC was in draft 3. At the time, the consensus on the thread was that one entry sufficed, like Blake3. The Named Information Hash registry, on the other hand, added two versions of K12 a year later, when the RFC was in draft 6; I suspect the choice of 256 output length was motivated by the mention of NIST post-quantum threshhold (at 256) from the security considerations section, but I haven't chased down yet where the 512 entry came from.
There might be no action here, but since I've been trying to work roundtrip translation between the two systems into the new draft, it makes for a bit of an ugly corner case-- might make sense just to grab two sigils specifically for
k12-256
andk12-516
depending on what I find out from a little more digging, if anyone expresses interest on the mailing list or in the application process. the existing registration can stay put, maybe renamed tok12-variable
ork12-xof
if we wanted to be extra explicit.The text was updated successfully, but these errors were encountered: