Re: [Cryptography] In the face of cooperative end-points, PFS doesn't help

2013-09-08 Thread John Kelsey
Your cryptosystem should be designed with the assumption that an attacker will 
record all old ciphertexts and try to break it later.  The whole point of 
encryption is to make that attack not scary.  We can never rule out future 
attacks, or secret ones now.  But we can move away from marginal key lengths 
and outdated, weak ciphers.  Getting people to do that is like pulling teeth, 
which is why we're still using RC4, and 1024-bit RSA keys and DH primes.  

--John


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


Re: [Cryptography] In the face of cooperative end-points, PFS doesn't help

2013-09-08 Thread Marcus D. Leech

On 09/07/2013 06:57 PM, james hughes wrote:


PFS may not be a panacea but does help.

There's no question in my mind that PFS helps.  I have, in the past, 
been very in much favor of turning on PFS support in various protocols, 
when it has

  been available.  And I fully understand what the *purpose* of PFS is.

But it's not entirely clear to me that it will help enough in the 
scenarios under discussion.  If we assume that mostly what NSA are doing 
is acquiring a site
   RSA key (either through donation on the part of the site, or 
through factoring or other means), then yes, absolutely, PFS will be a 
significant roadblock.
   If, however, they're getting session-key material (perhaps through 
back-doored software, rather than explicit cooperation by the target 
website), the
   PFS does nothing to help us.  And indeed, that same class of 
compromised site could just as well be leaking plaintext.  Although 
leaking session

   keys is lower-profile.

I think all this amounts to a preamble for a call to think deeply, 
again, about end-to-end encryption.I used OTR on certain chat 
sessions, for example,
  because the consequences of the server in the middle disclosing the 
contents of those conversations protected by OTR could have dire 
consequences

  for one of the parties involved.

Jeff Schiller pointed out a little while ago that the crypto-engineering 
community have largely failed to make end-to-end encryption easy to 
use.  There are
  reasons for that, some technical, some political, but it is 
absolutely true that end-to-end encryption, for those cases where end 
to end is the obvious
  and natural model, has not significantly materialized on the 
Internet.  Relatively speaking, a handful of crypto-nerds use end-to-end 
schemes for e-mail
  and chat clients, and so on, but the vast majority of the Internet 
user-space?  Not so much.



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

Re: [Cryptography] In the face of cooperative end-points, PFS doesn't help

2013-09-08 Thread james hughes


On Sep 7, 2013, at 8:16 PM, Marcus D. Leech mle...@ripnet.com wrote:

 But it's not entirely clear to me that it will help enough in the scenarios 
 under discussion.  If we assume that mostly what NSA are doing is acquiring a 
 site
RSA key (either through donation on the part of the site, or through 
 factoring or other means), then yes, absolutely, PFS will be a significant 
 roadblock.
If, however, they're getting session-key material (perhaps through 
 back-doored software, rather than explicit cooperation by the target 
 website), the
PFS does nothing to help us.  And indeed, that same class of compromised 
 site could just as well be leaking plaintext.  Although leaking session
keys is lower-profile.

I think we are growing closer to agreement, PFS does help, the question is how 
much in the face of cooperation. 

Let me suggest the following. 

With RSA, a single quiet donation by the site and it's done. The situation 
becomes totally passive and there is no possibility knowing what has been read. 
 The system administrator could even do this without the executives knowing. 

With PFS there is a significantly higher profile interaction with the site. 
Either the session keys need to be transmitted  in bulk, or the RNG cribbed. 
Both of these have a significantly higher profile,  higher possibility of 
detection and increased difficulty to execute properly. Certainly a more risky 
think for a cooperating site to do. 

PFS does improve the situation even if cooperation is suspect. IMHO it is just 
better cryptography. Why not? 

It's better. It's already in the suites. All we have to do is use it... 

I am honestly curious about the motivation not to choose more secure modes that 
are already in the suites?



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


Re: [Cryptography] In the face of cooperative end-points, PFS doesn't help

2013-09-08 Thread james hughes


On Sep 8, 2013, at 1:47 PM, Jerry Leichter leich...@lrw.com wrote:

 On Sep 8, 2013, at 3:51 PM, Perry E. Metzger wrote:
 
 In summary, it would appear that the most viable solution is to make
 the end-to-end encryption endpoint a piece of hardware the user owns
 (say the oft mentioned $50 Raspberry Pi class machine on their home
 net) and let the user interact with it over an encrypted connection
 (say running a normal protocol like Jabber client to server
 protocol over TLS, or IMAP over TLS, or https: and a web client.)
 
 It is a compromise, but one that fits with the usage pattern almost
 everyone has gotten used to. It cannot be done with the existing
 cloud model, though -- the user needs to own the box or we can't
 simultaneously maintain current protocols (and thus current clients)
 and current usage patterns.

 I don't see how it's possible to make any real progress within the existing 
 cloud model, so I'm with you 100% here.  (I've said the same earlier.)

Could cloud computing be a red herring? Banks and phone companies all give up 
personal information to governments (Verizon?) and have been doing this long 
before and long after cloud computing was a fad. Transport encryption 
(regardless of its security) is no solution either. 

The fact is, to do business, education, health care, you need to share 
sensitive information. There is no technical solution to this problem. Shared 
data is shared data. This is arguably the same as the analogue gap between 
content protected media and your eyes and ears. Encryption is not a solution 
when the data needs to be shared with the other party in the clear. 

I knew a guy one that quipped link encryptors are iron pipes rats run 
through. 

If compromised end points are your threat model, cloud computing is not your 
problem. 

The only solution is the Ted Kazinski technology rejection principal (as long 
as you also kill your brother).



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

Re: [Cryptography] In the face of cooperative end-points, PFS doesn't help

2013-09-08 Thread Anne Lynn Wheeler

note when the router hughes references was 1st introduced in in IETF gateway 
committee meeting as VPN it caused lots of turmoil in the IPSEC camp as well as 
with the other router vendors. The other router vendors went into standards 
stall mode ... their problem was none of them had a product with processors 
capable of handling the crypto processing. A month after the IETF meeting one 
of the vendors announced what was supposedly an equivalent product ... but was 
actually their standard product (w/o crypto) packaged with hardware link 
encryptors (needed dedicated links instead of being able to tunnel thru the 
internet).

The IPSEC camp whined a lot but eventually settled for referring to it as 
lightweight IPSEC (possibly trying to imply it didn't have equivalent crypto).

As to DNSSEC ... the simple scenario is requiring domain owners to register a 
public key and then all future communication is digitally signed and 
authenticated with the onfile, registered public key (as a countermeasure to 
domain name take-over which affects the integrity of the domain name 
infrastructure and propogates to SSL CA vendors if they can't trust who the 
true owner is). Then the SSL CA vendors can also start requiring that SSL 
certificate requests also be digitally signed ... which can also be 
authenticated by retrieving the onfile public key (turning an expensive, 
error-prone and time-consuming identification process into a reliable and 
simple authentication process). The catch22 is once public keys can be 
retrieved in realtime ... others can start doing it also ... going a long way 
towards eliminating need for SSL certificates. Have an option piggy-back public 
key in the same response with the ip-address. Then do SSL-lite ... XTP had 
reliable communication minim
um 3-pack
et exchange ... compared to TCP requiring minimum 7-packet exchange.

In the key escrow meetings, I lobbied hard that divulging/sharing authentication keys was 
violation of fundamental security principles. Other parties at the key escrow meetings 
whined that people could cheat and use authentication keys for encryption. However, there 
was commercial no single point of failure business case for replicating keys 
used in encrypting data-at-rest corporate assets.

One might hypothesis that some of the current DNSSEC complexity is FUD ... 
unable to kill it ... make it as unusable as possible.

disclaimer: person responsible for original DNS worked at the science center in 
the early 70s when he was at MIT.

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


Re: [Cryptography] In the face of cooperative end-points, PFS doesn't help

2013-09-08 Thread Jerry Leichter
On Sep 8, 2013, at 7:16 PM, james hughes wrote:
 Let me suggest the following. 
 
 With RSA, a single quiet donation by the site and it's done. The situation 
 becomes totally passive and there is no possibility knowing what has been
 read.  The system administrator could even do this without the executives 
 knowing.
An additional helper:  Re-keying.  Suppose you send out a new public key, 
signed with your old one, once a week.  Keep the chain of replacements posted 
publicly so that someone who hasn't connected to you in a while can confirm the 
entire sequence from the last public key he knew to the current one.  If 
someone sends you a message with an invalid key (whether it was ever actually 
valid or not - it makes no difference), you just send them an update.

An attacker *could* sent out a fake update with your signature, but that would 
be detected almost immediately.  So a one-time donation is now good for a 
week.  Sure, the leaker can keep leaking - but the cost is now considerably
greater, and ongoing.
-- Jerry

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


Re: [Cryptography] In the face of cooperative end-points, PFS doesn't help

2013-09-08 Thread Max Kington
This space is of particular interest to me.  I implemented just one of
these and published the protocol (rather than pimp my blog if anyone wants
to read up on the protocol description feel free to email me and I'll send
you a link).

The system itself was built around a fairly simple PKI which then allowed
people to build end-to-end channels.  You hit the nail on the head though,
control of the keys.  If you can game the PKI you can replace someone's
public key and execute a MITM attack.  The approach I took to this was that
the PKI publishes peoples public keys but then allows other users to verify
your public key.  A MITM attack is possible but as soon as your public key
is rotated this is detected and the client itself asks if you'd like to
verify if out of band (this was for mobile devices so it lends itself to
having other channels to check keys via, like phone your friend and ask
them).  The much more likely thing is where someone tries to do a MITM
attack for just a particular user but as the channels are tunnelled end to
end they need to essentially ask the PKI to publish two duff keys, i.e. one
in each direction, Alice's key as far as Bob is concerned and Bob's key as
far as alice is concerned..  In turn the two people who's traffic the
attacker is trying to obtain can in turn ask someone else to double check
their.  It means that you need to publish an entirely fake PKI directory to
just two users.  The idea was the alarm bells go off when it transpires
that every person you want to get a proxy verification of a public key via
has 'all of a sudden' changed their public key too.  It's a hybrid model, a
PKI to make life easy for the users to bootstrap but which uses a web of
trust to detect when the PKI (or your local directory) has been attacked.
 Relationships become 'public' knowledge at least in so far as you ask
others in your address book to verify peoples public keys (all be it via
uuids, you could still find out if your mate Bill had 'John's' public key
in his address book because he's asked you to verify it for him).  So for
those who want to protect the conversational meta data it's already
orthogonal to that.

Group chat semantics are quite feasible in that all users are peers but you
run into difficulty when it comes to signing your own messages, not that
you can't sign them but that's computationally expensive and the eats
battery life.  Again, you are right though, what do you want to achieve?

I certainly built a protocol that answered the main questions I was asking!

As for multiple devices, the trick was always usability.  How do you
securely move an identity token of some description from one node to
another.  I settled on every device having its own key pair but you still
need an 'owning' identity and a way to 'enrol' a new key pair because if
that got broken the attacked just enrols their own 'device'
surreptitiously.  You then get into the realms of passwords through salted
hashing algorithms but then you're back to the security of a password being
brute forced.  If you were really paranoid I proposed a smart card
mechanism but I've yet to implement that (how closed a world are smart
cards with decent protection specifications?! but that's another
conversation), the idea being that you decrypt your device key pair using
the smart card and ditch the smart card if needs be, through a typical
office shredder.

Silent Circle was one of the most analogous systems but I'm an amateur
compared to those chaps.  As interesting as it was building, it kept
boiling down to one thing: Assuming I'd done a good job all I had done was
shift the target from the protocol to the device.

If I really wanted to get the data I'd attack the onscreen software
keyboard and leave everything else alone.

Max


On Sun, Sep 8, 2013 at 7:50 PM, Jerry Leichter leich...@lrw.com wrote:

 On Sep 7, 2013, at 11:16 PM, Marcus D. Leech wrote:
  Jeff Schiller pointed out a little while ago that the crypto-engineering
 community have largely failed to make end-to-end encryption easy to use.
  There are reasons for that, some technical, some political, but it is
 absolutely true that end-to-end encryption, for those cases where end to
 end is the obvious and natural model, has not significantly materialized
 on the Internet.  Relatively speaking, a handful of crypto-nerds use
 end-to-end schemes for e-mail and chat clients, and so on, but the vast
 majority of the Internet user-space?  Not so much.
 I agree, but the situation is complicated.  Consider chat.  If it's
 one-to-one, end-to-end encryption is pretty simple and could be made simple
 to use; but people also want to chat rooms, which are a much more
 complicated key management problem - unless you let the server do the
 encryption.  Do you enable it only for one-to-one conversations?  Provide
 different interfaces for one-to-one and chat room discussions?

 Even for one-to-one discussions, these days, people want transparent
 movement across their hardware. 

Re: [Cryptography] In the face of cooperative end-points, PFS doesn't help

2013-09-07 Thread Bill Stewart

At 06:49 PM 9/6/2013, Marcus D. Leech wrote:
It seems to me that while PFS is an excellent back-stop against NSA 
having/deriving a website RSA key, it does *nothing* to prevent the kind of
  cooperative endpoint scenario that I've seen discussed in other 
forums, prompted by the latest revelations about what NSA has been up to.
But if your fave website (gmail, your bank, etc) is disclosing the 
session-key(s) to the NSA,


Depends a lot on how cooperative they are.  It's much easier to get a 
subpoena/secret-order/etc. for business records that a company 
keeps, which may include the long-term key, than to get one for 
transient session keys that their software doesn't keep.  Doesn't 
mean they can't do it, but it's probably much easier to get an order 
to produce plaintext, especially for a company like a bank or email 
service where the plaintext is something they would be keeping, at 
least briefly, as a business record anyway.


Do we now strongly suspect that NSA have a flotilla of TWIRL (or 
similar) machines, so that active cooperation of websites isn't 
strictly necessary

  to derive their (weaker) RSA secret keys?


Unlikely - the economics are still strongly against that.  Keeping a 
fleet of key cracking machines to grab long-term private keys from 
high-value targets might make sense, but each long-term key gets used 
to protect thousands or millions of transient session keys.  If they 
have 1024-bit RSA crackers at all, unless there's been a radical 
breakthrough in factoring, they're still not fast.


I've always preferred RSA-signed Diffie-Hellmann to encrypted 
session-key transfer when it's practical.  The long-term keys only 
get used for signatures, so if they're compromised they can only be 
used to impersonate the endpoints, not to read previous sessions, and 
under less-than-NSA versions of due process, it's a lot easier to 
argue in court against a police agency that wants to impersonate you 
than one that wants a copy of a transaction.


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


Re: [Cryptography] In the face of cooperative end-points, PFS doesn't help

2013-09-07 Thread Tony Arcieri
On Fri, Sep 6, 2013 at 6:49 PM, Marcus D. Leech mle...@ripnet.com wrote:

 It seems to me that while PFS is an excellent back-stop against NSA
 having/deriving a website RSA key


Well, it helps against passive eavesdropping. However if the NSA has a web
site's private TLS key, they can still MitM the traffic, even with PFS.

Likewise with perfect forward secrecy, they can collect and store all
your traffic for the next 10-20 years when they get a large quantum
computer, and decrypt your traffic then.

PFS is far from perfect

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

Re: [Cryptography] In the face of cooperative end-points, PFS doesn't help

2013-09-07 Thread james hughes

On Sep 7, 2013, at 1:50 PM, Peter Fairbrother zenadsl6...@zen.co.uk wrote:

 On 07/09/13 02:49, Marcus D. Leech wrote:
 It seems to me that while PFS is an excellent back-stop against NSA
 having/deriving a website RSA key, it does *nothing* to prevent the kind of
   cooperative endpoint scenario that I've seen discussed in other
 forums, prompted by the latest revelations about what NSA has been up to.
 
 True.
 
 But does it matter much? A cooperative endpoint can give plaintext no matter 
 what encryption is used, not just session keys.

+1. 

Cooperative endpoints offer no protection to any cryptography because they have 
all the plaintext. One can argue that the subpoenas are just as effective as 
cooperative endpoints. The reductio ad absurdum argument is that PFS is not 
good enough in the face of subpoenas? I don't think cooperative endpoints is a 
relevant point. 

Passive monitoring and accumulation of cyphertext is a good SIGINT strategy. 
Read about the VENONA project. 
http://en.wikipedia.org/wiki/Venona_project
 Most decipherable messages were transmitted and intercepted between 1942 and 
 1945. […] These messages were slowly and gradually decrypted beginning in 
 1946 and continuing […] through 1980,

Clearly, the traffic was accumulated during which time there was no known 
attack.

While reusing OTP is not the fault here, PFS makes recovering information with 
future key recovery harder, since a single key being recovered with whatever 
means, does not make old traffic more vulnerable. 

This is not a new idea. The separation of key exchange from authentication 
allows this. A router I did the cryptography for (first produced by Network 
Systems Corporation in the 1994) was very careful not to allow any old (i.e. 
recorded) traffic to be vulnerable even if one or both end points were stolen 
and all the key material extracted. The router used DH (both sides ephemeral) 
for the key exchange and RSA for authentication and integrity. This work 
actually predates IPSEC and is still being used.

http://www.blueridge.com/index.php/products/borderguard/borderguard-overview

I am getting from the list that there have been or are arguments that doing two 
public key operations is too much. Is it really? 

PFS may not be a panacea but does help.


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

Re: [Cryptography] In the face of cooperative end-points, PFS doesn't help

2013-09-06 Thread Marcus D. Leech
It seems to me that while PFS is an excellent back-stop against NSA 
having/deriving a website RSA key, it does *nothing* to prevent the kind of
  cooperative endpoint scenario that I've seen discussed in other 
forums, prompted by the latest revelations about what NSA has been up to.


But if your fave website (gmail, your bank, etc) is disclosing the 
session-key(s) to the NSA, or has deliberately-weakened session-key 
negotiation in

  some way, then PFS doesn't help you.

I agree that if the scenario is NSA has a database of RSA keys of 
'popular sites' then PFS helps tremendously.  But if the scenario goes 
deeper
  into the cooperative endpoint territory, then waving the PFS flag 
is perhaps like playing the violin on the deck of the Titantic.


Do we now strongly suspect that NSA have a flotilla of TWIRL (or 
similar) machines, so that active cooperation of websites isn't strictly 
necessary

  to derive their (weaker) RSA secret keys?


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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