Subject: Re: [perpass] [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt

From: Patrick Pelletier <[email-masked]>
Date: Sun, 8 Sep 2013 22:46:40 -0700

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

> Patrick Pelletier <[email-masked]> writes:
>
>> It seems generally accepted that 1024-bit Diffie-Hellman is no  
>> longer secure,
>
> Really?  DLP != 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:

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 least
>> 2048 bits SHOULD be chosen"?
>
> Why at least 2048 bits?  What's wrong with 1280, or 1536, which will  
> be quite
> a lot faster.

It seems like a good ballpark from looking at these tables, but I'm  
certainly not claiming 2048 exactly the right number.  My point was  
merely that the 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

---

From: Yoav Nir <[email-masked]>
Date: Mon, 9 Sep 2013 06:59:01 +0000

Hi Patrick.

Those tables are mostly quoting NIST publications, so while it seems like there'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 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 this is based on, but then, IANAC.

BTW: If the entire Internet was using 768-bit RSA keying and single-DES encryption, then the NSA could decrypt any connection they wanted, but they 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 2048-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 <[email-masked]<mailto:[email-masked]>> wrote:

Patrick Pelletier <[email-masked]<mailto:[email-masked]>> writes:

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

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:

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:

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 "Diffie-Hellman parameters of at least
2048 bits SHOULD be chosen"?

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

It seems like a good ballpark from looking at these tables, but I'm certainly not claiming 2048 exactly the right number.  My point was merely that the 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/perpass

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 9 Sep 2013 03:16:41 +0000

Peter.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 09 Sep 2013 10:35:59 +0200

On 09/09/2013 08:59 AM, Yoav Nir wrote:

> Those tables are mostly quoting NIST publications, so while it seems
> like there'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 logical to suspect that the NSA can factor 1024-bit
> numbers. That would be a breakage of RSA, not D-H or DSA. 

Hello,
 While I am not in par with the advances in solving the DLOG problem,
the ECRYPT 2010 report on key sizes mentions in section 6.1: "According
to the state of the art the difficulty of solving DLOG in prime order
fields of size 2^n is, up to constants, asymptotically equivalent to
that of breaking n-bit RSA". Given that all reports on key sizes agree
on that (ECRYPT is not related to NIST in any way), I wouldn't ignore
these recommendations.

regards,
Nikos