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: [email protected] [mailto:[email protected]] On > Behalf Of Engelmayer Christian > > Sent: Tuesday, October 20, 2009 1:27 PM > > To: [email protected] > > 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 > > > > > >
