Thanks! The problem I was facing is a user experience problem while adding
end-to-end encryption to a simple email-like system.
The systems is simply 'log in, receive messages from people, send messages
to people'. The goal is to add end-to-end encryption to it without
compromising the user experience. Our goal is that the system should be
exactly as easy to use with e2ee as without e2ee.
The user experience is however quite awkward, for two reasons:
- everytime you install the software on a new device, you need to move your
private key from the previous device to the new one (this one still stands
unsolved).
- everytime you want to send a message to a new contact, you need to enter
not only his guid ("email address"), but also his public key. (this is the
one we try to address).
When you send a first message to a new contact, you need to look up his
public key. That's when you would do the traversal from your guid to their
guid, checking all the signatures along the path. Since you traverse by
flipping bits one-by-one, the length of the path is limited to length of the
guid hashes. You check all signatures along the way. You signed the public
key of your neighbour,... [... who signed the public key of his
neighbour,...]* ...who signed the public key publicly presented by your
intended recipient. Then it's safe to send the message.
if however the recipient's account has been hacked, then it will try to
present a different public key (one generated by the attacker, who is trying
to lure you into thinking that your message is safe when encrypted against
it). This will be detected instantly by the traversal:
You signed the public key of your neighbour,... [... who signed the public
key of his neighbour,...]* ...who /incorrectly/ signed the supposed public
key publicly presented by [the attacker of] your intended recipient.
If an attacker would manage to own an entire region of neighbours, then it
would still be obvious, because the signatures-chain would be broken at an
even earlier step.
Only if you hacked all accounts, would you, effectively, have hacked all
accounts.
Do you think this could work?
Many thanks!
Michiel.
On Mon, Dec 13, 2010 at 4:22 AM, David Barrett <dbarr...@quinthar.com>wrote:
> I think this is a really interesting idea, but I'll admit, I don't quite
> understand the problem. Can you give a real-world scenario of how this
> would be used, and how it would reject a simple attack?
>
> -david
>
> On 12/11/2010 07:09 PM, Michiel de Jong wrote:
> > Hi,
> >
> > I hope it's ok for me to post this here, I need some feedback on a
> > public key infrastructure. In return, you might enjoy reading it.
> >
> > My goal here is *only* to link public keys to guids, and like spki/sdsi,
> > I assume you already know that the guid as such is bonafide, and I am
> > not trying to link the guid to "Walton's Mountain assumptions" about a
> > real-world person or entity.
> >
> > The only reason I don't use the public key itself directly as the guid,
> > is that I want the guid to be human-memorable (Zooko's triangle); let's
> > say they are email addresses.
> >
> > The problem with using web-of-trust for this is that many times you will
> > want to give someone your email address and start communicating from
> > scratch, without an introducer. Even if a connection exists, it would
> > require search to find it, and search is difficult without
> > centralization. Also my list of "friend-of-a-friend"s (FOAFs), through
> > which i have a chain-of-trust with you, may contain private information
> > about who i hang out with. So the whole web-of-trust approach is a
> > hassle, and also privacy-sensitive. The CA-approach is out of the
> > question from the start, because it's too centralized.
> >
> > So what I came up with was to define a "fabric"-approach. We define a
> > multi-dimensional space in which all guids represent a fixed position.
> > Your coordinates in the fabric are determined not by you, nor by who you
> > interact with, but simply by the ASCII bits in your guid string. And
> > then it's simple: everybody sign the keys of their neighbours and vice
> > versa to form the fabric. Now to know your public key, I just walk from
> > my position in the fabric to yours, following the chain of neighbours
> > that are all 'holding hands', and so everyone's connected with everyone.
> >
> > The idea is that the fabric sums up all the security of everybody, and
> > links it together to make it strong. If you would want to compromise one
> > guid, the neighbourhood watch would notice and refuse to interact with
> > the conflicting public key. If you compromise a whole area, the
> > neighbours of that area would notice. Etcetera.
> >
> > I tried different ways to define the "neighbour" relationship, and in
> > the end I ended up defining a combination of additive and Hamming
> > distance, on bitstrings obtained from the original guid string with
> > non-reversible hashing. I think I sort of got it working, and it seems
> > pretty efficient. But the details of that are not what I wanted to
> > bother you with right now.
> >
> > The non-reversible hashing is there so it's not trivial to 'embush'
> > someone by registering a ring of email addresses around him. It makes it
> > hard to guess a given email address's neighbours, and thus hard to stage
> > an embush. You could still attack the system by flooding it with guids
> > until you are the owner of 99% of the guids. So all guid-providers
> > should put up a captcha to avoid that sort of attack.
> >
> > Also, you would need to define what needs to be done if a tear in the
> > fabric is detected. if there are 2 conflicting public keys being
> > announced, how do you decide what is the right one? you need to make it
> > hard to 'topple the system' into an auto-immune defense against itself.
> > also DDoS and vandalism attacks need some attention. But i think in
> > general, the pki could sort of work.
> >
> > My question is: does my fabric-based approach make any sense? or am i
> > maybe trying to solve a non-existing problem? There must be a flaw
> > somewhere that prevents other people from doing this already, I just
> > don't see it.
> >
> > Many thanks for your time!
> >
> >
> > Kind regards,
> > Michiel de Jong
> > www.unhosted.org/unhosted.html <http://www.unhosted.org/unhosted.html>
> >
> >
> >
> > _______________________________________________
> > p2p-hackers mailing list
> > p2p-hackers@lists.zooko.com
> > http://lists.zooko.com/mailman/listinfo/p2p-hackers
> _______________________________________________
> p2p-hackers mailing list
> p2p-hackers@lists.zooko.com
> http://lists.zooko.com/mailman/listinfo/p2p-hackers
>
_______________________________________________
p2p-hackers mailing list
p2p-hackers@lists.zooko.com
http://lists.zooko.com/mailman/listinfo/p2p-hackers
