F21 System Wide Change: System-wide crypto policy

Andrew Lutomirski luto at mit.edu
Thu Feb 27 17:12:49 UTC 2014


On Thu, Feb 27, 2014 at 9:22 AM, Jaroslav Reznik <jreznik at redhat.com> wrote:
> = Proposed System Wide Change: System-wide crypto policy =
> https://fedoraproject.org/wiki/Changes/CryptoPolicy
>
> Change owner(s): Nikos Mavrogiannopoulos <nmav at redhat.com>
>
> Unify the crypto policies used by different applications and libraries. That is
> allow setting a consistent security level for crypto on all applications in a
> Fedora system.
>
> == Detailed Description ==
> The idea is to have some predefined security levels such as LEVEL-80,
> LEVEL-128, LEVEL-256,
> or ENISA-LEGACY, ENISA-FUTURE, SUITEB-128, SUITEB-256. These will be the
> security levels
> that the administrator of the system will be able to configure by modifying
> /usr/lib/crypto-profiles/config
> /etc/crypto-profiles/config

How much of the system will break if the administrator does something
silly like setting LEVEL-256?

For reference, there isn't a well-established, widely accepted
symmetric cipher with 256-bit security.  AES-256 is weak [1] and
should probably not be used at all, let alone by anyone who wants a
256-bit security level.  3-DES is slow and doesn't offer 256-bit
security. Salsa20 and ChaCha20 are probably okay for 256-bit security,
but they aren't widely supported yet.

This means that sensible websites (and browsers!) don't enable the
AES-256 cipher suites.  Should a system set to LEVEL-256 disallow
access to those sites?  What about disallowing use of CA certificates
that use SHA-1?  (Oops, there goes the Internet.)

If someone sets SUITEB-whatever, is Curve25519 acceptable?

How many people even know what an ENISA algorithm is?  (I don't.)

I would maybe support a division into "probably already broken by
people with deep pockets" (e.g. DES, RC4, MD5, maybe SHA-1 in some use
cases), "probably safe against classical computers for a long time"
(everything at 128 bits or higher, RSA with, say, 3072 bits and up,
maybe RSA2048, and Suite B, depending on your philosophical views),
and "probably safe against quantum computers for a long time"
(Probably Salsa20, ChaCha20, and a handful of public-key cryptosystems
that are either patent-encumbered, insecure, impractical, or more than
one of the above.)

Alternatively, a systemwide setting like "avoid modp groups below X
bits" could make sense.  Far too many things 1024-bit modp groups.
This includes *SSH* until very recently.  Having a single switch to
turn that cr*p off would be very useful, although it might imply a lot
of patches.

[1] https://www.schneier.com/blog/archives/2009/07/another_new_aes.html

--Andy


More information about the devel mailing list