[Cryptography] Blockchain without proof of work

Ángel angel at crypto.16bits.net
Fri Jan 11 18:57:21 EST 2019


On 2019-01-06 at 13:29 -0500, Phillip Hallam-Baker wrote:

> I think your confusion is probably due to the fact that I haven't
> pushed out the draft yet which gives the context. This is a
> fingerprint scheme that has been extended to support commitments. It
> was not designed as a pure commitment scheme.
> 
> 
> This is the latest draft but it is not complete. It may still have the
> previous construction in places that did not use HMAC.
> 
> 
> https://tools.ietf.org/html/draft-hallambaker-udf-12

I am a bit worried by the truncation part. The fact that a hash function
is collision-resistant does NOT mean that the first N-bits (in your case
25) are as collision resistant as the whole hash.
Thus, you may find for instance that a SHA2 truncated to 128 bits is
actually suffering more collisions than a "weaker" MD5.

> 
> (...)
> 
> 
> One of the antipatterns I see when using BASE32 fingerprints is that
> folk end up generating fingerprints like MONEY-SXCSN-BFY3H-JBAAD-XKS7D
> or MICRO-SOFTN-BFY3H-JBAAD-XKS7D
> 
> 
> Which seems great at first until you realize that a human is only ever
> going to check the readable part. (...)

If that human misuse is a concern, I think you would have to move to
either use a wordlist (either PGP Word List or a new one). Or perhaps by
completely making it non-readable (like removing vowels) you might get
some people making a better check than readable words that would attract
to be the ones checked, (however, it increases the odds of people not
making any verification at all).

I guess there's also the argument of people actually lowering the
entropy by focusing on generating readable hashes (on the other handit
would be easier to remember a hash of "MONEY-LENDI-NGSER-VICES-BANK").
Even if placing a (human) filter after random key generation for
discarding "ugly hashes" decreases the initial entropy, I am however not
aware of any way that could be actually exploited, provided:
* It uses a strong hash function (pre-image resistance)
* The keys themselves are not weakened for facilitation getting a
readable hash (eg. using composite numbers in place of a prime)
* The generation method does not follow a set of steps that actually
allow cheaper generation of the key.
(in summary, that you still do the things the right way™)


Best regards



PS:  Note the html entities on section 4.



More information about the cryptography mailing list