[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3f23e59d190153219377aaffca153609@smtp.hushmail.com>
Date: Fri, 25 Jan 2013 00:03:03 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Formats ssh and ssh-ng
On 24 Jan, 2013, at 23:48 , Frank Dittrich <frank_dittrich@...mail.com> wrote:
> On 01/24/2013 08:06 PM, magnum wrote:
>> I had a look at check_padding_3des() that verifies the result. It's hard to calculate a probability. The padding check might give false *negatives* unless there always is padding present even for blocks that happened to be aligned. But it looks to me it would be a pretty freaking unreal coincidence if it ever made a false positive. If you ask me (but you shouldn't), we could remove the FMT_NOT_EXACT flag.
>
> Is that "false negatives" as in "john might fail to recognize that a
> candidate matches the hash"?
Yes. The format assumes that padding is always applied (by any fork of any version of ssh, ideally including future ones) even when the data is block aligned without it (a pad-only block is added). Maybe this is a perfectly valid assumption because it is specified somewhere, I do not know. If it's just based on observations, it is dangerous. I believe this kind of padding check is pretty common. If it's in the specifications, everything is OK.
> This would be really bad. ssh-ng would need to be orders of magnitude
> faster than ssh to be useful despite such a problem.
> IMHO, it would be unfair to compare the performance of a format which
> might miss candidates with the performance of a format which doesn't.
Yes. False negatives are the absolute worst (by far) bug that can ever hit us. A format with known false negatives would go straight to unused. I can live with false positives.
> Also, these 2 comments don't look like inspiring confidence:
> if(pad > 16) /* FIXME: is this check valid? */
> // "Bad padding byte. You probably have a wrong password"
> return -1;
It is a valid check provided the initial assumption is correct.
> and
>
> /* FIXME: now this integer has to be big, is this always true? */
Yes, that is worrisome. So Dhiru is probably right we should keep the old format, and have this one with lower precedence.
magnum
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.
