Dear Matt, Some months were passed and how is this progressed?
Regards, Roy In 2018-7-25 11:14 PM, Péter Szabó <pts...@gmail.com> wrote: > > > ---------- Forwarded message ---------- > From: Péter Szabó <pts...@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 <m...@ucc.asn.au> > > > Hi, > > On Wed, Oct 4, 2017 at 4:49 PM, Matt Johnston <m...@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/4bb002ccad33a5fa55b88b4216586b09881e0d3c/ed25519.c#L70 >> >> if (buf->pos + 83 > buf->len || >> 0 != memcmp(buf->data + buf->pos, "\0\0\0\x0bssh-ed25519\0\0\0@", 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. >
