|
|
Joined: Jan 2004
Posts: 2,127
Hoopy frood
|
OP
Hoopy frood
Joined: Jan 2004
Posts: 2,127 |
Changing the $hotp and $totp 'hash' parameter to 'md5' results in output with a very bad frequency distribution. This group of 8 6-digit passwords should randomly appear only around 80 times in 10,000 tests, but instead they appear nearly 10 times as often:
//var %list 658240 093696 529152 964608 400064 835520 270976 706432 , %i 0 , %x 0 | while (%i < 10000) { if ($istok(%list,$hotp($rand(1,999999),$rand(1,999999),md5,6),32)) inc %x | inc %i } | echo -a 8 passwords appeared %x out of %i times
//var %list 658240 093696 529152 964608 400064 835520 270976 706432 , %i 0 , %x 0 | while (%i < 10000) { if ($istok(%list,$totp($rand(1,999999),$rand(1,999999),md5,6,1),32)) inc %x | inc %i } | echo -a 8 passwords appeared %x out of %i times
Is md5 actually used for either protocol or was it simply offered as a choice because the md5 identifier was already available? I see lots of mentions where MD5 is fine for use with HMAC-MD5, but this is an unrelated problem caused by the way these 2 protocols choose the truncated 32-bit value within the HMAC hash. 'Truncate' chooses 4 bytes beginning with the 1st through 16th byte of the HMAC digest, depending on the value of the final hex digit of that HMAC. The other hashes except MD5 are longer than 19 bytes, so that final 4-bits of the digest is never used as part of 'truncate'. When $hotp receives the HMAC-MD5 digest ending with '*f', 'truncate' begins with the 16th and final byte of the digest, which is reduced by a logical AND of 0x7f to avoid problems with being a signed integer. I could find no documentation anywhere about special handling for using MD5 in HOTP or TOTP, and mIRC's method in this situation is to append 1/2/3 0x00 bytes when the HMAC ends with d/e/f. This means that 1/16th of the time the HMAC ends with 'f', so there are only 8 possible 'truncate' values in the pattern of [0-7]F000000, resulting in the password being only 1 of 8 specific values. When the HMAC ends with the 'd' or 'e' nibble, the 0x00 padding also limits the possible outputs, though not as severely. i.e. when the HMAC ends with 'e' there are 8x256=2048 possible passwords out of the 0-999999 6-digit passwords. The skewed distribution is further demonstrated by these snippets, where a small group of results appear much more often in a pseudorandom output. The first snippet shows the result from using $rand(0,999), where the frequency typically ranges from 0-13. The 2nd and 3rd snippets show the distribution of the 1000 possibilities of the 0-999 last 3 digits of the output, where there is a greater number of 0's and a noticeable group of numbers greater than 13-14, and a group of 8 outputs which are much more common than the others, and are the 8 values shown in the 1st example above.
//var %i 5000 , %dice $str(0 $chr(32),1000) | while (%i) { var %roll 1 + $rand(0,999) | var %dice $puttok(%dice,$calc(1+$gettok(%dice,%roll,32)),%roll,32) | dec %i } | echo -ag $sorttok(%dice,32,n)
//var %i 5000 , %dice $str(0 $chr(32),1000) | while (%i) { var %roll 1 + $hotp($rand(1,999999),$rand(1,999999),md5,3) | var %dice $puttok(%dice,$calc(1+$gettok(%dice,%roll,32)),%roll,32) | dec %i } | echo -ag $sorttok(%dice,32,n)
//var %i 5000 , %dice $str(0 $chr(32),1000) | while (%i) { var %roll 1 + $totp($rand(1,999999),$rand(1,999999),md5,3,1) | var %dice $puttok(%dice,$calc(1+$gettok(%dice,%roll,32)),%roll,32) | dec %i } | echo -ag $sorttok(%dice,32,n)
This bad distribution could be avoided by having the protocol pad from the 1st 3 bytes of the hash instead of padding 2/4/6 0's, but if there is actually a userbase out there using MD5 in the current format, mIRC would have a high percentage of output not 'correct'. At least this warning post could be found if someone searches the forum for $md5 associated with these two identifiers.
|
|
|
|
|
Joined: Dec 2002
Posts: 5,420
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 5,420 |
Thanks for your bug report. This implementation should match the one used by OpenSSL. Have you checked with OpenSSL to confirm whether this identifier is or is not matching it? If it is matching it, it cannot be changed.
|
|
|
|
|
