Using Cryptography the secure way

Published on 2017-05-11 11:58:59.

Recently Wikileaks, as part of its CIA materials dump, published a paper titled “Network Operations Division Cryptographic Requirements” [1]. This 17-page document described the cryptographic policies that shall be followed by developers of tools aimed to be used to advance CIA’s intelligence collection activists.

It is a well-based assumption that government security agencies have a greater insight at state-of-art undisclosed cryptanalysis techniques which makes this paper interesting in order to gain a deeper insight at what government surveillance recommends as a secure policy for cryptographic usage. This article outlines a few highlights that are interesting particularly due to its divergence from public cryptographic standards such as the ECRYPT [2].

AES key size

The majority of the public standards consider a key size of 128 bit for AES as sufficiently secure for any application unless there is need for quantum resistance in which case a key size of 256 bits is recommended [3]. However, the CIA requests a 256 bits key size for all symmetric key operations, including HMAC.


It doesn’t come as a surprise that SHA-1 is forbidden by the CIA which was recently proven practically flawed [4]. It is also surprising that HMAC is also forbidden, despite common knowledge that HMAC is considered to be secure despite the hash function lacking collusion resistant capabilities [5]. There can be two possible explanations for this:

  1. The tag length for HMAC-SHA-1 is fixed to 160 bits (20 bytes), which might be considered too short.
  2. It makes it easier for auditing/compliance checks to ban all the SHA-1 instances.

Repeating nonces and IV’s

In applied cryptography, it is well known that parameters such as the nonces and IV’s are never to be constant or repeated values. The paper makes references to this, which albeit expected, is interesting to note as such references are not commonly found in the key-length recommendation documents.

Public-Key Cryptography Standards (PKCS) #1 v1.5

The padding scheme described in the PKCS#1 v1.5 is known to be vulnerable to attacks since 1998 [6] but it is interesting to continue finding it in new proposals. One explanation might be that due to legacy issues there are still devices that uses PKCS#1 v1.5, making it necessary to highlight this vulnerability.

Compulsory HMAC

Unauthenticated encryption is completely banned, and tool developers are required to use HMAC or a signature mode rather than the symmetric-key MAC. A very good recommendation that needs to be followed is to preserve the integrity of the encrypted data.

Conclusion: Is your cryptographic policy secure?

The paper finally recommends many other recommendations that CIA expected to be followed by its developers. In this article, we made a summary of some recommendations mentioned within the paper.

Is your company using strong cryptographic algorithms to be secure in long run? Contact to test your organization for security compliance best practices.