RSA и OAEP: выбирать или не выбирать алгоритм Ha sh? - PullRequest
Новая
       31

RSA и OAEP: выбирать или не выбирать алгоритм Ha sh?

1 голос
/ 06 февраля 2020

Я внедряю систему асимметричного шифрования: 

''' <summary>
''' A facade for a data asymmetrical encryption algorithm relying on a pair of public and private keys.
''' </summary>
Public Interface IAsymEncrypter

    ''' <summary>
    ''' The public key to rely upon for encrypting data. Under XML format.
    ''' </summary>
    ReadOnly Property PublicKeyXml As String

    ''' <summary>
    ''' The private key to rely upon for decrypting data. Under XML format.
    ''' <para>Also contains the public key.</para>
    ''' </summary>
    ReadOnly Property PrivateKeyXml As String

    ''' <summary>
    ''' Encrypts data, using a public key.
    ''' </summary>
    ''' <param name="Data">The data to encrypt.</param>
    Function Encrypt(Data As Byte()) As Byte()

    ''' <summary>
    ''' Decrypts data, using a private key.
    ''' </summary>
    ''' <param name="Cipher">The cipher to decrypt the data from.</param>
    Function Decrypt(Cipher As Byte()) As Byte()

End Interface

Реализация включает RSACryptoServiceProvider. Реализация Encrypt и Decrypt требует выбора для заполнения. Я уже исследовал и понимаю следующее:

  • Заполнение OAEP должно быть предпочтительнее, чем PKCS.
  • Слабость против коллизий алгоритма ha sh, связанных с OAEP, на сегодняшний день не имеет значения и не должно быть решающим критерием.
  • Опираясь на более короткий вывод, га sh позволяет шифровать большие строки.

Я ищу лучшие методы обеспечения безопасности, сохраняя техническое обслуживание как можно ниже. Я видел, что .Encrypt имеет две перегрузки :

  • .Encrypt(Data as Byte(), fOAEP as Boolean) as Byte(), где fOAEP должно быть установлено на True, чтобы полагаться на OAEP. Я предполагаю, что это означает, что алгоритм ha sh выбирается автоматически; по каким критериям я этого не выяснил.
  • .Encrypt(Date as Byte(), Padding as RsaEncryptionPadding) as Byte(), где можно указать OAEP, связанный с SHA-1 - SHA512.

Два вопроса:

  1. Хранится ли режим заполнения вместе с зашифрованным сообщением? То есть можно ли по зашифрованному сообщению угадать, какой режим заполнения использовать для его расшифровки?
  2. Если нет, то, наверное, мне лучше выбрать этот режим самостоятельно, и в этом случае я хотел бы знать, есть ли другие соображения, которые я должен принять во внимание?

Ура!

1 Ответ

3 голосов
/ 06 февраля 2020

Я предполагаю, что это означает, что алгоритм ha sh выбирается автоматически; по каким критериям я этого не выяснил.

К сожалению, старые API-интерфейсы Microsoft ужасно занижены (или, скорее, недокументированы). Это не единственное место, где алгоритм или метод кодирования не могут быть найдены. SHA-1 является стандартом по умолчанию, поэтому он, вероятно, используется, если вы не укажете его (также для обратной совместимости).

Q1: режим заполнения хранится рядом с зашифрованное сообщение? То есть можно ли из зашифрованного сообщения угадать, какой режим заполнения использовать для его расшифровки?

Нет, и даже если это так, вам не следует его использовать. RSA PKCS # 1 указывает, что вы должны предварительно определить параметры конфигурации. Кроме того, вы дадите атакующему небольшое преимущество, если разрешите изменение, не проверив сначала этот выбор.

Q2: Если нет, то, наверное, мне лучше выбирая режим самостоятельно, в этом случае я хотел бы знать, есть ли другие соображения, которые я должен принять во внимание?

SHA-1 является стандартным значением по умолчанию, SHA-256 может использоваться как это относительно быстро и не имеет никаких атак. Это также ускоряется на последних процессорах. Недостаток: он все еще самый медленный ha sh на 64-битных машинах без этого ускорения (но, по сравнению с RSA, это, вероятно, будет не так заметно на практике). SHA-512 является одновременно очень быстрым и безопасным, хотя запас прочности на самом деле не имеет большого значения для этой конкретной c цели.

Если есть унаследованные проблемы, я просто go с SHA-1 - в этом случае SHA-1 должен быть ужасно сломан, чтобы вызывать беспокойство. В противном случае SHA-256 имеет больше смысла, так как он значительно более безопасен.

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

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

И пока мы обсуждаем скрытие важных деталей, ты боишься, что скрываешь все детали в своем классе Facade? Обычно такие классы представляют собой лишь тонкий слой вокруг указанного API, и они скрывают именно те детали, которые вы не хотите скрывать. Если они используются внутри нескольких проектов, их может быть почти невозможно изменить, если вы допустите какую-либо ошибку.

Обычно такие классы создаются просто для обобщения знаний разработчика чем с приложением, указанным c цель. Хорошо писать их для практических целей, но я бы не стал использовать их в вашей обычной кодовой базе. Вместо этого напишите классы для конкретных c вариантов использования .

Как правило, вы будете использовать гибридную криптографию и шифровать случайный ключ AES, если вы обеспокоены тем, что ваше сообщение не ' т вписывается в единый блок RSA. Тогда другие среды выполнения могут использовать необработанный RSA для реализации RSA-KEM, но это, вероятно, не очень хорошая идея в среде Microsoft /. NET, где вам всегда нужно дополнять.

...