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

Tony Arcieri tony.arcieri at gmail.com
Fri Jan 11 10:43:07 PST 2013


On Fri, Jan 11, 2013 at 10:08 AM, Sean Lynch <seanl at literati.org> wrote:

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

It's all equally important, although I intend to identify nodes or peers
rather than people (who may operate many nodes).

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

I was thinking of a log of how much data was transferred and the transfer
rate. The type of metadata you're describing is kept secret in my 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.
>

The point of doing this is so both ends can authenticate the other party as
the same party who signed data they're interested in. CurveCP still uses DH
to generate an ephemeral session key.

I was to CodesInChaos earlier on about this approach on the CurveCP and he
said he looked into it before and thought it seemed sound.

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.


Yeah, uTP is definitely nice in that it has the congestion part licked
(perhaps too well). It would be neat to try to take the CurveCP encryption
protocol design and sort of layer it on top of uTP.


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

Yeah, this is definitely something else I am extremely interested in. I
have been looking at a friend's capabilities-based JavaScript wrapper
around <iframe sandbox> which seemed like it'd be an interesting way to
sandbox web applications being loaded from a system like the Cryptosphere.
They could talk back to a parent iframe via postMessages and request
various services from the system. See:

https://github.com/tildeio/oasis.js

-- 
Tony Arcieri

_______________________________________________
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