The proper and accurate implementation and usage of cryptography are extremely critical to its efficiency. A small mistake in configuration or coding will result in removing a large degree of the protection it affords, rendering the crypto implementation useless against serious attacks.
The purpose of this document is to define rules for the use of encryption controls, as well as rules for the use of cryptographic keys, in order to protect the confidentiality, integrity, authenticity, and non-repudiation of information.
This document applies to the entire Information Security Management System (ISMS) scope, and to all personal data processing activities.
If users are in doubt as to the definitions or methods contained in this document, they must contact the InfoSec team or send an e-mail to infosec@resolver.com before implementing or utilizing algorithms, crypto-libraries, or crypto-functions.
The users of this document are IT, Development, DevOps, and QE team members.
Cryptography is the practice of constructing and analyzing protocols that prevent third parties or the public from reading private messages. Cryptography prior to the modern age was effectively synonymous with encryption, the conversion of information from a readable state to apparent nonsense. This involves the transformation of plain data into encoded data by applying encryption, and the decoding of encoded data by decryption.
Cryptography relies on two basic components: a cryptographic algorithm and a cryptographic key.
A cryptographic algorithm is a mathematical function used for encryption and decryption of data. The fundamental set of cryptographic algorithms can be divided into three groups:
In symmetric algorithms, the same key is used for message encryption and decryption.
In asymmetric cryptography different keys (a public key and its corresponding private key) must be used for encryption and decryption. The encrypting key is called the public key and the decrypting key is the private key. If you hold the private key, I can send you a message that only you can read.
These keys also work in the opposite direction. That is, anything you encrypt with your private key, I can decrypt with your public key. You can use this to digitally sign a document (Digital Signature).
Encrypt a message with your private key, and I’ll be able to verify your signature by decrypting with your public key. I have confidence that the message came from you because only someone who holds your private key could have produced a working signature.
Asymmetric cryptography is synonymous with public key infrastructure (PKI).
There are three asymmetric algorithms in use today:
Diffie-Hellman is not quite suitable for establishing identity (Digital Signature) as described above, but the other two algorithms are. RSA is the most commonly used today, but the Elliptic Curve does appear to be on its way to becoming the next standard.
The encryption key is a random string of bits, used in conjunction with a cryptographic algorithm to encrypt and decrypt (scrambling and unscrambling) data. The key acts as a lock to the encryption process. Knowledge of the appropriate key is required to encrypt or decrypt the data. Keys used in asymmetric cryptography are normally referred to as ‘private’ and ‘public’ keys, whilst those used in symmetric cryptography are referred to as ‘secret’ keys or ‘shared secrets’.
Encryption keys are designed with algorithms intended to ensure that every key is unpredictable and unique.
A public key and a private key are mathematically related; whatever is encrypted with a Public Key may only be decrypted by its corresponding Private Key and vice versa.
The key length describes the amount of data required for the cryptographic key. In the case of cryptographic keys for computer-based algorithms, this is normally expressed as a number of bits. Some algorithms require a fixed key length, while others accept variable key lengths. Typically, the larger the key the more difficult a well-written algorithm becomes to break. It is important to note that it is not normally possible to directly compare the comparative strength of different algorithms based on key length alone.
As highlighted above, crypto relies on keys to ensure an object’s identity, provide confidentiality and integrity, as well as non-repudiation. It is vital that the keys are adequately protected. Should a key be compromised, it can no longer be trusted.
Any system that has been compromised in any way should have all its cryptographic keys replaced.
Hash functions take some data of an arbitrary length (and possibly a key or password) and generate a fixed-length hash based on this input. Hash functions used in cryptography are such that it is easy to calculate the hash but difficult or impossible to re-generate the original input if only the hash value is known.
In addition, hash functions useful for cryptography have the property that it is difficult to craft an initial input such that the hash will match a specific desired value.
SHA-256 is a common hashing algorithm used today.
Password hashing functions are hashing algorithms designed explicitly for the verification of password credentials. Typically, you do not want to use a fast hashing algorithm such as SHA-256 for this purpose, as it enables a rainbow table or brute force style attacks. There are specialized algorithms such as bCrypt or sCrypt which serve this purpose well – they are complex and CPU intensive to utilize, and they typically have a separate salt for every hash, making rainbow table style attacks impossible.
Password hashing functions also utilize a strategy known as key stretching to increase the cost complexity of the hash over time – which enables these algorithms to scale as computing power increases, without having to swap implementations.
For bCrypt, it is important to use key stretching, and you should use a minimum of 10 salt rounds to ensure the hash is secure.
This standard specifies the requirements for the use of cryptography and all information technology systems used or developed in Resolvers.
Do not implement a cryptographic algorithm on your own.
Industry-proven implementations of algorithms (i.e. cryptographic toolkits that have been established over time), using mature and trusted crypto libraries and security providers (e.g.: OpenSSL, JSSE, Bouncy Castle, Schannel,) must be employed.
In the following sections, cryptographic algorithms are listed in order of preference. It is
required that where multiple algorithms are supported the preferred algorithm be selected. These are the minimum baseline algorithms that should be used.
A stronger version of these approved algorithms is perfectly acceptable (e.g., AES-256-bit versus 128-bit). The use of any algorithm not listed below will require approval.
The following block ciphers (symmetric algorithms) are approved for use:
The following cryptographic checksums/hashing algorithms are approved for use:
The following asymmetric protocols for digital signature are approved:
The following key exchange algorithms are approved for use within Resolver:
Symmetric encryption mode of operation:
Message Authentication Codes (MAC):
Data at rest:
Data in transit:
Web application front end should be configured to use ONLY:
Digital signature algorithm:
| Algorithm name | Comments |
| SHA256RSA | |
| SHA256ECDSA | Recommended for mobile application usage, since more efficient. |
Key size:
| Algorithm name | Public Key size | Comments |
| RSA | 2048 | Recommended |
| RSA | 4096 | Optional |
| ECC | 256 | Recommended |
| ECC | 384 | Optional |
Hash Algorithm:
| Algorithm name | Recommendations for use |
| SHA256 | Recommended |
| SHA384 | Optional |
| SHA512 | Optional |
If Server-side implementation using Tokenization mechanism in combination with Token Signing/Verification like JWT:
The Token should be signed using the following algorithms:
| Algorithm name | Recommendations for use |
| HS256 | Recommended for testing environment. |
| RS256 | Recommended+, Standard for distributed, microservice architecture with one Token issuer and multiple validation points. |
| ES256 | Recommended+, since more efficient. |
InfoSec team is responsible for these rules and activities regarding key management:
Keys are managed by their owners in line with the abovementioned rules.
Cryptographic keys should be protected against loss, change, or destruction in the best secure way that available in the system where this key is deployed.
In the case of loss, corruption, or destruction, keys will be revoked and the new one will be issued and deployed instead of revoked.
This document is valid as of July 2020.
The owner of this document is an Information Security Analyst who must check and, if necessary, update the document at least once a year.
When evaluating the effectiveness and adequacy of this document, the following criteria need to be considered:
EFFECTIVE ON: September 2020
REVIEW CYCLE: Annual at least and as needed
REVIEW, APPROVAL & CHANGE HISTORY: Last time reviewed and approved in August 2020 by Resolver’s Information Technology Security team.