Hi John,
(I think we are in agreement here, there was just one point below where
I didn't make myself clear.)
On 18/09/13 23:45 PM, John Kemp wrote:
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.
Right. So the amount of effort we should put in should not be dictated
(solely) by received wisdom about perfect security, but (also) by how
quickly we can push the bulk of the attackers elsewhere. Thus releasing
our costly resources for 'elsewhere'.
I wrote about this tradeoff many moons ago. I called the preferred
target Pareto-secure as a counterpoint to the expected 100% secure,
which I defined as a point where there is no Pareto-improvement that can
be made, because the attacker is already pushed elsewhere.
The other side of the coin is to have a gentler attitude to breaches.
When a breach is announced, we also need to consider whether anyone has
actually lost anything, and whether the ones that weren't attacked have
got good service. A protocol is rarely broken for the user, even if the
cryptographic world uses the word 'broken' for a few bits. E.g., if one
looks at the TLS changes of the last 5 years due to a series of attacks,
there isn't much of a record of actual hacks to users.
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.
To some extent, mass passive surveillance is entirely possible because
SSL/TLS is so poorly employed. I haven't looked for a while, but it was
always about 1% of web traffic.
This is the motive behind HTTPS Everywhere - All The Time. Let's make
SSL the norm not the exception. Then we've got some security against
passive surveillance, then we force the attacker to other attacks, which
are typically much more expensive.
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…
Just to point out, in the above I meant 'systems provider' not as an
end-user-facing services supplier, but as a cryptographic protocol/tool
provider. E.g., OpenSSL is the latter, whereas gmail.com is the former.
Then,...
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.
Right. So this issue has become substantially complicated for (a) very
large suppliers such as google/apple/microsoft because they control
every part of the supply chain and we are reduced to 2-eyes
verification, and (b) closed source suppliers like skype because they
can slide in their non-contractual sharing without anyone noticing.
iang
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
