[liberationtech] How to make the Internet secure

[carlo von lynX]

Hello Phillip, nice reading your feedback.

On Wed, Feb 01, 2017 at 03:21:52PM -0500, Phillip Hallam-Baker wrote:
> ​I believe that mail, chat, voice, video, blog comments and mailing lists
> are all separate messaging modalities that need to be addressed in any
> replacement scheme. However, there is no reason why it should not be
> possible ​to support all of these modalities in a single message format.

Exactly. That's what we are working on.

> ​Facebook is not just a messaging infrastructure. It is also an
> infrastructure that allows social networks to be defined, published and
> applied. The main objection I have to FB is that it is walled garden.

secushare is a distributed multicast system without central nodes,
it intends to recreate a featureset like FB, Skype, Whatsapp
fully under control of the participants - no walled garden.

> Establishing a uniform identifier that has unambiguous meaning across
> domains is the key to breaking up walled gardens.

The complex operation is how to do next-gen routing from Alice
to Bob when all you know is Bob's public key address. Most
solutions route across a distributed hashtable, then optimize
such route if in-between nodes are optional. Netheads (the new
bellheads) would say, but you are still using IP - but the
meshheads say no, we are running an overlay over IP but our
architecture works also without, for instance with ad-hoc wifi.
So, akin to the historic bellheads vs netheads dispute,
this is the age of netheads vs meshheads.

> ​The reason for not using public keys is security. I want identifiers to be
> stable for long lengths of time, potentially a lifetime. It should be
> possible to rotate public keys on a weekly basis without cost to the user.

Excuse me, but you seem to be conflating PGP's need for key rotation
in order to achieve a poor man's forward secrecy with the use of public
keys for identification. Modern crypto systems would not architect it
this way. Our architecture is more like this:

    master key per identity (kept offline, on a sheet of paper)
	--> device key (in case a device of yours gets stolen)
	    --> ongoing ratchets (axolotl-style forward secrecy)

There are also peer keys. Looking up a person's device key provides
you with a route to a rendez-vous peer. That peer may be the person's
current computer, but it might aswell be the end-point of an onion
circuit. This way, looking up a person doesn't necessarily expose
that person's actual peer, and the peer keys can change as frequently
as desired. Thus, there is no need to rotate the device key itself.
Also, within the conversation there is no need to rotate the key,
because the ratchet is advanced automatically while you speak. The 
master key is needed only to be able to revoke a device key that 
may have gotten lost or stolen, that's why it can be kept on paper,
on external storage or be split over multiple parties.

Any identifier, which is not itself a public key, needs a way to
be mapped to a public key - and that is always an attack vector,
so I'm skeptical about that approach.

> UDF fingerprints can be taken of any data object. They are used in the Mesh
> to provide a unique identifier for the signature key of a master profile
> that represents a user's personal root of trust.​ The intention is to
> permit these to be offline keys that do not need to be used very often and
> may well be secured by multi-party key splitting.

Alright, so the intention is similar and the extra look-up
mechanism uses fingerprints instead of the public keys
themselves.

> ​The point of using fingerprints is to provide a baseline which needs no
> further validation or external trust sources that can be referenced by the
> infrastructures that build on top of it. Use of nicknames, etc is a very
> good idea. But just as the Internet protocols are ultimately built on IP as
> the basic unit of interchange for packets, there needs to be a basic unit
> for trust.
> ​

Yup.

> ​No.​ I am using a completely different approach using a form of
> cryptography developed by Matt Blaze in the 1990s that allows end to end
> encryption when using traditional client-server architectures.

gnunet has different protocols for different purposes. End-to-end
encrypted tunnels with axolotl-style forward secrecy are handled
by the CADET protocol. So you should be able to do what you are
setting out to do with prismproof.

Excuse me adding a musing in that regard however: Traditional 
client-server architectures introduce de-anonymization vulne-
rabilities by design, also they enable a digital equivalence of 
rich vs poor inequality, when scalability is a feature that only 
the rich, the owners of clouds and content delivery networks can 
achieve. Distributed architectures can offload the weight of 
scalability to all the participants who want to consume a certain 
information item - this way cutting out the cloud business model 
on scalability, which the users pay for by allowing being tracked.
That's why secushare has added a distributed multicast pubsub 
protocol on top of CADET - essentially an interest-driven cloud 
infrastructure without owner and thus without monetization. Other
projects such as Tribler and IPFS are exploring similar 
approaches. Bittorrent is also correlated.


-- 
  E-mail is public! Talk to me in private using encryption:
         http://loupsycedyglgamf.onion/LynX/
          irc://loupsycedyglgamf.onion:67/lynX
         https://psyced.org:34443/LynX/