Отличие правильного IV от неправильного IV в AES CBC, когда известен ключ

В настоящее время я использую статическое значение IV для всего шифрования и дешифрования, но я хотел бы, чтобы оно было динамическим для каждого запроса шифрования/дешифрования, поэтому я начал использовать новый байт [16], и это работает. Проблема в том, как обнаружить и расшифровать старые данные. Ниже приведен мой код для расшифровки, и я передаю статический IV, хранящийся в секрете в хранилище ключей.

частный статический байт [] DecryptFromBytes_Aes (байт [] dataBytes, байт [] ключ, байт [] iV)
    {
        если (dataBytes == null || dataBytes.Length <= 0)
            выбросить новое исключение ArgumentNullException("DataBytes");
        если (ключ == null || key.Length <= 0)
            бросить новое исключение ArgumentNullException («ключ»);
        if (iV == null || iV.Length <= 0)
            бросить новое исключение ArgumentNullException ("iV");

        байт [] результат = ноль;
        используя (AesCryptoServiceProvider aesAlg = новый AesCryptoServiceProvider())
        {
            aesAlg.Key = ключ;
            aesAlg.IV = IV;
            aesAlg.Padding = PaddingMode.PKCS7;
            ICryptoTransform decryptor = aesAlg.CreateDecryptor(aesAlg.Key, aesAlg.IV);
            используя (MemoryStream memoryStream = новый MemoryStream (байты данных))
            {
                используя (CryptoStream cryptoStream = new CryptoStream (memoryStream, decryptor, CryptoStreamMode.Read))
                {
                    byte[] decryptedBytes = новый байт[dataBytes.Length];
                    int read = cryptoStream.Read (decryptedBytes, 0, dataBytes.Length);
                    Array.Resize(ref decryptedBytes, read);
                    результат = расшифрованные байты;
                }
            }

        }

        вернуть результат;
    }

Проблема в том, как обнаружить и расшифровать старые данные. Ниже приведен мой код для расшифровки, и я передаю статический IV, хранящийся в секрете в хранилище ключей.

Ответ зависит от заполнения и правильности ключа.

• Случай: Если ключ правильный, а IV нет;

  Помните, что расшифровка CBC выполняется как \начать{выравнивать} P_1 =& Dec_k(C_1) \oplus IV\ P_i =& Dec_k(C_i) \oplus C_{i-1},\;\; 1 < i \leq nb, \end{выравнивание}

  Следовательно, если IV неверен, то первый блок $P_1$ не является правильным. Мы можем считать это похожим на атака с переворачиванием битов в первом блоке. Следующие блоки $P_i$ будут расшифровывать правильно, так как они полагаются на правильность $C_i$ и $C_{i-1}$ и в этом случае они правы. Только ваш первый блок будет неправильным. Различить это может быть сложно, и вам нужно подготовить некоторый фильтр, чтобы отличить его от свойств открытого текста. - язык или формат. Необходимо сравнить два случая; это статический IV или случайный IV. Какой бы ни был ваш фильтр, это может быть правильным случаем, и это действительно зависит от ваших данных.

  Если первый блок открытого текста представляет собой чистый текст и содержит только символы из первой части ASCII (т. е. значение int для char < 128), то это хороший различитель. Просто проверьте, что каждые 16 байт <128.

  Как можно скорее перенесите все свои файлы в уникальный формат.

• Случай: если ключ не правильный тогда вы получите ошибку заполнения PKCS # 7 с высокой вероятностью.

  Байты заполнения будут одним из следующих в конце открытого текста в зависимости от размера открытого текста.При заполнении размер должен быть как минимум кратен размеру блока AES, который имеет размер блока 16 байт.

    отсутствует 1 байт - байты заполнения: 01
    отсутствуют 2 байта - байты заполнения: 02 02
    отсутствуют 3 байта - байты заполнения: 03 03 03
    отсутствуют 4 байта - байты заполнения: 04 04 04 04
    отсутствуют 5 байтов - байты заполнения: 05 05 05 05 05
    отсутствуют 6 байтов - байты заполнения: 06 06 06 06 06 06
    ...
    полный блок - байты заполнения: 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 
    Даже если открытый текст кратен 128, необходим полный блок, чтобы заполнение не было неоднозначным.
  

  Проверьте правильность заполнения.

  Если это не так, вы можете быть уверены, что IV неверен. Если правильно, то есть $1/256$ вероятность того, что IV сгенерирует случайный действительный 01 прокладка, с $1/(256)^2$ вероятность 0202 допустимое заполнение и так далее. Чтобы убрать эту возможность, нужно проверить данные. Язык или любой другой формат открытого текста может помочь вам устранить ложные срабатывания.

Вы не можете надежно проверить, имеют ли данные случайный префикс или нет. Для одного и того же ключа данные даже вообще не подведут распаковку. Итак, что вам нужно сделать, это использовать другой протокол.

Например, у вас может быть 16-байтовая полностью случайная магия перед вновь зашифрованными файлами (конечно, сгенерированная один раз), затем номер версии и другие данные, включая случайный IV, зашифрованный текст и HMAC над заголовком и данными, включая IV. Таким образом, вы можете обнаружить, что используется правильное шифрование (поскольку случайное генерирование этой магии имеет вероятность 1 из $2^{128}$), просто выполнив сравнение. Вы также защитили свой файл на целостность и подлинность с помощью HMAC (это необязательно и не обязательно для обеспечения конфиденциальности, но настоятельно рекомендуется).

Итак, это будет:

 МАГИЯ (16 байт) | ВЕРСИЯ | IV (16 байт) | ШИФРОТЕКСТ | ТЕГ

Где TAG — это тег аутентификации, созданный с использованием HMAC поверх всего, что было раньше.

Конечно, было много людей, которые уже написали подобные протоколы, поэтому вы можете захотеть изучить форматы контейнеров, такие как CMS (который обычно зависит от шифрования/сертификатов с открытым ключом) или даже NaCL.