offline keygeneration
Rob Landley
rob at landley.net
Wed Sep 27 13:00:26 WST 2006
On Tuesday 26 September 2006 8:48 am, Matt Johnston wrote:
> I'll have a think about a way that Dropbear could do this by
> default - if the listening process could generate keys while
> waiting for new connections, but break out upon a client
> connecting, that would be quite handy.
If you have to generate a key before you can handle a connection anyway, then
in theory you can just generate the key before blocking in accept(), then
hand that key off to the new connection and calculate a new one before
getting back to accept() in the loop.
The upside is you're using time _before_ a connection comes in to generate the
key, so if there's any downtime at all between connections you have lower
latency answering each new connection, and if they come one after the other
you're not noticeably worse. (You can set a backlog with listen, and if you
have to finish calculating the key before you can let them try to log on
anyway, what's wrong with waiting for the key to finish calculating before
handling the connection at all?)
The potential downside of this is that somebody connecting and dropping
connections to attack the server (with no actual negotiation) can make you
eat CPU, but that's not hard to do anyway.
Not having looked at how that part of the code's implemented, I could be
totally off about this, of course. :)
Rob
--
Never bet against the cheap plastic solution.
More information about the Dropbear
mailing list