[Cryptography] Cipher death notes (was: Re: Fwd: OPENSSL FREAK)

[Natanael]

Den 31 mar 2015 22:26 skrev "Michael Kjörling" <michael at kjorling.se>:

> What would entice said TLA to publish the break, rather than
> (attempting to) keep the ability to themselves and maybe a few of
> their closest allies? What would entice them to break the specific
> "negative cert authority" key (which gains them nothing except the
> ability to force the primitive in question out of use, depriving them
> of their ability to break the security of the system), rather than,
> say in the case of public key cryptography or cryptographic hashes,
> the root cert of Comodo or Verisign (which gains them potentially
> _very_ significant leverage) or the PGP key of a high-value target?

Out of scope, I presume. The purpose is entirely to prove the weakness in
case of publicly known breaks in algorithms.

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.

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.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150331/a9437292/attachment.html>