Mercurial > dropbear
view INSTALL @ 1672:3a97f14c0235
Add Chacha20-Poly1305, AES128-GCM and AES256-GCM support (#93)
* Add Chacha20-Poly1305 authenticated encryption
* Add general AEAD approach.
* Add [email protected] algo using LibTomCrypt chacha and
poly1305 routines.
Chacha20-Poly1305 is generally faster than AES256 on CPU w/o dedicated
AES instructions, having the same key size.
Compiling in will add ~5,5kB to binary size on x86-64.
function old new delta
chacha_crypt - 1397 +1397
_poly1305_block - 608 +608
poly1305_done - 595 +595
dropbear_chachapoly_crypt - 457 +457
.rodata 26976 27392 +416
poly1305_process - 290 +290
poly1305_init - 221 +221
chacha_setup - 218 +218
encrypt_packet 1068 1270 +202
dropbear_chachapoly_getlength - 147 +147
decrypt_packet 756 897 +141
chacha_ivctr64 - 137 +137
read_packet 543 637 +94
dropbear_chachapoly_start - 94 +94
read_kex_algos 792 880 +88
chacha_keystream - 69 +69
dropbear_mode_chachapoly - 48 +48
sshciphers 280 320 +40
dropbear_mode_none 24 48 +24
dropbear_mode_ctr 24 48 +24
dropbear_mode_cbc 24 48 +24
dropbear_chachapoly_mac - 24 +24
dropbear_chachapoly - 24 +24
gen_new_keys 848 854 +6
------------------------------------------------------------------------------
(add/remove: 14/0 grow/shrink: 10/0 up/down: 5388/0) Total: 5388 bytes
* Add AES128-GCM and AES256-GCM authenticated encryption
* Add general AES-GCM mode.
* Add [email protected] and [email protected] algo using
LibTomCrypt gcm routines.
AES-GCM is combination of AES CTR mode and GHASH, slower than AES-CTR on
CPU w/o dedicated AES/GHASH instructions therefore disabled by default.
Compiling in will add ~6kB to binary size on x86-64.
function old new delta
gcm_process - 1060 +1060
.rodata 26976 27808 +832
gcm_gf_mult - 820 +820
gcm_add_aad - 660 +660
gcm_shift_table - 512 +512
gcm_done - 471 +471
gcm_add_iv - 384 +384
gcm_init - 347 +347
dropbear_gcm_crypt - 309 +309
encrypt_packet 1068 1270 +202
decrypt_packet 756 897 +141
gcm_reset - 118 +118
read_packet 543 637 +94
read_kex_algos 792 880 +88
sshciphers 280 360 +80
gcm_mult_h - 80 +80
dropbear_gcm_start - 62 +62
dropbear_mode_gcm - 48 +48
dropbear_mode_none 24 48 +24
dropbear_mode_ctr 24 48 +24
dropbear_mode_cbc 24 48 +24
dropbear_ghash - 24 +24
dropbear_gcm_getlength - 24 +24
gen_new_keys 848 854 +6
------------------------------------------------------------------------------
(add/remove: 14/0 grow/shrink: 10/0 up/down: 6434/0) Total: 6434 bytes
author | Vladislav Grishenko <themiron@users.noreply.github.com> |
---|---|
date | Mon, 25 May 2020 20:50:25 +0500 |
parents | 986126448688 |
children | 295377ecbf49 |
line wrap: on
line source
Basic Dropbear build instructions: - Edit localoptions.h to set which features you want. Available options are described in default_options.h, these will be overridden by anything set in localoptions.h localoptions.h should be located in the build directory if you are building out of tree. - If using a Mercurial or Git checkout, "autoconf; autoheader" - Configure for your system: ./configure (optionally with --disable-zlib or --disable-syslog, or --help for other options) - Compile: make PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp" - Optionally install, or copy the binaries another way make install (/usr/local/bin is usual default): or make PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp" install (you can leave items out of the PROGRAMS list to avoid compiling them. If you recompile after changing the PROGRAMS list, you *MUST* "make clean" before recompiling - bad things will happen otherwise) See MULTI for instructions on making all-in-one binaries. If you want to compile statically use ./configure --enable-static By default Dropbear adds various build flags that improve robustness against programming bugs (good for security). If these cause problems they can be disabled with ./configure --disable-harden Binaries can be stripped with "make strip" ============================================================================ If you're compiling for a 386-class CPU, you will probably need to add CFLAGS=-DLTC_NO_BSWAP so that libtomcrypt doesn't use 486+ instructions. ============================================================================ Compiling with uClibc: Firstly, make sure you have at least uclibc 0.9.17, as getusershell() in prior versions is broken. Also note that you may get strange issues if your uClibc headers don't match the library you are running with, ie the headers might say that shadow password support exists, but the libraries don't have it. Compiling for uClibc should be the same as normal, just set CC to the magic uClibc toolchain compiler (ie export CC=i386-uclibc-gcc or whatever). You can use "make STATIC=1" to make statically linked binaries, and it is advisable to strip the binaries too. If you're looking to make a small binary, you should remove unneeded ciphers and MD5, by editing localoptions.h It is possible to compile zlib in, by copying zlib.h and zconf.h into a subdirectory (ie zlibincludes), and export CFLAGS="-Izlibincludes -I../zlibincludes" export LDFLAGS=/usr/lib/libz.a before ./configure and make. If you disable zlib, you must explicitly disable compression for the client - OpenSSH is possibly buggy in this regard, it seems you need to disable it globally in ~/.ssh/config, not just in the host entry in that file. You may want to manually disable lastlog recording when using uClibc, configure with --disable-lastlog. One common problem is pty allocation. There are a number of types of pty allocation which can be used -- if they work properly, the end result is the same for each type. Running configure should detect the best type to use automatically, however for some systems, this may be incorrect. Some things to note: If your system expects /dev/pts to be mounted (this is a uClibc option), make sure that it is. Make sure that your libc headers match the library version you are using. If openpty() is being used (HAVE_OPENPTY defined in config.h) and it fails, you can try compiling with --disable-openpty. You will probably then need to create all the /dev/pty?? and /dev/tty?? devices, which can be problematic for devfs. In general, openpty() is the best way to allocate PTYs, so it's best to try and get it working.