<div dir="ltr">Greetings,<div><br></div><div style>I completed a first cut of the fast math version -- sadly, it did not help much. 狢 went back to my linux PC and did some testing with valgrind/callgrind -- and, according to callgrind, for both the tommath and the fast math versions, the hot spots are in tight loops inside of fp_montgomery_reduce and fast_mp_montgomery_reduce. The 2nd hot spot is in fast_s_mp_sqr and the similar routine in fast math.</div>
<div style><br></div><div style>I am pondering my next step -- I guess I will study those inner loops and see why they are so slow on the microblaze -- but I am a bit confused by the fact that openssh / sshd completes in 5 to 10 seconds on the same system...</div>
<div style><br></div><div style>If there is interest in these modifications to dropbox for fast math, let me know and I will send them or put them online. �The changes are pretty clean -- just a couple of things as mentioned previously.</div>
<div style><br></div><div style>Suggestions welcome!</div><div style><br></div><div style>William</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, May 25, 2013 at 10:19 AM, Matt Johnston <span dir="ltr">&lt;<a href="mailto:matt@ucc.asn.au" target="_blank">matt@ucc.asn.au</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I&#39;d start from 2013.58. It&#39;s mostly a case of search/replace<br>
of function calls, though mp_init is a bit different I<br>
think (it allocates whereas the straight libtommath version<br>
doesn&#39;t?). Take a look at<br>
<a href="https://secure.ucc.asn.au/hg/dropbear/file/75509065db53/ecdsa.c#l169" target="_blank">https://secure.ucc.asn.au/hg/dropbear/file/75509065db53/ecdsa.c#l169</a><br>
- the ltc_mp variable is set up at<br>
<a href="https://secure.ucc.asn.au/hg/dropbear/file/75509065db53/crypto_desc.c#l71" target="_blank">https://secure.ucc.asn.au/hg/dropbear/file/75509065db53/crypto_desc.c#l71</a><br>
so it could be set to tfm_desc instead.<br>
<br>
Tomsfastmath 0.12 would be best from <a href="http://libtom.org" target="_blank">libtom.org</a><br>
<br>
Cheers,<br>
Matt<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Sat, May 25, 2013 at 10:01:16AM -0500, William Welch wrote:<br>
&gt; Thank you for your reply.<br>
&gt;<br>
&gt; If I were to attempt to add support for tomsfastmath, using ltc_mp as you<br>
&gt; described, which version of dropbear should I start from? 鼦nd where should<br>
&gt; I obtain the tomsfastmath library?<br>
&gt;<br>
&gt; Thank you,<br>
&gt;<br>
&gt; William<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Sat, May 25, 2013 at 3:41 AM, Matt Johnston &lt;<a href="mailto:matt@ucc.asn.au">matt@ucc.asn.au</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; Hi,<br>
&gt; &gt;<br>
&gt; &gt; I think the solution is to use tomsfastmath instead. There was a patched<br>
&gt; &gt; version posted a while ago on this list. Eventually I&#39;d like to have<br>
&gt; &gt; Dropbear able to build against either tomsfastmath (for speed) or<br>
&gt; &gt; libtommath (for portability) using the ltc_mp mechanism in libtomcrypt.<br>
&gt; &gt;<br>
&gt; &gt; There&#39;s also ECC support nearly complete in the &#39;ecc&#39; mercurial branch.<br>
&gt; &gt; That&#39;s a few times faster than normal kexdh. It adds around 30kB to binary<br>
&gt; &gt; size on x86. That should make it into the next Dropbear release, though<br>
&gt; &gt; only will help for recent OpenSSH peers.<br>
&gt; &gt;<br>
&gt; &gt; Matt<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; William Welch &lt;<a href="mailto:bvwelch@gmail.com">bvwelch@gmail.com</a>&gt; wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Greetings,<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; First -- thank you for dropbear! 狢 have enjoyed using dropbear on<br>
&gt; &gt;&gt; various smallish systems for years now!<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; But I have a problem with a specific system -- admittedly it is rather<br>
&gt; &gt;&gt; slow -- only 50 BogoMips according to the linux kernel. It is a Microblaze.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I use the Buildroot system for many different routers and other small<br>
&gt; &gt;&gt; systems here. 狢 have compared different versions of dropbear, against<br>
&gt; &gt;&gt; openssh.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; My issue is with the server mode -- sshd -- 狢 note that on dropbear 0.52<br>
&gt; &gt;&gt; (which I happen to run on other routers here), I can connect from my ubuntu<br>
&gt; &gt;&gt; or mac, to dropbear sshd, in about 45 seconds. �This is having disabled the<br>
&gt; &gt;&gt; RSA host key, and already generated the DSS host key. � But on more recent<br>
&gt; &gt;&gt; versions of dropbear, e.g. 2013.58, several minutes elapse without a<br>
&gt; &gt;&gt; connection.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; In contrast, switching to openssh in buildroot, and also disabling the<br>
&gt; &gt;&gt; RSA host key, connection time is 5 to 10 seconds! 𡠻nfortunately, the<br>
&gt; &gt;&gt; openssh has a huge &#39;footprint&#39; in the flash filesystem that I would rather<br>
&gt; &gt;&gt; avoid.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; The issue seems to be in the key exchange ( I can watch this by doing<br>
&gt; &gt;&gt; &#39;ssh -v &#39; from my client connection). 瓱eanwhile, running &#39;top&#39; on my<br>
&gt; &gt;&gt; Microblaze shows near 100% cpu used. 慯he debug message is: expecting<br>
&gt; &gt;&gt; SSH2_MSG_KEXDH_REPLY<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Buildroot has the gnu cross tool chain set to &#39;optimize for size&#39; in all<br>
&gt; &gt;&gt; cases.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Suggestions welcome!<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; thank you,<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; William<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
</div></div></blockquote></div><br></div>