Re: [liberationtech] Security / reliability of cryptoheaven ?

On Tue, Oct 9, 2012 at 5:01 AM, Maxim Kammerer wrote:

On Wed, Oct 3, 2012 at 2:41 PM, D J Capelis 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