[cryptography] Client TLS Certificates - why not?

ianG iang at iang.org
Wed Mar 6 06:51:16 EST 2013

On 6/03/13 14:33 PM, StealthMonger wrote:

> Your only argument is that the key ID is "longer" or more "random".

This of course is the ZT challenge.  The issue isn't that Zooko's 
Triangle can or can't be squared, but that we the developer have to 
square it [0].

> A
> solution is redesign of the hash code so it doesn't have to be so long
> plus maybe merchant generating and discarding lots of keys until
> stumbling on one with a pronounceable hash.

I'm currently working on an invite process from phone to phone.  For now 
I'm just using 6 char hex codes (24 bits).

There's an easy MITM possibility here, which is fineessed by human 
processes, time and code space.  But once the invite process is over, 
assuming no MITM, the phones are locked together (in that the internal 
addressbooks know each other at 1st class crypto level).

I am musing on whether to go to Base 32, like the airline reservation 
codes.  That seems to be workable, in that I personally manage to not 
miss my plane most of the time.

Has anyone got any view as to how complicated a handshake code could be 
before users start making more mistakes than it is worth?


PS: in stricter metaphorical terms, we are pyramiding the triangle into 
a 4 sided die, but squaring sounds easier on the ear.

More information about the cryptography mailing list