On Sep 18, 2013, at 4:05 AM, ianG <i...@iang.org> wrote: > On 17/09/13 23:52 PM, John Kemp wrote: >> On Sep 17, 2013, at 2:43 PM, Phillip Hallam-Baker <hal...@gmail.com > >>> I am sure there are other ways to increase the work factor. >> >> I think that "increasing the work factor" would often result in >> switching the kind of "work" performed to that which is easier than >> breaking secrets directly. > > > Yes, that's the logical consequence & approach to managing risks. Mitigate > the attack, to push attention to easier and less costly attacks, and then > start working on those. > > There is a mindset in cryptography circles that we eliminate entirely the > attacks we can, and ignore the rest. This is unfortunately not how the real > world works. Most of risk management outside cryptography is about reducing > risks not eliminating them, and managing the interplay between those reduced > risks. Most unfortunate, because it leads cryptographers to strange > recommendations.
The technical work always needs doing. It's not that we shouldn't do our best to improve cryptographic protection. It's more that one can always bypass cryptographic protection by getting to the cleartext before it is encrypted. > > >> That may be good. Or it may not. > > > If other attacks are more costly to defender and easyish for the attacker, > then perhaps it is bad. But it isn't really a common approach in our > security world to leave open the easiest attack, as the best alternative. > Granted, this approach is used elsewhere (in warfare for example, minefields > and wire will be laid to channel the attack). > > If we can push an attacker from mass passive surveillance to targetted direct > attacks, that is a huge win. The former scales, the latter does not. My point was that "mass passive surveillance" is possible with or without breaking SSL/TLS (for example, but also other technical attacks), and that it is often simpler to pay someone to create a backdoor in an otherwise well-secured system. Or to simply pay someone to acquire the data in cleartext form prior to the employment of any technical protections to those data. Other kinds of technical protections (not really discussed here so far) might be employed to protect data from such attacks, but they would still depend on the possibility for an attacker to acquire the cleartext before such protections were applied. I would point out that it was historically the case that the best espionage was achieved by paying (or blackmailing) people close to the source of the information to retrieve the necessary information. The idea of the "mole". That would seem to still be possible. > > >> "PRISM-Hardening" seems like a blunt instrument, or at least one which >> may only be considered worthwhile in a particular context (technical >> protection) and which ignores the wider context (in which such technical >> protections alone are insufficient against this particular adversary). > > > If I understand it correctly, PRISM is or has become the byword for the NSA's > vacuuming of all traffic for mass passive surveillance. In which case, this > is the first attack of all, and the most damaging, because it is > undetectable, connects you to all your contacts, and stores all your open > documents. > > From the position of a systems provider, mass surveillance is possibly the > most important attack to mitigate. If you yourself the systems provider, or a "bad" employee in your organization, are not handing the necessary cleartext to the attacker… > This is because: we know it is done to everyone, and therefore it is done > to our users, and it informs every other attack. For all the other targetted > and active attacks, we have far less certainty about the targetting (user) > and the vulnerability (platform, etc). And they are very costly, by several > orders of magnitude more than mass surveillance. The issue for me is that it is becoming difficult to know whether one can reasonably trust service providers in the face of coercion. Both for the creation of good-enough technical protections, and the use of them. - johnk > > > > iang > _______________________________________________ > The cryptography mailing list > cryptography@metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
