[LEDE-DEV] Planning v17.01.2

Vincenzo Romano vincenzo.romano at notorand.it
Thu Jun 15 11:00:01 EDT 2017

2017-06-15 16:41 GMT+02:00 Jo-Philipp Wich <jo at mein.io>:
> Hi,
>> ... and, if I may throw my EUR 0.02 in, why not recompile dropbear
>> with "elliptic curve" support?
> whats the size impact?
> ~ Jo

>From the options.h file I read:

/* ECDSA is significantly faster than RSA or DSS. Compiling in ECC
 * code (either ECDSA or ECDH) increases binary size - around 30kB
 * on x86-64 */

/* Generate hostkeys as-needed when the first connection using that
key type occurs.
   This avoids the need to otherwise run "dropbearkey" and avoids some problems
   with badly seeded /dev/urandom when systems first boot.
   This also requires a runtime flag "-R". This adds ~4kB to binary
size (or hardly
   anything if dropbearkey is linked in a "dropbearmulti" binary) */

/* Enable Curve25519 for key exchange. This is another elliptic
 * curve method with good security properties. Increases binary size
 * by ~8kB on x86-64 */
#define DROPBEAR_CURVE25519

/* Enable elliptic curve Diffie Hellman key exchange, see note about
 * ECDSA above */

Then I have tried a compilation on my x86-64 macchine with defaults
(ECC enabled) and with those 4 options disabled.
In the first case I've got:

dbclient: 228504
dropbear: 233624
dropbearkey: 137736

While in the second one:

dbclient: 194136
dropbear: 203336
dropbearkey: 108120

More or less confirming what's in the options.h.
By rough comparison, my Archer C7 says its dropbear single binary is
176517 bytes long.
Unfortunately I haven't a cross compilation environment at hand right
now to provide RISC binary code sizes.

Maybe one could think about an alternative dropbear-full package.

Vincenzo Romano - NotOrAnd.IT
Information Technologies

More information about the openwrt-adm mailing list