your post was very long, not that it wasn't good, but i just want to premise my response with .. i skimmed the aforementioned.<br><br><br>I have a scenario. <br><br>foobar127 creates his freedombox social networking profile and posts information with his user key. foobar127 sends messages to various members including an employee for a repressive government that foobar127 will leak information on in the future. Foobar127 uses various services which utilises the user keys ect ect. <br>
<br>foobar127 leaks information on his government that can get him into a lot of trouble. The leaked information is sent/encrypted with the same user key/keys <br><br>cant these be back traced to identify the original source. <br>
<br><br>any form of automatic user/box identification should be excluded in my opinion. <br><br><div class="gmail_quote">On Sat, Jul 9, 2011 at 7:25 PM, Boaz <span dir="ltr"><<a href="mailto:alt.boaz@gmail.com">alt.boaz@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">In recognition of the fact that the list is being swamped with<br>
enthusiastic but unspecific comments, and to help you decide not to<br>
read my post if it suits your fancy, I'm going to state right at the<br>
beginning of the post that I'm not a competent developer by any<br>
stretch.<br>
<br>
On the other hand, I have been following the list for many months now,<br>
so I won't be completely oblivious to discussions that have already<br>
taken place.  And as for my technical prowess and insight, well, judge<br>
me by my words.<br>
<br>
I humbly ask for your readership.<br>
<br>
>If the repressed source is known only publicly as "fubar127", the<br>
>non-repressed activist can use OpenPGP certifications to assert that<br>
>fubar127 does in fact hold key X.<br>
<br>
Here I must disagree.  The anonymous blogger named fubar127 does not<br>
need anyone to attest to his identity as fubar127.  He need only start<br>
posting comments under that name, signed with some key.  Consider the<br>
person who reads some posts by fubar, and comes to think of fubar as a<br>
specific person whom a new post may or may not be written by.  If he<br>
wants to know whether a new post is by the “real” fubar127, he (his<br>
software) need only check that it's signed with the same key as the<br>
prior posts.<br>
<br>
Indeed, an ad-hock identity with no prior meaning to the person who<br>
needs to verify it is the one and only type of identity for which key<br>
continuity alone is a sufficient authentication method.  For any other<br>
“identity”, some authentication is required.<br>
<br>
<br>
The recent talk of public key authentication in the “Relationship<br>
driven privacy” and “Establishing Communication between Freedomboxes”<br>
threads and the fascinating discussion of the “bump” or “high-five” or<br>
whatever it should be called, a while back, as well as my finally<br>
having time to write, has inspired me to write this post.<br>
<br>
Perhaps before reading this post you should read two other posts,<br>
“Freedom Box as the server for other projects' protocols”, and<br>
“Freedom Box client device software” that I'll make within the next<br>
couple minutes, because in this post I reference ideas discussed in<br>
them.  Also, if you're interested by what I say, I've already written<br>
about aspects of this post's topic in previous posts to this list,<br>
which you could find and read if you like.<br>
<br>
In this post, I advocate a design philosophy for end-to-end<br>
cryptographic protocols, which has been brewing in my head for over a<br>
year now.  It's a philosophy which I'm sure I can't truthfully claim<br>
to be novel, indeed, I'm sure components of it have come to me from<br>
dozens of sources.  I call it novel in the subject, only because it is<br>
not reflected in the design of any existing protocol, it desperately<br>
needs to be, and I've never seen it described explicitly in its<br>
entirety.<br>
<br>
It's a simple philosophy, which grows naturally out of a single<br>
remarkable insight, which I feel that the global community of<br>
developers in the field of cryptography is gradually coming to, but<br>
not nearly quickly enough.<br>
<br>
It's a simple philosophy, but I think it will be revolutionary in its<br>
effects.  At the risk of being over dramatic, for thousands of years,<br>
cryptography has been a tool only for the powerful to oppress, never<br>
for the balance of humanity to live free.  In the 1970s came advances<br>
which stand poised to change all that, but a few obstacles remain.  I<br>
believe that this philosophy, properly implemented, will be the final<br>
ingredient in a recipe, (started in the 1970s) for human liberation on<br>
such a scale as the world has never seen.<br>
<br>
Its proper conclusion is a protocol and a software to implement it<br>
which I'm sure would become a cornerstone of Freedom Box, but which,<br>
like the myriad of components of the future Freedom Box which don't<br>
yet exist, probably should be developed apart from the Freedom Box<br>
project.  That said, the reason I'm writing about it here is that I<br>
intend, over the next few weeks/months/years, to peddle this notion to<br>
anyone who will listen, and this list is too great a gathering of<br>
people with both the skills and the interests necessary for realizing<br>
this vision, to pass up the opportunity to peddle it here.<br>
<br>
Now that I've talked this notion up so high, without further ado I'll<br>
begin my sales pitch.<br>
<br>
<br>
If you want to skip ahead, so to speak, and cut to the chase, here are<br>
the tenants of the philosophy I'm advocating:<br>
<br>
1. A persistent key, which defines an identity, is used for<br>
authenticating transient keys used for encryption of message content.<br>
I'll call these “identity keys”.<br>
2. All the numerous and varied communication protocols serving<br>
different forms of communication and with different security<br>
properties derive their authentication from the single identity key.<br>
3. When two people want to start communicating, their software<br>
exchanges their identity keys and starts using them, even if no method<br>
for authenticating the identity keys is available at the time of<br>
exchange.<br>
4. Authentication of the identity keys could take place at the time of<br>
exchange, or at a later time.<br>
5. There are many different ways to authenticate identity keys, each<br>
of which may be more practical than all the others in some set of<br>
circumstances.<br>
6. To secure all forms of communication with one individual, it's<br>
necessary to authenticate one identity key, once, by the single most<br>
convenient from among all the possible methods.<br>
7. Bottom line: communication protocol is independent of authentication method.<br>
<br>
Following is a more thorough discussion of the advantages of this framework.<br>
<br>
We know the goal; the goal is the privacy of strong end-to-end<br>
cryptography extended to every last human soul and to every last<br>
message.<br>
<br>
And we know the problem, the problem of public key authentication, the<br>
problem of “I'm sending and/or receiving messages to/from someone, but<br>
is that someone the someone I think it is?”.<br>
<br>
It's a difficult problem.  A public key is an unwieldy thing.  And<br>
while it does not need to be kept secret (it's best feature), it,<br>
which is an instrument of “signatures”, before it can be fully<br>
trusted, ironically must itself be “signed” so to speak in some way<br>
that proves that it belongs to whoever it is that you actually want to<br>
be talking secrets with.<br>
<br>
Excuse my pessimism, but no method which involves manually verifying,<br>
by voice or print, hexadecimal strings, will ever be used by very many<br>
people.  He who has both the proper skills and either an intense need<br>
for secrecy, or a deep fascination with cryptography itself, might<br>
embrace this method, but the lion's share of humanity never ever will.<br>
<br>
I think it'll be valuable to discuss at this juncture some tremendous<br>
limitations in the utility of PKI, that system by which someone whose<br>
key you've already securely verified, and whom you personally trust,<br>
has verified the relationship between a key and the “identity” of the<br>
new person you want to talk to.  Too many people seem to think that<br>
this method is a total solution to the problem.<br>
<br>
Even when, unlike X.509 as implemented by web browsers, and like<br>
OpenPGP, the trust model is in keeping with the actual human trust<br>
model of the user, I see three very burdensome limitations inherent to<br>
this method:<br>
<br>
1.Okay, so you verify the key of the new person you want to talk with<br>
based on your trust in someone else.  How did you verify that person's<br>
key?  And how did that person verify the key of the new person?  At<br>
some point, someone's got to be using some other method.<br>
2.It's easy to lose sight of the fact when traveling among certain<br>
social circles unrepresentative of humanity as a whole, but among the<br>
vast majority of humanity, the WOT is a green field.  You don't get<br>
much help from a “web” when that web so far has no strands.<br>
3.“Identity” you say?  What is this “identity” thing?  One name almost<br>
surely belongs to many people, and one person surely belongs to many<br>
names.  Just what value of “identity” were you interested in<br>
verifying.  Any solution that has someone else do the verification for<br>
you involves you and that person having the same notion of what<br>
identity means.  The most robust solution is one which enables you,<br>
through direct cooperation with the person whose identity you're<br>
trying to verify, to verify exactly the “identity” which is of concern<br>
to you.<br>
<br>
I'm not trying to say that the WOT model doesn't have its use.  I'm<br>
trying to say that we shouldn't rely on it as being the perfect and<br>
only solution.<br>
<br>
Thankfully, several powerful and elegant solutions have been<br>
developed.  The newer versions of OTR use a system by which an (even<br>
very short!) arbitrary shared secret can be used for authentication,<br>
using a very cool protocol called socialist millionaire's protocol.<br>
One word or even a single character scribbled on a napkin at a party,<br>
perhaps?  Or, if you have shared past experiences with this person,<br>
you could surely agree, over a potentially insecure channel, on a<br>
secret which you both know, but which an attacker, even having access<br>
to the words you used to agree on it, would not be able to guess.  The<br>
value of “identity” that this procedure verifies is “that person who<br>
knows the secret”, rather than a name.<br>
<br>
A protocol called ZRTP authenticates VoIP calls using verification, by<br>
voice, of two words generated from a list of words using a hash of the<br>
result of a Diffie-Helman exchange.  “Clockwork Pegasus?”  “Yup,<br>
Clockwork Pegasus.”  “Okay good, we're secure.”  The value of identity<br>
that this procedure verifies is “that person whose voice is that<br>
particular voice which I recognize”, not a name.<br>
<br>
The discussion on this list a few days ago, points out that a key<br>
fingerprint could be exchanged in a scanable, machine readable format<br>
(e.g. a QR code), either displayed on a smartphone screen for another<br>
smart phone to scan, or printed on a business card to be scanned on<br>
the spot or at a later time.  The same QR code could also contain<br>
other information (e.g. contact info).  The value of identity which<br>
this procedure verifies is “that person whom I met that one time”, not<br>
a name.<br>
<br>
There's three different, relatively easy to use ways to authenticate a<br>
person's public key.  Each one might be easier than the others in a<br>
different set of circumstances.  The ZRTP way is probably easiest for<br>
someone you already know (and recognize the voice of), especially if<br>
meeting in person is not convenient.  Unless you don't have the<br>
ability to make a voice call (there might be many reasons for this),<br>
in which case a secret negotiated based on past shared experience<br>
might be best.  If this is someone you're just now meeting, in person,<br>
then the “bump” system is probably easiest.  Of course, unless not<br>
both parties brought smart phones and not both parties brought<br>
business cards, in which case the secret agreed on in person will do<br>
nicely.<br>
<br>
Okay, so far I've established that there's a problem, it's a difficult<br>
problem, but there are some good solutions for it.  So what's the<br>
special insight?<br>
<br>
Think of, for a moment, all the cryptographic protocols which you use.<br>
 You probably use SSL/TLS, and IPSEC, and SSH, and OpenPGP.  Perhaps<br>
you use OTR, maybe even ZRTP, probably others which I didn't think of<br>
just now or haven't heard of.<br>
<br>
You're used to the authentication method of each of those protocols.<br>
You're browser has checked X.509 certificates, you have verified PGP<br>
fingerprints, and SSH fingerprints (or maybe just crossed your<br>
fingers), perhaps you've typed shared secrets into your chat client or<br>
voiced short authentication strings.<br>
<br>
It's a paradigm that we take for granted: each protocol has it's own<br>
method for solving the difficult problem of authentication, and if<br>
you're going to use that protocol, you'd better authenticate the other<br>
person using the authentication method used by that protocol.<br>
<br>
So I pose a hypothetical.<br>
<br>
Say you're trying to establish secure communication with someone you<br>
just met.  You plan to securely communicate with this person using<br>
many different forms of communication: email, IM, VoIP, websites, file<br>
transfer, remote login sessions, everything you can think of.  You're<br>
on the phone, and you have just finished reading each other your PGP<br>
fingerprints.  Okay, now you should exchange SSH fingerprints, then<br>
OTR fingerprints, then X.509 certificate fingerprints, and so on.  Get<br>
comfortable, you're going to be on the phone for a while.  Or wait,<br>
why bother?  Just end the call, and then send the other person an<br>
email, signed with your PGP key (which you've already exchanged),<br>
containing all that other information.<br>
<br>
Notice what just happened.  You've already authenticated this other<br>
person, you've already accomplished that difficult task.  Now you can<br>
use that authentication which you've already done as a basis to secure<br>
many different communication protocols.  In fact, why do you need to<br>
do anything manually to take advantage of this?  Shouldn't your<br>
computer do it automatically?<br>
<br>
That's the basic insight.  Why do I need to use a specific method of<br>
authentication for a specific form of communication?  Why not just use<br>
whichever method is most practical given the circumstances.  Why<br>
should I need to authenticate with a single person more than once?<br>
Why not just once.<br>
<br>
This basic premise is what's so revolutionary about Monkeysphere.<br>
What actually is Monkeysphere?  It's just a way to use the<br>
authentication mechanism of one protocol, OpenPGP, to authenticate two<br>
other protocols, SSL and SSH.  In other words, it's the beginning of<br>
the process by which the unnecessary mapping between communication<br>
methods and authentication methods starts to breakdown.<br>
<br>
So here are the tenants of the design philosophy that I think so<br>
desperately needs to be used as the basis for cryptographic protocol<br>
design:<br>
1. A persistent “identity key” is used for authenticating transient<br>
keys used for encryption of message content.<br>
2. All encrypted communication protocols derive their authentication<br>
from the single identity key.<br>
3. Identity keys are exchanged, and encryption starts, immediately.<br>
4. Authentication could place at the beginning, or at a later time.<br>
5. A whole list of authentication methods are supported.<br>
6. All communication protocols are authenticated by one authentication<br>
event, which utilizes the single most convenient from among the<br>
supported methods.<br>
7. Bottom line: communication protocol is independent of authentication method.<br>
<br>
What I imagine as a base reference implementation of this philosophy,<br>
is a combination mail client, IM client, and VoIP client, with a<br>
unified contacts interface.  Each contact is defined by an identity<br>
key, and identified in the interface by a local pet name which the<br>
user chooses, though the contact may suggest one.<br>
<br>
For example, the user “bumps” with a person whose smart phone is<br>
configured to suggest the name “Robert Foo” (which is his actual full<br>
name).  But this particular Robert Foo is the user's mother's brother,<br>
and so she ignores that suggestion and chooses the name “Uncle Bob”<br>
for this contact.  When she's using the contact interface, to send<br>
emails or initiate chats or phone calls, she needn't even mess with<br>
the actual email addresses, SIP addresses, or XMPP addresses.  She<br>
just, for example, starts a chat with “Uncle Bob”.<br>
<br>
The identity key isn't used for encryption of message content.<br>
Rather, it's used for verification of the keys that are used to<br>
encrypt message content.  Each communication protocol can have the<br>
security properties desired.  For example, perhaps by default phone<br>
calls come with perfect forward secrecy and deniability, and are not<br>
recorded, chats come with perfect forward secrecy and deniability, but<br>
are recorded, and same for email, except email with people in the<br>
“business contacts” section of the contacts, which are non-repudiable.<br>
 Or whatever.  The point is that each form of communication can get<br>
it's own desired security properties, but all are authenticated by a<br>
single identity key which isn't ever used for any other purpose and so<br>
doesn't interfere with the unique security properties of the<br>
respective protocols.<br>
<br>
Now say our user, call her Alice, has chatted with Uncle Bob a few<br>
times.  Then, Bob sends her an email, using an email address that her<br>
client software has never seen before.  But it identifies itself using<br>
the identity key that her client knows as “Uncle Bob”.  And therefore,<br>
the email (from an address she's never seen before in her life), is<br>
automatically presented to her as being from “Uncle Bob”.<br>
<br>
So the problem of authentication is confirming that the identity key<br>
which defines a contact truly belongs to the person that the user had<br>
in mind.  That the Uncle Bob key really does belong to Alice's uncle,<br>
Bob.  This is up to the user to determine.<br>
<br>
The program provides several convenient ways to do this.  Ever time<br>
the user makes a phone call, short authentication strings appear ready<br>
to be verified in case the parties to the conversation decide to do<br>
so.  While chatting, the user can at any time click “enter secret” to<br>
offer to the other person's client to do a socialist millionaire's<br>
exchange against the other persons' secret.  At any time, the user can<br>
scan a QR code, containing a key fingerprint (and which may also<br>
contain an email address, and XMPP address, a SIP address, and a<br>
suggested pet name, among other information), and confirm that it<br>
matches the key.<br>
<br>
But even if the user doesn't do any of these things, keys are agreed<br>
upon and used, preventing a passive listening attack from working.<br>
Whenever the user does do any of these things, from that moment on she<br>
can be assured that all future and past communications will not<br>
be/have not been MITMed.<br>
<br>
Perhaps the way two users got each other's contact info was using QR<br>
codes, in which case the keys were authenticated right from the<br>
beginning.  Or maybe the users exchanged email addresses, exchanged a<br>
few emails over the course of a week, and then made a phone call and<br>
verified the short authentication string, and the keys were<br>
authenticated a week after they started to be used.  Maybe the users<br>
communicate for years, and only then decide to talk about something<br>
super secret, and do a socialist millionaire exchange on some shared<br>
secret.  Whatever.<br>
<br>
I envision that in the contact interface, you can click on a contact<br>
and select “authentication information” or “is this really the right<br>
person” or something like that, and see information about what<br>
method(s) have or have not been used to authenticate that contact.<br>
<br>
Provided with this tool, with a selection of easy to use<br>
authentication methods any one of which can be used just once to<br>
authenticate encryption for all forms of communication with a certain<br>
contact, the bulk of the internet connected world will finally be able<br>
to enjoy the benefit of strong and strongly authenticated end-to-end<br>
encryption, rather than just a few crypto geeks.  This tool's effects<br>
on human freedom will be profound and long lasting.<br>
<br>
<br>
Ultimately, I envision that this combined mail/IM/VoIP client will be<br>
expanded to support other protocols (anyway this program is really<br>
just existing clients for the various protocols tacked together into a<br>
single interface).  And as it grows to support other protocols, it<br>
will come to support every protocol that the Freedom Box will come to<br>
serve, and it will become the Freedom Box interface application.<br>
<br>
I hope that I have captured the imagination of even just one person<br>
with skills to help bring this vision about.  Thank you for your time.<br>
<br>
<br>
<br>
Boaz<br>
<br>
_______________________________________________<br>
Freedombox-discuss mailing list<br>
<a href="mailto:Freedombox-discuss@lists.alioth.debian.org">Freedombox-discuss@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Thank you for your time<br>~Nathan<br><a href="mailto:nathan1465@gmail.com" target="_blank">nathan1465@gmail.com</a><br><br>