So yes, back to my original point. A Civic's blockchain, one that does not rely on the integrity (or rather is resilient to) the system it runs on, or the security of the transmission media ; as a platform for use in civic's - needs to exist first.
Block-chains are relatively new and we are still discovering properties and flaws in them, but I think if you view them as data-structure and as being useful for certain things, they potentially mitigate a lot of traditional security concerns. But we are a long way away from having them adopted as an everyday tool. I've been on the NZ government panel on on-line voting, and submitted a submission to the Canada electoral commission whilst living here. Unfortunately people view on-line voting and make the false comparison to banks "Well if some SSL secured website cluster, backed by some $sql database, in some $secure data centre is good enough for banks ..." falacy all the time. The problem is a bank is a centralised system, they have legal responsibilities and make calculated risk assessments and have insurance coverage. You have a one to one relationship with them and have choice (arguably) over choosing them or not. The trust relationship is between you and your bank, that's it. The bank is responsible for liability to third parties not you. Civics engagement by necessity needs to be verifiable, independent and distributed, not reliant on central systems where you trust some entity to negotiate on your behalf. It is a lot more nuanced that it appears at first glance. Would I design a voting station to run on OpenBSD ... sure... but I would also design it to work on /Linux, Windows or an Abacus. The paper comparison is a good one, block-chains provide a ledger verifiable by hand (yes with some hard math, but doable) but unlike paper can't be lost, or tampered with (the court is still out on exactly the best ways to implement this is...) and don't care how much they get graphetti'd on during passing around. You can also check your vote went to where you wanted it to go. Talking about traditional Databases, and Application system designs is simply the wrong mindset. On 15 November 2016 at 00:03, gwes <g...@oat.com> wrote: > On 11/14/2016 22:19, Alan Corey wrote: > >> OK, it's relevant to OpenBSD because I wouldn't consider anything else >> safe enough to run on the servers. Not that I'm in a position to do >> any of it. The servers could even be run from custom official live >> CDs so they were harder to tamper with, with maybe a RAM drive for >> speed. >> >> There seems to be a conflict between having anonymous votes and having >> something similar to paper ballots that can be recounted. So let >> authentication, identification, etc. be handled by one machine and >> stored in one database then the transaction is handed over to another >> machine which stores the votes. That could be something simple like a >> tab-delimited file which could be counted by hand, one line per voter. >> The file could be only writeable by the owner. The same person can't >> vote twice because the first machine wouldn't allow them in a second >> time. >> >> > How do you know if the voter is under duress or being watched? > > Paper can last two thousand years. It's pretty easy to make > paper that can't be duplicated in any useful quantity. > Functionally indelible ink, too. > > Using machines to assist voting is a good thing. > Physical objects are much more convincing and easier to secure. > > Oh yes -- the magic ghost Intel has put in every processor > for years. With a secret key -- security by obscurity. > Disk drives can be secretly reprogrammed. Network interfaces > have microcode, too. The memory system is also vulnerable > to secret tampering. All of these are back doors which are > or could be in place. > > Securing the system is far harder than securing a program > or group of programs. > > Geoff Steckel
