Рекомендуемая комбинация шифрования для цифровых подписей

Question

Наконец, после нескольких дней мучений, я понял, что мне нужно две формы шифрования для моего проекта цифровых подписей. Первый будет симметричным (AES) и будет шифровать данные лицензии , а второй будет асимметричным (RSA) и будет шифровать симметричный ключ . Может кто-нибудь дать мне советы о лучших методах использования для Android.

For the public/private keys I am using: "RSA/ECB/PKCS1Padding" (у меня голова ECB плохая, так что мне использовать? Что насчет PKCS1Padding - шо, я использую PKCS5Padding?)

For the symetric keys I will probably use: "AES/???/?????????" (Какой режим и отступы следует использовать?)

Провайдер: "БК"

RSA Keysize: 1024 (я пробовал 2048, но по какой-то причине он не работал)

AES Keysize: ???? (предложения)

Также, если вы знаете, где я могу найти хорошее руководство по тому, что на самом деле поддерживается в Android, было бы замечательно.

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

Если вам известна хорошая комбинация, но вы не уверены, поддерживается ли она на Android, скажите, пожалуйста, чтобы я не тратил много времени на то, чтобы найти, что она не поддерживается.

Answer 1

ECB небезопасен для режимов блочного шифрования, потому что слишком легко повторно использовать 64, 128 или 256-битные блоки во входном потоке - наличие повторяющегося содержимого будет немедленно видно в зашифрованном тексте.

Но RSA не используется для шифрования входных «потоков» - он всегда используется только для шифрования сеансовых ключей (как вы, кажется, делаете) или для подписи выходных данных функций дайджеста сообщений.Так что режим ECB для RSA в порядке.

Используйте схему заполнения PKCS # 1 с RSA;Схема заполнения PKCS # 5 предназначена для симметричных шифров.

Если 1024 является самой большой парой ключей RSA, которую вы можете использовать (или сгенерировать на устройстве?), То, вероятно, 128 или 192-битный AES представляет аналогичный риск.В зависимости от того, насколько медленнее 256-битный AES, я мог бы использовать его вместо этого, просто чтобы предоставить еще один четырех или пятилетний буфер для алгоритмических улучшений в атаках AES.

Рекомендации NIST по использованию AES рекомендуют использовать любой из: CBCРежимы, CFB, OFB или CTR.

В тех же руководствах также упоминается 'add 1, и поскольку для заполнения механизма заполнения последнего блока требуется несколько 0 битов, поэтому он должен быть достаточно безопаснымиспользовать.

Но для всего этого я должен предложить использовать gpgme или openssl или gnutls для выполнения всей вашей работы.Попытка создать свои собственные протоколы может быть очень тонкой.Надеемся, что в Android есть несколько высокоуровневых наборов инструментов, которые значительно упростят процесс генерации / проверки подписи.

Рекомендации NIST: http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf

Answer 2

Когда дело доходит до режима работы для AES, вы можете перейти на CBC. Если ваш модуль RSA равен 1024 битам, вам не нужен ключ AES больше 128 бит. Если это связано с лицензиями и защитой программного обеспечения, люди обойдут код, а не нарушат криптографию:)

Answer 3

Вы не должны заново изобретать колеса.Используйте стандартные механизмы, поддерживаемые BouncyCastle.

Для подписи вы должны использовать подпись PKCS # 7, которая обрабатывается этим классом,

http://bouncycastle.gva.es/www.bouncycastle.org/docs/mdocs1.4/org/bouncycastle/cms/CMSSignedDataGenerator.html

Для шифрования выможет использовать API S / MIME, который обрабатывает для вас генерацию / шифрование / шифрование симметричного ключа,

http://www.bouncycastle.org/wiki/display/JA1/CMS+and+SMIME+APIs

Answer 4

Если вы делаете подписи, чем вы должны использовать Подпись класс.