[Mono-dev] RSA and ECDH

[Sebastien Pouliot]

Hello guys,

There's quite a few misconceptions in the above thread. There's a lot of
places that could be/do better but misidentifying them is not helpful (and
they are fairly googl'able assertions to be validated).

On Sun, Feb 16, 2014 at 3:03 PM, Edward Ned Harvey (mono) <
edward.harvey.mono at clevertrove.com> wrote:

> > From: Ian Norton [mailto:inorton at gmail.com]
> >
> > Hi folks.
> > Key generation can be hugely different on different platforms.
> Essentially for
> > RSA you need to generate two huge random integers and do primality checks
> > on them.
> > This is always going to be fairly nondeterministic in terms of time.
>

True words.

As for Mono this is entirely done in managed code. It means it's always
available anywhere you can run mono (without any additional dependencies),
i.e. you got mono, you got crypto and SSL/TLS. It also means it's not
optimized like it's generally is for most platforms (and yes, even in 2014,
most platforms still use hand-written assembly code for this).

OTOH Mono/.NET (and it's cryptographic stack) is easily extended so you're
free to add/replace cryptographic code with native code (e.g. Xamarin.iOS
does this using Apple's CommonCrypto and there are other examples in Mono's
crimson git repository).


> > What really matters for performance of TLS is the speed at which you can
> do
> > a decrypt using RSA.


Good (but incomplete). Both encrypt and decrypt speeds are important -
depending on which side of the SSL channel (i.e. client or server, both
supported by Mono) you are. The use of client certificates also affect
which operation is critical.


> The best way to measure this is to generate one key.
> > Start the stopwatch and do lots of signatures of about 20-60 bytes of
> data.
>

Again true - but let me emphasis that the "generate one key" is _not_
important above. The important (true) part is that you start the watch dog
after the key generation.


>
> I think you meant to respond to the list and not just me, so I included
> your whole text above.  And my response:
>
> This is true - by nature of the fact that you have to start with a random
> number, and from there, perform a search for a prime.  If you're lucky, you
> could get a prime on the first random pick, and if you're unlucky, you
> could be required to search for a long time before you find a prime.
>

Yup!


>
> But when the time required is *usually* 20-40 seconds, as opposed to
> usually 1-2 sec...


Proving a prime is not easy (nor fast) and it's easy to take shortcuts. We
try to say away from them and ensure any key we generate is safe to use,
now and in the future.

OTOH all our BigInteger code is available. You can optimize it or the way
you wish your prime numbers to be tested - they'll be yours after all ;-)



> And this is a blocking operation,


Wrong!


> and it's necessary to establish an https connection (or anything else
> using SSL/TLS) ...


Please re-read the TLS RFC (any of them) and tell me where you need to
_generate_ an RSA keypair to establish an SSL/TLS connection ?!?

Now that does not make mono faster at generating key pairs - but it makes
it unimportant for 99% of use cases I can dream of (including SSL/TLS).


>  That is well outside of the normal user tolerance.
>

A good thing it does not matter :-)


>
> Normally, all we need to do is generate a keypair, and then encrypt
> something on par with 32-128 bytes, to perform an AES key exchange, and
> then never care about the RSA key again.


No, this is not how SSL/TLS works. Do you normally trash for physical keys
after each use ? I don't.

As for virtual keys I bet certificate sellers would be thrilled if this was
the case ;-) Thankfully it's not something required for SSL/TLS.


> So I humbly disagree that the speed of encryption / decryption is what
> matters.


and I disagree with your disagreement.

You might state that mono key generation is slow and I'll agree (your data
shows this);

You might state that mono's SSL/TLS is slow and I'll agree (no data given
but it's never been a secret, the implementation sits on a wholly managed
code base);

But if you state that SSL/TLS is slow because of the key generation then
you'll not get my agreement (your assertion is wrong);



> What matters is the total time to perform session key exchange (AES or
> whatever algorithm was negotiated), which includes the time to generate the
> RSA key.
>

Right (total) and wrong (key generation).

Sebastien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20140216/5b7ede34/attachment.html>