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\u2026 and that\u2019s 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\u2019s KeySize<\/code> values and DSA\u2019s KeySize<\/code> values shouldn\u2019t 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 \u201ccurve\u201d.
\nSo, OK, everyone agrees that the \u201ckey size\u201d of an ECC key is \u201cthe number of bits required to represent p<\/code>\u201c.
\n.NET at the time only supported 3 curves: NIST P-256, NIST P-384, and NIST P-521.
\nThe number after \u201cP-\u201d is \u201chow many bits are required to represent p<\/code>\u201c,
\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\u2019s brainpool384r1<\/code> and NIST\u2019s P-384 both report 384<\/code> from the getter, but what should the setter do?
\nThe best answer we came up with was \u201cthe setter still picks from the 3 options it had before, and we need a new way to inspect or specify the curve.\u201d<\/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\u2019re adding more new algorithms.
\nGiven an ML-DSA-65 key, what should we report as the KeySize<\/code> value?
\n\u201c65\u201d is an obvious answer, but it\u2019s sort of meaningless (that name just means that this \u201cparameter set\u201d makes use of a 6\u00d75 matrix).
\nThe \u201craw\u201d 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 \u201cbreak up\u201d with AsymmetricAlgorithm<\/code>.<\/p>\n\u2026 Anything Else?<\/h2>\n
Many moons ago I saw a poster that said something like \u201cChange is terrible\u2026 unless it\u2019s great!\u201d.
\nBased on where it was, I think the target audience was UX designers and the poster was saying
\n\u201cusers hate it when you move buttons around, so if you\u2019re going to move it, you better have a great reason\u201d.
\nRegardless of the intended audience, the message has resonated with me all these years,
\nand so I knew that we needed something other than \u201cAsymmetricAlgorithm, but without the KeySize property.\u201d
\nSo, we took a look at what things we like about AsymmetricAlgorithm<\/code>, and what parts we don\u2019t.<\/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\u2019t 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\u2019t 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\u2019t always mean \u201cthe object is unusable\u201d, often it meant \u201cI\u2019ve abandoned this key, but I can generate another one!\u201d<\/li>\n- You can\u2019t really use it as-is. If you accept one you need to cast it to an algorithm type.<\/li>\n
KeySize<\/code> doesn\u2019t 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\u2019re 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\u2019s a consistent way to import\/export keys.<\/li>\n<\/ul>\n
Clearly, once we started making the \u201cbreakup\u201d list, it was pretty obvious.<\/p>\n
Sorry, AsymmetricAlgorithm<\/code>, it\u2019s not you, it\u2019s me (P.S.: it\u2019s totally you).<\/p>\n
![\"\u2705\"](\"https:\/\/s.w.org\/images\/core\/emoji\/16.0.1\/72x72\/2705.png\")
All of the instance methods are about \u201cthe key\/keypair\u201d, none are about \u201cthe algorithm\u201d.\n