Fwd: proof-of-concept ed25519 crypto and other additions implemented

Péter Szabó ptspts at gmail.com
Wed Jul 25 23:10:06 AWST 2018

---------- Forwarded message ----------
From: Péter Szabó <ptspts at gmail.com>
Date: Thu, Oct 5, 2017 at 5:08 PM
Subject: Re: proof-of-concept ed25519 crypto and other additions implemented
To: Matt Johnston <matt at ucc.asn.au>


On Wed, Oct 4, 2017 at 4:49 PM, Matt Johnston <matt at ucc.asn.au> wrote:

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

Please see https://github.com/pts/dropbear-ptscrypto/tree/ptscrypto. I hope
I've done it correctly. Feel free to skip the irrelevant commints and files
(e.g. c.sh and README.txt).

- I don't like the pointer arithmetic https://github.com/
> pts/pts-dropbear/blob/4bb002ccad33a5fa55b88b4216586b09881e0d
> 3c/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.

That's fine for me.

I don't understand the Dropbear merge process yet. The most convenient
option for me would be that someone else does the work of merging and code
cleanup, and I'm available for consultation (e.g. explaining my motivations
and implementation decisions) in e-mail or over chat if something looks
wrong with my code.

-  Agree that SHA512 from libtomcrypt should be used instead.

That's also fine for me.

> - what is the reason for wanting a 8192 bit RSA key.

I have a 8192-bit RSA key which I use rarely, but I want to keep for years
(decades) in authorized_keys on the server.

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

Thanks for the heads up! If I ever start working on it, my plan is to copy
the code from tinyssh, to have something which works quickly. I agree that
the final implementation should use libtomcrypt.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20180725/1ed1020a/attachment.htm 

More information about the Dropbear mailing list