[Cryptography] hash size

[Peter Fairbrother]

On 01/11/18 13:21, Phillip Hallam-Baker wrote:
[...]
> This is something I have spent quite a bit of time thinking about in the 
> design of the Mesh.

I haven't been following lately, could you give a summary please?

> 
> The only digest algorithms I use in the Mesh are SHA-2-512 and 
> SHA-3-512, truncating to whatever number of bits I need to achieve the 
> necessary work factor. The Mesh uses UDF fingerprints which are 
> presented for human readability in Base 32 with as many digits as are 
> needed to provide the desired precision:
> 
>     Text Presentation (100 bit)  SCFIN-CQGDR-KG47R-7OVPZ
> 
>     Text Presentation (125 bit)  SCFIN-CQGDR-KG47R-7OVPT-TCHZ5
> 
>     Text Presentation (150 bit)  SCFIN-CQGDR-KG47R-7OVPT-TCHZ7-UXY4I
> 
>     Text Presentation (250 bit)  SCFIN-CQGDR-KG47R-7OVPT-TCHZ7-UXY5S-
>        CFSMN-YBKBP-FELHX-I56EH


Sounds very like the "mash" I proposed here years ago, eg see

http://www.metzdowd.com/pipermail/cryptography/2013-September/017564.html

> The scheme also allows for compression. If the first 25 bits are all 
> zero, there is an efficient way to express this that saves five characters.

To get that you need to do 2^25 work on average, increasing the workload 
on an attacker and (perhaps) decreasing the number of bits required.

100 human-readable bits (4 x 5-blocks) with the first 25 at zero from a 
good hash gives a very acceptable 125 bits of security against 
non-birthday attacks.

This means that a user needs to do 2^25 hashes in order to generate an 
identity mash - but he only has to do that once. If everybody does that 
- and why not? - there is no need to indicate it has been done.



One small point, I used to suggest using a 31-character alphabet - a-z 
plus 0-9 excluding 0125 and i because they can be confused with oizs and l.

However now I include i for a 32-character alphabet, as any confusion 
between i and l would require different capitalisation.

> How many bits do you need though? It really depends on the work factor 
> you require to prevent an attack against a particular use.
> 
> When people are exchanging credentials peer to peer, then 100 bit work 
> factor is probably acceptable (today at least). But 125 bit is obviously 
> better.
> 
> The truncation mechanism is deliberately designed to allow users to 
> truncate the UDF by truncating the string. This allows for fingerprint 
> strengthening. if a short UDF is matched against a long one, the longer 
> representation is stored for future comparison. This allows use of a 
> shorter representation for user interface tasks without compromising 
> future use.

Sounds like a bad idea.

Users can be compared with idiots as far as security goes - and why 
shouldn't they be, that is our job, not theirs. To Quote the Operative: 
Secrets are not my concern. Keeping them is.

Using mixed lengths gains little, and opens the risk that a too-short 
length might be used somewhere. If lengths are fixed, that becomes 
impossible.

> 25 characters (125-8 bits) are acceptable for a business card. 

20 is better for human use. 16 (4 x 4 characters) is better still. But 
with a little stretching as above 20 (+5) is cryptographically OK except 
for birthday attacks and maybe quantum computing.

Birthday attacks aren't really a problem as they are necessarily 
untargeted, and one side of the birthday, the list of mashes in use, is 
unlikely to exceed say 2^33, one for each human on the planet - an 
attacker would have to do more than 2^92 work to find each collision 
with a mash in use, and then it would probably be for someone uninteresting.

QC? well, that's another story ...

> The other use I make of digests is to create strong internet names 
> (SINs). This is a DNS name that contains a UDF 

UDF? user-defined-function?

> fingerprint of a security 
> policy statement that controls the interpretation of the name. So if 
> SCFIN-- is the fingerprint of the ICANN root cert (it isn't), we can 
> create an absolute SIN that says 'validate this against DNSSEC'
> 
> alice at example.com.mm--SCFIN-CQGDR-KG47R-7OVPT-TCHZ7-UXY4I

A bit long-winded, but yes - and you can do it with IPs too.

However, I think you may have missed the main thrust of mashes - you do 
not include the email address on the business card or human-readable 
directory entry, only the mash.

Effectively, the mash is the email address.

And/or the telephone number. And/or the true address, or whatever you 
want it to be.

That way a sender has to lookup the mash, thereby finding the 
recipient's public key, before he can send a message. This means eg you 
can write software so that sending unencrypted messages is so difficult 
as to be beyond the capabilities of the average user.

It makes transitioning a little tricky, but any transitioning to eg a 
secure email service is going to be tricky. I have some ideas about that 
if you are interested.


> (NB, I no longer work for a CA).

Pleased to hear that - your designs were suffering because you wanted to 
find a use for a TTP.

Strangely, mashes do have a place for a semi-trusted third party - 
storing mashes, receiving mash requests, and sending the original with 
the user's name, public key, email address/IP etc to whoever wants it.

-- Peter Fairbrother