Как правильно использовать OAEPEncoding замка Bouncy для RSA (Легкий вес API)
Я играл вокруг с реализацией замка Bouncy RSA (Легкий вес API) и выяснил основы. Рассмотрение их спецификации для реализации поставщика JCE, я заметил, что различные дополнительные схемы могут использоваться с RSA. Из того, что я понимаю, пустым дополнением по умолчанию используется. Таким образом, я начал исследовать дополнение OAEP, особенно OAEPWithSHA512AndMGF1Padding. Поиск с Google не был очень полезен, таким образом, я начал рыть через исходный код BC и нашел org.bouncycastle.jce.provider.JCERSACipher класс. Но взгляд на initFromSpec быстро дал мне головную боль... А именно, я не понимаю то, что последние два параметра, которые могут быть переданы OAEPEncoding конструктор. Согласно API BC OAEPEncoding конструктор, который позволяет четыре параметра, принимает Digest mgf1Hash и byte[] encodingParams как последние два аргумента. Это озадачило меня, потому что я понятия не имею, как овладеть экземпляром алгоритма поколения маски, и при этом я не понимаю цели позади массива байтов, называемого как encodingParams. Что должно быть значениями arg3 и arg4 в коде ниже?
RSABlindedEngine rsa = new RSABlindedEngine();
SHA512Diges sha512 = new SHA512Digest();
Digest arg3 = ???;
byte[] arg4 = ???;
AsymmetricBlockCipher cipher = new OAEPEncoding(rsa, sha512, arg3, arg4);
1 ответ
OAEP определяется PKCS # 1, раздел 7.1 .
OAEP требует следующих параметров:
- хэш-функция;
- «функция генерации маски», которую можно рассматривать как хеш-функцию с неограниченной длиной вывода;
- «метка» (произвольная последовательность байтов).
Существует только одна определенная функция генерации маски, называемая MGF1, и эта функция построена на основе хэш-функции. Итак, ваш arg3 - это хеш-функция, которую будет использовать MGF1. Это может быть та же хэш-функция, что и первая (я не уверен, что это может быть тот же экземпляр Digest в API Bouncy Castle; здесь я говорю математически). Также это может быть другая хеш-функция.
Метка может использоваться как своего рода различие между экземплярами (например, вы можете зашифровать данные с явной «целью», закодированной в метке). Это удобно для некоторых математических доказательств, но сейчас PKCS # 1 рекомендует использовать пустую строку и покончить с ней. Для целей, описанных в PKCS # 1, пустая метка ничем не хуже других.
Процесс дешифрования должен знать эти параметры для работы. Обычно их кодируют в структуре, которая идет вместе с зашифрованным сообщением и гласит: «это зашифровано с помощью RSA / OAEP»; вот как это происходит в CMS .
В случае сомнений используйте ту же хеш-функцию, что и первый параметр и для MGF1, и используйте пустую метку.