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 <vitteayme...@gmail.com > <mailto:vitteayme...@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
-- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
