Re: [Cbor] Gordian Envelope and Crypto-Agility for its Hash

[Christopher Allen <[e-mail]>]

On Wed, Mar 8, 2023 at 1:51 PM Vadim Goncharov <[e-mail]>
wrote:

> On Tue, 7 Mar 2023 00:25:22 -0800
> Christopher Allen <[e-mail]> wrote:
> > I'd really not like to go down the alley that Protocol Labs did with
> > https://datatracker.ietf.org/doc/draft-multiformats-multihash/ — our
>
> Read that draft, wanted to ask why ther's no "multi" (several hash at
> once) and what about truncating, if length field seems to be present
> but no utilized. But seemd that this is not your spec?
>

Not really — it was a spec that was originally developed by Protocol Labs
for use with content-addressing schemes like IPFS. Several proposed DID
methods (W3C Decentralized Identifier), in particular from the Web3
community, wanted to use it for DID URNs, and we said that they needed to
document it before we would register them as a preliminary DID method.

They published that as https://github.com/w3c-ccg/hashlink and also shared
it as an I-D. Note that the CCG (W3C Credential Community Group) has no
authority to create standards, but does have the ability to have working
groups to delegate items like these and to also register various list to
community groups, as in W3C working groups are only for 2 years, and the
CCG has been around for over a decade, and there is no equivalent to IANA.
Different standards processes ;-)


> > experience has been that the lack of constraint in that list resulted
> > in a large surface area for attacks.
>
> What do you mean?
>

I don't mean that there have been any CVEs — I'm not aware of any. However,
the design had unintended consequences. How does one really know a hashlink
in SHA256 and hashlink for the same object BLAKE3 are to the same object?
You can't without the original deterministically encoded object, which
turns out isn't always easy in many Web3 protocols, in particular IPFS
where you don't have guarantees of availability. Also, though Web3 does not
require blockchain tokens, many do use them, and there are interesting
opportunities for hash malleability, say  to sell something (say an NFT)
twice.


> > In addition, specifically for us, as the Envelope tag and Wrapped
> > Envelope tag is used so often, adding even more bytes to specify a
> > hash algorithm risks support in constrained environments (for
> > instance, signing on JavaCard is quite limited).
>
> Is 1 byte really too much? What are sizes of packet?
>

Under ordinary circumstances, no, 1 byte doesn't make a difference. But
remember, the design of the structure is envelopes nesting envelopes, so
there is rarely just one.  But we do have implementers now working with
very constrained JavaCard devices (they are using an Gordian Envelope
encoded Shamir to backup private keys from their devices), and we have one
silicon device company (Crossbar/Cramium) that is looking into dCBOR for
encoding data for new chip designs, where dCBOR might be implemented in
silicon logic.

-- Christopher Allen