Re: [Cryptography] In the face of "cooperative" end-points, PFS doesn't help
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 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 hardw
Re: [Cryptography] In the face of "cooperative" end-points, PFS doesn't help
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
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
On Sep 8, 2013, at 1:47 PM, Jerry Leichter 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
On Sep 7, 2013, at 8:16 PM, "Marcus D. Leech" 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
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. If I'm in a chat session on my laptop and leave the house, I'd like to be able to continue on my phone. How do I hand off the conversation - and the keys? (What this actually shows is the complexity of defining "the endpoint". From the protocol's point of view, the endpoint is first my laptop, then my phone. From the user's point of view, the endpoint is the user! How do we reconcile these points of view? Or does the difference go away if we assume the endpoint is always the phone, since it's always with me anyway?) The same kinds of questions arise for other communications modalities, but are often more complex. One-to-one voice? Sure, we could easily end-to-end encrypt that. But these days everyone expects to do conference calls. Handling those is quite a bit more complex. There does appear to be some consumer interest here. Apple found it worthwhile to advertise that iMessage - which is used in a completely transparent way, you don't even have to opt in for it to replace SMS for iOS to iOS messages - is end-to-end encrypted. (And, it appears that it *is* end-to-end encrypted - but unfortunately key establishment protocols leave Apple with the keys - which allows them to provide useful services, like making your chat logs visible on brand new hardware, but also leaves holes of course.) Silent Circle, among others, makes their living off of selling end-to-end encrypted chat sessions, but they've got a tiny, tiny fraction of the customer base Apple has. I think you first need to decide *exactly* what services you're going to provide in a secure fashion, and then what customers are willing to do without (multi-party support, easy movement to new devices, backwards compatibility perhaps) before you can begin to design something new with any chance of success. -- Jerry -- 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
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
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
On Sep 7, 2013, at 1:50 PM, Peter Fairbrother 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
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. Okay, that might be a little harder to do in bulk - but perhaps not that much harder, depending on circumstances. 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? Maybe. Or maybe they have broken (the NIST curves for) ECDHE. Or maybe it's something else. Whatever, I don't think they would be asking for $5.2 billion plus (for comparison, BULLRUN has an annual budget of $280 million) to spend on developing "advanced cryptanalytic capabilities" for which it is useful to "shape the worldwide cryptography marketplace to make it more tractable to" unless it was against some sort of key establishment mechanism in SSL/TLS. I can't think of any other target which is worth that much money. Okay, maybe I'm ignoring the "never underestimate what the enemy is willing to spend" rule here, but.. Breaking a cipher like AES, 3DES or RC4 wouldn't give them nearly as much access to plaintext as breaking a KEM - they would have to break each ciphertext individually, whereas they would only need to break a KEM once. And most of their interception is passive, they just listen - you generally need at least one plaintext/ciphertext pair to break a cipher and find a session key, and most often they don't have the plaintext, just the ciphertext. You just need the right math (and/or maybe some input into curve choices) to break a PK KEM, and find *all* the session keys it is used for. (the $5.2 billion figure is from a NSA request for additional congressional funding for "exciting new cryptanalytic capabilities" made a few years ago, and leaked by a congressman) -- Peter Fairbrother ___ 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
On Fri, Sep 6, 2013 at 6:49 PM, Marcus D. Leech 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
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
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
