6 ms·

> The integrity of your centralized program cannot. Open source it. And not in the traditional sense, either. I mean setup the server to expose source code. Ha

by maratd 14y ago

> The integrity of your centralized program cannot. Open source it. And not in the traditional sense, either. I mean setup the server to expose source code. Have a 3rd party verify security and integrity. This is actually much easier to do than in the traditional process.

mindslight 14y ago
> I mean setup the server to expose source code Please explain how you envision this being implemented. (Warning: while 'remote attestation' is a valid answer for some assertions, it means that we are once again back to trusting the central signing authority. which might seem less scary, but we'd really be having the same argument at a much more technical and nitpicky level)
- maratd 14y ago
  > Please explain how you envision this being implemented. Make the directory containing source code read-accessible using your web server? There is nothing you can truly implement that can guarantee that the code being executed is the same as the code being exposed, but you can hire a 3rd party to audit the server and verify as much.
  - mindslight 14y ago
    So to paraphrase, your answer is "give up, forget about the property that every voter can audit the system, and fall back to relying on a trusted third party to certify the opaque process" ? But yet you call it an "obvious direction" ? And we haven't even talked about coercion resistance.. Hurricane madness indeed. Please read up on actual electronic voting systems, what properties are expected of them, and what properties the state of the art ones can actually provide.
0x0 14y ago
Wouldn't help if they hid a backdoor in the compiled code, and the compiler, etc. "Reflections on trusting trust" and all that.
- unimpressive 14y ago
  Ken's compiler trojan is not invulnerable, and could here be defeated by checksums and versioning. http://www.schneier.com/blog/archives/2006/01/countering_trus.html http://www.schneier.com/blog/archives/2006/01/countering_tru...
  - dllthomas 14y ago
    Diverse double compiling is not "checksums and versioning". You need other compilers from sufficiently different sources as to minimize the chance that they all were subject to the same modification. Edited to add: Which is to say, it's actually a pretty cool idea, and not super complicated[1], and amazing it took 20ish years to spot. [1] Though do be careful; I'm amazed at the number of comments that misunderstand it.
    - unimpressive 14y ago
      >Diverse double compiling is not "checksums and versioning". You need other compilers from sufficiently different sources as to minimize the chance that they all were subject to the same modification. I was assuming you would write your own. Of course, if you keep going along this line of thinking, you end up wire wrapping your own computer and writing your OS and other utilities in assembly.
      - dllthomas 14y ago
        > I was assuming you would write your own. That only works if you do it in machine code (and your hex-editor is clean). The point of the whole thing is that you can use compilers from untrusted sources, just provided you use several of them, and trust that at least one of the compilers you are checking won't have the same modifications as the others.
        unimpressive 14y ago
        > That only works if you do it in machine code (and your hex-editor is clean). Not necessarily. It would be very hard to get a ken trojan to propagate if you were to write your compiler in a high-level language such as python and then use a C compiler to Compile the Java runtime which you would use to run a C compiler to compile say go, then use the go-based c compiler to compile the python source, which you would then use to compile gcc. Gcc would then compile itself, resulting in an almost certainly clean gcc. If the gcc were compiled by the go compiler, presumably that gcc would be functionally equivalent to any other gcc binary of the same version. If it's functionally equivalent then when you compile the clean gcc with your go compiled gcc, it should be binary equivalent to any other gcc binary compiled with the same compiler, flags, and version. EDIT: Now that I think about it, you wouldn't need to write your own compiler at all at that point, making your earlier point correct. But I meant something else when I was talking about checksums and versioning. You then compare the checksum of your final result with the one on the server, if they don't match theres probably a problem. Another approach would be to use assembly to implement a higher level language such as scheme, and then use that to write a C compiler. Also, I would pay $50 to see a hex editor or assembler that can detect that it is writing a C compiler in all possible cases and bug the users final program. Of course, none of that matters if your hardware has a backdoor in it. So everything enumerated here depends on the assumption that your hardware is trustworthy.

by maratd 14y ago

mindslight 14y ago

> I mean setup the server to expose source code Please explain how you envision this being implemented. (Warning: while 'remote attestation' is a valid answer for some assertions, it means that we are once again back to trusting the central signing authority. which might seem less scary, but we'd really be having the same argument at a much more technical and nitpicky level)

maratd 14y ago
> Please explain how you envision this being implemented. Make the directory containing source code read-accessible using your web server? There is nothing you can truly implement that can guarantee that the code being executed is the same as the code being exposed, but you can hire a 3rd party to audit the server and verify as much.
- mindslight 14y ago
  So to paraphrase, your answer is "give up, forget about the property that every voter can audit the system, and fall back to relying on a trusted third party to certify the opaque process" ? But yet you call it an "obvious direction" ? And we haven't even talked about coercion resistance.. Hurricane madness indeed. Please read up on actual electronic voting systems, what properties are expected of them, and what properties the state of the art ones can actually provide.

0x0 14y ago

Wouldn't help if they hid a backdoor in the compiled code, and the compiler, etc. "Reflections on trusting trust" and all that.

unimpressive 14y ago
Ken's compiler trojan is not invulnerable, and could here be defeated by checksums and versioning. http://www.schneier.com/blog/archives/2006/01/countering_trus.html http://www.schneier.com/blog/archives/2006/01/countering_tru...
- dllthomas 14y ago
  Diverse double compiling is not "checksums and versioning". You need other compilers from sufficiently different sources as to minimize the chance that they all were subject to the same modification. Edited to add: Which is to say, it's actually a pretty cool idea, and not super complicated[1], and amazing it took 20ish years to spot. [1] Though do be careful; I'm amazed at the number of comments that misunderstand it.
  - unimpressive 14y ago
    >Diverse double compiling is not "checksums and versioning". You need other compilers from sufficiently different sources as to minimize the chance that they all were subject to the same modification. I was assuming you would write your own. Of course, if you keep going along this line of thinking, you end up wire wrapping your own computer and writing your OS and other utilities in assembly.
    - dllthomas 14y ago
      > I was assuming you would write your own. That only works if you do it in machine code (and your hex-editor is clean). The point of the whole thing is that you can use compilers from untrusted sources, just provided you use several of them, and trust that at least one of the compilers you are checking won't have the same modifications as the others.
      - unimpressive 14y ago
        > That only works if you do it in machine code (and your hex-editor is clean). Not necessarily. It would be very hard to get a ken trojan to propagate if you were to write your compiler in a high-level language such as python and then use a C compiler to Compile the Java runtime which you would use to run a C compiler to compile say go, then use the go-based c compiler to compile the python source, which you would then use to compile gcc. Gcc would then compile itself, resulting in an almost certainly clean gcc. If the gcc were compiled by the go compiler, presumably that gcc would be functionally equivalent to any other gcc binary of the same version. If it's functionally equivalent then when you compile the clean gcc with your go compiled gcc, it should be binary equivalent to any other gcc binary compiled with the same compiler, flags, and version. EDIT: Now that I think about it, you wouldn't need to write your own compiler at all at that point, making your earlier point correct. But I meant something else when I was talking about checksums and versioning. You then compare the checksum of your final result with the one on the server, if they don't match theres probably a problem. Another approach would be to use assembly to implement a higher level language such as scheme, and then use that to write a C compiler. Also, I would pay $50 to see a hex editor or assembler that can detect that it is writing a C compiler in all possible cases and bug the users final program. Of course, none of that matters if your hardware has a backdoor in it. So everything enumerated here depends on the assumption that your hardware is trustworthy.