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:[email protected]] > Sent: Wednesday, October 28, 2009 12:51 PM > To: Engelmayer Christian > Cc: [email protected] > 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: [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 > > > > > > > > > >
