<p dir="ltr">Den 31 mar 2015 22:26 skrev "Michael Kjörling" <<a href="mailto:michael@kjorling.se">michael@kjorling.se</a>>:</p>
<p dir="ltr">> What would entice said TLA to publish the break, rather than<br>
> (attempting to) keep the ability to themselves and maybe a few of<br>
> their closest allies? What would entice them to break the specific<br>
> "negative cert authority" key (which gains them nothing except the<br>
> ability to force the primitive in question out of use, depriving them<br>
> of their ability to break the security of the system), rather than,<br>
> say in the case of public key cryptography or cryptographic hashes,<br>
> the root cert of Comodo or Verisign (which gains them potentially<br>
> _very_ significant leverage) or the PGP key of a high-value target?</p>
<p dir="ltr">Out of scope, I presume. The purpose is entirely to prove the weakness in case of publicly known breaks in algorithms.</p>
<p dir="ltr">Define a number of tests designed to be catch-all (as far as possible) tests for broad classes of weaknesses that could negatively affect security of software implementing the algorithm.</p>
<p dir="ltr">Once weaknesses are found, attempt to create inputs for the algorithm that triggers these tests. Distribute these inputs as proofs of weakness that various devices and services can fetch from security alert subscription services. </p>
<p dir="ltr">This is explicitly not preemptive against potential not yet proven weaknesses - you wouldn't be able to create the necessary proofs of weakness. This is quick-response trust-minimized (proof carrying) reactive alerts, to attempt to quickly limit exposure *globally* to potential attacks. To eliminate the ability to break into further systems for anybody already using it. </p>
<p dir="ltr">IIRC these security alert subscription services should have several types and degrees of alerts. You could have both proof carrying assertions and proof-less assertions, descriptions of what use cases are broken and which aren't (MD5 still works for HMAC and plain integrity checks, but is useless for 3rd party signatures and anything else where birthday search collisions and pregenerated pairs with same hash breaks security). Also preferably with signatures from the organizations that is making the assertions.</p>
<p dir="ltr">This way it is far easier to define revocation policy - multiple trusted entities simultaneously saying cipher X is broken for my usecase Y probably means it should halt until manually reviewed. Proof carrying alerts that shows that a security assumption that is critical for my service is now broken in practice probably means my service shouldn't just halt, but also put up red flags and warn all users. </p>