[Cryptography] Cipher death notes

ianG iang at iang.org
Wed Apr 1 07:22:05 EDT 2015

On 31/03/2015 21:11 pm, Michael Kjörling wrote:
> On 31 Mar 2015 10:47 -0700, from bear at sonic.net (Ray Dillinger):
>> Honestly, this was exactly the scenario I had in mind when I proposed
>> implementing "death notes" for ciphers.
>> It was a simple idea then, and is still simple.  A death note is
>> simply a proof that the encryption has been broken, (such as, in
>> this case, a cert issued by a known-bogus "negative cert authority"
>> whose keys were publicly destroyed immediately after creation).

I can see how to do it for a root key.  Just issue a new subroot and 
it's private key :) or use the root key to sign its own revocation, 
might be more polite.

How would you do a 'proof' for a symmetric cipher?  Simplistically, the 
cipher sponsor could encrypt "this is a secret" and anyone who can crack 
it could then reveal the cipher.

But many cracks happen under exotic conditions, such as 1 million 
ciphertexts probed on a key made with a broken RNG while standing on 
your head...

Creating a 'proof' with a symmetric cipher seems to imply turning it 
into an asymmetric signature cipher:  something hard to crack but easy 
to proof?  Or at least a one way function.

>> Everything that gets the death note (and has implemented the
>> feature, sigh) responds by permanently disabling that crypto
>> primitive (in this case erasing all certificates that use that
>> cipher), permanently storing the death note, and thereafter
>> passing on the death note to anyone who later tries to use
>> the dead crypto primitive.

Hmmm... ok.  So a death note is a pretty powerful virus.

We can imagine the WGs worrying about the security effects of that.  Can 
someone craft a virus that turns off *all* ciphers?  If the IoT thing is 
20 years old and switches the cooling water on a NY nuclear 
powerstation, is it clearly more secure by eliminating its 20 year old 
cipher?  Does the fallback to cleartext make the effect of the last 
cipher dropping off worse?  Is letting someone hack the cipher worse or 
better than disabling access?

> Maybe I'm missing the utter simplicity here, but there's something I
> don't quite understand. Hopefully you can enlighten me in the matter.
> Suppose that the feature you describe was widely implemented. Suppose
> also that the relevant primitive gets broken in a meaningful manner,
> _but_ that the ability to break said primitive has not yet spread to
> the masses. Maybe the break was limited to a fairly specific case, but
> still bad enough to warrant sunsetting the primitive in question on a
> rapid schedule (perhaps something like for example that we find an
> efficient way to factor one out of every ten thousand RSA moduli, for
> some given value of efficient, but there is no good test for such
> moduli). Maybe the break requires a large amount of computational
> resources, making it out of the reach of all but the very most
> resourceful adversaries. Maybe it requires a combination of multiple
> such factors before the break becomes feasible. Or whatever.
> The end result of the above is the same: we have reason to believe
> that YFTLA (Your Favorite Three-Letter Agency, for some given values
> of "Three" and "Letter") may have the capability to break said
> cryptographic primitive at least in select cases, but it remains well
> out of the reach of the general public, let alone any one individual.
> 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?
> Your proposal is certainly an interesting idea for academic exercises,
> where the whole idea would presumably be to publish and get wide
> dissemination of the result,

I agree it's an academic exercise.  But so was asymmetric cryptography 
when it was first proposed, until D&H and then RSA found their solution.

I see the "death note" as a perfectly good answer to the original 
question:  if you have decided to adopt multiple ciphers, you've also 
adopted the responsibility of retiring those.  How?  When?  What 
delivery mechanism?

If you have multiple ciphers, you *have to have an answer to retirement* 
else you've only done half the job - the fun and easy part, but also the 
less responsible part.

It's an *important* exercise.

> but how does it help with adversaries who
> keep the capability to themselves and/or secret/classified for the
> purposes of making good use of the break?

I don't think it does that.  Detecting the adversary is more the domain 
of certificate transparency, a trip wire that picks up a breach after 
the fact and makes the job of doing an MITM that much more uncertain.

I would see the "death note" more of a by-fiat administrative 
requirement, and more of a signed assertion than a proof of compromise. 
  Holistically, I'd expect the agency that accepted the cipher into the 
lists in the first place to be the one to issue the death note.  So we 
could imagine the WG for TLS deciding to vote on dropping DES, and once 
done, the Area Director would use the specially secured "death notice 
key" to sign the statement, and then just post it back to the WG, for 


More information about the cryptography mailing list