namespace System.Security.Cryptography;\n\npublic partial class AsymmetricAlgorithm : IDisposable { }\npublic partial class RSA : AsymmetricAlgorithm\n{\n public static RSA Create();\n}\npublic partial class DSA : AsymmetricAlgorithm\n{\n public static DSA Create();\n}\npublic partial class RSACng : RSA { }\npublic partial class RSAOpenSsl : RSA { }\n\/\/ etc<\/code><\/pre>\nIt Starts To Go Wrong<\/h2>\n
When we started the PQC project, the obvious answer was that we should continue to extend AsymmetricAlgorithm<\/code>,\nbut there was sort of a hint that was a bad answer… and that’s the KeySize<\/code> property on AsymmetricAlgorithm<\/code>:<\/p>\npublic partial class AsymmetricAlgorithm\n{\n public virtual int KeySize { get; set; }\n}<\/code><\/pre>\nThis property was introduced when .NET only supported RSA and DSA, and it mostly made sense:\nwhen creating an RSA key or a DSA key, pretty much the only parameter is the RSA modulus (n) size or the DSA prime modulus (p) size.\nRSA’s KeySize<\/code> values and DSA’s KeySize<\/code> values shouldn’t be compared across the algorithms, but they are a property of any given key.<\/p>\nThen we introduced EC-DSA and EC-DiffieHellman.\nECC keys have a simple integer value as a private key, a number in the range [1, p)<\/code>, where p<\/code> is the prime modulus for the “curve”.\nSo, OK, everyone agrees that the “key size” of an ECC key is “the number of bits required to represent p<\/code>“.\n.NET at the time only supported 3 curves: NIST P-256, NIST P-384, and NIST P-521.\nThe number after “P-” is “how many bits are required to represent p<\/code>“,\nso now we have a sensible answer for this property:\nthe getter reports the number of bits required to represent p<\/code>,\nand the setter chooses from NIST P-256, NIST P-384, and NIST P-521.<\/p>\nThen Windows added support for more elliptic curves, so .NET added support for more elliptic curves.\nBrainpool’s brainpool384r1<\/code> and NIST’s P-384 both report 384<\/code> from the getter, but what should the setter do?\nThe best answer we came up with was “the setter still picks from the 3 options it had before, and we need a new way to inspect or specify the curve.”<\/p>\nThat was basically like hearing a creak of wood on a calm day while standing next to a dam.<\/p>\n
So now we’re adding more new algorithms.\nGiven an ML-DSA-65 key, what should we report as the KeySize<\/code> value?\n“65” is an obvious answer, but it’s sort of meaningless (that name just means that this “parameter set” makes use of a 6×5 matrix).\nThe “raw” public key for ML-DSA-65 is 1952 bytes, so maybe 1952?\nWell, this is cryptography, so it should be in bits: 15616?<\/p>\nThis was the start of a journey where we decided to “break up” with AsymmetricAlgorithm<\/code>.<\/p>\n… Anything Else?<\/h2>\n
Many moons ago I saw a poster that said something like “Change is terrible… unless it’s great!”.\nBased on where it was, I think the target audience was UX designers and the poster was saying\n“users hate it when you move buttons around, so if you’re going to move it, you better have a great reason”.\nRegardless of the intended audience, the message has resonated with me all these years,\nand so I knew that we needed something other than “AsymmetricAlgorithm, but without the KeySize property.”\nSo, we took a look at what things we like about AsymmetricAlgorithm<\/code>, and what parts we don’t.<\/p>\nThe bad parts:<\/p>\n
\n- Heavy use of
public virtual<\/code> means that we have to repeat state and argument validation in every derived type.\n\n- And sometimes we didn’t repeat it correctly.<\/li>\n<\/ul>\n<\/li>\n
- You have to create an instance to ask about its capabilities (e.g.
public virtual LegalKeySizes[] { get; }<\/code>)<\/li>\nCreate()<\/code> doesn’t generate a key, in case you do import. As a result, key generation happens when the key is first needed, making for some perf surprises.<\/li>\nDispose()<\/code> doesn’t always mean “the object is unusable”, often it meant “I’ve abandoned this key, but I can generate another one!”<\/li>\n- You can’t really use it as-is. If you accept one you need to cast it to an algorithm type.<\/li>\n
KeySize<\/code> doesn’t seem to make sense for these new algorithms.<\/li>\nKeyExchangeAlgorithm<\/code>, SignatureAlgorithm<\/code>, ToXmlString(bool)<\/code>, FromXmlString(string)<\/code> are intrusions from SignedXml<\/code> and EncryptedXml<\/code>, they’re at the wrong layer.<\/li>\nExportParameters(bool)<\/code> makes it hard to write a consistent flow analyzer for when you have private key data or public key data.<\/li>\n<\/ul>\nThe good parts:<\/p>\n
\n- There’s a consistent way to import\/export keys.<\/li>\n<\/ul>\n
Clearly, once we started making the “breakup” list, it was pretty obvious.<\/p>\n
Sorry, AsymmetricAlgorithm<\/code>, it’s not you, it’s me (P.S.: it’s totally you).<\/p>\n