search

BlockchainCommons / Gordian-Developer-Community

Discussions of Gordian principles, Gordian specifications, Gordian references, and making it all a reality.
Other
64 stars 18 forks source link

Creating a new encoding standard based on bech32 for use for cryptographic primitives #5

Open ChristopherA opened 4 years ago

ChristopherA commented 4 years ago

Blockchain Commons has been exploring the use of bech32 for encoding small data for use in URIs and QR codes, in particular for keys, shards, signatures, etc.

Bech32 is specified in https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki and has been updated in something we've been calling bech32bis at https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb to address a specific bug.

The advantage of bech32 is not only that it eliminates commonly visual characters "1", "b", "i", and "o" (like base58 does), but that it does not only error-detection, but also error correction. This means that you can know where in the string the characters are incorrect.

This feature could be particularly useful with public keys and signatures, as it allows for someone to use voice, QR or other low-bandwidth unreliable (but hopefully less-censorable) channels to confirm these cryptographic primitives.

A limitation we have to be careful about is that this capability only works for some sizes of data, and is optimized for 40 bytes, and is great for common sizes of cryptographic data of 32 to 64 bytes, but looses or even make problematic for byte sizes much larger (I've been in conversations with Peter Wuille about another one that is optimized for around 80-128 bytes)

Quoting @sipa in BIP-0173:

An unfortunate side effect of error correction is that it erodes error detection: correction changes invalid inputs into valid inputs, but if more than a few errors were made then the valid input may not be the correct input.…Because of this, implementations SHOULD NOT implement correction beyond potentially suggesting to the user where in the string an error might be found, without suggesting the correction to make.

Also quoting @sipa in https://github.com/BlockchainCommons/AirgappedSigning/issues/4#issuecomment-620327751:

My comment from BIP173 you're quoting doesn't apply if you don't use error correction (which hopefully no BIP173 implementation provides).

Another problem is that the bech32 specification offers more than just the encoding format and includes some items like the human-readable part (HRP) and "1" as the separator between, which can cause a problem with its use in URI schemes, as many of the characters allowed in the HRP are not allowed by URLs without escaping.

Is there any interest in formalizing a new encoding standard for small (32, 64 or 128 byte) cryptographic standards? Or should we stick with bas64url or work on base58 or QR compression optimized encoding?

Some of the items I'd like to see standard URI and QR optimized bech32 encoding of:

-- Christopher Allen

stepansnigirev commented 4 years ago
  • wallet kesy (derived HD xprv plus path)
  • watch keys (derived HD xpub plus path)

Maybe you want to look into this: https://github.com/satoshilabs/slips/blob/master/slip-0032.md

It doesn't include derivation path and parent fingerprint, but can be used as a starting point. It is already using bech32 encoding but is not widely adapted. Actually I've never seen these bech32-xpubs in the wild.

ChristopherA commented 4 years ago

@wolfmcnally has written up a research report on using a derivative of bech32 that we are calling bc32 at https://github.com/blockchaincommons/research and has been implemented in our bech32 library (which supports both) https://github.com/blockchaincommons/bc-bech32

One specific goal Blockchain Commons has in the short term is a cross-wallet QR standard for encoding master seeds (the binary root of both BIP39 and SLIP39), and for encoding SLIP39 shards, and we'd like to see bc32 encoding for this, and possibly some form of URL compatible prefix.

-- Christopher Allen