proof-of-concept ed25519 crypto and other additions implemented

Matt Johnston matt at ucc.asn.au
Wed Oct 4 22:49:33 AWST 2017


Hi Péter,

Thank you for the work. I think most of these look useful and could be merged. I'll have a closer look over them in the next week or so with some more detailed comments.

A few comments for now:

- I'm tending to avoid "make CONFIGVAR=1", I think all of yours can be in options.h instead? You don't have to worry about pulling in unneeded size like keyimport.o - if nothing is called in that file then it will be excluded from the linked executable.
- Can the patches be made from a fork of the Dropbear tree, with the 2017.75 tag? That will make merging/cherry picking easier https://github.com/mkj/dropbear/tree/DROPBEAR_2017.75 <https://github.com/mkj/dropbear/tree/DROPBEAR_2017.75>

- I don't like the pointer arithmetic https://github.com/pts/pts-dropbear/blob/4bb002ccad33a5fa55b88b4216586b09881e0d3c/ed25519.c#L70 <https://github.com/pts/pts-dropbear/blob/4bb002ccad33a5fa55b88b4216586b09881e0d3c/ed25519.c#L70>

	if (buf->pos + 83 > buf->len ||
	    0 != memcmp(buf->data + buf->pos, "\0\0\0\x0bssh-ed25519\0\0\[email protected]", 19)
	   ) return DROPBEAR_FAILURE;
	memcpy(key->spk, buf->data + buf->pos + 19, 64);

Instead it should use buf_getstring(), buf_getbufstring(), buf_incrwritepos() etc.

-  Agree that SHA512 from libtomcrypt should be used instead.
- what is the reason for wanting a 8192 bit RSA key?

I see you mentioned chacha20-poly1305 in the TODO. If you (or anyone else) is going to implement that it would be worth using the upcoming libtomcrypt 1.18 release which supports those. The mode used by OpenSSH may be a bit different though, with a separate cipher for lengths.

Cheers,
Matt

> On Mon 2/10/2017, at 12:26 am, Péter Szabó <ptspts at gmail.com> wrote:
> 
> Dear Dropbear Authors,
> 
> Thank you for your work on Dropbear! It's a great SSH server and toolset for resource-constrained systems, I use it every day.
> 
> This weekend I've implemented a couple of features I've always wanted to have:
> 
> * Added ssh-ed25519 crypto for server host keys and user keys. The implementation is based on TweetNaCl v20140427.
> * Added environment variable propagation (similar to OpenSSH AcceptEnv, command-line flag -A) to Dropbear sshd.
> * Added autodetection and loading of OpenSSH hostkeys to Dropbear sshd (with `make OPENSSHHOSTKEYLOAD=1').
> * Added flag to dropbearkey to generate private keys in OpenSSH format directly (dropbearkey -Z openssh, with `make WRITEOPENSSHKEYS=1').
> * Improved some command-line flags (e.g. dropbear -E is always available).
> * Compilation instructions for pts-xstatic (statically linked i386 Linux binary). Binary size is 350456 bytes.
> * Added option to compile without loading any system hostkeys (e.g. from /etc/dropbear) (with `make NOSYSHOSTKEYLOAD=1').
> * Made dropbearkey behavior is more compatible with ssh-keygen in OpenSSH:
> ** dropbearkey now creates a .pub file.
> ** -b bits flag.
> ** -C comment flag. (The comment will be added to the public key file, and not to the private key file.)
> ** -P passphrase flag. Only the empty passhprase is allowed.
> ** -N passphrase flag. Only the empty passhprase is allowed.
> * Added autodection of the input private key file format, as `dropbearconvert any'.
> 
> The code is in https://github.com/pts/pts-dropbear <https://github.com/pts/pts-dropbear>, which is a fork of 
> dropbear-2017.75.tar.bz2.
> 
> It would be great if these improvements could be merged to upstream Dropbear, so all Dropbear users would benefit. Please let me know what the best course of action would be to make this happen, and how I can help.
> 
> Best regards,
> 
> Péter Szabó

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20171004/a96dabe2/attachment-0001.htm 


More information about the Dropbear mailing list