[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 10 Sep 2015 19:47:49 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: auditing our use of FMT_* flags
Kai,
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.
Thanks,
Alexander
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.
