OK, thanks for the pointers. I realize that you are in no way obligated to incorporate such changes into your official version, but I will try to make these changes in such a way that they may be useful to you...
Right now, after a brief review, my thinking is to add tomsfastmath (TFM) to your BUNDLED_LIBTOM list, and enable it in your options.h, with USE_TFM as per the libtomcrypt document. In places where the changes are more involved than just cut & paste, I will if-def with USE_TFM. thanks for any suggestions! William On Sat, May 25, 2013 at 10:19 AM, Matt Johnston <m...@ucc.asn.au> wrote: > I'd start from 2013.58. It's mostly a case of search/replace > of function calls, though mp_init is a bit different I > think (it allocates whereas the straight libtommath version > doesn't?). Take a look at > https://secure.ucc.asn.au/hg/dropbear/file/75509065db53/ecdsa.c#l169 > - the ltc_mp variable is set up at > https://secure.ucc.asn.au/hg/dropbear/file/75509065db53/crypto_desc.c#l71 > so it could be set to tfm_desc instead. > > Tomsfastmath 0.12 would be best from libtom.org > > Cheers, > Matt > > > > On Sat, May 25, 2013 at 10:01:16AM -0500, William Welch wrote: > > Thank you for your reply. > > > > If I were to attempt to add support for tomsfastmath, using ltc_mp as you > > described, which version of dropbear should I start from? And where > should > > I obtain the tomsfastmath library? > > > > Thank you, > > > > William > > > > > > > > On Sat, May 25, 2013 at 3:41 AM, Matt Johnston <m...@ucc.asn.au> wrote: > > > > > Hi, > > > > > > I think the solution is to use tomsfastmath instead. There was a > patched > > > version posted a while ago on this list. Eventually I'd like to have > > > Dropbear able to build against either tomsfastmath (for speed) or > > > libtommath (for portability) using the ltc_mp mechanism in libtomcrypt. > > > > > > There's also ECC support nearly complete in the 'ecc' mercurial branch. > > > That's a few times faster than normal kexdh. It adds around 30kB to > binary > > > size on x86. That should make it into the next Dropbear release, though > > > only will help for recent OpenSSH peers. > > > > > > Matt > > > > > > > > > William Welch <bvwe...@gmail.com> wrote: > > >> > > >> Greetings, > > >> > > >> First -- thank you for dropbear! I have enjoyed using dropbear on > > >> various smallish systems for years now! > > >> > > >> But I have a problem with a specific system -- admittedly it is rather > > >> slow -- only 50 BogoMips according to the linux kernel. It is a > Microblaze. > > >> > > >> I use the Buildroot system for many different routers and other small > > >> systems here. I have compared different versions of dropbear, against > > >> openssh. > > >> > > >> My issue is with the server mode -- sshd -- I note that on dropbear > 0.52 > > >> (which I happen to run on other routers here), I can connect from my > ubuntu > > >> or mac, to dropbear sshd, in about 45 seconds. This is having > disabled the > > >> RSA host key, and already generated the DSS host key. But on more > recent > > >> versions of dropbear, e.g. 2013.58, several minutes elapse without a > > >> connection. > > >> > > >> In contrast, switching to openssh in buildroot, and also disabling the > > >> RSA host key, connection time is 5 to 10 seconds! Unfortunately, the > > >> openssh has a huge 'footprint' in the flash filesystem that I would > rather > > >> avoid. > > >> > > >> The issue seems to be in the key exchange ( I can watch this by doing > > >> 'ssh -v ' from my client connection). Meanwhile, running 'top' on my > > >> Microblaze shows near 100% cpu used. the debug message is: expecting > > >> SSH2_MSG_KEXDH_REPLY > > >> > > >> Buildroot has the gnu cross tool chain set to 'optimize for size' in > all > > >> cases. > > >> > > >> Suggestions welcome! > > >> > > >> thank you, > > >> > > >> William > > >> > > >> >