Почему SecureString и ProtectedMemory были размещены в разных сборках и пространствах имен?

Question

На концептуальном уровне SecureString выглядит как специализация ProtectedMemory.

Разумеется, его основная функция заключается в сокращении времени жизни (неизменяемых) строк внутри оперативной памяти, подкачки и аварийных дампов.Однако он также использует DPAPI для защиты данных, кроме точек входа и выхода.DPAPI использует криптографию для своей работы.Так почему SecureString был помещен в System.Security, а не в System.Security.Cryptography?

На мой взгляд, если бы криптография не использовалась в реализации, то SecureString обеспечил бы только минимальное преимущество удобства вышесуществовавший ранее StringBuilder.

В именах классов SecureString и ProtectedMemory также есть контраст между «Secure» и «Protected», я не уверен, как это может быть мотивировано.

Answer 1

Я только что узнал, что SecureString не шифрует внутреннее хранилище в .NET Core;что SecureString не следует использовать в новой разработке (DE0001);и что до тех пор, пока я не получу строку из SecureString через Marshal.SecureStringToGlobalAllocUnicode, у меня все равно всегда будет танцевать незашифрованная строка в поколении 0 управляемой кучи, даже в случае .NET.Поэтому справедливо сказать, что SecureString в основном был просто украшенным StringBuffer, и «безопасность», на которую ссылается его имя класса, была больше связана с изменчивостью, чем с криптографией.

Damien_The_Unbeliever в его больше невидимый комментарий показал, что это согласуется с тем, как два класса были задокументированы (все время, начиная с .NET 2, где они оба были добавлены):

Я мог догадаться, что это потому, что они имеют разные концептуальныеуровни - SecureString обещает защитить строку, но не говорит, как она это делает.ProtectedMemory специально говорит это для доступа к DPAPI.То, что один может использовать другой (или базовую технологию) в качестве детали реализации, не означает, что он должен определять, где он принадлежит.