<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 27, 2013 at 3:59 AM, John Gilmore <span dir="ltr"><<a href="mailto:gnu@toad.com" target="_blank">gnu@toad.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> And the problem appears to be compounded by dofus legacy implementations<br>
> that don't support PFS greater than 1024 bits. This comes from a<br>
> misunderstanding that DH keysizes only need to be half the RSA length.<br>
><br>
> So to go above 1024 bits PFS we have to either<br>
><br>
> 1) Wait for all the servers to upgrade (i.e. never do it because the won't<br>
> upgrade)<br>
><br>
> 2) Introduce a new cipher suite ID for 'yes we really do PFS at 2048 bits<br>
> or above'.<br>
<br>
</div>Can the client recover and do something useful when the server has a<br>
buggy (key length limited) implementation?  If so, a new cipher suite<br>
ID is not needed, and both clients and servers can upgrade asynchronously,<br>
getting better protection when both sides of a given connection are<br>
running the new code.<br></blockquote><div><br></div><div>Actually, it turns out that the problem is that the client croaks if the server tries to use a key size that is bigger than it can handle. Which means that there is no practical way to address it server side within the current specs.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In the case of (2) I hope you mean "yes we really do PFS with an<br>
unlimited number of bits".  1025, 2048, as well as 16000 bits should work.<br></blockquote><div><br></div><div>There is no reason to use DH longer than the key size in the certificate and no reason to use a shorter DH size either.</div>
<div><br></div><div>Most cryptolibraries have a hard coded limit at 4096 bits and there are diminishing returns to going above 2048. Going from 4096 to 8192 bits only increases the work factor by a very small amount and they are really slow which means we end up with DoS considerations.</div>
<div><br></div><div>We really need to move to EC above RSA. Only it is going to be a little while before we work out which parts have been contaminated by NSA interference and which parts are safe from patent litigation. RIM looks set to collapse with or without the private equity move. The company will be bought with borrowed money and the buyers will use the remaining cash to pay themselves a dividend. Mitt Romney showed us how that works.</div>
<div><br></div><div>We might possibly get lucky and the patents get bought out by a white knight. But all the mobile platform providers are in patent disputes right now and I can't see it likely someone will plonk down $200 million for a bunch of patents and then make the crown jewels open.</div>
<div><br></div><div><br></div><div>Problem with the NSA is that its Jekyll and Hyde. There is the good side trying to improve security and the dark side trying to break it. Which side did the push for EC come from?</div><div>
<br></div><div><br></div><div> </div></div><div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>