[liberationtech] How to make the Internet secure

Thu Feb 2 11:05:10 PST 2017

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