Re: [Mathmesh] UDF Design notes

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Aug 14, 2019 at 7:45 PM Michael Richardson <[e-mail]>
wrote:

>
> Phillip Hallam-Baker <[e-mail]> wrote:
>     > The original starting point was the need for a 'better PGP
> fingerprint'. In
>     > particular, I wanted a digest representation that was:
>
>     > * Reasonably compact in both printed and voiced form.
>     > * Supported use of SHA2
>     > * Could be expressed at varying precision as the application needs
> demanded
>     > * Could be upgraded to make use of new algorithms if absolutely
> necessary
>     > * Could be input via a keyboard
>     > * Could be compared for equality
>     > * Could be used to create a fingerprint of any type of data (not
> just keys)
>     > * Support use in QR codes, DNS labels, etc.
>
> I think that this was a rather ambitious set of requirements :-)
>

Unless the requirements actually conflict, I would much rather make a
decision for a reason even if it is not a very strong one than flip a coin.

I don't have strong feelings on whether we should group the characters in
blocks of 4, 5 or 3/5 or whatever.




>     > The choice of Base32 comes from the observation that fingerprints are
>     > frequently read out aloud and having to distinguish case makes the
> process
>     > tedious and error prone. So it cant be Base64 but Base32 gives us
> five bits
>     > per char instead of four.
>
> I agree with your use.
> I wonder if we can train people not to need to mention the case as they
> compare.  I should look again if you specify upper-case only.
>

I am aiming for case insensitive because case is lost in a lot of contexts.
The QR code spec specifies upper case (I think) but the tools almost
invariably convert to lower.



>     > The Type Identifiers for SHA-2 and SHA-3 are chosen so as to cause
> the
>     > first letter of a SHA-2 digest to always be an M (for Merkle-Damgard
> and to
>     > remind us of the Rivest/MD5 legacy) and tthe first letter of a SHA-3
> digest
>     > will always be a K for Keccak.
>
> This was very cute.
>

The design constraint was that the fingerprints must not start with a hex
digit so that UDF and PGP fingerprints remain distinct.

>
>     > The two use cases that I am most tempted to add are representations
> for
>     > public and private key literals.
>
>     > PRO: One spec fits all.
>     > CON: Even 25519 keys are long do we read them out over the phone?
> Perhaps
>     > we should consider Base64?
>
> No, but being able to scan QR codes with public keys is important.
> DPP needs/uses this already.
>

If you want QR codes of the public keys, that would probably mean we should
go for Base32. I would have to actually try it out but I think it turns out
that Base32  maps onto the supported QR code encodings more efficiently
than Base64.

I don't think that reading base64 over the phone will ever be a thing.
> Validating (visually) that a QR scan worked right will be a thing.
> I prefer to keep it all in base32.
>

That is certainly my preference. I will add it into the draft once I have
the sync bug I am chasing sorted. Given the existing code, I think I can
probably hammer it out in a few hours because the code I use to take
fingerprints of public keys is already using the PKIX keyinfo format.

Lets break this out into a separate thread. Can you suggest the data flow?
I am assuming here that this is so I can make a secure connection to a
device over WiFi without Internet connectivity so the connection mechanism
described in the doc isn't exactly going to work :).