CryptoStream и аутентифицированные режимы шифрования

Question

Я заинтересован в предоставлении управляемой DLL для использования в .NET, которая обеспечивает аутентифицированные услуги шифрования. DLL может использоваться в программе WPF или приложении ASP. У меня есть пара вопросов, связанных с криптографическими и потоковыми моделями Microsoft.

Аутентифицированные режимы шифрования (CCM, CWC, EAX, GCM и т. Д.) Обычно создают два артефакта - сначала это шифрованный текст, а второй - тег аутентификации. Его довольно простое шифрование, но могут быть некоторые проблемы. Например, CCM не может быть потоковым из-за способа создания заголовка, а аутентифицированные режимы шифрования создают тег аутентификации.

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

Как адаптировать аутентифицированный режим шифрования для блочного шифрования, чтобы его можно было использовать в CryptoStream? Возможно ли это? Возможно, это почему Microsoft не предоставляет его?

Имеет ли рекомендация Microsoft? Например, разбейте большое сообщение на более мелкие сообщения или единицы (каждый со своим собственным тегом)? Или MS рекомендует буферизацию, пока не будет введено все сообщение и тег?

Где Microsoft рекомендует «поместить» тег? В начале потока? В конце потока?

Некоторые полезные ссылки:

• SymmetricAlgorithm Class
• CipherMode Enumeration
• CryptoStream Class

Answer 1

В 2010 году Microsoft команда безопасности CLR выпустила extension to the System.Security.Cryptography, который включал аутентификацией симметричного шифрования специально GCM. Почему они ничего не сделали с этим с тех пор, я не знаю.

Но, поскольку в вашем вопросе акцент делается на «что бы сделать Microsoft?», Вот оно ... они сделали это.

Answer 2

Вы используете предположение, которое действительно не выполняется для аутентифицированного шифрования baard на потоковых шифрах, таких как GCM: что вы не можете расшифровать перед проверкой. Это справедливо для, например, AES в режиме CBC, который аутентифицируется MAC при применении оракулов. Например, режим GCM не выполняет прописку, поскольку базовый потоковый шифр - это шифрование режима CTR. Это, в свою очередь, означает, что отступы не должны применяться, поэтому прописные оракулы не применяются.

Конечно, было бы крайне неразумно выполнять любую бизнес-логику с дешифрованными данными до ее аутентификации. Любой код, который затрагивает непроверенные данные, должен считаться высоким риском, и его следует статически анализировать и проверять. Если вы хотите выполнить какую-либо бизнес-логику раньше, тогда вы должны убедиться, что она будет проходить проверку подлинности до этого. Разделение его на более мелкие части, несомненно, имело бы смысл.

Очевидно, что это только мои рекомендации. Для рекомендаций Microsoft: если они не могут быть найдены с помощью Google или (не дай бог) Bing: спросите Microsoft. Здесь никто не может говорить.