[liberationtech] Security / reliability of cryptoheaven ?

[D J Capelis]

On Tue, Oct 9, 2012 at 5:01 AM, Maxim Kammerer <mk at dee.su> wrote:
> On Wed, Oct 3, 2012 at 2:41 PM, D J Capelis <djcapelis at cs.ucsc.edu> wrote:
> > I like the part where you say the problem is easy and then point to a
> > solution with issues that make it anything but easy, tenable or
> > workable.
>
> Why? The solution (if you refer to cables in LibertC)) is easy to use,
> is robust, and it works.

Until it works with gmail and other commonly used communications
systems and/or works across multiple common devices and allows a user
to extend their identity and ability to communicate securely using it
across *all* of their devices we're not there yet.  I know that's
frustrating, but I think it's true.  I realize that many of these
systems are great tradeoffs that work in *some* niches, but pretending
the problem of secure communications is simple and solved when most
users do not have access to a usable solution goes too far IMO.

I'm not saying the technology we have is bad, or that anything that's
been developed isn't good, I'm just saying that calling the problem
easy or solved erases the huge amount of space for work and progress
that still remains.

> There is apparently no solution to this
> tradeoff b see Zooko's triangle in [2].

Yes.  The fact that some levels of usability is *impossible* under
some designs constraints contributes to the fact that writing this
problem off as easy or solved is probably unwise.

> [2] http://www.skyhunter.com/marcs/petnames/IntroPetNames.html

For what it's worth, I think the PetNames are the right approach if
you focus on Zooko's triangle as your solution space.  (As Jake noted,
it may be possible the square the triangle in some cases.)

I think we often fail when it comes to good interfaces to make
PetNames work in both a secure and usable way.  (It should be so
simple, but people have a tendency to mess it up.)  But I'll note I
haven't reviewed the interfaces for some of the systems discussed in
this thread thoroughly.

> That's why you need self-authenticating addresses, or another way of
> non-optional recipient authentication.

No disagreement from me.

> > And that's not even getting into platform inter-op issues that
> > drive so many people to want to do their crypto in a web interface or on
> > some other person's server.
>
> You can't provide interoperability between secure and insecure systems
> while leaving the security intact. That's why the military uses
> compartmentalization and air gaps.

That's certainly one approach, but are you *certain* it's the only one?

It's a hard problem, but there are sometimes ways to bootstrap certain
types of things on certain types of legacy systems.  It gets really
specific to the type of application in each case and exactly what
parts of the system you want to try calling legacy and unchangeable
vs. parts you want to say you can change.  (Have you thought about the
types of systems you could build with a bit of software and a bit
hardware attached to a USB key?  The possibilities there have been
interesting.  I like designing systems using sandwich stacks, where
you control things under and over an otherwise insecure legacy
system.)

It is true that you usually can't get everything, but sometimes you
can what you need.

> > Pretending it's an easy problem because technologies exist that aren't
> > usable ignore the real technology issues we haven't solved yet.
>
> Only if you want to use technologies that weren't developed with
> security in mind.

I like talking to people using technologies they already use.  When
and if I can do that securely, I'm happy.  When and if I cannot, I'm
aware that there is a lot more progress left to be made on problems
that aren't easy, aren't solved and often aren't tech issues.

My objection wasn't about the technology, it was about declaring
problems as solved and easy when they aren't solved yet.  Which isn't
to say we haven't made progress and shouldn't celebrate that progress,
but I think we can and should do that in a way that keeps a sharp
focus on the challenges which remain.

~DJ
--
Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE