[p2p-hackers] Distributed identity, chat, publishing, and sharing

Sean Lynch seanl at literati.org
Fri Jan 11 10:08:59 PST 2013


On 01/10/2013 07:14 PM, Tony Arcieri wrote:

> For what it's worth, this sounds an awfully lot like what I have
> envisioned for the Cryptosphere:
> 
> https://github.com/tarcieri/cryptosphere

Very interesting. "Cryptosphere" is a good name for such a system,
though from what you describe there the project seems more concerned
about identifying content than people, whereas my idea centers around
identifying people, with content being secondary.

> 
>     Contacts would be identified by their (Ed25519) public key. When you add
>     someone, you just paste their public key and type a "pet name" for them,
>     which is what would be shown in your contact list.
> 
> 
> Really close to what I had in mind, and I plan on using Ed25519. This is
> actually an approach that forces you to do more than take a fleeing
> glance at a given user's public key thumbprint/ID and I feel that's
> missing from many similar systems (e.g. OTR)

Yeah, to me verifying key fingerprints is a lost cause - people will
never do it. Instead we need the socialist millionaire protocol for
bootstrapping, and a web of trust. Or the very simple fact that you got
someone's public key via a MITM-proof channel in the first place, like a
QR code on a business card, NFC, etc.

>  
> 
>     People could also associate various metadata with their public key
>     in a very similar way
>     to how they do with PGP keys: with metadata packets signed by themselves
>     and other people, thus establishing a web of trust that would enable
>     search, the same way we can reliably search for PGP keys but with an
>     easier-to-use interface that will always show someone's relationship to
>     your current trusted contacts.
> 
> 
> My goal was to collect metadata about content transfers in the system by
> having all participants in file transfers sign a client-specific long
> chain which serves as a record of who has transferred what.
> 
> Through the course of normal system operation any given peer will
> collect a number of these long chains, which can be run through a
> collaborative filtering algorithm (e.g. singular value decomposition) in
> order to make an educated guess about the properties of peers you've
> never interacted with based on their collective similarity to peers you
> have interacted with directly.

Can you elaborate on this? By metadata I was thinking of things like
filename, content description, ratings, etc.

> 
>     Here are some possible implementation strategies. The only one I've made
>     any progress on so far is uTP:
> 
>     1. uTP with our own DHT implementation for bootstrapping, lookup, and
>     storage of published stuff
> 
> 
> My plan was to use CurveCP with the Ed25519 private scalar as the
> CurveCP private key. This allows you to set up secure channels which are
> based on the same identities as the other signatures in the system.

Given that the part that needs to be small is the public key, what's the
benefit of using the same private key? Once you have an Ed25519 public
key, you can always do an authenticated Diffie-Hellman exchange with an
ephemeral session key, which gives you perfect forward security if any
individual session private key is compromised.

> 
> CurveCP presently has some issues with embedding and congestion control
> but I hope if people actually start using it these problems will get
> resolved.

I ran across CurveCP before and had forgotten about it. Embedding and
congestion control are primary requirements for me, and libutp fits the
bill, even allowing the user to provide a callback for sending and
receiving data, which is where I'd apply the encryption.

> 
>     I guess you could call this a p2p, pseudonymous version of Facebook,
>     with all the same functionality and none of the privacy problems because
>     privacy would always be defined by encryption. If you want something
>     public, you post it in the clear. If you want something seen by only
>     your friends, you encrypt the encryption key with each of their
>     curve25519 keys.
> 
> 
> A crypto capability-based access control scheme comes to mind here.

The system you describe could certainly make a good platform for what I
describe, though I'm far more interested in the "applications"
themselves, i.e. chat, publishing, sharing, etc., than in the underlying
infrastructure. My primary concern about the underlying infrastructure
is that it be secure, easy to install/use, doesn't use a tremendous
amount of CPU or bandwidth (this should ideally run on mobile phones),
and connects reasonably quickly.

All of the applications could even be written in Javascript and
distributed through the network itself, signed by their authors. They
could run as web workers using a particular protocol to talk to the main
app if the network runs in a browser, or in QtScript if it's a native Qt
app. I have no idea how to securely run untrusted JS in Java, though.

I'd like to implement as little of this as possible, since it's a pretty
big undertaking and will require a number of iterations to get something
usable. That's why I am thinking of things like embedding I2P and
Freenet or Tor and Gnunet. I'd prefer C++ and Qt over Java, though
building for Windows will be a bit of a challenge, especially for Gnunet
with its huge number of not-very-crossplatform dependencies like
libgcrypt, among others. I'd love to have it able to build in VS, but
Tor won't either IIRC.





_______________________________________________
p2p-hackers mailing list
p2p-hackers at lists.zooko.com
http://lists.zooko.com/mailman/listinfo/p2p-hackers


----- 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





More information about the cypherpunks-legacy mailing list