[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7223877869e4beeeddc92a361aa76fed@smtp.hushmail.com>
Date: Fri, 25 Jan 2013 11:32:45 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Formats ssh and ssh-ng
On 25 Jan, 2013, at 3:04 , Dhiru Kholia <dhiru.kholia@...il.com> wrote:
> On Fri, Jan 25, 2013 at 4:33 AM, magnum <john.magnum@...hmail.com> wrote:
>> On 24 Jan, 2013, at 23:48 , Frank Dittrich <frank_dittrich@...mail.com> wrote:
>> 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 padding length check is based on observations and prior experience ;)
>
>>> 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.
>
> BTW, this check is borrowed from Apple Keychain format.
>
>>> /* 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.
>
> I wouldn't worry too much about this check.
>
> RSA (as used in ssh) uses *big* prime numbers, correct?. In addition,
> ssh-keygen places a minimum key-bits length restriction.
Sounds all good to me then. Maybe the FIXME should be changed to a comment on what it actually is testing.
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.
