Re: [CFRG] NSA vs. hybrid

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

On 12/3/21, 10:50, "CFRG on behalf of D. J. Bernstein" <[e-mail] on behalf of [e-mail]> wrote:
>   > I'm asking why the current Classic algorithms have not been paired
>   > using the same approach
>
>   There is, of course, a long history of examples of double (and triple)
>   encryption, perhaps the most amusing in context being the following:
>
>       https://www.nsa.gov/Portals/75/documents/resources/everyone/csfc/threat-prevention.pdf
>
>   Under _that_ program, NSA insists on having two independent encryption
>   layers "to mitigate the ability of an adversary to exploit a single
>   cryptographic implementation to compromise both layers".

Indeed, an interesting and amusing find - and if I'm correct, fairly recent...?

However, the context does not seem right: this document is trying to contain a potentially compromised or malicious encryptor by funneling its output through a different (and hopefully non-colluding) one.

The concern seems to be not the algorithms, but implementations that might choose to, e.g., leak key bits, etc. The document you cited does NOT seem to require different ALGORITHMS - merely different _independent_ IMPLEMENTATIONS, presumably of the same ubiquitous AES.

That's an argument against Hybrid, not for it.


>   Meanwhile, under another program (the one that triggered this thread),
>   NSA asks everyone to deploy lattice systems and make sure to _turn
>   off ECC_, because, um, hmmm.

I did not see "make sure to turn off ECC" - I saw "ECC won't be _required_", which is a different thing.
Also, (I confess I did not read very carefully - slides on Twitter are less than convenient - but it seems to me the NSA said "we like Lattice systems". You like McEliece - fine, use that, and it's one of the reliable finalists, anyway. 

My use case (that I won't bring here because I don't want to bore you with details, and because I don't need "public" to validate it, thanks) does not allow public keys of McEliece size, unfortunately. 
But that's irrelevant to this topic - whether it's really beneficial to combine multiple algorithms. I said it isn't, because of negligible gains, and associated costs.


>   NSA's official story for this consists of
>   pointing at random implementation flaws and concluding that deploying
>   two layers will make things "less secure":
>
>      https://twitter.com/mjos_crypto/status/1433443198534361101/photo/1

A nice presentation - wish I could attend and participate in Q&A.

Is there a more convenient copy around?

But back to the topic: "two layers" means double the amount of code to evaluate, double the risk of somebody screwing up, etc. 
If you don't trust _any_ of the algorithms available, you might resort to combining two or more of them, in hope that at least one might not fail you. If, on the other hand, you rely on your analysis, and decided that an algorithm X is fine, in real life I see no evidence of deliberate "multiple layers" (I explained above why I don't consider the (interesting) example you brought up as one).
Unless you count deployment when Ethernet is secured by MacSec, on top of it people run IPsec between sites and routers, and applications running over that VPN employ TLS... Yes, I've seen plenty of that kind - but nowhere did I see, e.g., IPsec combining more than one symmetric or asymmetric algorithm, or TLS (until this Hybrid shtuff), or MacSec...