[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [kmip] KMIP: RNG Proposals
> > >NIST SP 800-90 Dual EC DRBG. > There are some people who use this algorithm. As such, I don't think > removing it outright is the correct thing to do. Fair enough. There is a reasonable argument that says that even the "undesirable" algorithms should have a place, just so the client knows exactly what they're in for. > > DES.... Well... maybe we ought to remove (or at least deprecate) > > those, too. Why include anything that is known insecure? Shouldn't > we, as a > > group, feel qualified to make a value judgment here? Or at least > follow NIST guidance? > > Deprecating the use of algorithms seems like a good idea, but where do > we draw the line? Should we do this based on security strength? A first pass would be to just copy NIST's 800-131a document, which is your deprecated list. > For example we could say: > > Deprecated: Less than or equal to 80 bits of security strength: DES, > RC2, MD2, MD4, MD5, Dual EC DRBG, FIPS 186 PRNG and RSA for key sizes > less than or equal to 1024, EC with P160 curve. And by this you mean that the algorithms would still be selectable, but noted in the standard as being deprecated, I assume? > Deprecated for use in new applications: Between 80 and 112 bits of > security strength: 3DES, SHA 224, RSA 2048, EC with P224 curve. Hmmm. I would be on board with this in theory, but putting RSA 2048 on that list basically requires a transition to EC to go higher given the performance of RSA 4096. A good thing, but rather bold. It might be considered overreach. John Leiseboer wrote: > Indeed, where do we draw the line? One client's secure algorithm is > another client's insecure algorithm. Make recommendations. Provide > guidance. Do not introduce weaknesses, and vulnerabilities into the > standard. Build ease of use into the standard; i.e. be secure by > default, and force clients to explicitly change the default, or > standard way of doing things, in order to be insecure. I agree with this. But...for the sake of argument let's take an extreme case - DES. Crackable in under 24 hours at cloudcracker (MS-CHAPv2) for something like $17. Should we allow clients to impale themselves upon it? Thinking back on this, (and contradicting my previous paragraph) I realize that I'm coming at this argument from a user interface point of view, where simplicity and removing everything that's not needed are good things. But perhaps this isn't the way to go for a standard such as KMIP, where we've got to support a wide variety of behaviors amongst clients / servers. This means we have to leave everything in, but we can at least provide guidance... -Mike
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]