On Thu, Feb 27, 2014 at 10:49 AM, Nikos Mavrogiannopoulos <nmav@xxxxxxxxxx> wrote: > On Thu, 2014-02-27 at 10:12 -0700, Andrew Lutomirski wrote: >> > == 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? > > Probably a lot, but I don't think we protect from someone doing rm -fr / > either :) > >> 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. > > AES-128 is broken too: > http://www.kuleuven.be/english/newsletter/newsflash/encryption_standard.html > > (in short it provides 126-bit security instead of 128). > > _However_, this and the attacks your describe on AES-256 don't matter > for practical purposes. Schneier explains in the blog you quote, but I > recap: > > 1. Related key attacks are nice for publishing papers, but they have > almost no practical relevance (AES or any other modern cipher isn't > designed to resist related key attacks). > 2. Attacking on reduced round variants of ciphers, doesn't matter either > except for academics and for getting the future trend of security of the > cipher. We use the full-round variants that resist the published > attacks. > 3. Breaking a cipher in the academic term means finding an attack that > is faster than brute force. The brute force level of AES-256 is terribly > high so "breaking" AES-256 in 2^245 steps is still very reassuring. So, in summary: - LEVEL-256 provides well under 256-bit security. - This is fine because no one actually needs 256-bit security. So *why on earth* would it make sense to implement this proposal? It sounds like we'd be offering options that (a) don't perform as advertised and (b) don't serve any purpose anyway. > >> access to those sites? What about disallowing use of CA certificates >> that use SHA-1? (Oops, there goes the Internet.) > > We have to document that, but there will be always ways to shoot > someones foot. There are legitimate uses of increasing a security level > (if one for example sets up machines to be used in a LAN). > >> If someone sets SUITEB-whatever, is Curve25519 acceptable? > > SuiteB only allows two curves. SECP256 and SECP384 if I remember well. I understand why people implement ridiculous FIPS modes: it's to comply with government rules. I don't see why Fedora should add to the mess. > >> How many people even know what an ENISA algorithm is? (I don't.) > > ENISA is not an algorithm. It is the "European Union Agency for Network > and Information Security" and they have some papers proposing various > security levels, similarly to NIST. https://www.enisa.europa.eu/ > >> 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. > > That's the idea. Then let's do that. --Andy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
