Public HD key export sets "master" flag for public key

[craigraw]

As the title suggests, the ur:crypto-hdkey shared from Derive Key > Other Key Derivations > Public HD Key actually shares the private key information.

[ChristopherA]

Assigned to @wolfmcnally to evaluate and @ChristopherA to prioritize.

[wolfmcnally]

@craigraw I followed the Derive Key > Other Key Derivations > Public HD Key instructions you gave. Below is my test case and analysis:

Seed: Oxford Blue Free Fair

ur:crypto-seed/otadgdzofndnptamfmditpgssnuoladkglsbvaaosecyiaytoentaxkpgwksiyjljpiecxfwjzkpihcxfgjpihihcxfghsinjpcprnvdtk

Public key from Oxford Blue Free Fair

ur:crypto-hdkey/onadykaxhdclaozsnnfhfxadgsotjnahtlfxveonnlrerflubkrsmouybbgrsadputtdsphdlecfjlaahdcxrnstsbsosgvlampmgauedknlwdbdzoimayenmhahgrdpprqzbsnefsrfrntnbdssahtaadehoyaoadaskscxfdfygrihkkcxiyjpjljncxgwksiyjljpiecxfwjzkpihcxfgjpihihcxfghsinjpprpemdhs

a501f503582102fa9e3f43014ca36d05d543e4a599b5bc8b0abf92db144bc22dddd2c8588a196f045820bec7cbc9cae306ad49de2499ea0bfb6a083690054b2db2b40f9f3dbcbeda0bc405d90131a1020109782048444b65792066726f6d204f78666f726420426c756520467265652046616972

{
   1:
   true,
   3:
   h'02fa9e3f43014ca36d05d543e4a599b5bc8b0abf92db144bc22dddd2c8588a196f',
   4:
   h'bec7cbc9cae306ad49de2499ea0bfb6a083690054b2db2b40f9f3dbcbeda0bc4',
   5:
   305(
      {2: 1}
   ),
   9:
   "HDKey from Oxford Blue Free Fair"
}

Private key from Oxford Blue Free Fair

ur:crypto-hdkey/oladykaoykaxhdclaelrkppmhhndlksfpmnylyenfhbwghtbsphecftydtrkyndahecmiabgceoscasegdaahdcxrnstsbsosgvlampmgauedknlwdbdzoimayenmhahgrdpprqzbsnefsrfrntnbdssahtaadehoyaoadaskscxfdfygrihkkcxiyjpjljncxgwksiyjljpiecxfwjzkpihcxfgjpihihcxfghsinjpjpgojtrh

a601f502f5035821008475ad5c9b8cccad9a81363f1354d6c85f19d429bbf6255f1663121ca71dc150045820bec7cbc9cae306ad49de2499ea0bfb6a083690054b2db2b40f9f3dbcbeda0bc405d90131a1020109782048444b65792066726f6d204f78666f726420426c756520467265652046616972

{
   1:
   true,
   2:
   true,
   3:
   h'008475ad5c9b8cccad9a81363f1354d6c85f19d429bbf6255f1663121ca71dc150',
   4:
   h'bec7cbc9cae306ad49de2499ea0bfb6a083690054b2db2b40f9f3dbcbeda0bc4',
   5:
   305(
      {2: 1}
   ),
   9:
   "HDKey from Oxford Blue Free Fair"
}

Analysis

Field 1 is true for both of them, which marks them as "master", as expected.
Field 2 is true for the private key, which marks it as private as expected, and omitted from the public key, which defaults to false hence marking it as public as expected.
Field 3, the key data, is different for each of them, as expected.
Field 4, the chain code, is the same for both of them, as expected.

Reference: HDKey CBOR Spec

Conclusion

I don't seem to be able to replicate the problem. Please let me know if there's something I'm missing here.

[shannona]

Testing out our on our default Yinmn Blue, I also couldn't replicate. Just like Wolf, I had different public & private keys, with only the private key marked appropriately in field 2.

If you can offer any guidance to replicate, @craigraw that'd be great!

[craigraw]

Apologies, I was incorrect - ur:crypto-hdkey does not share the private key.

However, I think there is still a problem. The UR is encoded with the master field as true, however the specification states that:

; A master key is always private, has no use or derivation information,
; and always includes a chain code.

Therefore hummingbird was creating an object that represented a private key - I believe correctly?

[wolfmcnally]

I'm a bit confused: are you saying there is a problem with how SeedTool is encoding non-master URs?

[craigraw]

Yes - specifically that a public key is encoding with the master field set to true, in contravention of the spec.

[wolfmcnally]

Thanks for calling this to my attention. I'm flagging this issue as a bug.