<div dir="ltr"><div>We use message digests as data fingerprints in lots of places. OpenPGP being the most visible of course but fingerprints are also used in BitCoin, for software distribution and even in S/MIME</div><div><br></div><div>The OpenPGP group was discussing approaches to a new fingerprint format based on Base32 so that we can squeeze more bits out of the data on a business card. So generalizing a bit, I came up with this:</div><div><br></div><a href="https://tools.ietf.org/html/draft-hallambaker-udf-00">https://tools.ietf.org/html/draft-hallambaker-udf-00</a><br><div><br></div><div><br></div><div>The basic function is </div><div><pre class="" style="font-size:13.3333330154419px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)">   Fingerprint = Version-ID + H ( Content-ID  + ':' + H(Data))

   Where

   H(x) is the cryptographic digest function
   Version-ID is the fingerprint version and algorithm identifier.
   Content-ID is the MIME Content-Type of the data.
   Data is the binary data</pre></div><div><br></div><div>Putting the MIME content type in the scope of the digest means that if the same data string has meaning in two different contexts, an attacker can't perform a substitution attack. It also means that whoever is interpreting the hash has to know the context in which the data is being used.</div><div><br></div><div>The fingerprint is base32 encoded and set in chunks of 5 characters for easier reading/verification. The precision is always a multiple of 25 bits using simple truncation:</div><div><br></div><div><pre class="" style="font-size:13.3333330154419px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)">100 bits - MB2GK-6DUF5-YGYYL-JNY5E</pre><pre class="" style="font-size:13.3333330154419px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)"><pre class="" style="font-size:13.3333330154419px;margin-top:0px;margin-bottom:0px">150 bits - MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ-SV75J</pre></pre></div><div><br></div><div>The version/algorithm identifier also defines the algorithm used. The predefined identifiers are 96 for SHA-2-512 and 144 for SHA-3-512. These produce mnemonics for 'Merkle' and 'Spongeworthy'</div><div><br></div><div><br></div><div>This might seem a little overdone, but the payoff is that say you have trust list as follows:</div><div><br></div><div><pre class="" style="color:rgb(0,0,0);font-size:13.3333330154419px;margin-top:0px;margin-bottom:0px">MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ-SV75J</pre><pre class="" style="color:rgb(0,0,0);font-size:13.3333330154419px;margin-top:0px;margin-bottom:0px"><pre class="" style="font-size:13.3333330154419px;margin-top:0px;margin-bottom:0px">MV75J-C4OZQ-5GIN2-GQ7FQ-EEHFI-W3RGH</pre></pre></div><div>...</div><div><br></div><div>You can have a trust list embedded in a device and it can stand for anything you need to be trusted. Could be the operating system executable, could be a PKIX root cert, could be a PKIX CTL, could be a PGP key. We can now direct all queries of the form 'is this anchor trustworthy' to this one list regardless of context.</div><div><br></div><div>That is something simple enough that we can think about silicon implementation someday.</div><div><br></div><div><br></div><div><br></div></div>