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