[Freedombox-discuss] Novel design philosophy for end-to-end cryptographic protocols and software

nathan nolast nathan1465 at gmail.com
Sun Jul 10 21:54:39 UTC 2011


your post was very long, not that it wasn't good, but i just want to premise
my response with .. i skimmed the aforementioned.


I have a scenario.

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.

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

cant these be back traced to identify the original source.


any form of automatic user/box identification should be excluded in my
opinion.

On Sat, Jul 9, 2011 at 7:25 PM, Boaz <alt.boaz at gmail.com> wrote:

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



-- 
Thank you for your time
~Nathan
nathan1465 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20110710/b95af75b/attachment-0001.html>


More information about the Freedombox-discuss mailing list