offline keygeneration

[Matt Johnston]

On Mon, Sep 25, 2006 at 12:26:10PM -0700, Prasad wrote:
> Hi matt,
> I was checking thro the code to figure out how to make it run faster
> (I am using dss hostkey now). I found that gen_kexdh_vals (&dh_f,
> &dh_y) takes about half of the time. So i wrote a task to pre-generate
> that when the system is not doing anything else and write it in a tmp
> file. This improves the speed by twice (since dropbear reads the keys
> from the file when the connection request comes).
> 
> Now i have few questions, assuming i am going to use dropbear sparsely
> just to set few parameters.
> 1) Is this method right?
> 2) How far is this secure? Assuming i regenerate the key after say 5
> minutes of the current login for the purpose of next login. (Till that
> time if any other login request comes, it can use the same key).

As far as I can tell, the concept of pregenerating keys
should be fine but re-using the same dh_priv value for
multiple sessions is a security problem. I'm not a
cryptographer so can't give a specific attack, but it seems
likely that it would introduce weaknesses to the key
exchange procedure.  Could you generate several keys with
the task while it is running in the background, then use
them once only per connection?

In a general purpose system it would probably be best to
avoid writing keys to disk, but in an embedded system it
probably mighn't matter so much (it's a ramdisk anyway?).
It'll depend on your application.

I'll have a think about a way that Dropbear could do this by
default - if the listening process could generate keys while
waiting for new connections, but break out upon a client
connecting, that would be quite handy.

> 3) The task i wrote does the following initialization,
> seedrandom();
> reseedrandom ();
> crypto_init()
> m_mp_init_multi(&dh_priv, &dh_pub, NULL);
> before calling gen_kexdh_vals (&dh_f, &dh_y). Should i need to add any
> more of initilisation for offline keygeneration.

You don't need to call reseedrandom() or crypto_init(), that
should be fine I think.

> 4) It also fails few times with this method (need to investigate why)

No idea there.

Thinking a bit more about your hardware, is there any chance
of increasing the cache size? (does it have any?) Someone
else using libtommath on a microblaze device seems to think
that it's the memory speed that makes it so slow [1].

Cheers,
Matt

[1] http://groups.google.com/group/comp.programming/browse_thread/thread/de98359e049a4297/f17eb1ba71a0bf4e?tvc=2#f17eb1ba71a0bf4e

> Appreciate your response,
> Thanx
> - Prasad
> 
> On 7/19/06, Matt Johnston <matt at ucc.asn.au> wrote:
> >On Tue, Jul 18, 2006 at 06:53:18PM -0700, Prasad wrote:
> >> The only problem now i have is that the entire process is really slow
> >> until i get the login. I takes about 90 secs for me to get the shell.
> >> (With or with-out the changes for my own interpreter). After i get
> >> login everything is pretty fast. The size of the SSH key is 1024 bit.
> >> (512 bytes reduces the time by about 60 secs).
> >>
> >> Doing a quick check, majoriy of the time taken was in mp_exptmod()
> >> routine with each call takes around 25 secs. I am running my
> >> processor(microblaze) at about 60mhz with hardware multipler, divider
> >> enabled.
> >>
> >> >From your knowledge, Is there any way to accelerate this in software
> >> or the only way to increase this is by hardware-acceleration?
> >
> >Using a DSS hostkey might be faster than RSA, you could try
> >that. I assume you're already compling with -O2 (or whatever
> >works for your platform) - that can make a big difference.
> >Aside from that, I'm not really sure. Looking at a faster
> >math library (or optimising LibTomCrypt) could be an option.
> >It looks as if TomsFastMath might be a fairly easy
> >replacement, though I'm not sure how portable or mature that
> >is.
> >
> >Cheers,
> >Matt
> >
> >