[cryptography] Client TLS Certificates - why not?

Michael Rogers michael at briarproject.org
Wed Mar 6 08:27:32 EST 2013

I don't think most non-programmers would differentiate between a string of hex digits and an arbitrary alphanumeric string, so you might as well use base 32. But do you really need to encode more bits? With a ZRTPish hash commitment / key exchange / confirmation code structure you can detect a MITM attack with probability 1 - 1/2^b, where b is the number of bits in the confirmation code. A 19-bit code fits into six decimal digits and fails to detect a MITM attack with a probability less than one in half a million, which strikes me as a good tradeoff between convenience and security.


ianG <iang at iang.org> wrote:

>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.
>cryptography mailing list
>cryptography at randombit.net

More information about the cryptography mailing list