<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">On Sun, Jan 13, 2019 at 8:46 PM Patrick Chkoreff <<a href="mailto:pc@fexl.com">pc@fexl.com</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ángel wrote on 1/11/19 6:57 PM:<br>
<br>
> I am a bit worried by the truncation part. The fact that a hash function<br>
> is collision-resistant does NOT mean that the first N-bits (in your case<br>
> 25) are as collision resistant as the whole hash.<br>
> Thus, you may find for instance that a SHA2 truncated to 128 bits is<br>
> actually suffering more collisions than a "weaker" MD5.<br>
<br>
That I don't understand.  If taking the first 128 bits of SHA-512 is<br>
less collision-resistant than some other 128 bit hash, wouldn't that<br>
indicate a serious flaw in SHA-512?<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">It certainly would and moreover, that is exactly what is done in HKDF and other key derivation functions.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Nor is collision resistance the consideration here. If I am using the digest to authenticate a public key pair, the work factor of interest is how many keys do I have to generate before I can impersonate someone (anyone at all). Which for a 25 character UDF and a user base of a billion keys is approx 2^117/2^30 = 2^87. Which indicates that we should move to 150 character fingerprints as the user base grows or use key compression to increase the work factor.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">On Fri, Jan 11, 2019 at 9:02 PM Ángel <<a href="mailto:angel@crypto.16bits.net">angel@crypto.16bits.net</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail_default"></span>You will probably think this is a very gross solution, but my initial<br>idea for the stated problem was that you simply obtained (eg. with Lets<br>Encrypt, but you can pay for it, too) HTTPS certificates for:<br><a href="http://kd25h-gsne2-jvvje-rxtma-7vawt.villain1of3.20190101prediction.hallambaker.com/" rel="noreferrer" target="_blank">KD25H-GSNE2-JVVJE-RXTMA-7VAWT.villain1of3.20190101prediction.hallambaker.com<br></a><a href="http://kcoo3-ekpag-fkyfc-o2b2n-o3uua.villain2of3.20190101prediction.hallambaker.com/" rel="noreferrer" target="_blank">KCOO3-EKPAG-FKYFC-O2B2N-O3UUA.villain2of3.20190101prediction.hallambaker.com<br></a><a href="http://kbr3a-rqlv7-smb6x-6ob7x-jmbnt.villain3of3.20190101prediction.hallambaker.com/" rel="noreferrer" target="_blank">KBR3A-RQLV7-SMB6X-6OB7X-JMBNT.villain3of3.20190101prediction.hallambaker.com</a> </blockquote><div><br></div><div> No, I like that better than anything to do with blockchain. </div></div></div></div>