Re: Creating an encoding standard based on bech32

On Fri, Apr 24, 2020 at 1:31 PM Christopher Allen <> wrote:

> 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?

One thing that I've been wanting to formalize that right leveraging bech32
is a standard for master seeds. These are cryptographic secrets that are
then used by hardware to derive HD master keys (aka xprv & xpub in
bitcoin), and can be saved offline in a mnemonic form (typically 12 or 24
words in BIP39 for bitcoin), or split into shamir shards also sharable in a
mnemonic form (20 or 40 word SLIP39 words).

These secrets are not specific to any cryptographic curve — though these
techniques were pioneered on bitcoin, these techniques are used by most
blockchains, as well as many non-blockchain technologies like secure
messaging, etc.

We've written up a little bit about this
as a possibility of encoding master seeds in their raw form using bech32.

We have a command-line tool in C at (in alpha) where you
can play around with some ideas.

We also have offline airgapped DIY hardware device called #LetheKit which
can create master seeds and transform them into many different forms,
including soon QR codes and hopefully some bech32-like encoding.

[image: A2C503C4-DB80-4DC5-A31E-1E8B63C4FFB3.jpg]

Once we've got agreement on encoding formats for master seeds, I'd like to
puzzle out encoding formats for shards, private and private keys,
signatures, etc., as well as allow for optional metadata (key birthday, HD
path, etc.). All need to be concise for use in URI, QR codes, messaging via
services like Twitter, Ham radio, etc.

We also want to encode these in a variety of formats, so here some initial
research on issues with various encoding schemes and URI constraints:

— Christopher Allen

Received on Friday, 24 April 2020 20:58:41 UTC