WhisperSystems + WhatsApp

Andy Isaacson adi at hexapodia.org
Fri Nov 28 20:00:10 PST 2014


On Fri, Nov 28, 2014 at 06:09:20PM -0800, coderman wrote:
> for my second act as devil's advocate,
>  i declare that it is unreasonable to demand users recognize or
> understand a threat model.
> 
> thus every system must be engineered to withstand the most difficult
> and well resourced threats, such that a solution covers all threat
> models sufficiently.

Agreed on the first point, disagree on the second.  Any system that
claims to be secure will attract uses that are inappropriate to its
assumptions.  Documentation is not enough to dissuade this.

A colleague and I, both interested in modern cryptographic systems,
started to collaborate on a new project, using Pond.  Months later, we
realized that we had communicated useful information early on, over Pond
exclusively, and the "social norm that communications are deleted after
a few days" resulted in us losing important notes about the early days
of our project.

Even though it was clearly documented and I had simultaneously advocated
Pond to other experimental users for exactly this feature, I didn't
think through the consequences of this design feature for my use case.
I didn't even realize that I *had* a use case, until much later.

For this scenario, it turns out we wanted a modern secure communication
system more like Prate, https://github.com/kragen/prate .  Except
perhaps with email-sized-message semantics rather than chat semantics
(or email in addition to chat?).

Generalizing from this specific example, you can find many other
examples of a security system being used outside of its designed
envelope.

ssh is widely used for login to ephemeral hosts, reducing
TOFU to single session duration.

ssh is used with github as merely a bidirectionally-key-authenticated
transport layer ("git clone git at github.com:kragen/prate") rather than
its original remote shell purpose.

HTTPS x509 DV certificates have the mostly verstigal x.500 (iirc?)
Location/organization/etc naming support, the CN/sAN fields being nearly
the only operative ones.

HTTPS virtually never uses the many varied client authentication
mechanisms supported in TLS (client certificates, SRP, etc), instead
Rails and the many other web-app frameworks implement user
authentication over the top using passwords and cookies etc.

-andy



More information about the cypherpunks mailing list