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

[roytam]

Dear Matt,

Some months were passed and how is this progressed?

Regards,
Roy

In 2018-7-25 11:14 PM, Péter Szabó  wrote:
>
>
> -- Forwarded message --
> From: Péter Szabó 
> Date: Thu, Oct 5, 2017 at 5:08 PM
> Subject: Re: proof-of-concept ed25519 crypto and other additions implemented
> To: Matt Johnston 
>
>
> Hi,
>
> On Wed, Oct 4, 2017 at 4:49 PM, Matt Johnston  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.
>

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

[Péter Szabó]

-- Forwarded message --
From: Péter Szabó 
Date: Thu, Oct 5, 2017 at 5:08 PM
Subject: Re: proof-of-concept ed25519 crypto and other additions implemented
To: Matt Johnston 


Hi,

On Wed, Oct 4, 2017 at 4:49 PM, Matt Johnston  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\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.

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

[Matt Johnston]

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 


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

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