Re: proof-of-concept ed25519 crypto and other additions implemented
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. >
Re: Dropbear 2019.77
Hello Matt, Matt Johnston wrote: > > Hi Roy, > > On Tue 29/6/2021, at 7:18 pm, roy...@gmail.com wrote: > > > - Make failure delay more consistent to avoid revealing valid usernames, set > server password > limit of 100 characters. Problem reported by usd responsible disclosure team > > > What is the technical reason of limiting server password length to > such a low value? It is even shorter than Windows PATH_MAX which I > think this doesn't make any sense. > > - Change handling of failed authentication to avoid disclosing valid > usernames, > CVE-2018-15599. > > > The problem with longer passwords is that the time taken to calculate a > password crypt is dependent on the length of the password. Passwords longer > than a certain length will take longer to crypt than the failure delay time - > 100 characters was less than what I tried empirically. > > That itself wouldn't be a problem if we could just crypt all incoming > password attempts before checking a username's existence - the problem is > that the password crypt algorithm can vary per user, so the time will vary > too. We have to guess which algorithm to use for unknown users. So rather > than adding some complicated logic I just limited the password length. OK I got it. But does the risk become higher if I change DROPBEAR_MAX_PASSWORD_LEN to higher value. for example, 200? > > Cheers, > Matt Regards, Roy
Re: Dropbear 2019.77
Hi, Sorry for replying such old message, but: Matt Johnston wrote: > > Hi all, > > At long last Dropbear 2019.77 is released. Most changes are > bug fixes, with a few small features. There are security > fixes to avoid revealing the existence of valid usernames. > > This release also merges the fuzzing branch. In a > normal build this should have no effect on operation. > > There are a few larger changes that are ready to merge > that will have to wait for the next release - I wanted to > get this bugfix out of the way first. > > Download at > https://matt.ucc.asn.au/dropbear/dropbear.html > mirror > https://dropbear.nl/mirror/dropbear.html > > Cheers, > Matt > > 2019.77 - 23 March 2019 > > - Fix server -R option with ECDSA - only advertise one key size which will be > accepted. > Reported by Peter Krefting, 2018.76 regression. > > - Fix server regression in 2018.76 where multiple client -R forwards were all > forwarded > to the first destination. Reported by Iddo Samet. > > - Make failure delay more consistent to avoid revealing valid usernames, set > server password > limit of 100 characters. Problem reported by usd responsible disclosure team What is the technical reason of limiting server password length to such a low value? It is even shorter than Windows PATH_MAX which I think this doesn't make any sense. > - Change handling of failed authentication to avoid disclosing valid > usernames, > CVE-2018-15599. > > - Fix dbclient to reliably return the exit code from the remote server. > Reported by W. Mike Petullo > > - Fix export of 521-bit ECDSA keys, from Christian Hohnstädt > > - Add -o Port=xxx option to work with sshfs, from xcko > > - Merged fuzzing code, see FUZZER-NOTES.md > > - Add a DROPBEAR_SVR_MULTIUSER=0 compile option to run on > single-user Linux kernels (CONFIG_MULTIUSER disabled). From Patrick Stewart > > - Increase allowed username to 100 characters, reported by W. Mike Petullo > > - Update config.sub and config.guess, should now work with RISC-V > > - Cygwin compile fix from karel-m > > - Don't require GNU sed (accidentally in 2018.76), reported by Samuel Hsu > > - Fix for IRIX and writev(), reported by Kazuo Kuroi > > - Other fixes and cleanups from François Perrad, Andre McCurdy, Konstantin > Demin, > Michael Jones, Pawel Rapkiewicz Regards, Roy
Re: Password authentication fails
Hello, Dan Stromberg wrote: > > > Hi people. > > I'm attempting to set up dropbear ssh on a mac, for testing something. > > For some reason, password authentication consistently fails for the account > I'm trying: testacct. If I set up RSA authentication for testacct, that > works fine, but I need to use a password for the testing. Do your account "testacct" have a very long password? ( > 100 characters) > > I have OpenSSH set up and running on the same system, so I have dropbear on > an alternate port: tcp/. > > If I log into testacct with a password, on tcp/22 (that is, using OpenSSH), > things work fine. > > My dropbear invocation and messages look like: > $ /usr/local/sbin/dropbear -p 127.0.0.1: -E -R -F > cmd output started 2021 Tue Jul 27 03:41:43 PM PDT > [3228] Jul 27 15:41:43 Not backgrounding > [3237] Jul 27 15:41:47 Child connection from 127.0.0.1:53525 > [3237] Jul 27 15:41:50 Bad password attempt for 'testacct' from > 127.0.0.1:53525 > [3237] Jul 27 15:41:53 Bad password attempt for 'testacct' from > 127.0.0.1:53525 > [3237] Jul 27 15:41:55 Exit before auth from <127.0.0.1:53525>: (user > 'testacct', 2 fails): Exited normally > > And from the clients I see: > $ ssh -p testacct@127.0.0.1 > testacct@127.0.0.1's password: > Permission denied, please try again. > testacct@127.0.0.1's password: > Permission denied, please try again. > testacct@127.0.0.1's password: > > $ dbclient -p testacct@127.0.0.1 > Host '127.0.0.1' is not in the trusted hosts file. > (ssh-ed25519 fingerprint sha1!! > 6f:b7:50:8c:82:87:ce:bf:cc:fd:e3:48:63:12:60:9d:39:17:e2:97) > Do you want to continue connecting? (y/n) y > testacct@127.0.0.1's password: > testacct@127.0.0.1's password: > testacct@127.0.0.1's password: > > What do I need to do to get dropbear server to allow password-based > authentication? > > BTW, I am using Dropbear v2020.81 from homebrew on macOS 11.5.1. > > Thanks! >
