<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br>I remember back when folk were doing all the work on cryptographic elections in the 1990s and the concern was to protect confidentiality. People really didn't get my assertion that what I was interested in was the ability to audit the election. </div></div></div></blockquote><div><br></div><div>I'm sorry about your experience but we're not talking about that right now nor was I involved in it in any way. We all agree that this particular application requires auditability. Your proposed technique does not provide bullet-proof auditability. Surely, you've followed the recent revelations about how agencies are hacking disk firmware even as we speak. Your proposed scheme fails in the presence of such an adversary.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>A TPM really does not help very much because it is a sealed box that the whole security of the system depends on and I can't audit it. I certainly can't expect to explain it to counsel. <br></div></div></div></div></blockquote><div><br></div><div>I don't know what you can and cannot explain to counsel, but many simple things that are easy to explain are also easily broken. Do you try to explain the operation of the CPU to counsel? Or other trusted hardware/software, like device firmware?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>It is really easy to throw the 'transitive trust' problem, the TPM is just as vulnerable. <br></div></div></div></div></blockquote><div><br></div><div>Sure, you're trusting the foundry and the silicon, but the TCB profile is vastly different: the attackers now have to have hacked a silicon foundry to launch an attack on you, instead of just hacking the machine where you prepared the raspbian OS. </div><div><br></div><div>Look, if you're happy with your approach in court, power to you. It's probably sufficient for whatever you're doing; I'd trust your gut call that it's the optimal tradeoff between being simple enough to explain and secure enough for your purpose (which you didn't quite describe, so you can't get upset if people assume a higher value case or a stronger attacker than what you have in mind). But you asked how the process could be improved, and I mentioned the state of the art. Feel free to ignore it as being "academic" -- you're probably right that it doesn't matter for low value cases, where there is no attacker or the attacker is severely limited. But when a high-value case comes along, you'll need stronger techniques, and adding TPM attestation on top of your process strictly improves what you're doing.  </div><div><br></div><div>- egs</div></div><br></div></div>