#java #ruby-on-rails #aes
#java #ruby-on-rails #aes
Вопрос:
Я использую следующее в проекте RoR:
somepass =Aes.encrypt_buffer(128, 'ECB', some_cypher_key, nil, pain_string)
Использует ли эта библиотека и метод ECB заполнение по умолчанию или нет?
В конечном итоге я пытаюсь добиться того, чтобы RoR-приложение и Java-приложение могли создавать одну и ту же зашифрованную строку из одной и той же простой строки.
В коде Java я использую: cipher = Cipher.getInstance("AES/ECB/PKCS5Padding", "SunJCE");
Эти две строки кода не создают один и тот же зашифрованный ключ.
Комментарии:
1. Надеюсь, вы имели в виду, что они не создают один и тот же зашифрованный блок вместо одного и того же зашифрованного ключа?
Ответ №1:
Aes.encrypt_buffer будет использоваться заполнение, просто не того типа, который вы ожидаете. Он заполнит блок n байтами со значением добавленных байтов. То есть, если ему нужно добавить 15 байт, он добавит 0x0f , если ему нужно добавить 5 байт, он добавит 0x05 . То есть PKCS7, как описано в RFC-5652.
Вам следует переключиться на openssl или использовать Cipher.getInstance("AES/ECB/PKCS7Padding", "BC") с java.
Комментарии:
1. Спасибо, Милан. Использование заполнения PKCS7 с поставщиком BC дает тот же результат, что и при использовании заполнения PKCS5 с поставщиком SunJCE. Есть идеи, почему это так? Также я заметил, что некоторые пароли возвращают зашифрованный ключ с ‘-‘ впереди, но в ruby это не так. Есть мысли? Спасибо
2. Прошло некоторое время с тех пор, как я в последний раз играл со стандартами pkc, но вскоре я понял, что pkcs7 — это просто расширение pkc5, которое может обрабатывать большие блоки. Вот почему вы получаете те же результаты. Кажется, что ваш код должен работать, но это не совсем так из-за ошибочной стандартной реализации ruby-aes. Мой совет — вместо этого переключиться на openssl и повторить попытку.
3. есть ли вероятность, что я мог получать эти странные ключи, потому что я неправильно кодирую байты из шифра?