[cryptography] Reply to Zooko (in Markdown)

ianG iang at iang.org
Sat Aug 31 13:45:34 EDT 2013

Hi Zooko,

On 30/08/13 01:26 AM, zooko wrote:
> On Sat, Aug 24, 2013 at 09:18:33PM +0300, ianG wrote:
>> I'm not convinced that the US feds can at this stage order the
>> backdooring of software, carte blanche.  Is there any evidence of
>> that?
>> (I suspect that all their powers in this area are from pressure and
>> horse trading.  E.g., the export of cryptomunitions needs a
>> licence...)
> I don't know. I asked a lawyer a few days ago -- a person who is, as far as I
> can tell, one of the leading experts in this field. Their answer was that
> nobody knows.

That is how they like it.  In such an environment, they can exert a lot 
of pressure.

But to come to the crunch -- is there *any* evidence that they have ever 
ordered the backdooring of some software system?  Or does it all come 
down to 'an accommodation' ?  I've heard of many of the latter, none of 
the former.

> In any case, you don't appear to be arguing that Silent Text is different than
> Silent Mail,

I'm arguing that there is a huge difference between Silent Text and 
Silent Mail, in that there is a *huge* difference between Text and Mail, 
and I presume SC are as trapped by that as the rest of us.  Text is 
relatively easy to secure, mail is not, and all that difference leads to 
the provision of much passive information at rest (inbox) and much 
metadata in flight (headers).  Juicy target, too much for the Feds to 

Whereas, IM can lock down the metadata, and can dispose of session data 
after the event.  Perfect forward security and all that.

> only that the U.S. Federal Government would not require Silent
> Circle to actively backdoor their own products. This argument applies equally
> to the canceled product and the current ones.

Right.  As we know from experience, the Feds are passive-aggressive. 
They ask you to cooperate and hand stuff over.  Getting a court order to 
hand over stuff that already exists is relatively easy.  But, requiring 
changes to the business approach is another thing entirely.

Also, why would they bother?  Passive eavesdropping is many orders of 
magnitude more efficacious, look at the PRISM take.  Indeed, it's a 
wonder why we ever bothered to worry about the latter, but that's 
another story.

> In fact, I don't think it is a useful question for evaluating the security of
> services that you rely on. If a service provider could spy on you at the behest
> of their government, then an attacker who infiltrated that service provider's
> systems could also spy on you.

I do think it is a useful question, and it is precisely the sort of 
subtle question that comes of risk analysis.

Firstly, the spectrum of most attacks goes from likely to middle to 
unlikely.  Some cryptographic attacks are possibly in a broader spectrum:

     Eliminated -> unlikely -> middle -> likely -> always (mass)

But most aren't.  It's only cryptographic ones that go down to 
"eliminated" and that tends to set us up for biased thinking [1].

Secondly, although most attacks are possible, some of them are more 
likely than others.  Recall the old debate about MITM versus 
eavesdropping.  It was very real, and now we are living it:  the feds 
are now eavesdropping everything, and on an industrial scale, *because 
we did not encrypt on a mass scale* .  But they are not MITMing on 
anything like that scale [0].

So, if the Feds for whatever reason choose to go for attack 1 on a mass 
scale, and not for attack 2 against specific targets, we gain a better 
protection by concentrating our efforts on attack 1.

Thirdly, no matter what our risk analysis does in a closed system of 
attacks {1,2} our users always work in an open system of attacks {1..n} 
and our job is done well if we decrease the likelihood of {1,2} to the 
point where it is going to push the attacker to {3..n}, where that 
subset is risks we can't influence.  There is little point in pushing 1 
& 2 down to zero risk if {3..n} are a mess [1].

(In the above, the risk of an insider infiltrating the service provider 
is just risk P for example.  How likely is it?  Analyse....)

> Imagine that your adversary is not the U.S. NSA, but instead Chinese
> cyber-warriors, and instead of contacting your service provider and demanding
> cooperation, they simply remotely infiltrate your service provider's employee's
> laptops. They've apparently done this many times in recent years, to Adobe,
> Google, Microsoft, Nortel Networks, and basically every other company you can
> name.

Right.  So how likely is this?  What damage does it do?  For the 
"everyone" analysis it seems pretty small, pretty remote.  Even if the 
Chinese get your data, do they care?  Whereas the NSA is now looming 
large as a danger to everyone.

(The distinction is obviously quite subtle and shifts pretty quickly. 
If everyone listening here is Chinese, it flips.  If the NSA were to 
stop feeding national intel to the police, we'd care less about them and 
more about the Chinese, who obviously couldn't care less about Chinese 
walls.  So to speak.  Etc etc.)

> So I don't think the question of "To whom is my service provider vulnerable?"
> is the right question. You can't really know the answer, so it doesn't help you
> much to wonder about it. The right question is "Am I vulnerable to my service
> provider?". The answer, as far as Silent Circle's current products go, is
> "Yes.".

Well.  This is where it gets into deeper analysis.  If the answer to 
your right question is YES, then you have to analyse deeper the risks at 
the service provider.

If the answer is NO, then you're done & dusted.  This is the best 
solution, but it is also something that might not be obtainable.  For 
example, and back to SC, I would say that SC-IM is something that can be 
YES, invulnerable to the provider whereas SC-EM is something that cannot 
be invulnerable to the provider.

It is germane of course that you have established your rep on the basis 
that your offering is invulnerable to service provider corruption.  But 
this is only one threat, one risk.  There are others.

For example, deployability of Tahoe-LAFS remains a barrier, and that 
barrier is probably (arguably) higher than the barrier of installing 
Skype.  Or, Silent Circle (don't know, haven't tried).

So, if your deployability is low, and your provider-invulnerability is 
high, how does that compare to something like Skype, which has the 
reverse, being high-deployability and low (fatally destroyed) 

The maths of risk are a bit complex, and handwavy, but we know from 
experience and principles [K6] that deployability probably trumps.  It's 
the multiplier, the network effect, whereas the other invulnerability 
factors are just asymptotic to 1.

>> I would be surprised if there was a single stated reason.
> Here are the first five hits from DuckDuckGo for the query "silent circle
> mail":

(The MSM love a story like my grandmama, but know not what the moral of 
it is so always bungle the delivery.)

Here's the real meat:

>      There are far too many leaks of information and metadata intrinsically in
>      the email protocols themselves. Email as we know it with SMTP, POP3, and
>      IMAP cannot be secure.
>      https://silentcircle.wordpress.com/2013/08/09/to-our-customers/
> (Kudos to Jon for saying something sensical in that last one!)

Email isn't securable!  (IMHO) IM is, because we can design it from scratch.


[0] Although they are collecting 0days on that scale, it seems, so 
assuming they get value for money, they must be doing some 100s of these 
too by now.

[1] It leads to an obsession of cryptographers to eliminate some risks 
completely, and ignore other risks completely. This is an abomination in 
security thinking!  It results in a panopoly of bad fantastical perfect 
failed products.  FWIW, this looks for a rationale that better places 
the behaviour: http://iang.org/papers/pareto-secure.html

[K6] Kerckhoffs' 6th says that "Finally, it is necessary, given the 
circumstances that command its application, that the system be easy to 
use, requiring neither mental strain nor the knowledge of a long series 
of rules to observe."

More information about the cryptography mailing list