Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 09 Aug 2012 01:30:38 +0200
From: magnum <>
Subject: Re: mscash2 / hmac-md5 ambiguity

On 2012-08-08 23:27, Alexander Cherepanov wrote:
> On 2012-07-27 09:58, Frank Dittrich wrote:
>> On 07/27/2012 06:58 AM, Frank Dittrich wrote:
>>> On 07/27/2012 12:57 AM, Alexander Cherepanov wrote:
>>>> One solution is to add to hmac-md5 hashes some prefix like
>>>> $HMAC-MD5$ or
>>>> {HMAC-MD5}. BTW why there is none now?
>>> Because for hmac-md5 *any* input is valid, you don't know if a hash is
>>> prefixed, of if "{HMAC-MD5}" just happens to be the begin of an
>>> unprefixed string, so you'd have to convert it to "{HMAC-MD5}{HMAC-MD5}"
> If we always require some prefix in this format then there is no
> problem. When
> the prefix is present then we accept this hash and strip the prefix before
> actual processing. When there are no such prefix we simply reject this hash
> (for this format).

I believe we currently never really require format tags. If you put a
dynamic_0 tag on a 32-character hex string, it will be recognized as a
raw-md5 with no --format given. If you do not use the tag, you can load
the bare hash using --format=raw-md5. I really like it this way so I
think I disagree with the above idea.

However, I did not write the hmac-md5 format (I did optimize it a while
ago). When I wrote the hmac-sha1 I just mimiced the md5 one. If we have
concensus on some new input format (like putting the salt last) I have
no objections. I haven't seen this format ITW in any form btw.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.