Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

2013-09-17 Thread Paul Crowley
At a stretch, one can imagine circumstances in which trying multiple seeds
to choose a curve would lead to an attack that we would not easily
replicate. I don't suggest that this is really what happened; I'm just
trying to work out whether it's possible.

Suppose you can easily break an elliptic curve with the right attack
string.  Attack strings are very expensive to generate, at say 2^80
operations. Moreover, you can't tell what curves they break until they are
generated, but it's cheap to test whether a given string breaks a given
curve. Each string breaks about one curve in 2^80. Thus the NSA generate an
attack string, then generate 2^80 curves looking for one that is broken by
the string they generated.  They can safely publish this curve, knowing
that unless a new attack is developed it will take 2^160 effort for anyone
else to generate an attack string that breaks the curve they have chosen.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

2013-09-13 Thread John Kelsey
On Sep 10, 2013, at 3:56 PM, Bill Stewart bill.stew...@pobox.com wrote:

 One point which has been mentioned, but perhaps not emphasised enough - if 
 NSA have a secret backdoor into the main NIST ECC curves, then even if the 
 fact of the backdoor was exposed - the method is pretty well known - without 
 the secret constants no-one _else_ could break ECC.
 So NSA could advocate the widespread use of ECC while still fulfilling their 
 mission of protecting US gubbmint communications from enemies foreign and 
 domestic. Just not from themselves.


I think this is completely wrong.

First, there aren't any secret constants to those curves, are there?  The 
complaint Dan Bermstein has about the NIST curves is that they (some of them) 
were generated using a verifiably random method, but that the seeds looked 
pretty random.  The idea here, if I understand it correctly, is that if the 
guys doing the generation knew of some property that made some of the choices 
of curves weak, they could have tried a huge number of seeds till they happened 
upon one that led to a weak curve.  If they could afford to try N seeds and do 
whatever examination of the curve was needed to check it for weakness, then the 
weak property they were looking for couldn't have had a probability much lower 
than about 1/N.  

I think the curves were generated in 1999 (that's the date on the document I 
could find), so we are probably talking about less than 2^{80} operations 
total.  Unlike the case with the Dual EC generator, where a backdoor could have 
been installed with no risk that anyone else could discover it, in this case, 
they would have to generate curves until one fell in some weak curve class that 
they knew about, and they would have to hope nobody else ever discovered that 
weak curve class, lest all the federal users of ECC get broken at once.  

The situation you are describing works for dual ec drbg, but not for the NIST 
curves, as best I understand things.  

--John
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

2013-09-11 Thread Viktor Dukhovni
On Tue, Sep 10, 2013 at 12:56:16PM -0700, Bill Stewart wrote:

 I thought the normal operating mode for PFS is that there's an
 initial session key exchange (typically RSA) and authentication,
 which is used to set up an encrypted session, and within that
 session there's a DH or ECDH key exchange to set up an ephemeral
 session key, and then that session key is used for the rest of the
 session.

This is not the case in TLS.  The EDH or EECDH key exchange is
performed in the clear.  The server EDH parameters are signed with
the server's private key.

https://tools.ietf.org/html/rfc2246#section-7.4.3

In TLS with EDH (aka PFS) breaking the public key algorithm of the
server certificate enables active attackers to impersonate the
server (including MITM attacks).  Breaking the Diffie-Hellman or
EC Diffie-Hellman algorithm used allows a passive attacker to
recover the session keys (break must be repeated for each target
session), this holds even if the certificate public-key algorithm
remains secure.

-- 
Viktor.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

2013-09-11 Thread Bill Stewart

At 10:39 AM 9/11/2013, Phillip Hallam-Baker wrote:
Perfect Forward Secrecy is not perfect. In fact it is no better than 
regular public key. The only difference is that if the public key 
system is cracked then with PFS the attacker has to break every 
single key exchange and not just the keys in the certificates and if 
you use an RSA outer with an ECC inner then you double the 
cryptanalytic cost of the attack (theory as well as computation).


I wouldn't mind if it had been called Pretty Good Forward Secrecy 
instead, but it really is a lot better than regular public key.
The main difference is that cracking PFS requires breaking every 
single key exchange before the attack using cryptanalysis, while 
cracking the RSA or ECC outer layer can be done by compromising the 
stored private key, which is far easier to do using subpoenas or 
malware or rubber hoses than cryptanalysis.


(Of course, any messages that were saved by the sender or recipient 
can still be cracked by non-cryptanalytic techniques as well, but 
that's a separate problem.)


___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

2013-09-11 Thread Phillip Hallam-Baker
On Wed, Sep 11, 2013 at 2:40 PM, Bill Stewart bill.stew...@pobox.comwrote:

 At 10:39 AM 9/11/2013, Phillip Hallam-Baker wrote:

 Perfect Forward Secrecy is not perfect. In fact it is no better than
 regular public key. The only difference is that if the public key system is
 cracked then with PFS the attacker has to break every single key exchange
 and not just the keys in the certificates and if you use an RSA outer with
 an ECC inner then you double the cryptanalytic cost of the attack (theory
 as well as computation).


 I wouldn't mind if it had been called Pretty Good Forward Secrecy instead,
 but it really is a lot better than regular public key.


My point was that the name is misleading and causes people to look for more
than is there. It took me a long time to work out how PFS worked till I
suddenly realized that it does not deliver what is advertised.



 The main difference is that cracking PFS requires breaking every single
 key exchange before the attack using cryptanalysis, while cracking the RSA
 or ECC outer layer can be done by compromising the stored private key,
 which is far easier to do using subpoenas or malware or rubber hoses than
 cryptanalysis.


That is my point precisely.

Though the way you put it, I have to ask if PFS deserves higher priority
than Certificate Transparency. As in something we can deploy in weeks
rather than years.

I have no problem with Certificate Transparency. What I do have trouble
with is Ben L.'s notion of Certificate Transparency and Automatic Audit in
the End Client which I imposes a lot more in the way of costs than just
transparency and moreover he wants to push out the costs to the CAs so he
can hyper-tune the performance of his browser.


-- 
Website: http://hallambaker.com/
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

2013-09-11 Thread Phillip Hallam-Baker
On Tue, Sep 10, 2013 at 3:56 PM, Bill Stewart bill.stew...@pobox.comwrote:

 At 11:33 AM 9/6/2013, Peter Fairbrother wrote:

 However, while the case for forward secrecy is easy to make, implementing
 it may be a little dangerous - if NSA have broken ECDH then
 using it only gives them plaintext they maybe didn't have before.


 I thought the normal operating mode for PFS is that there's an initial
 session key exchange (typically RSA) and authentication,
 which is used to set up an encrypted session, and within that session
 there's a DH or ECDH key exchange to set up an ephemeral session key,
 and then that session key is used for the rest of the session.
 If so, even if the NSA has broken ECDH, they presumably need to see both
 Alice and Bob's keyparts to use their break,
 which they can only do if they've cracked the outer session (possibly
 after the fact.)
 So you're not going to leak any additional plaintext by doing ECDH
 compared to sending the same plaintext without it.



One advantage of this approach is that we could use RSA for one and ECC for
the other and thus avoid most consequences of an RSA2048 break (if that is
possible).

The problem I see reviewing the list is that ECC has suddenly become
suspect and we still have doubts about the long term use of RSA.


It also have the effect of pushing the ECC IPR concerns off the CA and onto
the browser/server providers. I understand that many have already got
licenses that allow them to do what they need in that respect.

Perfect Forward Secrecy is not perfect. In fact it is no better than
regular public key. The only difference is that if the public key system is
cracked then with PFS the attacker has to break every single key exchange
and not just the keys in the certificates and if you use an RSA outer with
an ECC inner then you double the cryptanalytic cost of the attack (theory
as well as computation).


I think this is the way forward.

-- 
Website: http://hallambaker.com/
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

2013-09-06 Thread Peter Saint-Andre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9/6/13 8:36 AM, Perry E. Metzger wrote:
 One solution, preventing passive attacks, is for major
 browsers and websites to switch to using PFS ciphersuites (i.e.
 those based on ephemeral Diffie-Hellmann key exchange).
 
 It occurred to me yesterday that this seems like something all
 major service providers should be doing. I'm sure that some voices
 will say additional delay harms user experience. Such voices should
 be ruthlessly ignored.

+1

In practice, how do we make that happen? On the XMPP network we're
pushing to make sure that all client-to-server and server-to-server
hops are encrypted (yes, I know, per-hop encryption is not enough, we
need end-to-end encryption too). Is there a handy list of PFS-friendly
ciphersuites that I can communicate to XMPP developers and admins so
they can start upgrading their software and deployments?

Thanks!

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSKgDaAAoJEOoGpJErxa2pMssQAKVjwZZqy0q2ogIk13rGZkym
8PnXm6H9qsw08q4w3NEXPOU41rEh/GpS4agcgVxA+huYo5hU+qeA8YuhrVXt2xS7
Jt/fUgpJup297W4ErUpzMDQegVfP8ckNizI2AXBfr631PKUs7U3ije6wdxK30Hyx
262V/SLP0uVnJpbmepWUMCfzTGMY0SAvq2blVAPJjqjulC6lshj/aiKP6RBi9hCF
CW8yWO4L7Uot1mAa7j87Ywlyg9V8j6nKNEsKu81rjhSLpGvmed0GncK7U3GxLmsM
z2VzZKRJ+NxwJ3MKicmEy2bNnPjSJUd8itUWKru2vYMZftGImljWv1cUsLjXkxI7
DvQQ0lrjl3W8tisN7aqmGPi2734j8AN6ilHAUCbWniJfaarfC6rU/fDuk6fGnFss
N/zq9+NhYdvegmJiLvwVm42d1XdCxgoKzb27g/d8CsUWqWWXtQhxTeLL+OcKXiqh
kXLDDTv9uqBgdqWDZ/uhhlFGd/PFfeakeW7QWDjAvRMyF3XWaHA+OBJpg+nE/Dsl
kSfLmiCzOj4FN8aPQoM39T9IHbASpp+KYgnCl0nDweYXXBH/v5B/bCwsqz5Sy0ut
SET7zglbKm6oVf9hWoXsv01Kqsrxw6xj2bdnMU6YSUQoDvDHdXlilRZ6dTP5G63v
8XfdEe3k0aa+7uPpWQ5t
=SiIp
-END PGP SIGNATURE-
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

2013-09-06 Thread Raphaël Jacquot

On 06.09.2013 18:20, Peter Saint-Andre wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9/6/13 8:36 AM, Perry E. Metzger wrote:

One solution, preventing passive attacks, is for major
browsers and websites to switch to using PFS ciphersuites (i.e.
those based on ephemeral Diffie-Hellmann key exchange).


It occurred to me yesterday that this seems like something all
major service providers should be doing. I'm sure that some voices
will say additional delay harms user experience. Such voices should
be ruthlessly ignored.


+1

In practice, how do we make that happen? On the XMPP network we're
pushing to make sure that all client-to-server and server-to-server
hops are encrypted (yes, I know, per-hop encryption is not enough, we
need end-to-end encryption too). Is there a handy list of PFS-friendly
ciphersuites that I can communicate to XMPP developers and admins so
they can start upgrading their software and deployments?

Thanks!

Peter



yet, one can find this sort of thing in 3rd position when searching 
nginx crypto :


http://www.hybridforge.com/blog/nginx-ssl-ciphers-and-pci-compliance

quote :

The developers of Nginx have recently changed the default SSL ciphers to 
include the very strong Diffie-Hellman Ephemeral (DHE) cipher. DHE is 
used to provide perfect forward secrecy in TLS.


Further reading on Ephermal Diffie-Hellman, PFS and TLS at Wikipedia.org

While I applaud this move on the part of the Nginx dev team there is a 
tradeoff and that is slower performance. DHE provides stronger 
encryption which in turn requires more computation but here’s where it 
gets interesting. To meet today’s PCI DSS crypto standards DHE is not 
required. Like many things in life there’s a balance to be struck 
between the risk of compromised encryption and the additional expense or 
rather the relative loss of connections per second. I’m not a lawyer nor 
should this be considered legal advice but I prefer things that go fast 
while meeting the necessary PCI compliance criteria.


In order to disable DHE in the server context of the Nginx configuration 
add the following line:


ssl_ciphers RC4:HIGH:!aNULL:!MD5:!kEDH;

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

2013-09-06 Thread Daniel Veditz
On 9/6/2013 9:52 AM, Raphaël Jacquot wrote:
 To meet today’s PCI DSS crypto standards DHE is not required.

PCI is about credit card fraud. Mastercard/Visa aren't worried that
criminals are storing all your internet purchase transactions with the
hope they can crack it later; if the FBI/NSA want your CC number they
can get it by asking.

-Dan Veditz



smime.p7s
Description: S/MIME Cryptographic Signature
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

2013-09-06 Thread Peter Fairbrother

On 06/09/13 15:36, Perry E. Metzger wrote:

One solution, preventing passive attacks, is for major browsers
and websites to switch to using PFS ciphersuites (i.e. those
based on ephemeral Diffie-Hellmann key exchange).


It occurred to me yesterday that this seems like something all major
service providers should be doing. I'm sure that some voices will say
additional delay harms user experience. Such voices should be
ruthlessly ignored.


Any additional delay will be short - after all, if forward secrecy by 
ephemeral key setup (I hate the term PFS, there is nothing perfect about 
it) is not used then you have to use something else - usually RSA - 
instead.


For a desktop, laptop, or even a decent mobile the difference is not 
noticeable in practice if the server is fast enough.




However, while the case for forward secrecy is easy to make, 
implementing it may be a little dangerous - if NSA have broken ECDH then

using it only gives them plaintext they maybe didn't have before.




Personally, operating on the assumption that NSA have not made a crypto 
break is something I'm not prepared to do. I just don't know what that 
break is is. I think it's most likely RSA/DH or ECC, but could easily be 
wrong.


I don't really care if the break is non-existent, irrelevant or 
disinformation - beefing up today's crypto is only hard in terms of 
getting people to choose a new updated crypto, and then getting people 
to implement it. This happens every so often anyway.



One point which has been mentioned, but perhaps not emphasised enough - 
if NSA have a secret backdoor into the main NIST ECC curves, then even 
if the fact of the backdoor was exposed - the method is pretty well 
known - without the secret constants no-one _else_ could break ECC.


So NSA could advocate the widespread use of ECC while still fulfilling 
their mission of protecting US gubbmint communications from enemies 
foreign and domestic. Just not from themselves.



Looking at timing, the FIPS 186-3 curves were introduced in July 2009 - 
the first hints that NSA had made a cryptanalytic break came in early to 
mid 2010.



I'm still leaning towards RSA, but ...


-- Peter Fairbrother
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

2013-09-06 Thread ianG

On 6/09/13 20:15 PM, Daniel Veditz wrote:

On 9/6/2013 9:52 AM, Raphaël Jacquot wrote:

To meet today’s PCI DSS crypto standards DHE is not required.


PCI is about credit card fraud.



So was SSL ;-)  Sorry, couldn't resist...



Mastercard/Visa aren't worried that
criminals are storing all your internet purchase transactions with the
hope they can crack it later; if the FBI/NSA want your CC number they
can get it by asking.



That's what the crims do to, they ask for all the numbers, they don't 
bother much with SSL.




iang
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

2013-09-06 Thread Ben Laurie
On 6 September 2013 17:20, Peter Saint-Andre stpe...@stpeter.im wrote:

  Is there a handy list of PFS-friendly
 ciphersuites that I can communicate to XMPP developers and admins so
 they can start upgrading their software and deployments?


Anything with EDH, DHE or ECDHE in the name...
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

2013-09-06 Thread Anne Lynn Wheeler

we were brought in as consultants to a small client/server startup that wanted to do payment transactions on 
their server, they had this technology they called SSL they wanted to use, the result is now 
frequently called electronic commerce. The two people at the startup responsible for the 
commerce server we had worked with in prior life on parallel Oracle cluster scaleup.

As part of mapping SSL technology to payment transactions we had to audit operations 
selling SSL digital certificates and also came up with recommendations on how browsers 
and servers would deploy and use the technology. Almost immediately several of the recommendations 
were violated, resulting in some number of the exploits that continue to this day.

We were then tangentially involved in the Cal. data breach notification legislation, 
having been brought in to help wordsmith the Cal. electronic signature legislation. Many 
of the parties were heavily involved in privacy issues and had done numerous, indepth, 
public surveys. The number one issue was identity theft of the form involving 
fraudulent financial transactions ... frequently as result of data breach. The issue was 
nothing was being done about the problems and so it was hoped that the publicity from the 
notifications might motivate corrective action. Part of the issue is normally 
institutions take security measures in self-interests ... however, the institutions 
having breaches weren't at risk, it was the account holders.

PCI DSS shows up some time after Cal. data breach notification and frequently the joke is 
that if you have a breach ... you loose your PCI DSS certification. It turns out that 
there was a number of Federal data breach notification bills introduced, 
preempting state legislation and effectively eliminating notification requirements ... 
citing PCI DSS industry effort as justification for no longer needing notification.

Another problem we've frequently pointed out is current paradigm with dual 
use paradigm and even if the planet was covered in miles of information hiding 
encryption, it wouldn't stop data leakage. Account information is used for authenticating 
new transactions and so has a requirement that it be kept totally confidential and never 
divulged to anybody ... but at the same time, account information is needed in dozens of 
business processes at millions of locations around the planet.

disclaimer: we were co-authors of the x9.59 financial transaction standard that 
slightly tweaked the current payment paradigm and eliminated the dual-use 
characteristic  which then also eliminated the need to hide account 
information and as a result it also eliminated the need for SSL to hide account 
information in electronic commerce transactions  eliminating the major 
requirement for SSL in the world today.

--
virtualization experience starting Jan1968, online at home since Mar1970
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography