[cryptography] open letter to Phil Zimmermann and Jon Callas of Silent Circle, re: Silent Mail shutdown

Peter Maxwell peter at allicient.co.uk
Sat Aug 17 18:05:02 EDT 2013


On 17 August 2013 19:23, Jon Callas <jon at callas.org> wrote:

>
> On Aug 17, 2013, at 10:41 AM, ianG <iang at iang.org> wrote:
>
> > Apologies, ack -- I noticed that in your post.
> >
> > (And I think for crypto/security products, the BSD-licence variant is
> more important for getting it out there than any OSI grumbles.)
>
> Thanks. I agree with your comments in other parts of those notes that I
> removed about issues with open versus closed source. I often wish I didn't
> believe in open source, because the people doing closed source get much
> less flak than we do.
>

I'm not sure that's true (that closed-source gets less flak).  From the
user's point of view if security issues arise in a closed-source product
then there are two possible explanations: either the vendor made a mistake
or they did it deliberately; with no way to distinguish, it can be much
more damaging to a company's reputation.  This can be demonstrated by
example: can we have a show of hands for anyone who would trust Skype to
handle anything important/sensitive?

An open-source product on the other hand - in theory at least - is more
amenable to people determining whether a problem was a mistake or
deliberate... or at least the user can make an informed choice based on the
evidence.  From a personal point of view, I don't tend to run software I
cannot look at the source for; granted that is in part due to being able to
fix problems more easily but there have been instances where I've chosen
not to use software because I've seen the state of the source and thought
"nae danger am I running that on an internet facing interface".

So, long-story-short, I think your choice was the preferable one and any
flak you might be getting is more likely to work in your favour in the long
term, as long as you keep doing as you have done by continuing to address
those concerns.  There are complicating factors with software like
SilentCircle as I don't trust the underlying OS or firmware of any
currently available mobile device - and I trust even less any potential
recipient's device - but that's a whole other discussion, and a far more
difficult problem.



>
> > Ah ok.  Will they be writing an audit report?  Something that will give
> us trust that more people are sticking their name to it?
>
> I get regular audit reports, and have since last fall. :-)
>
> I haven't been putting them out because it felt like argument from
> authority. Hey, don't audit this yourself, trust these guys!
>
> Moreover, those reports are guidance we have from an independent party on
> what to do next. I want those to be raw and unvarnished. If they're going
> to get varnished, I lose guidance and I also lose speed. A report that's
> made for the public is definitionally sanitized. I don't want to encourage
> sanitizing.
>
> It's a hard problem. I understand what you want, but my goal is to provide
> a good service, not a good report.
>

I personally wouldn't expect publication of internal audits.  What might
assuage peoples' concerns though is being able to verify the package they
are running has definitely been compiled from the source code that is
publicly available: people have checked the source for SilentCircle's
products - and from what I can tell, independently - so if we assume we
trust the source there needs to be a chain of trust to ensure the binary
that's being executed has not been altered (I don't expect you ever would
but it's a nice feature to be able to prove it).

The corollary to this is for the ultra paranoid, the provision of a
hash/signature would probably be better done by a third-party, i.e. if
Zooko is intimating that in the current model SilentCircle could distribute
a back-doored package then there is no improvement unless the trust is
shared with an independent third-party... preferably someone not subject to
US jurisdiction.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20130817/3d44e277/attachment.html>


More information about the cryptography mailing list