Hi Brent, I'll see about improving the visibility of the default key sizes in options.h and also dropbearkey's printout. I changed to 2048 because 1024 is likely to become breakable within the next few years, it's best to have secure defaults if systems are going to remain un-updated for that timeframe. The change was never mentioned in the CHANGES for 2013.61test - sorry about that oversight, I've added it now.
For a slow device maybe it'd be better to disable RSA and DSS altogether and just use ECDSA keys? Those are siginificantly faster and supported by all recent SSH implementations I know of (at least for desktops and servers). The newer "-R" option can also be used to generate keys on first connection - that might be fast enough with ECDSA. Cheers, Matt > On Sat 24/6/2017, at 9:31 am, Brent Roman <br...@mbari.org> wrote: > > I recently upgraded some low power ARM9 systems from dropbear v0.52 to > v2017.75 > > Everything went well until a system system tried to generate server keys on > first boot. > Then it hung while working to generate the default 2048 bit RSA key. > > Further investigation determined that it had not really hung. > Given many tens of minutes, it would complete the initial boot. > > Why did we decide to change the default to 2048 bit keys given the cost of > generating these on the embedded systems for which it is intended to run? > > The #define for setting the default key size is currently in a .c file. > Could this be moved to the options.h file with a comment recommending > reducing the default size when targeting slow systems? > > Note, I do realize that there is a -s option for dropbearkey, but the > appropriate values for that option are dependent on the key algorithm > selected. I believe the defaults should always be usable. > > Dropbear is a great piece of Open Source software. > > I hope you'll consider this small change. > > - brent > > >