summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorelijah <elijah@riseup.net>2013-12-09 12:47:52 -0800
committerelijah <elijah@riseup.net>2013-12-09 12:47:52 -0800
commit1a08b316ea1d28a9e350df65c22356bd45aab5ef (patch)
tree967f09325028c2381d23d3fb0030a1f307d832a5
parent0faf2b9bae79db79450d5be8d4eb3e873604bf8b (diff)
updated hard-problems text
-rw-r--r--docs/tech/hard-problems/en.md14
1 files changed, 12 insertions, 2 deletions
diff --git a/docs/tech/hard-problems/en.md b/docs/tech/hard-problems/en.md
index d8a748e..635ae16 100644
--- a/docs/tech/hard-problems/en.md
+++ b/docs/tech/hard-problems/en.md
@@ -30,6 +30,8 @@ The problem:
If proper key validation is a precondition for secure communication, but it is too difficult for most users, what hope do we have? We have developed a unique federated system called [Nicknym](/nicknym) that automatically discovers and validates public keys allowing the user to take advantage of public key cryptography without knowing anything about keys or signatures.
+The standard protocol that exists today to solve this problem is [DANE](https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities). DANE might be the better option in the long run, but currently DANE is complex to set up, complex for clients to consume, leaks association information to a network observer, and relies on trusting the DNS root zone and TLD zones.
+
### Meta-data problem
The problem:
@@ -66,7 +68,7 @@ In the short term, we are layering forward secret transport for email and chat r
This approach is potentially effective against external network observers, but does not achieve forward secrecy from the service providers themselves.
-In the long term, we plan to work with other groups to create new encryption protocol standards that can be both asynchronous and forward secret. :
+In the long term, we plan to work with other groups to create new encryption protocol standards that can be both asynchronous and forward secret:
* [Forward Secrecy Extensions for OpenPGP](http://tools.ietf.org/html/draft-brown-pgp-pfs-03)
* [Triple elliptical curve Diffie-Hellman handshake](https://whispersystems.org/blog/simplifying-otr-deniability/)
@@ -81,6 +83,8 @@ We have a lot of ideas, but we don't have any solutions yet to fix this. Essenti
Most of the interesting work in this area has been done by companies working on secure file backup/sync/sharing, such as Wuala and Spideroak. Unfortunately, there are not yet any good open protocols or free software packages that can handle group cryptography.
+At the moment, probably the best approach is the simple approach: a protocol where the client encrypts each message to each recipient individually, and has some mechanism to verify the transcript to ensure that all parties received the same messages.
+
There is some free software work on some of interesting building blocks that could be useful in building group cryptography. For example:
* [Proxy re-encryption](https://en.wikipedia.org/wiki/Proxy_re-encryption): This allows the server to re-encrypt to new recipients without gaining access to the cleartext. The [SELS mailing list manager](http://sels.ncsa.illinois.edu/) uses OpenPGP to implement a [clever scheme for proxy re-encryption](http://spar.isi.jhu.edu/~mgreen/proxy.pdf).
@@ -104,10 +108,16 @@ The problem:
> People want to smoothly switch devices, and restore their data if they lose a device, but this very difficult to do securely.
-Users today demand the ability to access their data on multiple devices and to have piece of mind that there data will not be lost forever if they lose a device. In the free software world, only Firefox has addressed this problem adequately and in a secure way (with Firefox Sync).
+Users today demand the ability to access their data on multiple devices and to have piece of mind that their data will not be lost forever if they lose a device. In the free software world, only Firefox has addressed this problem adequately and in a secure way (with Firefox Sync).
At LEAP, we have worked to solve the availability problem with a system we call [Soledad](/soledad) (for Synchronization of Locally Encrypted Documents Among Devices). Soledad gives the client application an encrypted, synchronized, searchable document database. All data is client encrypted, both when it is stored on the local device and synced with the cloud. As far as we know, there is nothing else like it, either in the free software or commercial world.
+Soledad tries to solve the problem of general data availability, but other initiatives have tried to tackle the more narrow problem of availability of private keys and discovered public keys. These initiatives include:
+
+* Ben Laurie's [proposed protocol for storing secrets in the cloud](http://www.links.org/files/nigori/nigori-protocol-01.html)
+* Experimental [code for similar cloud storage of keys](https://github.com/mettle/nilcat)
+* Phillip Hallam-Baker's [thoughts along similar lines](http://tools.ietf.org/html/draft-hallambaker-prismproof-key-00)
+
### Update problem
The problem: