Соответствуют ли доступные схемы заполнения директиве BSI? - PullRequest
Новая
       54

Соответствуют ли доступные схемы заполнения директиве BSI?

1 голос
/ 04 мая 2011

В настоящее время я оцениваю криптографические возможности библиотеки безопасности ESAPI для Java. Моя цель - убедиться, что ESAPI поддерживает метод симметричного шифрования, который предлагается в этом руководстве, написанном BSI (ссылка идет на немецкий документ, версия на английском языке недоступна).

Насколько я могу использовать предложенный AES-128 в режиме CBC. К сожалению, BSI предлагает только следующие 3 схемы заполнения (стр. 10 в документе):

  • Заполнение ISO (в соответствии с ISO-7816-4-2005)
  • Заполнение в соответствии с RFC 4303
  • ESP padding

Библиотека ESAPI поддерживает только PKCS5 Padding и ISO-10126 Padding (который устарел, согласно Wikipedia ). Теперь мне интересно, может ли схема заполнения PKCS5 соответствовать RFC 4303 (см. Стр. 13 и 14). На мой взгляд, это выглядит совместимым, но было бы полезно второе мнение. Может ли кто-нибудь с более твердым криптографическим фоном пролить свет на это? Если бы я допустил какие-либо ошибки в своем анализе, было бы здорово, если бы вы могли указать на них. Может быть, я слишком усложняю вещи, и некоторые из этих схем эквивалентны, и я пропустил это.

Ответы [ 2 ]

1 голос
/ 07 мая 2011

ESAPI должен поддерживать любую схему заполнения, доступную и поддерживаемую вашим поставщиком JCE. Просто по умолчанию используется заполнение PKCS # 5, но это можно изменить, настроив свойство Encryptor.CipherTransformation в файле ESAPI.properties.

ESAPI использует любого провайдера JCE, который используется вашей JVM по умолчанию. Обычно это SunJCE. Однако это также можно изменить с помощью свойства Encryptor.PreferredJCEProvider в ESAPI.properties. SunJCE поддерживает только схемы дополнения NOPADDING, PKCS5PADDING, ISO10126PADDING для AES в JDK 1.6. (IIRC, я не думаю, что заполнение ISO-10126 поддерживается в JDK 1.5 и более ранних версиях, но я не подтвердил это.) Однако другие схемы дополнения могут быть доступны от других поставщиков JCE, таких как Bouncy Castle. (В соответствии с этим http://www.bouncycastle.org/specifications.html, выглядит так, как будто Bouncy Castle поддерживает заполнение ISO-7816-4 через ISO7816d4Padding. Я не проверял это, но если это не работает, пожалуйста, покажите электронное письмо в список пользователей ESAPI на сайте Google Issue http://code.google.com/p/owasp-esapi-java/issues/list или откройте его, и я постараюсь исправить его для вас.)

Кстати, я не читаю по-немецки, но не уверен, что беспокоит заполнение PKCS # 5, если, возможно, это не нападение оракула заполнения. Если да, ESAPI покрывает вас до тех пор, пока вы либо используете режим шифрования, который поддерживает аутентификацию сообщений, такой как GCM или CCM (оба из которых одобрены NIST), либо используете ESAPI, чтобы обеспечить аутентификацию сообщений через HMAC. Последний управляется через свойство Encryptor.CipherText.useMAC, которое по умолчанию установлено в «true» в поставляемом стандартном файле ESAPI.properties.

-кевиновая стена

1 голос
/ 05 мая 2011

Чтобы ответить на вопрос, совместимы ли механизмы заполнения PKCS # 5 и RFC 4303: нет, они не являются.

Во-первых, мое чтение RFC 4303 показывает, что байты заполнения получают значения 01, 02, ..., а PKCS # 5 устанавливает число байтов заполнения в качестве значения на all байтов заполнения. Таким образом, заполнение 2 байтов будет 01 02 в RFC 4303 и 02 02 в PKCS # 5.

Второе несоответствие, которое я видел, - это фактическое количество байтов для заполнения. PKCS # 5 указывает, что вы добавляете полный блок заполнения, когда сообщение уже кратно длине блока. Я не видел такого требования в RFC4303. Только то, что отступ составляет от 0 до 255 байтов. Однако, кроме неправильных значений, длина пэда PKCS # 5 будет приемлемой по длине для RFC 4303.

...