[Cryptography] Crypto best practices

[John Denker]

On 03/10/2017 01:42 PM, Jerry Leichter wrote:

>> Another interesting recommendation: "Tools should perform key
>> exchange exactly once per connection. Many algorithms have
>> weaknesses during key exchange and the volume of data expected
>> during a given connection does not meet the threshold where a
>> re-key is required.xiii To reiterate, re-keying is not
>> recommended.” Footnote xiii adds "The exact nature of which
>> algorithms are weak at this stage is highly classified....
> The only thing this brings immediately to mind is related key
> attacks.  Though if your re-keying mechanism allows related-key
> attacks you have other problems.
> 
> Anyone have any insight into just what they're referring to?  It
> could be extremely significant, given that forward security relies on
> very frequent re-keying.

The insight department is out of the office at the moment, but
here are a few comments from the keen-grasp-of-the-obvious
department:

1) The quote "re-keying is not recommended" must not be taken
 out of context.  It applies in a very special case where the
 session is so short that rekeying is not worth the trouble.
 There will be a new key for the next session, and that provides
 sufficient forward secrecy in this special case.

2) AES has related-key weaknesses that you could drive a truck
 through ... but we knew that already.  BS claims that this is
 not a weakness in AES, because only an idiot would choose a
 related key.  However, I disagree.  There are plenty of real-world
 situations where you might want related keys, e.g. random-access
 disk encryption, real-time interaction, etc.  So either hash
 your keys before letting AES get its mitts on them (which means
 the allegedly fast AES key scheduling is not so fast), or go
 straight to ChaCha20.

3) I find cipher chaining modes to be creepy as a matter of
 principle.  You would really rather have a new key per block.
 However, many ciphers are weak and/or slow when it comes to
 changing keys.  The idea of changing the IV is a kludgey
 workaround for this problem.  It fails in lots of situations,
 including random access, real-time interaction, et cetera.

4) The quoted passage is only one of several hints that they
 have something that exploits weaknesses in AES.  I'll bet
 the CIA and NSA are really steamed about this leak, because
 now every OS and every app is going to upgrade to AES-256
 and hash all their keys.

5) One of the big problems with tapping and bugging is always
 backhaul, i.e. getting the harvest back to headquarters.  I
 assume when the CIA snatches data from somebody's phone they
 make it look like something innocuous, perhaps a TLS or Signal
 connection.  Otherwise it would be too easy to detect.  Also
 the fact that they are defending against against weaknesses
 in common protocols (not just exploiting them) lends support
 to this idea.

6) The question is not whether they have a related key attack;
 we can take that as a given and move on.  The more interesting
 question is whether they have something else /also/.  Some
 sort of protocol failure during key exchange, in some widely
 used protocol(s).

==========================

It is remarkable that they consider such weaknesses to be super-
highly classified.  As it says in reference [1], quoting none
other than Frank Rowlett, 

      "in the long run it is more important to secure one's own 
       communications than to exploit those of the enemy."

Alas the NSA and CIA seem to get this wrong again and again
and again.

[1] Thomas R. Johnson
    "American Cryptology during the Cold War; 1945-1989"
     Center For Cryptologic History / National Security Agency (1998)

That document used to be available on the NSA web site:
     http://www.nsa.gov/public_info/_files/cryptologic_histories/cold_war_iii.pdf
but they took it down.  Have they never heard of the WayBack Machine?
     http://web.archive.org/web/20160313120238/https://www.nsa.gov/public_info/_files/cryptologic_histories/cold_war_iii.pdf