A customer wanted to write their own custom implementation of an existing standard encryption algorithm. The customer liaison noted that this custom implementation would presumably produce results identical to the built-in implementation because it is, after all, a standard. But if that’s the case, there doesn’t seem to be much point to the undertaking. <\/p>\n
There was some speculation as to why the customer wanted to reimplement a standard algorithm. Maybe they thought they could do a better job by taking advantage of special-purpose instructions in the CPU<\/a> for encryption and decryption? But a member of the security team confirmed that the built-in providers already take advantage of those instructions if available. “Unless your customer wants to use a mode that the built-in providers don’t support, there is no technical reason for them to write their own implementation.” <\/p>\n The customer liaison reported that the customer was trying to close a deal with a client. The client wants to be able to configure Exchange to use a customized encryption algorithm<\/a>. “They might not end up creating such a customized encryption algorithm, but they want to be sure that it’s possible, so they need a proof-of-concept demonstration.” The customer found the Cryptographic Provider Development Kit<\/a> and was working through the sample provider. <\/p>\n One person contributed to the discussion with a story from personal experience: <\/p>\n I worked at a company where custom cryptography was a government requirement. Don’t do it. Developing and supporting custom cryptography is a multi-year undertaking. It is technically possible<\/a>, but I don’t think your customer is willing to invest so much. You need to position the solution differently. <\/p><\/blockquote>\n