AES 128 DOT NET и совместимость с Java - PullRequest
Новая
       7

AES 128 DOT NET и совместимость с Java

3 голосов
/ 23 ноября 2010

Мы пытались создать прототип схемы, в которой мы шифруем дешифрованные данные между двумя системами: одна в .NET, а другая в Java.Мы собирались использовать простое 128-битное шифрование AES.

Проблема, с которой я столкнулся, тривиальна, но я не могу найти правильного решения.Возможно, мое понимание AES или шифрования в целом меньше.

Предполагая, что у нас есть предопределенный ключ, представленный следующей шестнадцатеричной строкой: "9c361fec3ac1ebe7b540487c9c25e24e".Это 16-байтовый ключ.Часть шифрования в Java была бы 

  final byte[] rawKey = hexStringToByteArray("9c361fec3ac1ebe7b540487c9c25e24e");
  final SecretKeySpec skeySpec = new SecretKeySpec(rawKey, "AES");
  // Instantiate the cipher
  final Cipher cipher = Cipher.getInstance("AES");
  cipher.init(Cipher.ENCRYPT_MODE, skeySpec);

  final byte[] encrypted = cipher.doFinal(plainText.getBytes());

Функция 'hexStringToByteArray' преобразует шестнадцатеричную строку в байтовый массив.Проблема в том, что в Java байты подписаны.Таким образом, значение 9C равно -100, а не 156 (как это было бы в .NET).

В Java это становится: -100,54,31,-20,58,-63,-21,-25,-75,64,72,124,-100,37,-30,78

В .NET, однако, это: 156,54,31,236,58,193,235,231,181,64,72,124,156,37,226,78

Вопрос: Учитывая, что представление самих ключей отличается, повлияет ли это на сам процесс шифрования?Это простое шифрование без CBC и PADDING.

Редактировать: Обновлен код, чтобы он выглядел отформатированным.

1 Ответ

3 голосов
/ 23 ноября 2010

Я не думаю, что у вас вообще есть проблемы.У вас есть абсолютно одинаковые данные на обеих платформах.Одна версия показывает это как данные со знаком, другая как без знака ... но сами биты одинаковы.

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

...