Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 10 Sep 2015 19:47:49 +0300
From: Solar Designer <>
Subject: Re: auditing our use of FMT_* flags


On Thu, Sep 10, 2015 at 10:57:41AM +0800, Kai Zhao wrote:
> I try to find the #3 error, here is my step:
>     If (did not set FMT_SPLIT_... ) and (binary_size is not 0)
>         get the original binary
>         change case
>         get the current binary
>         if (current binary is the same as original binary)

This looks right to me.

>             we should check these formats, maybe it need to add
>             FMT_SPLIT... and unifies case in split()
> When should unify case in split() and add FMT_SPLIT... ?

I guess in all cases when "current binary is the same as original
binary", unless we find any exceptions to that.

> I think we should do this when the binary() is case-insensitive.
> E.g. the binary() of "HAVAL-256-3" is case-insensitive, so the
> return of binary() is same when we change the case of ciphertext.

Yes.  You could also apply this logic to salt(), separately.

> If my understand is right, the 'AFS' format maybe has the #3 error.

Yes, it appears to have that error, and I think I'll prefer the
alternative fix (have it refuse to handle the other case), since those
strings are meant to be produced with our own unafs program.



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.