# The cr.yp.to microblog: 2022.08.29 03:09:53

2022.08.29 03:09:53 (1564057719434162176) from Daniel J. Bernstein, replying to "John Carlos Baez (@johncarlosbaez)" (1563543861607010305):

Your parenthetical sentence here is false. For example, there exists a proof of the minimal cost of an AES-128 attack, with standard formalizations of "cost"+"attack"+"proof". We don't know if there's a proof of length <2^L for any useful value of L; that's a different question.

### Context

2022.08.27 17:00:08 (1563541882696675331) from "John Carlos Baez (@johncarlosbaez)", replying to "John Carlos Baez (@johncarlosbaez)" (1563538925838163968):

But I think this sentence is still suboptimal. Most readers of Quanta don't know the definition of "unconditionally secure". And unconditional security is not even the goal of most practical cryptography - it's a higher standard. So why bring it up here?
(2/n)

2022.08.27 17:02:10 (1563542394116616192) from "John Carlos Baez (@johncarlosbaez)", replying to "John Carlos Baez (@johncarlosbaez)" (1563541882696675331):

The passage goes:
"Itâ€™s impossible to guarantee that a system is unconditionally secure. Instead, cryptographers rely on enough time passing and enough people trying to break the problem to feel confident."
(3/n)

2022.08.27 17:04:26 (1563542963044503555) from "John Carlos Baez (@johncarlosbaez)", replying to "John Carlos Baez (@johncarlosbaez)" (1563542394116616192):

There's an imaginable third alternative: we can imagine that cryptographers would prove that an encrypted text would take at least X amount of computational resources to decrypt. This seems more reasonable than demanding unconditional security, but...
(4/n)

2022.08.27 17:08:00 (1563543861607010305) from "John Carlos Baez (@johncarlosbaez)", replying to "John Carlos Baez (@johncarlosbaez)" (1563542963044503555):

... as far as I know, this is never done for widely-used systems, because nobody knows how to prove things like this. (They might be unprovable in principle, but nobody knows that either.) Anyway, I would change the passage in question to something like this:
(5/n)