Why were SecureString and ProtectedMemory placed in different assemblies and namespaces?

Question

On the conceptual level, SecureString looks like a specialization of ProtectedMemory.

Granted, its primary function is to shorten the lifetime of (immutable) strings inside RAM, swap, and crash dumps. However, it also uses DPAPI to protect the data except on the entry and exit points. DPAPI uses cryptography to do its job. So why SecureString was placed in System.Security rather than in System.Security.Cryptography?

In my view of it, if cryptography wasn't used in the implementation, then SecureString would provide only minimum benefit of convenience above the pre-existing StringBuilder.

There's also the contrast between "Secure" vs. "Protected" in SecureString and ProtectedMemory class names, I'm not sure how that might be motivated either.

Answer 1

I just found out that SecureString does not encrypt the internal storage in .NET Core; that SecureString should not be used in new development (DE0001); and that unless I get the string out of SecureString via Marshal.SecureStringToGlobalAllocUnicode, I'll still always have the unecrypted string dancing on generation 0 of the managed heap eventually, even in case of .NET. Therefore it is fair to say that SecureString basically was just a decorated StringBuffer and the "security" alluded to by its class name had more to do with mutability than with cryptography.

Damien_The_Unbeliever in his no longer visible comment showed that this aligns with how the two classes have been documented (all the time since .NET 2 where they were both added):

I could guess that it's because they're at different conceptual levels - SecureString promises to protect the string but doesn't say how it does it. ProtectedMemory specifically says it for accessing DPAPI. That one may use the other (or underlying tech) as an implementation detail doesn't mean that should dictate where it belongs.