RSA default key size of 2048 bits too large for low-spec systems
matt at ucc.asn.au
Sat Jun 24 11:02:41 AWST 2017
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.
> On Sat 24/6/2017, at 9:31 am, Brent Roman <brent at 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
More information about the Dropbear