<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 13, 2015 at 3:52 PM, Ray Dillinger <span dir="ltr"><<a href="mailto:bear@sonic.net" target="_blank">bear@sonic.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
<br>
On 06/06/2015 12:48 PM, Alexandre Anzala-Yamajako wrote:<br>
> Just a thought...<br>
> If we re going to kill of md5sum and break user's habits and scripts we<br>
> might as well do it once and for all.<br>
> Why not build a tool called hashsum whose options are md5 sha2 sha3 and<br>
> blake2 ? This tool could be transparently updated wo breaking compatibility<br>
> in the future and the man page would explain the rationale for each option<br>
> (md5 would be indicated as deprecated but there for verifying old file<br>
> hashes for example)<br>
<br>
</span>But the problem with 'hiding' the hash algorithm behind a toool<br>
named hashsum is that if the algorithm behind it ever changes,<br>
then a bunch of big userland software archives, repositories,<br>
filesharing systems, and databases will immediately break.<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Breaking existing userland stuff isn't something you can fix<br>
by hiding the change behind a generic name suitable for scripts<br>
etc. Any change means that all the existing checksums are no<br>
longer good, and all the data in those vital applications is<br>
suddenly useless.<br>
<br>
What's needed is a way for migration of userland applications<br>
from one hashing algorithm to another to happen. That means<br>
additional functionality has to be added to all that database,<br>
archive, and repository software: It needs to be able to take<br>
a one-time command to replace (all and _only_ the correct)<br>
checksums of the current algorithm, with checksums that are<br>
correct according to the new algorithm.<br></blockquote><div><br></div><div>We had a long discussion of this on the OpenPGP list. This is the result:</div><div><br></div><div><a href="https://tools.ietf.org/html/draft-hallambaker-udf-00">https://tools.ietf.org/html/draft-hallambaker-udf-00</a><br></div><div><br></div><div>The basic idea is that the fingerprint consists of a version/algorithm identifier which is initially one byte and an optionally truncated hash value. The default encoding is Base32 which is the best compromise between density and convenience.</div><div><br></div><div>The initial spec has code points for SHA-2-512 and SHA-3-512 (the latter obviously not implemented yet).</div><div><br></div><div><pre class="" style="font-size:13.3333330154419px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)"> The binary encoding of a fingerprint is calculated using the formula:
Fingerprint = Version-ID + H ( Content-ID + ':' + H(Data))</pre></div><div><br></div><div>The point to this scheme is that it allows one fingerprint to be used to declare a trusted anchor of any type or format. In the crypto space these might be:</div><div><br></div><div>* Open PGP Key Binding application/openpgp-key-v5</div><div>* PKIX KeyInfo element application/pkix-keyinfo</div><div>* DNSSEC trust anchor application/dnsssec-key</div><div><br></div><div>If you don't know the content type of a data blob, you can efficiently check against a list of known content types without having to reprocess the content each time.</div><div><br></div><div>A code distribution is a type of trust anchor. We could use the content type application/executable but it is probably better to differentiate according to processor architecture, binary format, etc. </div><div><br></div><div>One of the changes in the industry that more folk should be taking notice of is that Microsoft has put their .NET code out under an MIT open source license and will be supporting OSX and Linux platforms. Starting to use managed code by default for crypto and network code would be a huge step forward in security.</div><div><br></div><div><br></div><div><br></div></div></div></div>