Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B5E21E8159; Sun, 8 Sep 2013 23:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wBBMCqqD5Ve; Sun, 8 Sep 2013 23:59:28 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A7B2D21E8143; Sun, 8 Sep 2013 23:59:27 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r896x18I029156; Mon, 9 Sep 2013 09:59:01 +0300 X-CheckPoint: {522D71B5-6-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Mon, 9 Sep 2013 09:59:01 +0300 From: Yoav Nir To: Patrick Pelletier Thread-Topic: [perpass] [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt Thread-Index: AQHOrSAT7vhu+KgFPUyyfi4xkQQkepm8x56A Date: Mon, 9 Sep 2013 06:59:01 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C7344731843@uxcn10-6.UoA.auckland.ac.nz> <7CBBDAB6-15FF-4EB8-B1D0-CE96B3F8002F@funwithsoftware.org> In-Reply-To: <7CBBDAB6-15FF-4EB8-B1D0-CE96B3F8002F@funwithsoftware.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.29] x-kse-antivirus-interceptor-info: protection disabled Content-Type: multipart/alternative; boundary="_000_F11AE80BE1A148688C81AFF533B6E6A9checkpointcom_" MIME-Version: 1.0 Cc: "" , "" Subject: Re: [TLS] [perpass] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 06:59:40 -0000 --_000_F11AE80BE1A148688C81AFF533B6E6A9checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Patrick. Those tables are mostly quoting NIST publications, so while it seems like t= here's many sources, they're not really independent. There are academic results in factoring 768-bit numbers, so with sufficient= thrust (and the NSA has more thrust than most academics), it's perfectly l= ogical to suspect that the NSA can factor 1024-bit numbers. That would be a= breakage of RSA, not D-H or DSA. There seems to be an assumption behind th= ose tables that the strength of RSA and DSA for the same bit length is abou= t equal. I don't know what this is based on, but then, IANAC. BTW: If the entire Internet was using 768-bit RSA keying and single-DES enc= ryption, then the NSA could decrypt any connection they wanted, but they wo= uld only have the resources to spy on very few people. Even if we used anon= ymous D-H for TLS, which would allow the NSA to trivially MITM any connecti= on, just having the encryption there means that the same hardware can inter= cept far fewer connections. I suspect that with enough TOR traffic scrambled hard enough that you can't= decrypt a particular one without decrypting a significant portion of the c= onnections, 1024-bit DHE is plenty strong enough. Sure, upgrading to 2048-b= it makes it harder to crack, but the TOR network is already way too slow. Yoav On Sep 9, 2013, at 8:46 AM, Patrick Pelletier > wrote: On Sep 8, 2013, at 8:16 PM, Peter Gutmann wrote: Patrick Pelletier > writes: It seems generally accepted that 1024-bit Diffie-Hellman is no longer secur= e, Really? DLP !=3D factoring. I'm an engineer, not a cryptographer, and I don't claim to understand the m= ath. But I've seen statements to that effect here, for example: http://blog.erratasec.com/2013/09/tor-is-still-dhe-1024-nsa-crackable.html The IETF's own RFC 3766/BCP 86 indicates that 1024-bit Diffie-Hellman would= fall in between a 70 and 80 bit symmetric key: +-------------+-----------+--------------+--------------+ | System | | | | | requirement | Symmetric | RSA or DH | DSA subgroup | | for attack | key size | modulus size | size | | resistance | (bits) | (bits) | (bits) | | (bits) | | | | +-------------+-----------+--------------+--------------+ | 70 | 70 | 947 | 129 | | 80 | 80 | 1228 | 148 | | 90 | 90 | 1553 | 167 | | 100 | 100 | 1926 | 186 | | 150 | 150 | 4575 | 284 | | 200 | 200 | 8719 | 383 | | 250 | 250 | 14596 | 482 | +-------------+-----------+--------------+--------------+ and other such tables come to similar conclusions. For example, ECRYPT II = says a 1248-bit discrete log group only provides protection until 2015: http://www.keylength.com/en/3/ How about something along the lines of "Diffie-Hellman parameters of at lea= st 2048 bits SHOULD be chosen"? Why at least 2048 bits? What's wrong with 1280, or 1536, which will be qui= te a lot faster. It seems like a good ballpark from looking at these tables, but I'm certain= ly not claiming 2048 exactly the right number. My point was merely that th= e draft should say something about DH group size. If 1024 is in fact good = enough, then it should say that, rather than being silent on the subject. --Patrick _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass --_000_F11AE80BE1A148688C81AFF533B6E6A9checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8F13BD361FD30E41A1E47BEB75AF84A6@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable Hi Patrick. 

Those tables are mostly quoting NIST publications, so while it seems l= ike there's many sources, they're not really independent. 

There are academic results in factoring 768-bit numbers, so with suffi= cient thrust (and the NSA has more thrust than most academics), it's perfec= tly logical to suspect that the NSA can factor 1024-bit numbers. That would= be a breakage of RSA, not D-H or DSA. There seems to be an assumption behind those tables that the strength= of RSA and DSA for the same bit length is about equal. I don't know what t= his is based on, but then, IANAC.

BTW: If the entire Internet was using 768-bit RSA keying and single-DE= S encryption, then the NSA could decrypt any connection they wanted, but th= ey would only have the resources to spy on very few people. Even if we used= anonymous D-H for TLS, which would allow the NSA to trivially MITM any connection, just having the encryption= there means that the same hardware can intercept far fewer connections.

I suspect that with enough TOR traffic scrambled hard enough that you = can't decrypt a particular one without decrypting a significant portion of = the connections, 1024-bit DHE is plenty strong enough. Sure, upgrading to 2= 048-bit makes it harder to crack, but the TOR network is already way too slow.

Yoav

On Sep 9, 2013, at 8:46 AM, Patrick Pelletier <code@funwithsoftware.org> wrote:

On Sep 8, 2013, at 8:16 PM, Peter Gutmann wrote:

Patrick Pelletier <code@funwithsoftware.org> writes:

It seems generally accepted that 1024-bit Diffie-= Hellman is no longer secure,

Really?  DLP !=3D factoring.

I'm an engineer, not a cryptographer, and I don't claim to understand = the math.  But I've seen statements to that effect here, for example:<= /div>


The IETF's own RFC 3766/BCP 86 indicates that 1024-bit Diffie-Hellman = would fall in between a 70 and 80 bit symmetric key:

   +-------------+-----------+--------------+= ;--------------+
   | System      |        = ;   |              |     =          |
   | requirement | Symmetric | RSA or DH    | DSA = subgroup |
   | for attack  | key size  | modulus size | size=         |
   | resistance  | (bits)    | (bits)   =     | (bits)       |
   | (bits)      |        = ;   |              |     =          |
   +-------------+-----------+--------------+= ;--------------+
   |     70      |     70=    |      947     |     129 &= nbsp;    |
   |     80      |     80=    |     1228     |     148  =    |
   |     90      |     90=    |     1553     |     167  =    |
   |    100      |    100=    |     1926     |     186  =    |
   |    150      |    150=    |     4575     |     284  =    |
   |    200      |    200=    |     8719     |     383  =    |
   |    250      |    250=    |    14596     |     482  =    |
   +-------------+-----------+--------------+= ;--------------+

and other such tables come to similar conclusions.  For example, = ECRYPT II says a 1248-bit discrete log group only provides protection until= 2015:


How about something along the lines of "Diff= ie-Hellman parameters of at least
2048 bits SHOULD be chosen"?

Why at least 2048 bits?  What's wrong with 1280, or 1536, which will b= e quite
a lot faster.

It seems like a good ballpark from looking at these tables, but I'm ce= rtainly not claiming 2048 exactly the right number.  My point was mere= ly that the draft should say something about DH group size.  If 1024 i= s in fact good enough, then it should say that, rather than being silent on the subject.

--Patrick

_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass

--_000_F11AE80BE1A148688C81AFF533B6E6A9checkpointcom_--