A recent wikileaks dump of CIA material included a file called “Network Operations Division Cryptographic Requirements“. Assuming it’s genuine, this 17-page PDF describes crypto policy that must be followed by developers of “tools used to advance the CIA’s intelligence collection activities”.
Since a government security agency has insight into the state of the art in non-public cryptanalysis, it’s interesting to see what government spies recommend as a secure policy for crypto usage. Here I’ve picked out a few of the highlights that were interesting to me, in particular in the ways they’re different from other public crypto standards like PCI or ECRYPT.
AES with 256 bit key
Most public standards treat 128 bits as sufficient for any application unless it’s intended to resist brute force attacks by quantum computers at some point in the future (in which case 256 bits should be fine). However the CIA mandates 256 bits for all symmetric key operations (including HMAC) from 2012 onwards.
No SHA-1, not even HMAC-SHA-1
It’s not surprising that SHA-1 is forbidden (the first public full SHA-1 collision was disclosed recently), but a bit more surprising that it’s forbidden for HMAC since HMAC is still secure even if the hash function is not collision resistant. Two possible explanations: 1) it makes the crypto audit easier just to forbid SHA-1 completely – this is the explanation suggested in the document 2) the tag length for HMAC-SHA1, at 160 bits, is considered too short.
No repeating nonces, or IVs
Repeated or fixed values for parameters that are supposed to be unique or pseudorandom is a recurrent problem across practical cryptography. It’s not surprising to see it mentioned in a practical guide like this, whereas it doesn’t appear in pure algorithm/key-length recommendation documents.
No PKCS#1v1.5 Padding in RSA Encryption
PKCS#1v1.5 has been known to be vulnerable to attack since at least 1998, but it still turns up in new proposals. Interesting to see it completely forbidden by the CIA.
Mandatory HMAC authentication of ciphertexts and IVs
Unauthenticated encryption is disallowed, and tool writers are asked to use HMAC or a signature mode rather than a symmetric-key MAC, presumably because there’s less chance of screwing up.
Requirements on key-management are pretty vague, apart from requiring that the cryptographic design document submitted for approval “must discuss key management” and “may reference their key management plan”. Given the variety of deployment scenarios for these snooping tools, that’s perhaps not surprising.
Is my crypto CIA-ready?
Cryptosense Analyzer tests the security of an application’s use of crypto. As you might expect, we cover the CIA recommendations and more. Here’s an example of the output from our reports, where you can see the Analyzer detecting short key-lengths, repeated IVs, encryption PKCS#1v1.5 padding, encryption that’s missing an HMAC and key-management weaknesses. To see the demo report in more detail, sign up for free at testmycrypto.com.