[liberationtech] How to make the Internet secure

Thu Feb 2 11:28:50 PST 2017

You probably want to look at this proposal by Moxie, he has already used
the name convergence and while that project is dead, the Certificate
Transparency standard is based on it.

https://en.wikipedia.org/wiki/Convergence_(SSL)

I am not looking at the transport layer right now. If a transport offering
traffic analysis resistance is available, my tools could permit
applications to make use of it without user intervention. I work at the
message layer and up.

For example, lets say that Alice has a Mesh Mail Profile that says

1 User matches {h1, h2...} : Encrypt under public key Y, send via TORmail
2 User = {Bob, Carol}  : Encrypt under public key Y, send SMTP
3 Any : Encrypt under public key X, send SMTP

Here, Alice is using separate mail for users she knows and users she does
not. This allows her to use end to end encrypted mail for all incoming mail
with the proviso that if she knows and trusts the person, the endpoint is
her inbox and otherwise it is her anti-malware service.

A select number of users can use TORmail which is a hypothetical onion
routing mail system that protects against traffic analysis. To prevent
metadata analysis, we want to conceal the identity of these people. To do
this we use a DH key agreement and a salted hash.

To send a message to Alice, Bob's client first calculates H(DH (Y,
B_Private), Salt) and sees if the value matches one of the specified hash
values. If it does, the message is sent over TOR_mail. If not, Bob's client
matches the second rule and sends the message encrypted using S/MIME and
SMTP.

The policy above can be enforced as a sending policy automatically. If
Alice's key is registered in the mail app, the message will be sent
securely with no additional effort required from Alice.

On Thu, Feb 2, 2017 at 2:05 PM, Aymeric Vitte <vitteaymeric at gmail.com>
wrote:

> Please find here: http://www.peersm.com/Convergence.pdf a proposal
> addressing all of what you are discussing here and even more (IOT,
> crypto money, etc), writen for some fundings opportunities but that did
> not make it so far for some administrative reasons + apparently some
> misunderstanding regarding what's in there since this is addressing
> quite a lot of different non trivial topics
>
> This is not difficult to guess to whom it was sent, I have  removed the
> formalism but some is still there, if someone reads it then I would be
> happy to realize that I did not write this for nothing, this does
> include some new concepts I believe
>
> There is a patent inside and I have removed what was related to it, I
> know people don't like patents here but when you try to explain some
> concepts to standard bodies, organization, lists, etc and nobody care,
> then my position is just to patent and wait quietly that one day
> inevitably something like this happens:
> https://www.w3.org/2016/01/web-component-pag-charter.html
>
> It's of course not exhaustive (gnunet is not mentioned for example), and
> I would rewrite some parts now (Ethereum could maybe better means
> Bitcoin sometimes, securing IOT concepts can probably be extended) there
> is a certain level of details but not all answers are available, this
> was supposed to be a collaborative study, which probably will not
> happen, not sending it to discuss it, open license (unlike node-Tor for
> which I am contacted quite often but no it's not open source until some
> slight budget is allocated, maybe I will put it in a bitcoin contract
> that will unlock under certain conditions so this gives the code a
> chance not to disappear forever)
>
> The "world" is trying to secure people with no budget or tools (financed
> or not) that are not usable by normal people and do not cover
> everything, of course this cannot work
>
> Le 02/02/2017 à 00:01, carlo von lynX a écrit :
> > 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.
> >
> >
>
> --
> Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
> Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist:
> http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20170202/3635c612/attachment.html>