On Sat, Oct 11, 2014 at 5:45 AM, Joachim Schipper <[email protected]> wrote: > <moved to misc@; it's still not on-topic, but this message may be > somewhat interesting>
Moved back to tech for just this message: I am going to implement this inBSD, so I would still appreciate pointers and helpful tech advice, but please don't CC the list, just mail me privately. To prevent a flame war, please don't refute anything on the list without giving carefully considered, clear reasons why I and everyone else should agree with you, otherwise I will be obliged to respond to the list because I won't leave a falsehood uncontested on a public forum. >> The application is electronic democracy. I want to demonstrate how it >> is possible to do secure comms. over untrusted networks and hardware. > > But it *isn't* possible to do secure comms from/to compromised hardware; > that is what "compromised" means. That's why I used the term "untrusted": to make a distinction between the unknown status of security of the underlying media and "compromised" meaning definite knowledge that the hardware affects a compromise of privacy/integrity. > Note that the thesis above merely aims at cryptographic port knocking; a > global adversary can still just read the unencrypted traffic No, the "pre-shared keys" are communicated over the VPN, as are the keys which encrypt the VPN's own data as it appears in the actual TCP packets which carry the tunnel through which the VPN operates. This is not a common idea: that such a thing a thing is possible, so people should not be too quick to dismiss it solely on account of never having heard of the idea before. Dismiss it only when you have convinced yourself that it definitely won't work. Because otherwise you are rejecting something very valuable: perfectly secure communications. > Also, note that securely pre-sharing keys is a pain even in a small > group of friends; The purpose of the VPN is to provide this mechanism and make it automatic, that point should be fairly clear in my description. > there is no way you can scale that to "every human in > the world". No, and that is certainly not the plan. The verification of the voting is as I explain in that document: it is that each voter certifies the votes of three others, and because people know this, they know that their own vote is only represented if the others certified theirs. So the knowledge doesn't exist in any one person's mind, it only exists in the combined minds of all the people. And the same principle applies to the knowledge of the VPN keys: that knowledge will be shared between four independent orthogonal VPNs and that information will simply not exist, so could never be compromised. Please don't be too quick to dismiss this. The idea is not an obvious one, but people who can think about systems are typically better at grasping this sort of thing that people who who work with systems of formal proof which work by symbolic substitution. This is not something you can make obvious by symbolic substitution because it is based on human knowledge, not concrete representation in some language: that knowledge is the knowledge that "these really are three other independent VPNs that are providing the information I need to encrypt my traffic when it sending to this other machine.. >> I hope to be able do this by carrying out a global referendum. See >> >> http://livelogic.blogspot.com/2014/10/the-foundation-parts-iii-iii.html > > A very quick read shows that you want to do, roughly, electronic voting. > A number of proposals exists to achieve secure (or verifiable) > electronic voting; I believe you should be able to find fairly > accessible introductions to the cryptographic scheme proposed by Ron > Rivest (of RSA fame). > > No proposal that I'm aware of even contemplates using compromised > hardware, though, and all proposals assume a functioning census. Well, now you _are_ aware of at least one: which is this one :-) And I am not the only one who believes that this is possible. Roger Schell (cc'ed), who was very influential in the development of the NSA's TCSEC wrote in https://www.acsac.org/invited-essay/essays/2001-schell.pdf: "The science of computer and network information security has for some time given us the ability to purchase an information system from a mortal enemy and then assess its ability to enforce a well defined security policy, gaining sufficient assurance to confidently use the system to protect against massive loss and grave damage, and this has been actually been put into practice. This astonishing capability is known as “verified protection”." >> My plan is to use a virtual interface which magically shows behind the >> physical interface when connections are made with the right ISN key in >> the SYN packet. If the ISN is not one of the 'knocks' then the >> connection sees the ordinary physical interface. >> >> Then I want to make a connection between applications and the TCP >> stack so that the knocks can be determined only by data from within >> the VPN. Then the knocks will vary non-deterministically. To bootstrap >> into the VPN a machine will need a direct trusted connection to >> another machine which is already in the VPN, and which can send it the >> initial knock key sequence which will allow it to handshake into the >> VPN, and thereafter have a connection. >> >> The VPN will be tunneled over TCP and/or IP datagram connections. >> Within the VPN the routing and representation of data within real TCP >> network packets will also vary non-deterministically according to data >> passed over the VPN. >> >> The VPN will be used for trusted core protocols for authentication, >> key-exchange and verification. So it need not carry such high volumes >> of traffic The bulk of data will be carried over the exposed network. >> >> If anyone here has a better idea, or any other useful advice (even if >> it's "this has already been done!" or "It won't work," but please >> explain exactly why.) or pointers: I am new to this game: I have never >> seriously looked at network protocol driver code in OpenBSD or any >> other OS. > > This is way too large; start with something *much* smaller. Very smart > people have been working on the kind of things you're thinking about for > decades; you're not going to solve this in a weekend, or in just a > hundred lifetimes. Well, maybe I'm also very smart. And I have been working full-time on it for half a decade. And maybe OpenBSD is about to become the only open source OS that is verifiably secure. > Some things that you may find interesting: > [ ... lots of stuff trimmed ...] Thanks for that. Here's some contrary advice from Ed. Dijkstra: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD01xx/EWD196.html "(1) Select a project as advanced as you can conceive, as ambitious as you can justify, in the hope that routine work will be kept to a minimum; hold out against all pres- sure to incorporate such system expansions that would only result into a purely quantitative increase of the total amount of work to be done." Let's just do it. Best wishes Ian
