[LEDE-DEV] Planning v17.01.2

[Vincenzo Romano]

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 */
#define DROPBEAR_ECDSA

/* 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) */
#define DROPBEAR_DELAY_HOSTKEY

/* 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 */
#define DROPBEAR_ECDH

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
--
NON QVIETIS MARIBVS NAVTA PERITVS