On 3 Feb 1999, Niels [ISO-8859-1] Möller wrote: > > 4) create another signer/verifier descendant (dsa_old_signer, > > dsa_old_verifier), which would generate the old-style signatures, this > > would be good, but signer is initialized when the hostkey is read (e.g. > > no version string is known), and as the connection is opened this > > object has to be replaced by an instance of dsa_old_signer _iff_ ssh2 > > is version 2.0.11 or below and the selected keyexchange method is > > diffie-hellman. > > > what is your suggestion? I would go for #4, so I begin implementing it. > > Here are some random thougts on the subject... > > My first reaction is that handling it as a distinct signature > algorithm is probably the right way. The "version string not known > when host key is read" applies only to lshd, right? Perhaps you could > simply initialize two different signer objects. I don't really know > how to fit that into the keyexchange mechanism, though. yes, it applied to lshd. the client does not generate signatures if I understand correctly. as I see, the solution on the client side is quite straightforward, I pass a reference to the connection object to lookup_verifier, so I can decide which algorithm to use. (dsa_verifier or dsa_old_verifier) > Or have the keyexchange mechanism patch "ssh-dss"->"ssh-dss-kludge", > and use this when selecting signer object. There ought to be support > for some alist signature-algorithm -> signer object anyway. I don't understand this signature-algorithm->signer mapping. After the SSH_MSG_KEXINIT message is processed, the selected hostkey algorithm is passed to KEYEXCHANGE_INIT. We'd only have to call MAKE_SIGNER(signature_algorithm), of course the host's private and public keys are needed for this. So what is this mapping about? --- Bazsi
