Why Can't I Change the KeySize of Asymmetric Algoritms or: The Joys of Backwards Compatibility

re: Why Can't I Change the KeySize of Asymmetric Algoritms or: The Joys of Backwards Compatibility

Eric Newton — Sat, 09 Oct 2004 20:01:00 GMT

Shawn: A good portion of apps have an AppCompatibility SHIM to work in Windows XP, for various reasons. (Mostly I believe because of GDI changes and so forth).

The usage of Side-by-Side and targetting specific framework versions should be eliminating this "problem" or "compatibility bar" as you call it... Microsoft should see this as a way to minimize regression testing old apps on new code.

Think about COM... we had a problem when an app installed a newer version of a component because the apps were FORCED to use the new version, because only one version could be used, especially in binary compatibility modes [a vb term].

SxS and .Net have virtually eliminated this problem.

The only problem now is ASP.Net as a hosting platform, because if you want to use asp.net 2.0, but only want to use framework 1.1, its not possible, and in THAT sense, we should do some regression testing and acknowledge the fact that OLD APPS have a high probability of not properly running on the NEW FRAMEWORK... [caps only for emphasis]

re: Why Can't I Change the KeySize of Asymmetric Algoritms or: The Joys of Backwards Compatibility

Shawn — Fri, 01 Oct 2004 00:06:00 GMT

So we've taken everything into consideration. The LegalKeySize idea that Nicholas presented is a good and very creative one, however in many ways that would be more breaking than fixing the original bug. (Think of someone who news up a RSACryptoServiceProvider, then uses LegalKeySizes to see what size keys are available on that machine).

The FxCop rule is a very good idea, and most likely the route that we'll end up taking on this. Great suggestion AT.

-Shawn

re: Why Can't I Change the KeySize of Asymmetric Algoritms or: The Joys of Backwards Compatibility

Fred — Wed, 29 Sep 2004 16:40:00 GMT

I completely agree with Luc Cluitmans.

When you say lotus 1-2-3 is still running on... Yes. But this is different. There is no security issue to make lotus running.

If not so, why fixing any bug? Some older applications may use this bug as a fact and beeing manufactored to take it into account.

This is a normal process to correct an application even if I understand that a framework is a special kind of application.

re: Why Can't I Change the KeySize of Asymmetric Algoritms or: The Joys of Backwards Compatibility

Luc Cluitmans — Wed, 29 Sep 2004 07:39:00 GMT

This whole issue is interesting. I don't want to sound challenging, but it could be phrased as 'microsoft treats backward compatibility as more important than security', which is probably not the best message you can send out to the world.

I think that at least some mechanism should be added that will cause alarm bells to go off, preferably at compile time, when this setter is called. Or, alternatively, add some mechanism that will cause the setter to throw an exception (NotSupportedException, for instance) if a certain administrative action has taken place (for instance by setting a flag in the application configuration file, or event the system configuration files). This will give people the warm feeling that, in the case some software triggers this feature they will get informed about it, instead of not being made aware that the wrong key size is being used.

Frankly, I think this is a case where MS has to swallow the bitter pill, and security has to be prioritized over backward compatibility. Add those exceptions, or remove the setter, even if it will break existing software.

Btw, I disagree with AT. Yes, adding an FxCop rule is a good idea, but not everyone will run FxCop, and this is something that everyone needs to be aware of, so it cannot be the only solution.

re: Why Can't I Change the KeySize of Asymmetric Algoritms or: The Joys of Backwards Compatibility

AT — Wed, 29 Sep 2004 04:07:00 GMT

The only correct proposal: Create a FxCop rule for this !!

re: Why Can't I Change the KeySize of Asymmetric Algoritms or: The Joys of Backwards Compatibility

Nicholas Allen — Wed, 29 Sep 2004 02:35:00 GMT

You're entirely right about the origin of the setter. That's a shame because obsoleting gives good feedback to the user about what has changed.

Here's proposal #2 then:

The specification for the setter of KeySize says that a CryptographicException may be thrown if the key size is invalid. It goes on to say that the valid sizes are defined by the LegalKeySizes property. The specification for LegalKeySizes makes no guarantees that I can see about what those legal sizes are.

Why can't the LegalKeySizes for a particular instance of RSACryptoServiceProvider contain only the key size provided at creation time? Then there's no problem that the setter doesn't work. Either the property is being set to its current value, no work needed, or it's being set to an illegal value. This seems to maintain strict CLI compatibility.

The

Ensoft Mind Dump — Wed, 29 Sep 2004 00:20:00 GMT

The

Ensoft Mind Dump — Wed, 29 Sep 2004 00:20:00 GMT

re: Why Can't I Change the KeySize of Asymmetric Algoritms or: The Joys of Backwards Compatibility

Shawn — Tue, 28 Sep 2004 23:43:00 GMT

Good comments ... let me address them one at a time.

Nicholas: Obsoleting the setter sounds like a good idea, until you start digging down into the crux of the problem. If you ILDasm mscorlib.dll and look at the RSACryptoServiceProvider class, you'll notice something interesting. This class only provides a getter for the KeySize property, not a setter. The setter is actually defined in the base AsymmetricAlgorithm class. That's the underlying cause of the bug, the derived class overrode only one portion of the property.

We could technically go ahead and add a setter to the derived classes, and then mark them as Obsolete, however we could never actually remove the setter since it's derived in the base class, and that would break any number of people who have derived from it. This would also cause incompatibilities between our interfaces and other projects who have implemented the CLI. Declaring a method as obsolete without ever intending to remove it is not a good solution.

Eric: While its true that people should be running tests on new verisons of the framework, its a fact of life that not everyone will. That's part of the reason that Microsoft keeps its compatibility bar so high. There's a reason that you can still run Win95 code on Windows XP and that the PDC version of Longhorn still runs Lotus 1-2-3!

Tony: We do have regular security pushes. Generally these are scheduled for after code complete on a project, since after the security push is done we don't like to modify the code base and introduce potential new vulnerabilities. As part of the security push, we generate threat matrixes, and rank every potential vulnerability. This one doesn't rank as high as some other potential threats simply because the user is still getting encryption -- just not encryption as strong as they wanted. Also, if they were to ever check the KeySize property again, they would notice that the value did not change, so we're not completely lying to them.

All that being said, thanks a lot for the feedback. Its obvious that you guys think this is a bigger issue than we first imagined it to be. Because of this we'll continue to look at our options for this before we ship Whidbey. Hopefully my above comments help to explain why the fix isn't as clear cut as it first may seem.

Thanks for the feeback!
-Shawn

re: Why Can't I Change the KeySize of Asymmetric Algoritms or: The Joys of Backwards Compatibility

Tony Chow — Tue, 28 Sep 2004 22:03:00 GMT

I've heard that Microsoft developers have regular "security drives". Does this top ever come up at one of these meetings? From your tone, I don't get the impression that you've taken a very hard look at the security aspect of the problem. Rather it appears that you are seeing this merely as a matter of elegance.

This kind of mentality obviously isn't helping Microsoft's security initiative.