<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hello guys,</div><div class="gmail_quote"><br></div><div class="gmail_quote">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).</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">On Sun, Feb 16, 2014 at 3:03 PM, Edward Ned Harvey (mono) <span dir="ltr"><<a href="mailto:edward.harvey.mono@clevertrove.com" target="_blank">edward.harvey.mono@clevertrove.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">> From: Ian Norton [mailto:<a href="mailto:inorton@gmail.com">inorton@gmail.com</a>]<br>

><br>
> Hi folks.<br>
> Key generation can be hugely different on different platforms. Essentially for<br>
> RSA you need to generate two huge random integers and do primality checks<br>
> on them.<br>
> This is always going to be fairly nondeterministic in terms of time.<br></blockquote><div><br></div><div>True words.</div><div><br></div><div>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).</div>
<div><br></div><div>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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
> What really matters for performance of TLS is the speed at which you can do<br>
> a decrypt using RSA. </blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The best way to measure this is to generate one key.<br>

> Start the stopwatch and do lots of signatures of about 20-60 bytes of data.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I think you meant to respond to the list and not just me, so I included your whole text above.  And my response:<br>
<br>
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.<br>
</blockquote><div><br></div><div>Yup!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
But when the time required is *usually* 20-40 seconds, as opposed to usually 1-2 sec...  </blockquote><div><br></div><div>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.</div>
<div><br></div><div>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 ;-)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
And this is a blocking operation, </blockquote><div><br></div><div>Wrong!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
and it's necessary to establish an https connection (or anything else using SSL/TLS) ... </blockquote><div><br></div><div>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 ?!?</div>
<div><br></div><div>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).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
 That is well outside of the normal user tolerance.<br></blockquote><div><br></div><div>A good thing it does not matter :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
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.  </blockquote><div><br></div><div>No, this is not how SSL/TLS works. Do you normally trash for physical keys after each use ? I don't.</div>
<div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
So I humbly disagree that the speed of encryption / decryption is what matters.  </blockquote><div><br></div><div>and I disagree with your disagreement.</div><div><br></div><div>You might state that mono key generation is slow and I'll agree (your data shows this);</div>
<div><br></div><div>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);</div><div><br></div><div>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);</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.<br>
</blockquote><div><br></div><div>Right (total) and wrong (key generation).</div><div><br></div><div>Sebastien</div></div></div></div>