<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 23, 2014 at 1:10 PM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

That's a good idea, spending several extra seconds during key<br>
generation may well be worth a fingerprint that's smaller by<br>
20-something bits.<br>
<br>
There's a few obvious twists on this:<br>
<br>
2) Encode x into the fingerprint itself, e.g. use the first 4 bits to<br>
encode the count of zero bytes, allowing for a "scaleable" security<br>
level.<br></blockquote><div><br></div><div>Sounds like a potentially bad idea for usability-can't the attacker can just set their fingerprint to have no zero bytes? A user doing the comparison will probably ignore some extra junk in the middle. This is why I was thinking the system needs to impose a universal minimum.</div>

<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) Instead of searching for a prefix of zero bytes, search for a<br>
fingerprint with a high value in some useability metric.  E.g., my<br>
"base32 pseudoword" format searches for a base32 fingerprint with high<br>
vowel-consonant alternation, which I think makes compact but<br>
pronounceable fingerprints, e.g.<br></blockquote><div><br></div><div>The idea of pronounceable fingerprints sounds nice, but I would advocate separating the work added to make brute-force expensive from the work required by some more complicated hash algorithm which makes pronounceable fingerprints. Intertwining them sounds like poor engineering for the same reason depending on the difficulty of public key generation itself to slow down fingerprint searching is.</div>

</div><br></div></div>