Симметричное шифрование между .NET и Java

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

На их странице я могу шифровать данные и отправлять их на свой сервер через параметр запроса при вызове ресурса на моем сайте. Это делается с помощью симметричного шифрования AES.

Мне нужно указать пароль, соль (которая должна быть шестнадцатеричной) и вектор инициализации (но быть 16 символов).

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

System.Security.Cryptography.CryptographicException: Specified initialization vector (IV) does not match the block size for this algorithm. Source: mscorlib

Так, например, на их конце я указываю:

EncryptSymmetric("Hello World","AES","P4ssw0rD","00010203040506070809", "000102030405060708090A0B0C0D0E0F")

Где входы: обычный текст, алгоритм, парольная фраза, соль и IV соответственно.

Я получаю значение: eg/t9NIMnxmh412jTGCCeQ==

Если я попытаюсь расшифровать это со своей стороны, используя JCE или провайдера BouncyCastle, я получу (тот же алгоритм, парольную фразу, соль и IV, с 1000 итераций): 2rrRdHwpKGRenw8HKG1dsA==, что совершенно другое.

Я просмотрел много разных примеров Java в Интернете о том, как расшифровать AES. Одна из таких демонстраций выглядит следующим образом: http://blogs.msdn.com/b/dotnetinterop/archive/2005/01/24/java-and-net-aes-crypto-interop.aspx

Как я могу расшифровать симметричное шифрование AES, использующее парольную фразу, соль и IV, созданное платформой .NET на платформе Java?

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

Я использую JDK 1.5 в производстве, поэтому для этого мне нужно использовать 1.5.

В качестве примечания: во многих примерах на Java необходимо указать количество повторений на стороне java, но не на стороне .NET. Есть ли стандартное количество итераций, которое мне нужно указать на стороне java, которое соответствует выходу .NET по умолчанию.


java encryption aes .net encryption-symmetric
person Dominic    schedule 24.10.2011    source источник
comment
Поскольку он должен расшифровывать одно и то же значение независимо от языка программирования... вы пытались расшифровать его с помощью С# вместо Java? Построение кода расшифровки на другом языке может просто помочь найти любые различия в реализации.   -  person S.L. Barth    schedule 24.10.2011
comment
Я не программист на С#, поэтому не знаю, с чего начать. Я просто пытаюсь взаимодействовать с этой другой платформой.   -  person Dominic    schedule 24.10.2011
comment
Вы можете использовать любой другой язык, чтобы попробовать это, если у него есть криптографический API, поддерживающий AES. Еще одна мысль, может быть, проблема в разной кодировке открытого текста на исходной и целевой машинах? Например. UTF-8 против UTF-16.   -  person S.L. Barth    schedule 24.10.2011

Ответы (2)


arrow_upward
2
arrow_downward

Все зависит от того, как используются различные части/аргументы шифрования.

AES используется для шифрования байтов. Итак, вам нужно преобразовать строку в массив байтов. Поэтому вам нужно знать кодировку, используемую для преобразования строки. (UTF7, UTF8, ...).

Ключ в AES имеет несколько фиксированных размеров. Поэтому вам нужно знать, как перейти от парольной фразы к ключу AES с правильным размером бита.

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

Возможно, парольная фраза хэшируется (вы не предоставили для этого метод) с солью для получения ключа AES.

IV не секрет. Самый простой способ — добавить к зашифрованным данным IV. Видел длину зашифрованных данных, это не так.

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

person GvS    schedule 24.10.2011
comment
«Необходимость соли в AES мне неизвестна». Может быть, я неправильно понимаю, но наверняка AES так же уязвим для радужных таблиц, как и любой другой блочный шифр? - person S.L. Barth; 24.10.2011
comment
Хеш-функция всегда дает одно и то же количество байтов (хэш). Один уникальный результат хеширования может быть возвращен из нескольких входов. Таким образом, существует ограниченный набор результатов хэша. Если вы возьмете каждый результат из этого набора, вы сможете рассчитать возможный ввод. Таким образом, вы можете построить радужный стол. (Соль используется для создания бесконечного числа результатов). Для AES набор результатов бесконечен по размеру, потому что каждый ввод будет разрешаться в один уникальный зашифрованный результат. - person GvS; 24.10.2011
comment
+1. Доминик должен спросить своего делового партнера (то есть того, кто предоставляет сторонний сайт), какая именно комбинация алгоритмов используется. Обойти это невозможно, кроме бесцельных догадок. - person Paŭlo Ebermann; 24.10.2011
comment
Я предполагаю, что они используют соленый хэш для генерации ключа из фразы-пароля, и именно здесь появляется соль. Вы можете проверить это, передав NULL или неожиданное значение, и посмотрите на трассировку стека из исключение, которое выбрасывается. - person Yaur; 05.11.2011

arrow_upward
1
arrow_downward

Насколько я вижу, проблема связана с количеством итераций. При всем одинаковом (соль, IV, итерации) реализация .Net генерирует тот же результат, что и реализация Java. Я думаю, вам, возможно, придется спросить третью сторону, какие итерации они используют.

person flipchart    schedule 24.10.2011