[Cryptography] PRISM-Proofing and PRISM-Hardening

ianG iang at iang.org
Thu Sep 19 06:12:42 EDT 2013

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 <iang at iang.org> wrote:
>> On 17/09/13 23:52 PM, John Kemp wrote:
>>> On Sep 17, 2013, at 2:43 PM, Phillip Hallam-Baker <hallam at 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.


>>   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.


More information about the cryptography mailing list