[liberationtech] How to make the Internet secure
Aymeric Vitte
vitteaymeric at gmail.com
Thu Feb 2 13:53:53 PST 2017
The name is a coincidence and the former project has a very little to do
with what I sent, there is an entityID concept in the proposal instead
of a CA one, since the later obviously can't work with entities that
can't have a valid certificate, entityIDs could be combined with let's
encrypt
Le 02/02/2017 à 20:28, Phillip Hallam-Baker a écrit :
> 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)
> <https://en.wikipedia.org/wiki/Convergence_%28SSL%29>
>
>
> 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
> <mailto:vitteaymeric at gmail.com>> wrote:
>
> Please find here: http://www.peersm.com/Convergence.pdf
> <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
> <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
> <https://github.com/Ayms/zcash-wallets>
> Bitcoin wallets made simple:
> https://github.com/Ayms/bitcoin-wallets
> <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://github.com/Ayms/torrent-live%0Anode-Tor> :
> https://www.github.com/Ayms/node-Tor
> <https://www.github.com/Ayms/node-Tor>
> GitHub : https://www.github.com/Ayms
>
>
--
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/7615447f/attachment.html>
More information about the liberationtech
mailing list