Шифрование DES в Java против .NET - почему отличается? - PullRequest
5 голосов
/ 19 мая 2011

У меня есть метод .NET для шифрования DES на строке:

public static string EncryptTripleDES(string value, byte[] encryptionKey, byte[] initializationVector) {
  if (!value.IsNullOrEmpty()) {
    TripleDESCryptoServiceProvider cryptoProvider = new TripleDESCryptoServiceProvider();
    MemoryStream ms = new MemoryStream();
    CryptoStream cs = new CryptoStream(ms, cryptoProvider.CreateEncryptor(encryptionKey, initializationVector), CryptoStreamMode.Write);
    StreamWriter sw = new StreamWriter(cs);
    sw.Write(value);
    sw.Flush();
    cs.FlushFinalBlock();
    ms.Flush();
    //convert back to a string
    return Convert.ToBase64String(ms.GetBuffer(), 0, (int)ms.Length);
  } else {
    return "";
  }
}

Как видите, алгоритм принимает 2 параметра - «ключ шифрования» и «вектор инициализации».

Теперь мне нужно написать функцию шифрования / дешифрования DES в Java, параллельно с этой функцией, так что если вы предоставите тот же ключ шифрования и вектор инициализации, вы сможете дешифровать в Java то, что было зашифровано в C #. (Надевает спецодежду Java, проходит около 10 лет с момента последнего использования Java, Googles для шифрования DES в Java ...)

Найден достойный подход шифрования Java DES здесь . Но, о боже, получается, что этот алгоритм требует вектора инициализации ровно 8 байтов; код .NET использует вектор инициализации размером 24 байта!

И что теперь? Почему Java настаивает на 8-байтовом векторе инициализации? И как я могу расшифровать то, что было зашифровано с помощью 24-байтового вектора инициализации?

Ответы [ 3 ]

2 голосов
/ 19 мая 2011

Вы пытались использовать первые 8 байтов 24-байтового вектора инициализации в коде Java?Все, что я вижу при поиске и просмотре исходного кода, указывает на то, что будут использоваться только первые 8 байтов, поскольку Triple DES имеет размер блока 8 байтов.Я действительно удивлен тем, что .NET-код не вызывает исключений, подобных тому, который упоминается в в этом вопросе , поскольку IV не соответствует размеру блока алгоритма.Также см. в этом вопросе , где приведены примеры успешного использования 8-байтового IV.

Еще одна сложность в коде .NET заключается в том, что для заполнения и шифровального режима используются значения по умолчанию.Я не знаю, что .NET будет использовать для них, хотя замечания здесь указывают на то, что шифровальный режим по умолчанию - CBC.Я не вижу упоминания о заполнении, но из примера взаимодействия здесь кажется, что CBC и PKCS5Padding будут работать.Однако я бы не стал полагаться на значения по умолчанию для такой совместимости, поскольку они могут быть проблематичными.

Исходя из фона Java, я не совсем уверен, что происходит в коде C # с использованием 24-байтового IV, но 8-байтовый IV, применяемый Java, мне кажется правильным.Мне всегда интересно быть неправым и узнавать что-то новое.Bouncycastle, как упомянуто @Tim, также применяет это же ограничение, и похоже, что .NET обычно тоже.

2 голосов
/ 19 мая 2011

Из MSDN :

Свойству IV автоматически присваивается новое случайное значение при создании нового экземпляра одного из классов SymmetricAlgorithm или при вызове вручнуюМетод GenerateIV.Размер свойства IV должен совпадать со свойством BlockSize.

Поэтому мне кажется, что вы можете просто изменить свойство BlockSize, а затем установить для IV требуемый размер..

EDIT

Из того, что я собрал в своем исследовании, кажется, что все реализации алгоритма шифрования DES используют 8 байтов (64 бита, 8 из которых отбрасываются, оставляя вас с56 байт).TripleDES (3DES) позволяет использовать ключ длиной 24 байта (или 192 бита, 24 из которых отбрасываются, оставляя вас с 168 битами).

Похоже, вам придется использовать алгоритм TripleDES в Java(доступно несколько библиотек, пример , SO Вопрос ), или вам нужно будет повторно зашифровать ваши данные, используя обычный алгоритм шифрования DES в .NET.

0 голосов
/ 19 мая 2011

Вы взглянули на библиотеку Bouncy Castle для Java? Я не могу судить по их (очень редкой) документации и примерам, но это похоже на широко используемую библиотеку, поэтому я надеюсь, что она будет настолько гибкой. Стоит хотя бы взглянуть, если вы еще этого не сделали.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...