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?
iang
PS: in stricter metaphorical terms, we are pyramiding the triangle into
a 4 sided die, but squaring sounds easier on the ear.
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
