Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[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