dropbear - RSA authentication sporadically fails

[Engelmayer Christian]

Hi,

Thanks for the clarification!

> I'm fairly sure that the behaviour of Dropbear is correct

I tend to agree. Your response pointed me to the piece of information
on the "ssh-rsa" key format in RFC 4253 that I was missing before:

   Signing and verifying using this key format is performed according to
   the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using the SHA-1 hash.

Regards,
Christian

> -----Original Message-----
> From: Matt Johnston [mailto:matt at ucc.asn.au]
> Sent: Wednesday, October 28, 2009 12:51 PM
> To: Engelmayer Christian
> Cc: dropbear at ucc.asn.au
> Subject: Re: dropbear - RSA authentication sporadically fails
> 
> Hi,
> 
> I've taken a look at the RFCs (below), and I'm fairly sure
> that the behaviour of Dropbear is correct:
> 
>  From rfc3447
> - k is the length in octets of the RSA modulus n
> - If the length of the signature S is not k octets, output
>   "invalid signature" and stop.
> 
> Regarding interoperability, I'm reluctant to change
> Dropbear's behaviour to handle incorrect implementations.
> I might make an exception in the case where the broken
> client/server is in widespread use, and the changed
> behaviour is obvious.
> 
> In terms of allowing short-length signatures, I'm not sure
> of the consequences. If someone sends a S value with mostly
> 0x00 padding at the front, could that be exploited somehow?
> (I doubt it, but can't obviously tell, and crypto tends to
> be subtle).
> 
> Cheers,
> Matt
> 
> ssh-transport, Page 14
> http://www.ietf.org/rfc/rfc4253.txt
> 
> PKCS, section 4.1 specifically says that there should be
> zero digit padding. 8.2.2 defines how verification
> should work.
> http://www.ietf.org/rfc/rfc3447.txt
> 
> On Tue, Oct 27, 2009 at 10:33:05AM +0100, Engelmayer Christian wrote:
> > Hi Matt,
> >
> > It seems to me that the dropbear daemon enforces clients to use
> > some kind of padding schema for public key authentication. I think
> > it is obvious why there are detailed standards and all good clients
> > do that anyway.
> >
> > I would like to know whether You think it would be a good idea to
> > also allow older clients that use RSA without padding. As said,
> > following the ssh RFCs I was missing the requirement that clients
> > MUST use padding schemes when using RSA.
> >
> > I don’t want to start a discussion on security best practices, but
> > just like to know Your opinion whether that could be a topic that
> > effects more users and should be solved in the daemon as to provide
> > the same level of interoperability as other ssh implementations.
> >
> > Regards,
> > Christian
> >
> > > -----Original Message-----
> > > From: dropbear-bounces at ucc.asn.au [mailto:dropbear-bounces at ucc.asn.au]
On
> > Behalf Of Engelmayer Christian
> > > Sent: Tuesday, October 20, 2009 1:27 PM
> > > To: dropbear at ucc.asn.au
> > > Subject: dropbear - RSA authentication sporadically fails
> > >
> > > Hi,
> > >
> > > I have got the problem that a client that periodically connects
> > > to a dropbear server occasionally fails to authenticate as the
> > > size check in buf_rsa_verify() fails (slen is 127 vs. 128 as
> > > calculated from n).
> > >
> > > 	if (slen != (unsigned int)mp_unsigned_bin_size(key->n)) {
> > > 		TRACE(("bad size"))
> > > 		goto out;
> > > 	}
> > >
> > > Removing the check I can see that the user can be authenticated.
> > > After stepping a bit into the topic it seems to me like the following
> > > issue that was solved for OpenSSH. Also this client only faces the
> > > problem when connecting to a dropbear server.
> > >
> > >
> > >
> >
<http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/rsa-verify-failed
> > > .html>
> > >
> > > At the moment I am not sure whether this check is stricter than
> > > the requirements stated in the RFCs. Any suggestions?
> > >
> > > Regards,
> > > Christian
> > >
> > >
> >
> >