#1 Enhanced the Cryptography section
Closed 6 years ago by mjahoda. Opened 7 years ago by nmav.
nmav/defensive-coding-guide crypto-update  into  master

file modified
+43 -8
@@ -12,35 +12,52 @@ 

      </para>

      <itemizedlist>

        <listitem><para>RSA with 2048 bit keys and OAEP</para></listitem>

-       <listitem><para>AES-128 in CBC mode</para></listitem>

+       <listitem><para>AES-256 in CBC mode</para></listitem>

        <listitem><para>SHA-256</para></listitem>

+       <listitem><para>SHA3-256</para></listitem>

        <listitem><para>HMAC-SHA-256</para></listitem>

        <listitem><para>HMAC-SHA-1</para></listitem>

      </itemizedlist>

      <para>

+       The following encryption primitives are safe to use when combined

+       with a method that guarrantees unique nonces (e.g., a counter or

+       ECB encryption with a 64-bit cipher).

+     </para>

+     <itemizedlist>

+       <listitem><para>AES-256 in GCM mode</para></listitem>

+       <listitem><para>CHACHA20-POLY1305</para></listitem>

+     </itemizedlist>

+     <para>

        Other cryptographic algorithms can be used if they are required

        for interoperability with existing software:

      </para>

      <itemizedlist>

        <listitem><para>RSA with key sizes larger than 1024

          and legacy padding</para></listitem>

-       <listitem><para>AES-192</para></listitem>

-       <listitem><para>AES-256</para></listitem>

-       <listitem><para>3DES (triple DES, with two or three 56 bit keys)</para></listitem>

-       <listitem><para>RC4 (but very, very strongly discouraged)</para></listitem>

+       <listitem><para>AES under CCM mode</para></listitem>

+       <listitem><para>3DES (triple DES, with three 56 bit keys) for short data transmission</para></listitem>

        <listitem><para>SHA-1</para></listitem>

        <listitem><para>HMAC-MD5</para></listitem>

      </itemizedlist>

      <important>

        <title>Important</title>

        <para>

- 	These primitives are difficult to use in a secure way.  Custom

+ 	Cryptographic primitives are difficult to use in a secure way.  Custom

  	implementation of security protocols should be avoided.  For

  	protecting confidentiality and integrity of network

- 	transmissions, TLS should be used (<xref

- 	linkend="chap-Defensive_Coding-TLS"/>).

+ 	transmissions, TLS should be used (<xref linkend="chap-Defensive_Coding-TLS"/>).

        </para>

      </important>

+     <para>

+         For crypto primitives, we recommend to use one of the following cryptographic libraries.

+     </para>

+     <itemizedlist>

+       <listitem><para><ulink url="https://wiki.openssl.org/index.php/Libcrypto_API">OpenSSL's libcrypto</ulink></para></listitem>

+       <listitem><para>GNUTLS' provided primitives (<ulink url="http://www.gnutls.org/manual/gnutls.html#Using-GnuTLS-as-a-cryptographic-library">restricted to TLS-related crypto</ulink>)</para></listitem>

+       <listitem><para><ulink url="https://www.lysator.liu.se/~nisse/nettle/nettle.html">nettle crypto library</ulink></para></listitem>

+       <listitem><para><ulink url="https://gnupg.org/documentation/manuals/gcrypt/">GnuPG's crypto library (libgcrypt)</ulink></para></listitem>

+       <listitem><para>NSS' provided primitives via the PKCS#11 API</para></listitem>

+     </itemizedlist>

  <!-- TODO: More algorithms are available in the NIST documents

       linked from: http://wiki.brq.redhat.com/SecurityTechnologies/FIPS -->

    </section>
@@ -75,6 +92,9 @@ 

  	<para><function>os.urandom</function> in Python</para>

        </listitem>

        <listitem>

+ 	<para>The <function>getrandom</function> system call</para>

+       </listitem>

+       <listitem>

  	<para>Reading from the <filename>/dev/urandom</filename>

  	  character device</para>

        </listitem>
@@ -98,6 +118,21 @@ 

  	using these functions.

        </para>

      </important>

+     <important>

+       <title>Difficult to use API</title>

+       <para>

+ 	The <function>getrandom</function> system call has three-state

+ 	return values, hence requires careful error checking.

+       </para>

+       <para>

+ 	It was introduced in Linux kernel 3.17, but as of glibc 2.22 no API wrappers are

+ 	provided. As such one can only use it via the syscall interface

+ 	as <function>syscall(SYS_getrandom, (void*)dest, (size_t)size, (unsigned int)0)</function>.

+ 	For portable code targetting older kernel versions one has to check 

+ 	for the function being	available on run-time, and switch to another

+ 	facility if the running kernel doesn't support this call.

+       </para>

+     </important>

      <para>

        Other sources of randomness should be considered predictable.

      </para>

This documents the libraries available in Fedora (and RHEL), and adds text on getrandom().

There are some concerns about GCM modeā€”it is difficult ti implement in software (so it generally favors attackers), and nonce reuse is an issue.

Do we really want to recommend it over CBC mode?

I think you are right, It CBC is far safer to mis-use than anything else we have so far. I've added however both chacha20 and gcm to a special category, of safe to use if...

I've also recommended AES-256 instead of 128 due to possible future post-quantum threats.

rebased

7 years ago

You completely dropped AES-128, which doesn't seem right. It's unclear whether AES-128 or AES-256 is stronger, but better (still theoretical) attacks on AES-256 have not materialized in the meantime, so maybe we can move AES-256 up a notch.

I dropped AES-128 because it is considered insecure under quantum computers.
"Grover's algorithm could brute-force a 128-bit symmetric cryptographic key in roughly 2^64 iterations"
https://en.wikipedia.org/wiki/Grover%27s_algorithm

I can bring it back, but I think it makes sense to keep that list future proof.

Pull-Request has been closed by mjahoda

6 years ago
Metadata