1# ISA-L Security Policy 2 3## Report a Vulnerability 4 5Please report security issues or vulnerabilities to the [Intel Security Center]. 6 7For more information on how Intel works to resolve security issues, see 8[Vulnerability Handling Guidelines]. 9 10[Intel Security Center]:https://www.intel.com/security 11[Vulnerability Handling Guidelines]:https://www.intel.com/content/www/us/en/security-center/vulnerability-handling-guidelines.html 12 13## Security Considerations & Options for Increased Security 14 15### Security Considerations 16The security of a system that uses cryptography depends on the strength of 17the cryptographic algorithms as well as the strength of the keys. 18Cryptographic key strength is dependent on several factors, with some of the 19most important factors including the length of the key, the entropy of the key 20bits, and maintaining the secrecy of the key. 21 22The selection of an appropriate algorithm and mode of operation critically 23affects the security of a system. Appropriate selection criteria is beyond the 24scope of this document and should be determined based upon usage, appropriate 25standards and consultation with a cryptographic expert. This library includes some 26algorithms, which are considered cryptographically weak and are included only 27for legacy and interoperability reasons. See the "Recommendations" section for 28more details. 29 30Secure creation of key material is not a part of this library. This library 31assumes that cryptographic keys have been created using approved methods with 32an appropriate and secure entropy source. Users of this library are 33referred to NIST SP800-133 Revision 1, Recommendation for Cryptographic Key 34Generation, found at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133r1.pdf 35 36Even with the use of strong cryptographic algorithms and robustly generated 37keys, software implementations of cryptographic algorithms may be attacked 38at the implementation through cache-timing attacks, buffer-over-reads, and 39other software vulnerabilities. Counter-measures against these types of 40attacks are possible but require additional processing cycles. Whether a 41particular system should provide such counter-measures depends on the threats 42to that system, and cannot be determined by a general library such as this 43one. In order to provide the most flexible implementation, this library allows 44certain counter-measures to be enabled or disabled at compile time. These 45options are listed below as the "Options for Increased Security" and are 46enabled through various build flags. 47 48### Options for Increased Security 49 50There are two build options that are used to increase safety in 51the code and help protect external functions from incorrect input data. 52The SAFE_DATA and SAFE_PARAM options are enabled by default. 53Due to the potential performance impact associated to the extra code, these 54can be disabled by setting the parameter equal to "n" (e.g. make -f Makefile.unx SAFE_PARAM=n). 55 56No specific code has been added, and no specific validation or security 57tests have been performed to help protect against or check for side-channel 58attacks. 59 60### SAFE_DATA 61 62Stack and registers containing sensitive information, such as keys, are 63cleared upon completion of a function call. 64 65### SAFE_PARAM 66 67Input parameters are checked, looking generally for NULL pointers or an incorrect input length. 68 69### Galois Counter Mode (GCM) TAG Size 70 71The library GCM implementation provides flexibility as to tag size selection. 72As explained in [NIST Special Publication 800-38D](https://csrc.nist.gov/publications/detail/sp/800-38d/final) section 5.2.1.2 and Appendix C, using tag sizes shorter than 96 bits can be insecure. 73Please refer to the aforementioned sections to understand the details, trade offs and mitigations of using shorter tag sizes. 74