Re: RSA default key size of 2048 bits too large for low-spec systems

[Brent Roman]

Hi Matt,

I like the -R option and am already using it to
eliminate the need to generate keys on the initial system boot.
However, I still generate a public/private key pair for each user the 
first time they log in.

(which could delay that by many tens of minutes for the 2048 bit key)
Maybe I should run the key generation in the background...Hmmm...

ECDSA won't work so well here because of legacy systems (old OpenWRT 
routers) that don't support it.


Thanks again,

- brent


On 06/23/2017 08:02 PM, Matt Johnston wrote:

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  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

Re: RSA default key size of 2048 bits too large for low-spec systems

[Matt Johnston]

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  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
> 
> 
> 

RSA default key size of 2048 bits too large for low-spec systems

[Brent Roman]

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