RFC 8017 PKCS #1: RSA Cryptography Specifications Version 2.2

Internet Engineering Task Force (IETF)                  K. Moriarty, Ed.
Request for Comments: 8017                               EMC Corporation
Obsoletes: 3447                                               B. Kaliski
Category: Informational                                         Verisign
ISSN: 2070-1721                                               J. Jonsson
                                                               Subset AB
                                                                A. Rusch
                                                                     RSA
                                                           November 2016

PKCS #1: RSA Cryptography Specifications Version 2.2

Спецификация криптографии RSA — PKCS #1 версии 2.2

PDF

Аннотация

В этом документе даются рекомендации по реализации криптографии с открытым ключом на основе алгоритма RSA, охватывающие криптографические примитивы, схемы шифрования, схемы подписи с приложением (appendix) и синтаксис ASN.1 для представления ключей и идентификации схем.

Документ является переизданием PKCS #1 v2.2 из серии RSA Laboratories’ Public-Key Cryptography Standards (PKCS). Публикация этого RFC передаёт контроль над документом в IETF. Данный документ отменяет действие RFC 3447.

Статус документа

Документ не относится к категории Internet Standards Track и публикуется с информационными целями.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Не все документы, одобренные IESG, претендуют на статус стандартов Internet (см. раздел 2 в RFC 7841).

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc8017.

Авторские права

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку они могут описывать ваши права и ограничения применительно к этому документу. Компоненты кода, извлечённые из этого документа, должны включать текст Simplified BSD License, как указано в параграфе4.e Trust Legal Provisions, и представлены без каких-либо гарантий, как указано в Simplified BSD License.

1. Введение

В документе даны рекомендации по реализации криптографии с открытым ключом на основе алгоритма RSA [RSA], включая:

криптографические примитивы;
схемы шифрования;
схемы подписи с приложением (appendix);
синтаксис ASN.1 для представления ключей и идентификации схем.

Рекомендации предназначены для применения в компьютерных и коммуникационных системах и обеспечивают достаточную гибкость. Предполагается, что стандарты применения, основанные на этой спецификации, могут включать дополнительные ограничения. Рекомендации предназначены для обеспечения совместимости со стандартами IEEE 1363 [IEEE1363], IEEE 1363a [IEEE1363A] и ANSI X9.44 [ANSIX944].

Документ заменяет собой PKCS #1 версии 2.1 [RFC3447], но включает совместимые методы. Организация документа показана ниже.

Раздел 1 является вводным.
В разделе 2 определены применяемые в документе обозначения.
В разделе 3 определены типы открытых и секретных ключей RSA.
В разделах 4 и 5 задано несколько примитивов или базовых математических операций. Раздел 4 задаёт примитивы преобразования данных, а раздел 5 — криптографические примитивы (шифрование и расшифровка, подписи и их проверка).
В разделах 6 — 8 рассматриваются схемы шифрования и подписи. Раздел 6 содержит обзор. В дополнение к методам PKCS #1 v1.5 раздел 7 задаёт схему шифрования на основе оптимального дополнения асимметричного шифрования (Optimal Asymmetric Encryption Padding или OAEP) [OAEP], а в разделе 8 задана схема подписи с приложением на основе вероятностной схемы (Probabilistic Signature Scheme или PSS) [RSARABIN] [PSS].
В разделе 9 заданы методы кодирования для схем подписи из раздела 8.
В Приложении A представлен синтаксис ASN.1 для ключей из раздела 3 и схем из разделов 7 и 8.
В Приложении B определены функции хэширования и создания маски (mask generation function или MGF), используемые в документе, а также синтаксис ASN.1 для этих методов.
В Приложении C представлен модуль ASN.1.
Приложения D и E описывают историю изменений PKCS #1 и содержат базовые сведения о стандартах криптографии с открытым ключом (Public-Key Cryptography Standards).

Документ является переизданием PKCS #1 v2.2 [PKCS1_22] из серии RSA Laboratories’ Public-Key Cryptography Standards (PKCS).

1.1. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [RFC2119].

2. Обозначения

целочисленный представитель шифротекста (0 — n-1);

строка октетов шифротекста;

секретный показатель степени RSA;

d_i

дополнительный множитель показателя степени r_i китайской теоремы об остатке ( Chinese Remainder Theorem или CRT) — положительное целое число, такое, что e * d_i == 1 (mod (r_i-1)) при i = 3, …, u;

показатель степени CRT p — положительное целое число, такое, что e * dP == 1 (mod (p-1));

показатель степени CRT q — положительное целое число, такое, что e * dQ == 1 (mod (q-1));

открытый показатель степени RSA;

строка октетов кодированного сообщения;

emBits

(предусмотренный) размер кодированного сообщения EM в битах;

emLen

(предусмотренный) размер кодированного сообщения EM в октетах;

GCD(. , .)

наибольший общий делитель двух неотрицательных целых чисел;

Hash

хэш-функция;

hLen

размер выхода функции Hash в октетах;

размер модуля RSA n в октетах;

секретный ключ RSA;

необязательная строка октетов метки RSAES-OAEP;

LCM(., …, .)

наименьшее общее кратное набора неотрицательных чисел;

целочисленный представитель сообщения (0 — n-1);

строка октетов сообщения;

mask

выходная строка октетов MGF;

maskLen

(предусмотренный) размер строки октетов маски;

MGF

функция создания маски;

mgfSeed

строка октетов затравки (seed) для генерации маски;

mLen

размер сообщения M в октетах;

модуль RSA, n = r_1 * r_2 * … * r_u , u >= 2;

(n, e)

открытый ключ RSA;

p, q

первые два простых делителя модуля RSA n;

qInv

коэффициент CRT — положительное целое число меньше p, такое, что q * qInv == 1 (mod p);

r_i

простые сомножители RSA n, включая r_1 = p, r_2 = q и другие при их наличии;

целочисленный представитель подписи (0 — n-1);

строка октетов подписи;

sLen

число октетов затравки EMSA-PSS;

t_i

дополнительный простой сомножитель коэффициента CRT r_i — положительное целое число меньше r_i , такое, что r_1 * r_2 * … * r_(i-1) * t_i == 1 (mod r_i) при i = 3, … , u;

число простых сомножителей модуля RSA, u >= 2;

неотрицательное целое число;

строка октетов, соответствующая x;

xLen

(предусмотренный) размер строки октетов X;

индикатор шестнадцатеричного представления строки октетов; 0x48 указывает октет с шестнадцатеричным значением 48, «(0x)48 09 0e» указывает строку из трёх октетов с шестнадцатеричными значениями 48, 09, 0e;

\lambda(n)

LCM(r_1-1, r_2-1, … , r_u-1);

\xor

побитовая операция исключительное ИЛИ (exclusive-or) для двух строк октетов;

\ceil(.)

функция округления в большую сторону; \ceil(x) — наименьшее целое число, не меньше x;

оператор конкатенации (слияния);

знак конгруэнтности; a == b (mod n) означает, целое число n является делителем целого числа a — b

Примечание. Китайскую теорему об остатке (CRT) можно применять как рекурсивно, так и нерекурсивно. В этом документе используется рекурсивный подход по алгоритму Гарнера [GARNER] (см. примечание в параграфе 3.2).

3. Типы ключей

В примитивах и схемах, описанных в документе, применяются два типа ключей — открытые ключи и секретные ключи RSA, которые формируют ключевые пары RSA.

Спецификация поддерживает так называемый «многофакторный» (multi-prime) RSA, где модуль может иметь более двух простых сомножителей. Преимуществом многофакторного RSA является снижение вычислительных издержек для примитивов расшифровки и подписи при использовании CRT. Высокая производительность может быть достигнута на однопроцессорных платформах, но ещё больше — на многопроцессорных, где модульное возведение в степень может выполняться параллельно.

Обсуждение влияния многофакторности на безопасность криптосистемы RSA доступно в [SILVERMAN].

3.1. Открытый ключ RSA

В этом документе открытый ключ RSA представляется двумя компонентами:

модуль RSA, положительное целое число;

открытый показатель степени (exponent) RSA, положительное целое число

В действительном открытом ключе RSA модуль RSA n является произведением u разных простых чисел r_i, i = 1, 2, …, u, где u >= 2, а открытый показатель степени RSA e — целым числом от 3 до n — 1, удовлетворяющим выражению GCD(e,\lambda(n)) = 1, где \lambda(n) = LCM(r_1 — 1, …, r_u — 1). По соглашению два первых простых числа r_1 и r_2 обозначаются также p и q, соответственно.

Рекомендуемый синтаксис для обмена открытыми ключами RSA между реализациями приведён в Приложении A.1.1, но внутреннее представление в реализации может быть иным.

3.2. Секретный ключ RSA

В этом документе для секретных ключей RSA используются два варианта представления:

пара чисел (n, d):

n — модуль RSA, положительное целое число;

d — секретный показатель степени RSA, положительное целое число.
квинтет (p, q, dP, dQ, qInv) и (возможно пустая) последовательность триплетов (r_i, d_i, t_i), где i = 3, …, u, по одному для каждого простого числа, не входящего в пятерку:

p — первый сомножитель, положительное целое число;

q — второй сомножитель, положительное целое число;

dP — первый сомножитель показателя степени CRT, положительное целое число;

dQ — второй сомножитель показателя степени CRT, положительное целое число;

qInv — (первый) коэффициент CRT, положительное целое число;

r_i — i-й сомножитель, положительное целое число;

d_i — показатель степени CRT i-го сомножителя, положительное целое число;

t_i — коэффициент CRT i-го сомножителя, положительное целое число.

В действительном секретном ключе RSA с первым представлением модуль RSA n совпадает с модулем соответствующего открытого ключа и является произведением u простых чисел r_i, i = 1, 2, …, u, где u >= 2. Секретный показатель степени RSA d является положительным числом меньше n, удовлетворяющим выражению

      e * d == 1 (mod \lambda(n))

где e — соответствующий открытый показатель степени RSA, а \lambda(n) соответствует определению в параграфе 3.1.

В действительном секретном ключе RSA со вторым представлением сомножители p и q являются двумя первыми простыми сомножителями модуля RSA n (т. е. r_1 и r_2), показатели степени CRT dP и dQ — положительные целые числа меньше p и q, соответственно, удовлетворяющие выражениям

      e * dP == 1 (mod (p-1))
      e * dQ == 1 (mod (q-1))

а коэффициент CRT qInv — положительное целое число меньше p, такое что

      q * qInv == 1 (mod p)

Если u > 2, представление будет включать один или несколько триплетов (r_i, d_i, t_i), где i = 3, …, u. Сомножители r_i являются дополнительными простыми сомножителями модуля RSA n. Для показателя степени CRT d_i (i = 3, …, u), удовлетворяет выражению

      e * d_i == 1 (mod (r_i - 1))

Каждый коэффициент CRT t_i (i = 3, …, u) является положительным целым числом меньше r_i, таким что

      R_i * t_i == 1 (mod r_i)

где R_i = r_1 * r_2 * … * r_(i-1).

Рекомендуемый синтаксис обмена секретными ключами RSA между реализациями, включающий компоненты обоих представлений, приведён в Приложении A.1.2. Внутреннее представление реализации может быть иным.

Примечания.

Приведённое здесь определение коэффициентов CRT и формулы, где они используются в примитивах раздела 5, в целом соответствуют алгоритму Гарнера [GARNER] (см. также алгоритм 14.71 в [HANDBOOK]). Однако для совместимости с представлениями секретных ключей RSA в PKCS #1 v2.0 и предыдущих версиях роли p и q поменялись местами по сравнению с остальными простыми числами. Таким образом, первый коэффициент CRT qInv определяется как обращение q mod p, вместо обращения R_1 mod r_2, т. е. p mod q.
Quisquater и Couvreur [FASTDEC] отметили преимущество использования CRT для операций RSA.

4. Примитивы преобразования данных

В схемах, заданных этим документом, применяются два примитива преобразования данных:

I2OSP — преобразование целого числа в строку октетов;
OS2IP — преобразование строки октетов в целое число.

В этом документе строка октетов в соответствии с синтаксисом ASN.1 представляет собой упорядоченную последовательность октетов (8-битовых байтов). Последовательность индексируется от первого (слева) до последнего (справа) октета. При преобразовании первый октет строки считается старшим.

4.1. I2OSP

I2OSP преобразует неотрицательное целое число в строку октетов заданного размера.

I2OSP (x, xLen)

Вход

неотрицательное целое число для преобразования

xLen

предусмотренный размер результирующей строки октетов

Выход

соответствующая строка октетов длиной xLen

Ошибка: integer too large

Этапы

Если x >= 256^xLen, выводится ошибка «integer too large» и работа останавливается.
Целое число x записывается в его уникальное представление из xLen цифр по основанию 256
```
x = x_(xLen-1) 256^(xLen-1) + x_(xLen-2) 256^(xLen-2) + … + x_1 256 + x_0
```
где 0 <= x_i < 256 (отметим, что при x < 256^(xLen-1) одна или несколько первых цифр будут нулями).
Октеты X_i имеют целочисленные значения x_(xLen-i) при 1 <= i <= xLen. Выходная строка имеет вид
```
X = X_1 X_2 ... X_xLen.
```

4.2. OS2IP

OS2IP преобразует строку октетов в неотрицательное целое число.

OS2IP (X)

Вход

строка октетов для преобразования

Выход

соответствующее неотрицательное целое число

Этапы

Пусть X_1 X_2 … X_xLen — октеты X от первого до последнего, x_(xLen-i) — целочисленное значение октета X_i при 1 <= i <= xLen.
Тогда x = x_(xLen-1) 256^(xLen-1) + x_(xLen-2) 256^(xLen-2) + … + x_1 256 + x_0.
Вывод x.

5. Криптографические примитивы

Криптографические примитивы — это базовые математические операции, из которых создаются криптографические схемы. Примитивы предназначены для реализации в оборудовании или программных модулях и не обеспечивают безопасность отдельно от криптографической схемы.

Этот документ задаёт 4 типа примитивов, организованных в пары — шифрование и расшифровка, создание и проверка подписи. В спецификациях предполагается соблюдение некоторых условий для входных данных, в частности, открытые и секретные ключи RSA считаются действительными.

5.1. Примитивы шифрования и расшифровки

Примитив шифрования создаёт представителя шифротекста по представителю сообщения под управлением открытого ключа, а примитив расшифровки — представителя сообщения по представителю шифротекста под управлением соответствующего секретного ключа.

В описанных здесь схемах шифрования используется одна пара примитивов шифрования и расшифровки: RSA Encryption Primitive (RSAEP) и RSA Decryption Primitive (RSADP). RSAEP и RSADP включают одну и ту же математическую операцию с разными ключами на входе. Заданные здесь примитивы совпадают с примитивами IFEP-RSA³) и IFDP-RSA⁴ в IEEE 1363 [IEEE1363] (за исключение добавленной поддержки мнофакторного RSA) и совместимы с PKCS #1 v1.5. Основной операцией в каждом примитиве является возведение в степень.

5.1.1. RSAEP

RSAEP ((n, e), m)

Вход

(n, e)

открытый ключ RSA

представитель сообщения, целое число от 0 до n — 1

Выход

представитель шифротекста, целое число от 0 до n — 1

Ошибка: message representative out of range

Допущение: открытый ключ RSA (n, e) является действительным

Этапы

Если представитель сообщения m не лежит в интервале 0 — n — 1, выводится ошибка «message representative out of range» и работа останавливается.
Принимается c = m^e mod n.
Вывод c.

5.1.2. RSADP

RSADP (K, c)

Вход

секретный ключ RSA K в одной из форм:

пара (n, d);
квинтет (p, q, dP, dQ, qInv) с возможно пустой последовательностью триплетов (r_i, d_i, t_i), i = 3, …, u

представитель шифротекста, целое число от 0 до n — 1

Выход

представитель сообщения, целое число от 0 до n — 1

Ошибка: ciphertext representative out of range

Допущение: Секретный ключ RSA K является действительным

Этапы

Если представитель шифротекста m не лежит в интервале 0 — n — 1, выводится ошибка «ciphertext representative out of range» и работа останавливается.
Рассчитывается представитель сообщения m, как показано ниже
1. При использовании первой формы ключа (n, d) m = c^d mod n.
2. При использовании второй формы (p, q, dP, dQ, qInv) и (r_i, d_i, t_i) выполняются указанные ниже действия.
  1. Принимается m_1 = c^dP mod p и m_2 = c^dQ mod q.
  2. Если u > 2, m_i = c^(d_i) mod r_i, где i = 3, …, u.
  3. h = (m_1 — m_2) * qInv mod p.
  4. m = m_2 + q * h.
  5. Если u > 2 и R = r_1, от i = 3 до u выполняются операции:
    1. R = R * r_(i-1)
    2. h = (m_i — m) * t_i mod r_i
    3. m = m + R * h
Вывод m.

Примечание. Этап 2.b можно переопределить как один цикл при условии смены порядка p и q. Однако для согласованности с PKCS #1 v2.0 первые два простых числа p и q рассматриваются отдельно от других простых чисел.

5.2. Примитивы подписи и проверки

Примитив подписи формирует представителя подписи по представителю сообщения под контролем секретного ключа, а примитив проверки восстанавливает представителя сообщения по представителю подписи под контролем соответствующего открытого ключа. В заданных документом схемах подписи применяется одна пара примитивов подписи и проверки: RSA Signature Primitive версии 1 (RSASP1) и RSA Verification Primitive версии 1 (RSAVP1).

Заданные здесь примитивы совпадают с IFSP-RSA1⁵ и IFVP-RSA1⁶ из IEEE 1363 [IEEE1363] (за исключением добавления поддержки многофакторного RSA) и совместимы с PKCS #1 v1.5.

Основной операцией в каждом примитиве является возведение в степень, как в примитивах шифрования и расшифровки, заданных в параграфе 5.1. RSASP1 и RSAVP1 отличаются от RSADP и RSAEP лишь именами входных и выходных параметров, но имеют разное назначение.

5.2.1. RSASP1

RSASP1 (K, m)

Вход

секретный ключ RSA K в одной из форм:

пара (n, d)
квинтет (p, q, dP, dQ, qInv) с возможно пустой последовательностью триплетов (r_i, d_i, t_i), i = 3, …, u

представитель сообщения, целое число от 0 до n — 1

Выход

представитель подписи, целое число от 0 до n — 1

Ошибка: message representative out of range

Допущение: Секретный ключ RSA K является действительным

Этапы

Если представитель сообщения m не лежит в интервале 0 — n — 1, выводится ошибка «message representative out of range» и работа останавливается.
Рассчитывается представитель подписи s, как показано ниже
1. При использовании первой формы ключа (n, d) s = c^d mod n
2. При использовании второй формы (p, q, dP, dQ, qInv) и (r_i, d_i, t_i) выполняются указанные ниже действия.
  1. Принимается s_1 = c^dP mod p и s_2 = c^dQ mod q
  2. Если u > 2, s_i = c^(d_i) mod r_i, где i = 3, …, u
  3. h = (s_1 — s_2) * qInv mod p
  4. s = s_2 + q * h
  5. Если u > 2 и R = r_1, от i = 3 до u выполняются операции:
    1. R = R * r_(i-1)
    2. h = (s_i — s) * t_i mod r_i
    3. s = s + R * h
Вывод s.

5.2.2. RSAVP1

RSAVP1 ((n, e), s)

Вход

(n, e)

открытый ключ RSA

представитель подписи, целое число от 0 до n — 1

Выход

представитель сообщения, целое число от 0 до n — 1

Ошибка: signature representative out of range

Допущение: открытый ключ RSA (n, e) является действительным

Этапы

Если представитель подписи m не лежит в интервале 0 — n — 1, выводится ошибка «signature representative out of range» и работа останавливается.
m = s^e mod n
Вывод m.

6. Обзор схем

Схема объединяет криптографические примитивы и иные методы для достижения конкретных целей безопасности. Этот документ задаёт два типа схем — шифрование и подписи с приложением (appendix). Область действия этих схем ограничена в том смысле, что их операции включают лишь получение и проверку ключей. Поэтому для добавления в схему операций приложение будет обычно включать операции управления ключами, посредством которых стороны выбирают открытые и секретные ключи RSA для работы схемы. Конкретные дополнительные операции выходят за рамки документа.

Как и в случае с криптографическими примитивами (раздел 5), спецификации операций схемы предполагают соблюдение некоторых условий на входе, в частности, действительность открытых и секретных ключей RSA. При непригодном ключе поведение реализации становится неопределённым и его влияние зависит от приложения. Возможными способами проверки ключей является их явная проверка приложением, проверка через инфраструктуру открытых ключей (public-key infrastructure или PKI), а также возложение ответственности за операции с недействительным ключом на сторону, создавшую ключ.

В криптографии хорошим тоном является использование данной пары ключей RSA лишь в одной схеме. Это избавляет от риска того, что уязвимость одной схемы может скомпрометировать безопасность другой и может оказаться важным для поддержки доказуемой безопасности. Хотя RSAES-PKCS1-v1_5 (параграф 7.2) и RSASSA-PKCS1-v1_5 (параграф 8.2) традиционно применялись вместе без каких-либо известных проблем (именно такая модель была представлена в PKCS #1 v1.5), такое комбинированное использование пары ключей RSA не рекомендуется в новых приложениях.

Для иллюстрации рисков, связанных с использованием пары ключей RSA в нескольких схемах, предположим, что пара ключей RSA применяется в RSAES-OAEP (параграф 7.1) и RSAES-PKCS1-v1_5. Хотя схема RSAES-OAEP сама по себе устойчива к атакам, злоумышленник может воспользоваться уязвимостью в реализации RSAES-PKCS1-v1_5 для раскрытия зашифрованных по этой схеме сообщений. Другим примером может служить совместное использование пары ключей RSA в RSASSA-PSS (параграф 8.1) и RSASSA-PKCS1-v1_5. В этом случае доказательства безопасности RSASSA-PSS будет не достаточно, поскольку оно не учитывает возможность создания подписей с помощью второй схемы. Аналогичные соображение применимы и при использовании пары ключей в одной из определённых здесь схем и каком-то внешнем варианте.

7. Схемы шифрования

В документе схемой шифрования считается схема, включающая операции шифрования и расшифровки, где операция шифрования выдаёт шифротекст по открытому сообщению с использованием открытого ключа RSA, а операция расшифровки восстанавливает сообщение и шифротекст с использованием соответствующего секретного ключа RSA.

Схема шифрования может применяться в различных приложениях. Типовым вариантом является протокол организации ключей, где сообщение содержит ключевой материал, который нужно конфиденциально передать одной стороне от другой. Например, в PKCS #7 [RFC2315] такой протокол служит для доставки ключей шифрования содержимого от отправителя к получателю и заданные здесь схемы шифрования подходят для применения в таком контексте.

Документ задаёт две схемы шифрования — RSAES-OAEP и RSAES-PKCS1-v1_5. Поддержка RSAES-OAEP требуется в новых приложениях, а схема RSAES-PKCS1-v1_5 включена для совместимости с имеющимися приложениями.

Приведённые схемы шифрования основаны на общей модели, схожей с используемой в IEEE 1363 [IEEE1363], и сочетают примитивы шифрования и расшифровки с методом кодирования для шифрования. При шифровании сообщений применяется операция кодирования, а кодированное сообщение преобразуется в целочисленный представитель сообщения. Затем к представителю применяется примитив шифрования для получения шифротекста. При расшифровке к шифротексту применяется примитив расшифровки, восстанавливающий представитель сообщения, который затем преобразуется в сообщение, кодированное в виде строки октетов. Затем применяется операция декодирования для восстановления сообщения и проверяется корректность расшифровки.

Для предотвращения уязвимостей, связанных с обработкой ошибок при декодировании (см. [BLEICHENBACHER] и [MANGER]) операции кодирования и декодирования для RSAES-OAEP и RSAES-PKCS1-v1_5 включены в спецификации соответствующих схем шифрования, а не заданы в отдельных документах. Обе схемы шифрования совместимы с соответствующими схемами PKCS #1 v2.1.

7.1. RSAES-OAEP

RSAES-OAEP объединяет примитивы RSAEP и RSADP (параграфы 5.1.1 и 5.1.2) с методом кодирования EME-OAEP (п. 2 в параграфе 7.1.1 и п. 3 в параграфе 7.1.2). EME-OAEP основан на схеме оптимального асимметричного шифрования Беллара (Bellare) и Рогуэя (Rogaway) [OAEP]. Метод совместим со схемой шифрования на основе целочисленной факторизации (Integer Factorization Encryption Scheme или IFES), определённой в стандарте IEEE 1363 [IEEE1363], где примитивами шифрования и расшифровки являются IFEP-RSA и IFDP-RSA, а сообщение кодируется по методу EME-OAEP. RSAES-OAEP может работать с сообщениями размером до k — 2hLen — 2 октетов, где hLen — размер вывода базовой хэш-функции, а k — размер модуля RSA у получателя (в октетах).

В предположении невозможности расчёта e-х корней по модулю n и наличия соответствующих свойств функции генерации маски RSAES-OAEP, схема RSAES-OAEP семантически защищена от адаптивных атак по выбранному шифротексту. Это можно доказать в том смысле, что сложность взлома RSAES-OAEP напрямую связана со сложностью обращения функции RSA при условии, что функция генерации маски является «чёрным ящиком» или случайным оракулом. Дополнительные сведения приведены в [FOPS] и примечании ниже.

Операции шифрования и расшифровки в RSAES-OAEP принимают на входе метку L. В этой версии PKCS #1 меткой L служит пустая строка, а иные варианты применения метки выходят за рамки документа. Соответствующий синтаксис ASN.1 представлен в Приложении A.2.1.

Параметрами RSAES-OAEP являются функции хэширования и генерации маски. Выбор следует делать фиксированным для данного ключа RSA. Рекомендуемые функции указаны в Приложении B.

Примечание. Прошлые результаты помогли прояснить свойства безопасности метода кодирования OAEP [OAEP] (примерно такая процедура описана в п. 2 параграфа 7.1.1). Предыстория этого описана далее. В 1994 г. Bellare и Rogaway [OAEP] представили концепцию безопасности, которую они обозначили как осведомлённость об открытых данных (plaintext awareness, PA94). Они показали, что если детерминированный примитив шифрования с открытым ключом (например, RSAEP) трудно обратить без секретного ключа, соответствующая схема шифрования на основе OAEP будет осведомлена об открытых данных (в модели со случайным оракулом), что, грубо говоря, означает, что злоумышленник не сможет создать действительный шифротекст, «не зная» исходных открытых данных. Знание схемой шифрования открытых данных тесно связано со стойкостью схемы к атакам с выбранным шифротекстом, где злоумышленник может отправлять запросы оракулу для имитации примитива расшифровки. Используя результаты этих запросов злоумышленник пытается расшифровать шифротекст.

Существует два вида атак по выбранному шифротексту и PA94 подразумевает защиту лишь от одного из них. Различие заключается в том, что может делать атакующий после получения шифротекста. Сценарий индифферентной атаки (обозначается CCA1) не допускает запросов к оракулу расшифровки после получения злоумышленником шифротекста, а при адаптивной атаке (CCA2) это возможно (за исключением того, что оракул расшифровки отказывается расшифровывать данные после публикации). В 1998 г. Bellare и Rogaway вместе с Desai и Pointcheval [PA98] предложили новое, более строгое толкование знания открытых данных (plaintext awareness, PA98), предполагающее защиту от атак CCA2.

Подводя итог, можно сказать, что имеется два возможных источника ошибочного представления — признание понятий PA94 и PA98 эквивалентными и признание эквивалентными атак CCA1 и CCA2. Оба эти допущения ведут к заключению о том, что статья Bellare и Rogaway предполагает защиту OAEP от атак CCA2, однако это не так.

Примечание. Было бы справедливо упомянуть, что в PKCS #1 v2.0 цитируется [OAEP] и утверждается, что «атака по выбранному шифротексту неэффективна против схемы шифрования с осведомлённостью от открытых данных, такой как RSAES-OAEP» без уточнения о каком типе осведомлённости и какой атаке по выбранному шифротексту идёт речь.

Для OAEP не была доказана защищенность против CCA2 и Виктор Шоуп (Victor Shoup) [SHOUP] продемонстрировал, что в общем случае такого доказательства не существует. Шоуп показал, что в сценарии CCA2 злоумышленник, знающий, как частично обратить примитив шифрования, и не знает, как сделать это полностью, вполне способен нарушить работу схемы. Например, можно представить атакующего, способного взломать RSAES-OAEP, если он знает, как восстановить всё, кроме первых 20 байтов случайного значения, зашифрованного с помощью RSAEP. Такому злоумышленнику не требуется полное обращение RSAEP, поскольку в атаке первые 20 октетов не используются.

Тем не менее, RSAES-OAEP защищён от CCA2, что было показано Фудзисаки (Fujisaki), Окамото (Okamoto), Пойнтчевалом (Pointcheval) и Штерном (Stern) [FOPS] вскоре после анонсирования результата Шоупа. Используя хитрые методы сокращения решётки, авторы показали, как полностью обратить RSAEP, зная достаточно большую часть прообраза. Это наблюдение в сочетании с доказательством защищенности OAEP от CCA2 при условии сложности частичного обращения примитива шифрования, заполняет пробел между доказательством Bellare и Rogaway для RSAES-OAEP и тем, что некоторые считали доказанным. Парадоксально, но кажущаяся слабость RSAEP (т. е. возможность полного обращения на основе частичных) спасает.

К сожалению снижение уровня безопасности не является эффективным для конкретных параметров. Хотя доказательство успешно связывает злоумышленника A, применяющего CCA2 против RSAES-OAEP, с алгоритмом I для обращения RSA, вероятность успеха I составляет приблизительно \epsilon^2 / 2^18, где \epsilon — вероятность успеха A.

Примечание. В [FOPS] вероятность успеха обращения составляет \epsilon^2 / 4. Дополнительный коэффициент 1 / 2^16 обусловлен наличием 8 фиксированных нулевых битов в начале кодированного сообщения EM, которых нет в варианте OAEP, рассмотренном в [FOPS] (для обращения RSA алгоритм A должен применяться дважды и каждое применение вносит коэффициент 1 / 2^8).

Кроме того, время работы алгоритма I составляет приблизительно t^2, где t — время работы атакующего. Поэтому нельзя исключать возможность того, что взлом RSAES-OAEP будет значительно проще обращения RSA с конкретными параметрами. Тем не менее, доказательство обеспечивает некоторую уверенность в том, что конструкция RSAES-OAEP надёжней специализированных конструкций, таких как RSAES-PKCS1-v1_5.

Гибридные схемы шифрования на основе механизма инкапсуляции ключей (RSA Key Encapsulation Mechanism или RSA-KEM) предлагают строгие доказательства безопасности, применимые напрямую для конкретных параметров (см. [ISO18033]). Будущие версии PKCS #1 могут задавать схемы, основанные на этой парадигме.

7.1.1. Шифрование

RSAES-OAEP-ENCRYPT ((n, e), M, L)

Опции

Hash

хэш-функция (hLen — число октетов на выходе функции)

MGF

функция генерации маски

Вход

(n, e)

открытый ключ RSA у получателя (k — размер модуля n в октетах)

шифруемое сообщение в форме строки октетов размером mLen, где mLen <= k — 2hLen — 2

необязательная метка, связанная с сообщением, по умолчанию при отсутствии L применяется пустая строка

Выход

шифротекст в форме строки октетов размером k

Ошибки: message too long, label too long

Допущение: открытый ключ RSA (n, e) является действительным

Этапы

Проверка размера:
1. если размер L превышает входное ограничение хэш-функции (2^61 — 1 октет для SHA-1), вывод сообщения «label too long» и остановка;
2. если mLen > k — 2hLen — 2, вывод сообщения «message too long» и остановка.
Кодирование EME-OAEP (рисунок 1):
1. ```
                    +----------+------+--+-------+
               DB = |  lHash   |  PS  |01|   M   |
                    +----------+------+--+-------+
                                   |
         +----------+              |
         |   seed   |              |
         +----------+              |
               |                   |
               |-------> MGF ---> xor
               |                   |
      +--+     V                   |
      |00|    xor <----- MGF <-----|
      +--+     |                   |
        |      |                   |
        V      V                   V
      +--+----------+----------------------------+
EM =  |00|maskedSeed|          maskedDB          |
      +--+----------+----------------------------+
```
  Рисунок 1. Операция кодирования EME-OAEP.
  
  при отсутствии метки применяется пустая строка; принимается lHash = Hash(L) — строка октетов длиной hLen (см. примечание ниже);
2. создаётся строка дополнения PS из k — mLen — 2hLen — 2 нулевых октетов (строка PS может быть пустой);
3. выполняется конкатенация lHash, PS, октета 0x01 и сообщения M для формирования блока данных DB размером k — hLen — 1 октетов
```
    DB = lHash || PS || 0x01 || M
```
1. создаётся строка случайных октетов seed размером hLen;
2. устанавливается dbMask = MGF(seed, k — hLen — 1);
3. устанавливается maskedDB = DB \xor dbMask;
4. устанавливается seedMask = MGF(maskedDB, hLen);
5. устанавливается maskedSeed = seed \xor seedMask;
6. выполняется конкатенация октета 0x00, maskedSeed и maskedDB для формирования кодированного сообщения EM размером k октетов
```
    EM = 0x00 || maskedSeed || maskedDB
```
Шифрование RSA:
1. кодированное сообщение EM преобразуется в целочисленный представитель m (см. параграф 4.2)
```
    m = OS2IP (EM)
```
1. применяется примитив шифрования RSAEP (параграф 5.1.1) к открытому ключу RSA (n, e) и представителю сообщения m для создания целочисленного представителя шифротекста c
```
    c = RSAEP ((n, e), m)
```
1. представитель c преобразуется в шифротекст C размером k октетов (см. параграф 4.1)
```
    C = I2OSP (c, k)
```
Вывод шифротекста C.

Примечания.

lHash — хэш-значение необязательной метки L.
Операция декодирования выполняется обращением этапов для восстановления M и проверки lHash и PS.
При пустой строке L значение lHash будет шестнадцатеричным представлением функции Hash:

      SHA-1:   (0x)da39a3ee 5e6b4b0d 3255bfef 95601890 afd80709
      SHA-256: (0x)e3b0c442 98fc1c14 9afbf4c8 996fb924 27ae41e4 649b934c
                   a495991b 7852b855
      SHA-384: (0x)38b060a7 51ac9638 4cd9327e b1b1e36a 21fdb711 14be0743
                   4c0cc7bf 63f6e1da 274edebf e76f65fb d51ad2f1 4898b95b
      SHA-512: (0x)cf83e135 7eefb8bd f1542850 d66d8007 d620e405 0b5715dc
                   83f4a921 d36ce9ce 47d0d13c 5d85f2b0 ff8318d2 877eec2f
                   63b931bd 47417a81 a538327a f927da3e

7.1.2. Расшифровка

RSAES-OAEP-DECRYPT (K, C, L)

Опции

Hash

хэш-функция (hLen — число октетов на выходе функции)

MGF

функция генерации маски

Вход

секретный ключ RSA у получателя (k — число октетов модуля RSA n, где k >= 2hLen + 2)

шифротекст в форме строки октетов размером k

необязательная метка, связанная с сообщением, по умолчанию при отсутствии L применяется пустая строка

Выход

сообщение в форме строки октетов размером mLen, где mLen <= k — 2hLen — 2

Ошибка: decryption error

Этапы

Проверка размера:
1. если L превышает входное ограничение хэш-функции (2^61 — 1 октет для SHA-1), вывод сообщения «decryption error» и остановка;
2. если размер C отличается от k октетов, вывод сообщения «decryption error» и остановка;
3. если k < 2hLen + 2, вывод сообщения «decryption error» и остановка;
Расшифровка RSA:
1. преобразование шифротекста C в целочисленный представитель шифротекста c (см. параграф 4.2)
```
    c = OS2IP (C)
```
1. применение примитива расшифровки RSADP (параграф 5.1.2) к секретному ключу RSA K и представителю шифротекста c для создания целочисленного представителя сообщения m
```
    m = RSADP (K, c)
```
1. если RSADP выдаёт сообщение «ciphertext representative out of range» (означает, что c >= n), вывод сообщения «decryption error» и остановка;
2. преобразование представителя сообщения m в кодированное сообщение EM размером k октетов (см. параграф 4.1)
```
    EM = I2OSP (m, k)
```
Декодирование EME-OAEP:
1. при отсутствии метки применяется пустая строка; принимается lHash = Hash(L) — строка октетов длиной hLen (см. примечание в параграфе 7.1.1);
2. разделение кодированного сообщения EM на октет Y, строку октетов maskedSeed размером hLen и строку октетов maskedDB размером k — hLen — 1
```
    EM = Y || maskedSeed || maskedDB
```
1. устанавливается seedMask = MGF(maskedDB, hLen);
2. устанавливается seed = maskedSeed \xor seedMask;
3. устанавливается dbMask = MGF(seed, k — hLen — 1);
4. устанавливается DB = maskedDB \xor dbMask;
5. DB разделяется на строку октетов lHash’ размером hLen, (возможно пустую) строку дополнения PS из октетов 0x00 и сообщение M
```
        DB = lHash' || PS || 0x01 || M
```
1. при отсутствии октета 0x01 для отделения PS от M, отличии lHash от lHash’ или ненулевом значении Y вывод сообщения «decryption error» и остановка (см. примечание ниже).
Вывод сообщения M.

Примечание. Нужно позаботиться о том, чтобы противник не мог различать разные условия ошибки на этапе 3.g по сообщению или времени, а также (в более общем смысле) не мог получить частичные сведения о кодированном сообщении EM. Иначе противник сможет получить полезные сведения о расшифровке C, позволяющие организовать атаку с выбранным шифротекстом, подобную описанной Мэнгером (Manger) [MANGER].

7.2. RSAES-PKCS1-v1_5

RSAES-PKCS1-v1_5 объединяет примитивы RSAEP и RSADP (параграфы 5.1.1 и 5.1.2) с методом кодирования EME-PKCS1-v1_5 (п. 2 в параграфе 7.2.1 и п. 3 в параграфе 7.2.2). Это математический эквивалент схемы шифрования в PKCS #1 v1.5.

RSAES-PKCS1-v1_5 может работать с сообщениями размером до k-11 октетов (k — число октетов в модуле RSA), однако следует соблюдать осторожность, чтобы избежать некоторых атак на RSA с малым показателем степени, описанных Копперсмитом (Coppersmith), Франклином (Franklin), Патареном (Patarin) и Райтером (Reiter), при шифровании длинных сообщений (см. третье примечание ниже и [LOWEXP]; в [NEWATTACK] описана усовершенствованная атака). Как общее правило, не рекомендуется применять эту схему для шифрования произвольного сообщения, а не сгенерированного случайным образом ключа.

Можно создать действительные шифротексты RSAES-PKCS1-v1_5, не зная соответствующих открытых данных, с разумной вероятностью успеха, что может быть использовано для атаки по выбранному шифротексту, как описано в [BLEICHENBACHER]. Поэтому при использовании RSAES-PKCS1-v1_5 следует применять некоторые легко реализуемые меры противодействия таким атакам. Типовые примеры включают добавление структуры в кодируемые данные, тщательную проверку соответствия PKCS #1 v1.5 (и другой избыточности) в расшифрованных сообщениях, а также консолидацию сообщений об ошибках в протоколе клиент-сервер на основе PKCS #1 v1.5. Всё это может служить эффективным противодействием и не требует изменений в основанных на PKCS #1 v1.5 протоколах. Дальнейшее обсуждение и другие меры противодействия представлены в [BKS]. Недавно было показано, что безопасность протокола согласования SSL/TLS [RFC5246], использующего RSAES-PKCS1-v1_5 и некоторые меры противодействия, может быть связана с вариантом проблемы RSA, рассмотренной в [RSATLS].

Примечания. Ниже представлены некоторые рекомендации по безопасности при использовании RSAES-PKCS1-v1_5 из PKCS #1 v1.5, а также новые рекомендации, основанные на достижениях криптоанализа за прошедшие годы.

Рекомендуется генерировать случайные октеты в п. 2 (параграф 7.2.1) для каждого процесса шифрования независимо, особенно при вводе в разные процессы шифрования одних и тех же данных. Одним из мотивов этой рекомендации являются результаты Hastad [HASTAD].
Строке дополнения PS в п. 2 (параграф 7.2.1) следует иметь размер не менее 8 октетов при операциях с открытым ключом, что затруднит злоумышленнику восстановление данных путём перебора возможных блоков шифрования.
Псевдослучайные октеты могут помочь предотвратить атаки, описанные Копперсмитом и др. [LOWEXP] (см. усовершенствованную атаку в [NEWATTACK]), когда размер шифруемого сообщения остаётся небольшим. Атаки действенны для RSA с небольшим показателем степени, когда похожие сообщения шифруются с одним открытым ключом RSA. В одном варианте атаки, когда два ввода в RSAEP в значительной степени (8/9) совпадают и показатель степени RSA мал (e = 3) при шифровании обоих, атака позволяет восстановить оба набора входных данных. Другим вариантом атаки является расшифровка шифротекста, когда большая часть (2/3) входных данных RSAEP уже известна. В типовых приложениях шифруются короткие сообщения (например, 128-битовые симметричные ключи), поэтому для проведения атаки не будет достаточно информации из двух сообщений. Однако при шифровании длинного сообщения или знании части сообщения атака может вызывать опасения. В любом случае, схема RSAES-OAEP может противостоять атакам.

7.2.1. Шифрование

RSAES-PKCS1-V1_5-ENCRYPT ((n, e), M)

Вход

(n, e)

открытый ключ RSA у получателя (k — размер модуля n в октетах)

шифруемое сообщение в форме строки октетов размером mLen, где mLen <= k — 2hLen — 2

Выход

шифротекст в форме строки октетов размером k

Ошибка: message too long

Этапы

Проверка размера. Если mLen > k — 11, вывод ошибки «message too long» и остановка.
Кодирование EME-PKCS1-v1_5:
1. создание строки псевдослучайных октетов PS размером k — mLen — 3 (не менее 8 октетов);
2. конкатенация PS, сообщения M и другого дополнения для создания кодированного сообщения EM размером k октетов
```
    EM = 0x00 || 0x02 || PS || 0x00 || M
```
Шифрование RSA:
1. преобразование кодированного сообщения EM в целочисленный представитель m (см. параграф 4.2)
```
    m = OS2IP (EM)
```
1. применение примитива шифрования RSAEP (параграф 5.1.1) к открытому ключу RSA (n, e) и представителю сообщения m для создания представителя шифротекста c
```
    c = RSAEP ((n, e), m)
```
1. преобразование представителя шифротекста c в шифротекст C размером k октетов (см. параграф 4.1)
```
    C = I2OSP (c, k)
```
Вывод шифротекста C.

7.2.2. Расшифровка

RSAES-PKCS1-V1_5-DECRYPT (K, C)

Вход

секретный ключ RSA у получателя

шифротекст в форме строки октетов размером k, где k — число октетов модуля RSA n

Выход

сообщение в форме строки октетов размером mLen, где mLen <= k — 2hLen — 2

Ошибка: decryption error

Этапы

Проверка размера. Если размер шифротекста C не равен k октетов (или k < 11), вывод ошибки «decryption error» и остановка.
Расшифровка RSA:
1. преобразование шифротекста C в целочисленный представитель c (см. параграф 4.2)
```
    c = OS2IP (C)
```
1. применение примитива расшифровки RSADP (параграф 5.1.2) к секретному ключу RSA (n, d) и представителю шифротекста c для создания представителя сообщения m
```
    m = RSADP ((n, d), c)
```
1. если RSADP даёт на выходе сообщение «ciphertext representative out of range» (т. е. c >= n), вывод ошибки «decryption error» и остановка;
2. преобразование представителя сообщения m в кодированное сообщение EM размером k октетов (см. параграф 4.1)
```
    EM = I2OSP (m, k)
```
Декодирование EME-PKCS1-v1_5. Выделение из кодированного сообщения EM строки заполнения PS (ненулевые октеты) и сообщения M
```
    EM = 0x00 || 0x02 || PS || 0x00 || M
```
Если первый октет EM отличается от 0x00, второй отличается от 0x02, нет октета 0x00, отделяющего PS от M, или размер PS меньше 8 октетов, вывод ошибки «decryption error» и остановка (см. примечание ниже).
Output M.

Примечание. Нужно позаботиться о том, чтобы противник не мог различать разные условия ошибки на этапе 3 по сообщению или времени, а также (в более общем смысле) не мог получить частичные сведения о кодированном сообщении EM. Иначе противник сможет получить полезные сведения о расшифровке C, позволяющие организовать усиленную атаку Bleichenbacher [BLEICHENBACHER] (сравн. с атакой Мэнгера [MANGER]).

8. Схема подписи с приложением

В этом документе схема подписи с приложением (appendix) включает операции создания и проверки подписи, при этом операция генерации использует секретный ключ RSA подписывающей стороны, а операция проверки — соответствующий открытый ключ RSA подписавшего. Для проверки подписи, созданной с этим типом схемы требуется наличие самого сообщения. В результате схемы подписи с приложением отличаются от схем с восстановлением сообщения, которые в этом документе не поддерживаются.

Схема подписи с приложением может быть реализована в разных вариантах. Например, заданная здесь схема подписи с приложением подойдёт в качестве алгоритма подписи для сертификатов X.509 [ISO9594]. Похожие схемы подписи пригодны для PKCS #7 [RFC2315], хотя по техническим причинам текущая версия PKCS #7 отделяет хэш-функцию от схемы подписи, что отличается от принятого здесь (дополнительная информация приведена в Приложении A.2.3).

Этот документ задаёт две схемы подписи с приложением — RSASSA-PSS и RSASSA-PKCS1-v1_5. Хотя атаки на RSASSA-PKCS1-v1_5 неизвестны, для повышения отказоустойчивости в новых приложений требуется использовать RSASSA-PSS. Схема RSASSA-PKCS1-v1_5 включена лишь для совместимости с имеющимися реализациями.

Приведённые здесь схемы подписи с приложением следуют общей модели, похожей на принятую в IEEE 1363 [IEEE1363], сочетая примитивы подписи и проверки с методом кодирования подписей. Операции создания подписей применяют кодирование сообщения, которое затем преобразуется в целочисленный представитель сообщения. К представителю сообщения применяется примитив подписи, создающий подпись. При операции проверки подписи сначала применяется примитив проверки для восстановления представителя сообщения, который преобразуется в строку октетов кодированного сообщения. Операция проверки применяется к сообщению и кодированному сообщению для определения их соответствия друг другу.

Если метод кодирования является детерминированным (например, EMSA-PKCS1-v1_5), операция проверки может применить к сообщению операцию кодирования и сравнить полученный результат с ранее выведенным кодированным сообщением. При совпадении подпись считается корректной. Если метод кодирования использует случайность (например, EMSA-PSS), операция проверки усложняется. Например, операция проверки в EMSA-PSS извлекает случайную затравку (salt) и вывод хэш-функции из кодированного сообщения и проверяет из согласованность с сообщением. Вывод хэш-функции является детерминированным для сообщения и затравки. В обеих схемах подписи с приложением, заданных в этом документе, операции создания и проверки легко реализуются «в один проход», если подпись размещается после сообщения. Пример формата для случая RSASSA-PKCS1-v1_5 представлен в PKCS #7 [RFC2315].

8.1. RSASSA-PSS

RSASSA-PSS сочетает примитивы RSASP1 и RSAVP1 с методом кодирования EMSA-PSS. Это совместимо со схемой цифровой подписи с целочисленной факторизацией с приложением (Integer Factorization Signature Scheme with Appendix или IFSSA) с поправками IEEE 1363a [IEEE1363A], где примитивами подписи и проверки являются IFSP-RSA1 и IFVP-RSA1 из IEEE 1363 [IEEE1363], а методом кодирования — EMSA4. Метод EMSA4 является более общим, чем EMSA-PSS, поскольку он работает с битовыми строками, а не со строками октетов. EMSA-PSS эквивалентен EMSA4, но ограничен случаем, когда операнды, хэш-значения и затравки являются строками октетов.

Размер сообщений, с которыми может работать RSASSA-PSS не ограничен или ограничивается очень большим числом, зависящим от хэш-функции, используемой при кодировании EMSA-PSS.

В предположении, что расчёт e-х корней по модулю n не выполним, а функции создания хэш-значения и маски в EMSA-PSS обладают соответствующими свойствами, RSASSA-PSS обеспечивает безопасные подписи. Эти гарантии можно доказать в том смысле, что сложность подделки подписи может быть напрямую связана со сложностью обращения функции RSA при условии, что функции хэширования и создания маски рассматриваются как «чёрные ящики» или случайные оракулы. Границы в доказательстве безопасности по существу являются «жёсткими», а это означает, что вероятность успеха и время выполнения для лучшего алгоритма подделки RSASSA-PSS очень близки к соответствующим параметрам лучшего алгоритма обращения RSA (см. [RSARABIN] [PSSPROOF] [JONSSON]).

В отличие от схемы подписи RSASSA-PKCS1-v1_5, идентификатор хэш-функции не встраивается в кодированное сообщение EMSA-PSS и теоретически злоумышленник может подменить хэш-функцию, выбранную подписавшим (возможно, на более слабую). Поэтому рекомендуется создавать маску в EMSA-PSS с помощью той же хэш-функции. В результате закодированное сообщение целиком будет зависеть от одной хэш-функции и злоумышленнику будет сложно подменить её. Использование одной хэш-функции предназначено лишь для предотвращения её подмены и не требуется, если подмена определяется другим способом (например, проверяющий воспринимает лишь назначенную функцию). Более подробно это рассмотрено в [HASHID]. Доказуемая безопасность RSASSA-PSS не полагается на использование одной хэш-функции для сообщения и генерации маски.

RSASSA-PSS отличается от других схем подписи на основе RSA тем, что она скорей вероятностная, чем детерминированная, и включает случайно созданное значение затравки (salt). Затравка повышает уровень безопасности схемы, обеспечивая более «жёсткое» доказательство безопасности, нежели детерминированные варианты, такие как полное хэширование домена (Full Domain Hashing или FDH) (см. [RSARABIN]). Однако случайность не критична для безопасности и в ситуациях, когда генерация случайного значения невозможна, вместо этого можно использовать фиксированное значение или порядковый номер, что обеспечивает доказуемую безопасность, аналогичную FDH [FDH].

8.1.1. Создание подписи

RSASSA-PSS-SIGN (K, M)

Вход

секретный ключ RSA у подписывающего

подписываемое сообщение в форме строки октетов

Выход

подпись к виде строки октетов размером k, где k — число октетов модуля RSA n

Ошибки: message too long, encoding error

Этапы

Кодирование EMSA-PSS (параграф 9.1.1) для сообщения M, дающее на выходе кодированное сообщение EM размером \ceil ((modBits — 1)/8) октетов, таким, что число битов OS2IP (EM) (см. параграф 4.2) не превышает modBits — 1, где modBits — число битов в модуле RSA n
```
EM = EMSA-PSS-ENCODE (M, modBits - 1)
```
Отметим, что число октетов в EM на 1 меньше k, если modBits — 1 кратно 8 и совпадает с k в ином случае. Если операция кодирования возвращает «message too long» или «encoding error», выводится соответствующая ошибка («message too long» или «encoding error») и работа останавливается.
Подпись RSA:
1. преобразование кодированного сообщения EM в числовой представитель сообщения m (см. параграф 4.2)
```
    m = OS2IP (EM)
```
1. применение примитива подписи RSASP1 (параграф 5.2.1) к секретному ключу RSA K и представителю сообщения m для создания цифрового представителя подписи s
```
    s = RSASP1 (K, m)
```
1. преобразование представителя подписи s в подпись S размером k октетов (см. параграф 4.1)
```
    S = I2OSP (s, k)
```
Вывод подписи S.

8.1.2. Проверка подписи

RSASSA-PSS-VERIFY ((n, e), M, S)

Вход

(n, e)

открытый ключ RSA у получателя

сообщение, для которого проверяется подпись, в форме строки октетов

проверяемая подпись размером k октетов (k — число октетов в модуле RSA n)

Выход «valid signature» или «invalid signature»

Этапы

Проверка размера. Если размер подписи S в октетах не равен k, вывод «invalid signature» и остановка.
Проверка RSA:
1. преобразование подписи S в цифровой представитель s (см. параграф 4.2)
```
    s = OS2IP (S)
```
1. применение примитива проверки RSAVP1 (параграф 5.2.2) к открытому ключу RSA (n, e) и представителю подписи s для создания цифрового представителя сообщения m
```
      m = RSAVP1 ((n, e), s)
```
1. если RSAVP1 даёт на выходе «signature representative out of range», вывод «invalid signature» и остановка;
2. преобразование представителя сообщения m в кодированное сообщение EM размером emLen = \ceil ((modBits — 1)/8) октетов, где modBits — число битов модуля RSA n (см. параграф 4.1)
```
    EM = I2OSP (m, emLen)
```
1. отметим, что emLen будет на 1 меньше k, если modBits — 1 кратно 8 и равно k в ином случае; если I2OSP выдаёт «integer too large», вывод ошибки «invalid signature» и остановка.
Применение операции проверки EMSA-PSS (параграф 9.1.2) к сообщению M и кодированному сообщению EM для определения их соответствия
```
    Result = EMSA-PSS-VERIFY (M, EM, modBits - 1)
```
Если Result = consistent, вывод «valid signature», иначе — «invalid signature».

8.2. RSASSA-PKCS1-v1_5

В RSASSA-PKCS1-v1_5 используется сочетание примитивов RSASP1 и RSAVP1 с кодированием EMSA-PKCS1-v1_5. Метод совместим со схемой IFSSA из IEEE 1363 [IEEE1363], где примитивами подписи и проверки являются IFSP-RSA1 и IFVP-RSA1, а методом кодирования — EMSA-PKCS1-v1_5 (не задан в IEEE 1363, но есть в IEEE 1363a [IEEE1363A]).

Размер сообщений, с которыми может работать RSASSA-PKCS1-v1_5, не ограничен или ограничивается очень большим числом в зависимости от базового метода EMSA-PKCS1-v1_5.

В предположении, что расчёт e-х корней по модулю n не выполним, а функции создания хэш-значения и маски в EMSA-PKCS1-v1_5 обладают соответствующими свойствами, RSASSA-PKCS1-v1_5 обеспечивает безопасные подписи. Точнее говоря, предполагается, что подделка подписей невозможна без знания секретного ключа RSA. В кодирование EMSA-PKCS1-v1_5 включён идентификатор хэш-функции, поэтому злоумышленнику, пытающемуся найти сообщение с такой же подписью, как у подписанного ранее сообщения, потребуется найти коллизию в используемой хэш-функции. Применение атакующим другой хэш-функции не принесёт пользы. Дополнительные сведения приведены в [HASHID].

Примечание. Как отмечено в PKCS #1 v1.5, метод кодирования EMSA-PKCS1-v1_5 обладает таким свойством, что кодированное сообщение, преобразованное в числовой представитель, гарантированно будет большим и (по меньшей мере) в некоторой степени «случайным». Это предотвращает атаки, подобные описанным Десмедтом (Desmedt) и Одлизко (Odlyzko) [CHOSEN], когда между представителями сообщений создаются мультипликативные взаимосвязи, путём разложения представителей в набор небольших сомножителей (например, простых чисел). Coron, Naccache и Stern в работе [PADDING] показали, что более сильная форма такой атаки может быть достаточно эффективной против некоторых экземпляров схемы подписи ISO/IEC 9796-2. Они также проанализировали сложность этого типа атак на метод кодирования EMSA-PKCS1-v1_5 и пришли к выводу о непрактичности атак из-за того, что они требуют большего числа операций, нежели обращение хэш-функции (т. е. более 2^80 операций). Coppersmith, Halevi и Jutla в работе [FORGERY] развили атаку Coron и др. для взлома схемы подписи ISO/IEC 9796-1 с восстановлением сообщения. Различные атаки показывают важность тщательного подбора входных данных для примитива подписи RSA, особенно в схеме подписи с восстановлением сообщения. Поэтому метод кодирования EMSA-PKCS-v1_5 явно включает операцию хэширования и не предназначен для схем подписи с восстановлением сообщения. Более того, хотя ничего не известно об атаках на метод кодирования EMSA-PKCS-v1_5, рекомендуется постепенно переходить на метод EMSA-PSS в качестве меры предосторожности на случай будущих атак.

8.2.1. Создание подписи

RSASSA-PKCS1-V1_5-SIGN (K, M)

Вход

секретный ключ RSA у подписывающего

подписываемое сообщение в форме строки октетов

Выход

подпись размером k октетов (k — число октетов в модуле RSA n)

Ошибки: message too long, RSA modulus too short

Этапы

Применение операции EMSA-PKCS1-v1_5 (параграф 9.2) к сообщению M для создания кодированного сообщения EM размером k октетов
```
EM = EMSA-PKCS1-V1_5-ENCODE (M, k)
```
Если операция кодирования выдаёт «message too long», выводится ошибка «message too long» и работа останавливается. Если операция кодирования выдаёт «intended encoded message length too short», выводится ошибка «RSA modulus too short» и работа останавливается.
Подпись RSA:
1. преобразование кодированного сообщения EM в числовой представитель сообщения m (см. параграф 4.2)
```
    m = OS2IP (EM)
```
1. применение примитива подписи RSASP1 (параграф 5.2.1) к секретному ключу RSA K и представителю сообщения m для создания цифрового представителя подписи s
```
    s = RSASP1 (K, m)
```
1. преобразование представителя подписи s в подпись S размером k октетов (см. параграф 4.1)
```
    S = I2OSP (s, k)
```
Вывод подписи S.

8.2.2. Проверка подписи

RSASSA-PKCS1-V1_5-VERIFY ((n, e), M, S)

Вход

(n, e)

открытый ключ RSA у получателя

сообщение, для которого проверяется подпись, в форме строки октетов

проверяемая подпись размером k октетов (k — число октетов в модуле RSA n)

Вывод «valid signature» или «invalid signature»

Ошибки: message too long, RSA modulus too short

Этапы

Проверка размера. Если размер подписи S в октетах не равен k, вывод «invalid signature» и остановка.
Проверка RSA:
1. преобразование подписи S в цифровой представитель s (см. параграф 4.2)
```
    s = OS2IP (S)
```
1. применение примитива проверки RSAVP1 (параграф 5.2.2) к открытому ключу RSA (n, e) и представителю подписи s для создания цифрового представителя сообщения m
```
      m = RSAVP1 ((n, e), s)
```
1. если RSAVP1 даёт на выходе «signature representative out of range», вывод «invalid signature» и остановка.
2. преобразование представителя сообщения m в кодированное сообщение EM размером k октетов k (см. параграф 4.1)
```
    EM = I2OSP (m, k)
```
1. если I2OSP выдаёт «integer too large», вывод ошибки «invalid signature» и остановка.
Применение операции EMSA-PKCS1-v1_5 ( параграф 9.2) к сообщению M для создания второго кодированного сообщения EM’ размером k октетов
```
    EM' = EMSA-PKCS1-V1_5-ENCODE (M, k).
```
Если операция кодирования выдаёт «message too long», выводится ошибка «message too long» и работа останавливается. Если операция кодирования выдаёт «intended encoded message length too short», выводится ошибка «RSA modulus too short» и работа останавливается.
Сравнение кодированных сообщений EM и EM’. При совпадении вывод «valid signature», иначе — «invalid signature».

Примечание. Другим вариантом проверки подписи является применение операции «декодирования» сообщения (не задана здесь) для восстановления базового хэш-значения и сравнения с заново рассчитанным. Это занимает меньше места в хранилище (хэш-значения меньше сообщений), но требует дополнительного кода.

9. Методы кодирования для подписей с приложением

Методы кодирования состоят из операций, преобразующих строку октетов сообщения в строку октетов кодированного сообщения, которая преобразуется в схеме в целочисленный представитель сообщения. Представитель сообщения обрабатывается примитивами. Таким образом, методы кодирования связывают обрабатывающие сообщения схемы с примитивами.

В этом документе метод кодирования для подписей с приложением состоит из операции кодирования и может сопровождаться операцией проверки. Операция кодирования преобразует сообщение M в кодированное сообщение EM заданного размера. Операция проверки определяет согласованность сообщений M и EM, т. е. проверяет, является ли EM действительно кодированием сообщения M.

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

Документ задаёт для подписей с приложением два метода кодирования — EMSA-PSS и EMSA-PKCS1-v1_5.

9.1. EMSA-PSS

В качестве параметров методу кодирования передаются функции хэширования и создания маски, а также размер затравки (salt). Этим параметрам следует быть фиксированными для данного ключа RSA, за исключением возможности менять размер затравки (см. [JONSSON]). Предлагаемые функции хэширования и создания маски приведены в Приложении B. Метод кодирования основан вероятностной схеме подписи (Probabilistic Signature Scheme или PSS) Беллара и Рогуэя [RSARABIN][PSS]. Метод содержит случайность и включает операции кодирования и проверки. Операция кодирования показана на рисунке 2.

                         +-----------+
                         |     M     |
                         +-----------+
                               |
                               V
                             Hash
                               |
                               V
                 +--------+----------+----------+
            M' = |Padding1|  mHash   |   salt   |
                 +--------+----------+----------+
                                |
      +--------+----------+     V
DB =  |Padding2|   salt   |   Hash
      +--------+----------+     |
                |               |
                V               |
               xor <--- MGF <---|
                |               |
                |               |
                V               V
      +-------------------+----------+--+
EM =  |    maskedDB       |     H    |bc|
      +-------------------+----------+--+

Рисунок 2. Операция кодирования EMSA-PSS.

Проверка выполняется в обратном порядке для восстановления затравки с последующим расчётом и сравнением H.

Примечания.

Заданный здесь метод отличается от представленного Белларом и Рогуэем в IEEE 1363a [PSS] в 3 аспектах.

- К сообщению применяется хэш-функция, а не функция генерации маски. Несмотря на создание маски с помощью хэш-функции, представляется более естественным прямое хэширование.
- Значением, хэшируемым вместе с затравкой (salt), является строка (0x)00 00 00 00 00 00 00 00 || mHash, а не само сообщения M. Здесь mHash — это хэш сообщения M. Отметим, что на обоих этапах применяется одна хэш-функция (см. примечание 3). Использование термина salt вместо seed точнее отражает роль.
- Кодированное сообщение в EMSA-PSS имеет 9 фиксированных битов — первый бит 0 и последние восемь битов, образующие «трейлер» в форме октета 0xbc. В исходной схеме фиксированным был только первый бит. Трейлер добавлен для совместимости с примитивом подписи с целочисленной факторизацией (Integer Factorization Signature Primitive using Rabin-Williams или IFSP-RW) в IEEE 1363 [IEEE1363] и соответствующим примитивом ISO/IEC 9796-2:2010 [ISO9796].

Предполагается, что функция генерации маски основана на хэшировании, и рекомендуется использовать ту же хэш-функцию, которая применяется для сообщения (см. параграф 8.1).
Без ущерба для доказательства безопасности RSASSA-PSS можно реализовать этапы 1 и 2 в EMSA-PSS-ENCODE и EMSA-PSS-VERIFY (применение хэш-функции к сообщению) вне модуля, выполняющего остальную часть операции подписи, и подавать на вход модуля mHash вместо M. Иными словами, доказательство безопасности RSASSA-PSS сохраняет силу, даже если противник сможет контролировать значение mHash. Это удобно, если модуль имеет ограниченную пропускную способность ввода-вывода (например, смарт-карта). Отметим, что у предыдущей версии PSS [RSARABIN][PSS] такого свойства не было. По иным соображениям безопасности может всё-таки оказаться желательной обработка модулем всего сообщения. Например, модулю может потребоваться «видеть», что он подписывает, если у него нет доверия к компоненту хэширования.
Типичными размерами salt в октетах являются hLen (размер вывода функции Hash) и 0. В обоих случаях безопасность RSASSA-PSS тесно связана со сложностью обращения RSAVP1. Белларе и Рогуэй [RSARABIN] приводят жёсткую нижнюю границу безопасности исходной схемы RSA-PSS, которая примерно соответствует первому случаю, а Корон (Coron) [FDH] даёт нижнюю границу для связанной схемы FDH, которая примерно соответствует второму случаю. В работе [PSSPROOF] Корон приводит базовый подход с размерами salt от 0 до hLen (см. обсуждение в [IEEE1363A]). В работе [JONSSON] адаптированы доказательства безопасности из [RSARABIN] [PSSPROOF] для решения вопроса различий между исходной и представленной здесь (см. п. 1) версией RSA-PSS.
Как отмечено в стандарте IEEE 1363a [IEEE1363A], использование случайности в схемах подписи (как salt в EMSA-PSS) может приводить к возникновению скрытого канала передачи сведений сверх подписываемого сообщения. Дополнительное рассмотрение побочных каналов представлено в [SIMMONS].

9.1.1. Кодирование

EMSA-PSS-ENCODE (M, emBits)

Опции

Hash

хэш-функция (hLen — число октетов на выходе функции)

MGF

функция генерации маски

sLen

предусмотренный размер затравки в октетах

Вход

кодируемое сообщение в форме строки октетов

emBits

максимальное количество битов в целом числе OS2IP (EM) (см. параграф 4.2), не менее 8hLen + 8sLen + 9

Выход

кодированное сообщение в форме строки октетов размером emLen = \ceil (emBits/8)

Ошибки: encoding error, message too long

Этапы

Если размер M превышает входное ограничение хэш-функции (2^61 — 1 октетов для SHA-1), вывод ошибки «message too long» и остановка.
Принимается mHash = Hash(M), строка октетов размером hLen.
Если emLen < hLen + sLen + 2, вывод сообщения «encoding error» и остановка.
Создаётся случайная строка октетов salt размером sLen, при sLen = 0 затравкой является пустая строка.
Принимается
```
M' = (0x)00 00 00 00 00 00 00 00 || mHash || salt;
```
M’ — строка октетов размером 8 + hLen + sLen с нулевыми значениями первых 8 октетов.
Принимается H = Hash(M’), строка октетов размером hLen.
Создаётся строка октетов PS из emLen — sLen — hLen — 2 нулевых октетов. Строка PS может иметь размер 0.
Принимается DB = PS || 0x01 || salt, где DB — строка октетов размером emLen — hLen — 1.
Принимается dbMask = MGF(H, emLen — hLen — 1).
Принимается maskedDB = DB \xor dbMask.
Устанавливается значение 0 для левых 8emLen — emBits битов в левом октете maskedDB.
Принимается EM = maskedDB || H || 0xbc.
Выводится EM.

9.1.2. Проверка

EMSA-PSS-VERIFY (M, EM, emBits)

Опции

Hash

хэш-функция (hLen — число октетов на выходе функции)

MGF

функция генерации маски

sLen

предусмотренный размер затравки в октетах

Вход

проверяемое сообщение в форме строки октетов

кодированное сообщение в форме строки октетов размером emLen = \ceil (emBits/8)

emBits

максимальное количество битов в целом числе OS2IP (EM) (см. параграф 4.2), не менее 8hLen + 8sLen + 9

Выход consistent или inconsistent

Этапы

Если размер M превышает входное ограничение хэш-функции (2^61 — 1 октетов для SHA-1), вывод строки «inconsistent» и остановка.
Принимается mHash = Hash(M), строка октетов размером hLen.
Если emLen < hLen + sLen + 2, вывод строки «inconsistent» и остановка.
Если правый октет EM отличается от 0xbc, вывод строки «inconsistent» и остановка.
В качестве maskedDB принимаются emLen — hLen — 1 октетов EM слева, а в качестве H — следующие hLen октетов.
Если 8emLen — emBits битов в левом октете maskedDB отличны от 0, вывод строки «inconsistent» и остановка.
Принимается dbMask = MGF(H, emLen — hLen — 1).
Принимается DB = maskedDB \xor dbMask.
Для левых 8emLen — emBits битов левого октета DB устанавливается значение 0.
Если emLen — hLen — sLen — 2 октетов DB слева отличны от 0 или значение в позиции emLen — hLen — sLen — 1 (позиция 1 слева) отлично от 0x01, вывод строки «inconsistent» и остановка.
В качестве salt принимаются sLen последних октетов DB.
Принимается
```
M' = (0x)00 00 00 00 00 00 00 00 || mHash || salt;
```
M’ — строка октетов размером 8 + hLen + sLen с нулевыми значениями первых 8 октетов
Принимается H’ = Hash(M’), строка октетов размером hLen.
Если H = H’, выводится строка «consistent», иначе выводится «inconsistent».

9.2. EMSA-PKCS1-v1_5

Этот метод является детерминированным и включает только операцию кодирования

EMSA-PKCS1-v1_5-ENCODE (M, emLen)

Опция

Hash

хэш-функция (hLen — число октетов на выходе функции)

Вход

кодируемое сообщение в форме строки октетов

emLen

предусмотренное число октетов кодированного сообщения, не менее tLen + 11, где tLen — число октетов в DER-представлении T для значения, рассчитываемого в операции кодирования

Выход

кодированное сообщение в форме строки октетов размером emLen

Ошибки: message too long, intended encoded message length too short.

Этапы

К сообщению M применяется хэш-функция для получения значения H = Hash(M). Если хэш-функция выдаёт «message too long», вывод ошибки «message too long» и остановка.
Кодирование идентификатора алгоритма для хэш-функции и хэш-значения в значение ASN.1 типа DigestInfo (см. Приложение A.2.4) с DER, где тип DigestInfo использует синтаксис
```
               DigestInfo ::= SEQUENCE {
                   digestAlgorithm AlgorithmIdentifier,
                   digest OCTET STRING
               }
```
Первое поле указывает хэш-функцию, второе содержит хэш-значение. Пусть T — DER-представление значения DigestInfo (см. примечания), а tLen — число октетов в T.
Если emLen < tLen + 11, вывод ошибки «intended encoded message length too short» и остановка.
Генерация строки октетов PS размером emLen — tLen — 3 (не менее 8) со значениями октетов 0xff.
Конкатенация PS, DER-представления T и другого заполнения для формирования кодированного сообщения EM
```
EM = 0x00 || 0x01 || PS || 0x00 || T
```
Вывод EM.

Примечания.

Для девяти хэш-функций, указанных в Приложении B.1 DER-представления T для значений DigestInfo приведены ниже.

MD2:     (0x)30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 02 05 00 04 10 || H
MD5:     (0x)30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 05 05 00 04 10 || H
SHA-1:   (0x)30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14 || H
SHA-224:  (0x)30 2d 30 0d 06 09 60 86 48 01 65 03 04 02 04 05 00 04 1c || H
SHA-256: (0x)30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 || H
SHA-384: (0x)30 41 30 0d 06 09 60 86 48 01 65 03 04 02 02 05 00 04 30 || H
SHA-512: (0x)30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40 || H
SHA-512-224:  (0x)30 2d 30 0d 06 09 60 86 48 01 65 03 04 02 05 05 00 04 1c || H
SHA-512-256:  (0x)30 31 30 0d 06 09 60 86 48 01 65 03 04 02 06 05 00 04 20 || H

В версии этого документа 1.5 в качестве T было выбрано BER-представление значения DigestInfo. Возможно (по крайней мере, в теории), что заданная этим документом (а также версией 2.0) операция проверки будет отвергать подписи, которые действительны по спецификации в PKCS #1 v1.5. Это возможно при использовании для DigestInfo отличных от DER правил (например, неопределённый размер представления базового типа SEQUENCE). Хотя на практике это вряд ли вызовет беспокойство, осторожные разработчики могут выбрать операцию проверки на основе BER-представления из PKCS #1 v1.5. Таким способом обеспечивается совместимость с корректными реализациями на основе PKCS #1 v1.5. Такой операции проверки следует указывать, является ли базовое BER-представление кодированием DER и будет ли подпись действительной в соответствии с этой спецификацией.

10. Вопросы безопасности

Этот документ целиком посвящён вопросам безопасности.

11. Литература

11.1. Нормативные документы

[GARNER] Garner, H., «The Residue Number System», IRE Transactions on Electronic Computers, Volume EC-8, Issue 2, pp. 140-147, DOI 10.1109/TEC.1959.5219515, June 1959.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RSA] Rivest, R., Shamir, A., and L. Adleman, «A Method for Obtaining Digital Signatures and Public-Key Cryptosystems», Communications of the ACM, Volume 21, Issue 2, pp. 120-126, DOI 10.1145/359340.359342, February 1978.

11.2. Дополнительная литература

[ANSIX944] ANSI, «Key Establishment Using Integer Factorization Cryptography», ANSI X9.44-2007, August 2007.

[BKS] Bleichenbacher, D., Kaliski, B., and J. Staddon, «Recent Results on PKCS #1: RSA Encryption Standard», RSA Laboratories, Bulletin No. 7, June 1998.

[BLEICHENBACHER] Bleichenbacher, D., «Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS #1», Lecture Notes in Computer Science, Volume 1462, pp. 1-12, 1998.

[CHOSEN] Desmedt, Y. and A. Odlyzko, «A Chosen Text Attack on the RSA Cryptosystem and Some Discrete Logarithm Schemes», Lecture Notes in Computer Science, Volume 218, pp. 516-522, 1985.

[COCHRAN] Cochran, M., «Notes on the Wang et al. 2^63 SHA-1 Differential Path», Cryptology ePrint Archive: Report 2007/474, August 2008, <http://eprint.iacr.org/2007/474>.

[FASTDEC] Quisquater, J. and C. Couvreur, «Fast Decipherment Algorithm for RSA Public-Key Cryptosystem», Electronic Letters, Volume 18, Issue 21, pp. 905-907, DOI 10.1049/el:19820617, October 1982.

[FDH] Coron, J., «On the Exact Security of Full Domain Hash», Lecture Notes in Computer Science, Volume 1880, pp. 229-235, 2000.

[FOPS] Fujisaki, E., Okamoto, T., Pointcheval, D., and J. Stern, «RSA-OAEP is Secure under the RSA Assumption», Lecture Notes in Computer Science, Volume 2139, pp. 260-274, August 2001.

[FORGERY] Coppersmith, D., Halevi, S., and C. Jutla, «ISO 9796-1 and the new forgery strategy», rump session of Crypto, August 1999.

[HASTAD] Hastad, J., «Solving Simultaneous Modular Equations of Low Degree», SIAM Journal on Computing, Volume 17, Issue 2, pp. 336-341, DOI 10.1137/0217019, April 1988.

[HANDBOOK] Menezes, A., van Oorschot, P., and S. Vanstone, «Handbook of Applied Cryptography», CRC Press, ISBN: 0849385237, 1996.

[HASHID] Kaliski, B., «On Hash Function Firewalls in Signature Schemes», Lecture Notes in Computer Science, Volume 2271, pp. 1-16, DOI 10.1007/3-540-45760-7_1, February 2002.

[IEEE1363] IEEE, «Standard Specifications for Public Key Cryptography», IEEE Std 1363-2000, DOI 10.1109/IEEESTD.2000.92292, August 2000, <http://ieeexplore.ieee.org/document/891000/>.

[IEEE1363A] IEEE, «Standard Specifications for Public Key Cryptography — Amendment 1: Additional Techniques», IEEE Std 1363a-2004, DOI 10.1109/IEEESTD.2004.94612, September 2004, <http://ieeexplore.ieee.org/document/1335427/>.

[ISO18033] International Organization for Standardization, «Information technology — Security techniques — Encryption algorithms — Part 2: Asymmetric ciphers», ISO/IEC 18033-2:2006, May 2006.

[ISO9594] International Organization for Standardization, «Information technology — Open Systems Interconnection — The Directory: Public-key and attribute certificate frameworks», ISO/IEC 9594-8:2008, December 2008.

[ISO9796] International Organization for Standardization, «Information technology — Security techniques — Digital signature schemes giving message recovery — Part 2: Integer factorization based mechanisms», ISO/IEC 9796-2:2010, December 2010.

[JONSSON] Jonsson, J., «Security Proofs for the RSA-PSS Signature Scheme and Its Variants», Cryptology ePrint Archive: Report 2001/053, March 2002, <http://eprint.iacr.org/2001/053>.

[LOWEXP] Coppersmith, D., Franklin, M., Patarin, J., and M. Reiter, «Low-Exponent RSA with Related Messages», Lecture Notes in Computer Science, Volume 1070, pp. 1-9, 1996.

[MANGER] Manger, J., «A Chosen Ciphertext Attack on RSA Optimal Asymmetric Encryption Padding (OAEP) as Standardized in PKCS #1 v2.0», Lecture Notes in Computer Science, Volume 2139, pp. 230-238, DOI 10.1007/3-540-44647-8_14, 2001.

[MD4] Dobbertin, H., «Cryptanalysis of MD4», Lecture Notes in Computer Science, Volume 1039, pp. 53-69, DOI 10.1007/3-540-60865-6_43, 1996.

[MD4FIRST] Dobbertin, H., «The First Two Rounds of MD4 are Not One-Way», Lecture Notes in Computer Science, Volume 1372, pp. 284-292, DOI 10.1007/3-540-69710-1_19, March 1998.

[MD4LAST] den Boer, B. and A. Bosselaers, «An Attack on the Last Two Rounds of MD4», Lecture Notes in Computer Science, Volume 576, pp. 194-203, DOI 10.1007/3-540-46766-1_14, 1992.

[NEWATTACK] Coron, J., Joye, M., Naccache, D., and P. Paillier, «New Attacks on PKCS #1 v1.5 Encryption», Lecture Notes in Computer Science, Volume 1807, pp. 369-381, DOI 10.1007/3-540-45539-6_25, May 2000.

[OAEP] Bellare, M. and P. Rogaway, «Optimal Asymmetric Encryption — How to Encrypt with RSA», Lecture Notes in Computer Science, Volume 950, pp. 92-111, November 1995.

[PA98] Bellare, M., Desai, A., Pointcheval, D., and P. Rogaway, «Relations Among Notions of Security for Public-Key Encryption Schemes», Lecture Notes in Computer Science, Volume 1462, pp. 26-45, DOI 10.1007/BFb0055718, 1998.

[PADDING] Coron, J., Naccache, D., and J. Stern, «On the Security of RSA Padding», Lecture Notes in Computer Science, Volume 1666, pp. 1-18, DOI 10.1007/3-540-48405-1_1, December 1999.

[PKCS1_22] RSA Laboratories, «PKCS #1: RSA Cryptography Standard Version 2.2», October 2012.

[PREFIX] Stevens, M., Lenstra, A., and B. de Weger, «Chosen-prefix collisions for MD5 and applications», International Journal of Applied Cryptography, Volume 2, No. 4, pp. 322-359, July 2012.

[PSS] Bellare, M. and P. Rogaway, «PSS: Provably Secure Encoding Method for Digital Signatures», Submission to IEEE P1363a, August 1998, <http://grouper.ieee.org/groups/1363/P1363a/contributions/pss-submission.pdf>.

[PSSPROOF] Coron, J., «Optimal Security Proofs for PSS and Other Signature Schemes», Lecture Notes in Computer Science, Volume 2332, pp. 272-287, DOI 10.1007/3-540-46035-7_18, 2002.

[RFC1319] Kaliski, B., «The MD2 Message-Digest Algorithm», RFC 1319, DOI 10.17487/RFC1319, April 1992, <http://www.rfc-editor.org/info/rfc1319>.

[RFC1321] Rivest, R., «The MD5 Message-Digest Algorithm», RFC 1321, DOI 10.17487/RFC1321, April 1992, <http://www.rfc-editor.org/info/rfc1321>.

[RFC2313] Kaliski, B., «PKCS #1: RSA Encryption Version 1.5», RFC 2313, DOI 10.17487/RFC2313, March 1998, <http://www.rfc-editor.org/info/rfc2313>.

[RFC2315] Kaliski, B., «PKCS #7: Cryptographic Message Syntax Version 1.5», RFC 2315, DOI 10.17487/RFC2315, March 1998, <http://www.rfc-editor.org/info/rfc2315>.

[RFC2437] Kaliski, B. and J. Staddon, «PKCS #1: RSA Cryptography Specifications Version 2.0», RFC 2437, DOI 10.17487/RFC2437, October 1998, <http://www.rfc-editor.org/info/rfc2437>.

[RFC3447] Jonsson, J. and B. Kaliski, «Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1», RFC 3447, DOI 10.17487/RFC3447, February 2003, <http://www.rfc-editor.org/info/rfc3447>.

[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.

[RFC5652] Housley, R., «Cryptographic Message Syntax (CMS)», STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <http://www.rfc-editor.org/info/rfc5652>.

[RFC5958] Turner, S., «Asymmetric Key Packages», RFC 5958, DOI 10.17487/RFC5958, August 2010, <http://www.rfc-editor.org/info/rfc5958>.

[RFC6149] Turner, S. and L. Chen, «MD2 to Historic Status», RFC 6149, DOI 10.17487/RFC6149, March 2011, <http://www.rfc-editor.org/info/rfc6149>.

[RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., and M. Scott, «PKCS #12: Personal Information Exchange Syntax v1.1», RFC 7292, DOI 10.17487/RFC7292, July 2014, <http://www.rfc-editor.org/info/rfc7292>.

[RSARABIN] Bellare, M. and P. Rogaway, «The Exact Security of Digital Signatures — How to Sign with RSA and Rabin», Lecture Notes in Computer Science, Volume 1070, pp. 399-416, DOI 10.1007/3-540-68339-9_34, 1996.

[RSATLS] Jonsson, J. and B. Kaliski, «On the Security of RSA Encryption in TLS», Lecture Notes in Computer Science, Volume 2442, pp. 127-142, DOI 10.1007/3-540-45708-9_9, 2002.

[SHA1CRYPT] Wang, X., Yao, A., and F. Yao, «Cryptanalysis on SHA-1», Lecture Notes in Computer Science, Volume 2442, pp. 127-142, February 2005, <http://csrc.nist.gov/groups/ST/hash/documents/Wang_SHA1-New-Result.pdf>.

[SHOUP] Shoup, V., «OAEP Reconsidered (Extended Abstract)», Lecture Notes in Computer Science, Volume 2139, pp. 239-259, DOI 10.1007/3-540-44647-8_15, 2001.

[SHS] National Institute of Standards and Technology, «Secure Hash Standard (SHS)», FIPS PUB 180-4, August 2015, <http://dx.doi.org/10.6028/NIST.FIPS.180-4>.

[SILVERMAN] Silverman, R., «A Cost-Based Security Analysis of Symmetric and Asymmetric Key Lengths», RSA Laboratories, Bulletin No. 13, 2000.

[SIMMONS] Simmons, G., «Subliminal Communication is Easy Using the DSA», Lecture Notes in Computer Science, Volume 765, pp. 218-232, DOI 10.1007/3-540-48285-7_18, 1994.

Приложение A. Синтаксис ASN.1

A.1. Представление ключей RSA

В этом параграфе определены идентификаторы объектов ASN.1 для открытых и секретных ключей RSA, а также типы RSAPublicKey и RSAPrivateKey. Предусмотренное применение этих определений включает сертификаты X.509, PKCS #8 [RFC5958] и PKCS #12 [RFC7292].

Идентификатор объекта rsaEncryption указывает открытый и секретный ключ RSA, определённые в Приложениях A.1.1 и A.1.2. Полям параметров, связанным с этим OID в значении типа AlgorithmIdentifier нужно иметь тип NULL.

      rsaEncryption    OBJECT IDENTIFIER ::= { pkcs-1 1 }

Определения в этом параграфе расширены для поддержки многофакторного RSA, но совместимы с предыдущими версиями.

A.1.1. Синтаксис открытого ключа RSA

Открытый ключ RSA следует представлять типом ASN.1 RSAPublicKey

         RSAPublicKey ::= SEQUENCE {
             modulus           INTEGER,  -- n
             publicExponent    INTEGER   -- e
         }

modulus — модуль RSA n;
publicExponent — открытый показатель степени RSA e.

A.1.2. Синтаксис секретного ключа RSA

Секретный ключ RSA следует представлять типом ASN.1 RSAPrivateKey

         RSAPrivateKey ::= SEQUENCE {
             version           Version,
             modulus           INTEGER,  -- n
             publicExponent    INTEGER,  -- e
             privateExponent   INTEGER,  -- d
             prime1            INTEGER,  -- p
             prime2            INTEGER,  -- q
             exponent1         INTEGER,  -- d mod (p-1)
             exponent2         INTEGER,  -- d mod (q-1)
             coefficient       INTEGER,  -- (обращение q) mod p
             otherPrimeInfos   OtherPrimeInfos OPTIONAL
         }

version — номер версии для совместимости с будущими выпусками этого документа; в этой версии документа обычно нужно указывать значение 0, а для многофакторного RSA — 1;

            Version ::= INTEGER { two-prime(0), multi(1) }
               (CONSTRAINED BY
               {-- при наличии otherPrimeInfos версий должно быть несколько --})

modulus — модуль RSA n;
publicExponent — открытый показатель степени RSA e;
privateExponent — секретный показатель степени RSA d;
prime1 — простой множитель p для n;
prime2 — простой множитель q для n;
exponent1 — d mod (p — 1);
exponent2 — d mod (q — 1);
coefficient — коэффициент CRT q^(-1) mod p;
otherPrimeInfos — информация для дополнительных простых чисел r_3, …, r_u по порядку (нужно опускать при version = 0 и нужно включать хотя бы 1 экземпляр OtherPrimeInfo, если version = 1).

            OtherPrimeInfos ::= SEQUENCE SIZE(1..MAX) OF OtherPrimeInfo

            OtherPrimeInfo ::= SEQUENCE {
                prime             INTEGER,  -- ri
                exponent          INTEGER,  -- di
                coefficient       INTEGER   -- ti
            }

prime — простой множитель r_i для n, где i >= 3;
exponent — d_i = d mod (r_i — 1);
coefficient — коэффициент CRT t_i = (r_1 * r_2 * … * r_(i-1))^(-1) mod r_i;

Примечание. Важно защитить секретный ключ RSA от раскрытия и изменения, но это выходит за рамки документа. Методы хранения и распространения секретных ключей и других криптографических данных описаны в PKCS #12 и #15.

A.2. Идентификация схем

В этом параграфе заданы идентификаторы для схем шифрования и подписи. Совместимые с PKCS #1 v1.5 схемы используют определения из PKCS #1 v1.5. Предполагается использование определений в сертификатах X.509 и PKCS #7. Ниже приведены определения идентификаторов типов для PKCS #1 OID.

   PKCS1Algorithms    ALGORITHM-IDENTIFIER ::= {
       { OID rsaEncryption                PARAMETERS NULL } |
       { OID md2WithRSAEncryption         PARAMETERS NULL } |
       { OID md5WithRSAEncryption         PARAMETERS NULL } |
       { OID sha1WithRSAEncryption        PARAMETERS NULL } |
       { OID sha224WithRSAEncryption      PARAMETERS NULL } |
       { OID sha256WithRSAEncryption      PARAMETERS NULL } |
       { OID sha384WithRSAEncryption      PARAMETERS NULL } |
       { OID sha512WithRSAEncryption      PARAMETERS NULL } |
       { OID sha512-224WithRSAEncryption  PARAMETERS NULL } |
       { OID sha512-256WithRSAEncryption  PARAMETERS NULL } |
       { OID id-RSAES-OAEP   PARAMETERS RSAES-OAEP-params } |
       PKCS1PSourceAlgorithms                               |
       { OID id-RSASSA-PSS   PARAMETERS RSASSA-PSS-params },
       ...  -- Для будущих расширений --
   }

A.2.1. RSAES-OAEP

Идентификатор объекта id-RSAES-OAEP указывает схему шифрования RSAES-OAEP.

       id-RSAES-OAEP    OBJECT IDENTIFIER ::= { pkcs-1 7 }

Полю параметров, связанному с этим OID в значении AlgorithmIdentifier, нужно иметь тип RSAES-OAEP-params

   RSAES-OAEP-params ::= SEQUENCE {
       hashAlgorithm      [0] HashAlgorithm     DEFAULT sha1,
       maskGenAlgorithm   [1] MaskGenAlgorithm  DEFAULT mgf1SHA1,
       pSourceAlgorithm   [2] PSourceAlgorithm  DEFAULT pSpecifiedEmpty
   }

hashAlgorithm задаёт хэш-функцию; нужно указывать идентификатор алгоритма с OID из набора OAEP-PSSDigestAlgorithms; поддерживаемые хэш-функции указаны а Приложении B.1

       HashAlgorithm ::= AlgorithmIdentifier {
          {OAEP-PSSDigestAlgorithms}
       }

       OAEP-PSSDigestAlgorithms    ALGORITHM-IDENTIFIER ::= {
           { OID id-sha1       PARAMETERS NULL }|
           { OID id-sha224     PARAMETERS NULL }|
           { OID id-sha256     PARAMETERS NULL }|
           { OID id-sha384     PARAMETERS NULL }|
           { OID id-sha512     PARAMETERS NULL }|
           { OID id-sha512-224 PARAMETERS NULL }|
           { OID id-sha512-256 PARAMETERS NULL },
           ...  -- Для будущих расширений --
       }

По умолчанию применяется хэш-функция SHA-1

       sha1    HashAlgorithm ::= {
           algorithm   id-sha1,
           parameters  SHA1Parameters : NULL
       }

       SHA1Parameters ::= NULL

maskGenAlgorithm задаёт функцию генерации маски; нужно указывать идентификатор алгоритма с OID из набора PKCS1MGFAlgorithms, в который для этой версии нужно включать id-mgf1 для функции MGF1 (см. Приложение B.2.1). В поле параметров, связанном с id-mgf1, нужно указывать идентификатор алгоритма с OID из набора OAEP-PSSDigestAlgorithms, указывающего хэш-функцию, применяемую в MGF1.

       MaskGenAlgorithm ::= AlgorithmIdentifier { {PKCS1MGFAlgorithms} }

       PKCS1MGFAlgorithms    ALGORITHM-IDENTIFIER ::= {
           { OID id-mgf1 PARAMETERS HashAlgorithm },
           ...  -- Для будущих расширений --
       }

По умолчанию функция генерации маски MGF1 использует SHA-1

       mgf1SHA1    MaskGenAlgorithm ::= {
           algorithm   id-mgf1,
           parameters  HashAlgorithm : sha1
       }

pSourceAlgorithm задаёт источник (возможно, и значение) метки L; нужно указывать идентификатор алгоритма с OID из набора PKCS1PSourceAlgorithms, в который для этой версии нужно включать id-pSpecified, указывающий явно задаваемую метку. В поле параметров, связанном с id-pSpecified, нужно указывать значение типа OCTET STRING, содержащее метку. В предыдущих версиях этой спецификации использовался термин «параметры кодирования», сохранённый в имени типа.
```
       PSourceAlgorithm ::= AlgorithmIdentifier {
          {PKCS1PSourceAlgorithms}
       }

       PKCS1PSourceAlgorithms    ALGORITHM-IDENTIFIER ::= {
           { OID id-pSpecified PARAMETERS EncodingParameters },
           ...  -- Для будущих расширений --
       }

       id-pSpecified    OBJECT IDENTIFIER ::= { pkcs-1 9 }

       EncodingParameters ::= OCTET STRING(SIZE(0..MAX))
```
По умолчанию меткой является пустая строка (и lHash будет содержать хэш пустой строки)

       pSpecifiedEmpty    PSourceAlgorithm ::= {
           algorithm   id-pSpecified,
           parameters  EncodingParameters : emptyString
       }

       emptyString    EncodingParameters ::= ''H

При использовании в RSAES-OAEP-params принятых по умолчанию значений полей идентификатор алгоритма будет иметь вид

       rSAES-OAEP-Default-Identifier    RSAES-AlgorithmIdentifier ::= {
           algorithm   id-RSAES-OAEP,
           parameters  RSAES-OAEP-params : {
               hashAlgorithm       sha1,
               maskGenAlgorithm    mgf1SHA1,
               pSourceAlgorithm    pSpecifiedEmpty
           }
       }

       RSAES-AlgorithmIdentifier ::= AlgorithmIdentifier  {
           {PKCS1Algorithms}
       }

A.2.2. RSAES-PKCS-v1_5

Идентификатор rsaEncryption (см. Приложение A.1) указывает схему шифрования RSAES-PKCS1-v1_5. В поле параметров, связанном с этим OID в значении типа AlgorithmIdentifier, нужно указывать значение типа NULL (как и в PKCS #1 v1.5).

       rsaEncryption    OBJECT IDENTIFIER ::= { pkcs-1 1 }

A.2.3. RSASSA-PSS

Идентификатор id-RSASSA-PSS указывает схему подписи⁷ RSASSA-PSS.

       id-RSASSA-PSS    OBJECT IDENTIFIER ::= { pkcs-1 10 }

В поле параметров, связанном с этим OID в значении типа AlgorithmIdentifier, нужно указывать значение типа RSASSA-PSS-params

   RSASSA-PSS-params ::= SEQUENCE {
       hashAlgorithm      [0] HashAlgorithm      DEFAULT sha1,
       maskGenAlgorithm   [1] MaskGenAlgorithm   DEFAULT mgf1SHA1,
       saltLength         [2] INTEGER            DEFAULT 20,
       trailerField       [3] TrailerField       DEFAULT trailerFieldBC
   }

hashAlgorithm задаёт хэш-функцию; нужно указывать идентификатор алгоритма с OID из набора OAEP-PSSDigestAlgorithms (см. Приложение A.2.1); по умолчанию применяется хэш-функция SHA-1.
maskGenAlgorithm задаёт функцию генерации маски; нужно указывать идентификатор алгоритма с OID из набора PKCS1MGFAlgorithms (см. Приложение A.2.1). По умолчанию применяется функция генерации маски MGF1 с SHA-1. Для MGF1 (в общем случае и для других функций генерации маски на основе хэширования) рекомендуется применять хэш-функцию, которая указана в hashAlgorithm (см. примечание 2 в параграфе 9.1).
saltLength — число октетов затравки (salt); нужно указывать целое значение. Для данного hashAlgorithm принятым по умолчанию значением saltLength является число октетов хэш-значения. В отличие от других полей типа RSASSA-PSS-params, значение saltLength не обязано быть фиксированным для данной пары ключей RSA.
TrailerField — номер поля трейлера для совместимости с IEEE 1363a [IEEE1363A]; для данной версии документа нужно указывать значение 1, представляющее поле трейлера со значением 0xbc. Другие поля трейлера (включая HashID || 0xcc из IEEE 1363a) в этом документе не поддерживаются.

       TrailerField ::= INTEGER { trailerFieldBC(1) }

При использовании в полях hashAlgorithm, maskGenAlgorithm, trailerField структуры RSASSA-PSS-params принятых по умолчанию значений идентификатор алгоритма будет иметь вид

       rSASSA-PSS-Default-Identifier    RSASSA-AlgorithmIdentifier ::= {
           algorithm   id-RSASSA-PSS,
           parameters  RSASSA-PSS-params : {
               hashAlgorithm       sha1,
               maskGenAlgorithm    mgf1SHA1,
               saltLength          20,
               trailerField        trailerFieldBC
           }
       }

       RSASSA-AlgorithmIdentifier ::= AlgorithmIdentifier {
           {PKCS1Algorithms}
       }

Примечание. В некоторых приложениях хэш-функция для схемы подписи указывается отдельно от остальных операций схемы подписи. Например, в PKCS #7 [RFC2315] идентификатор хэш-функции указывается перед сообщением, а идентификатор алгоритма «шифрования дайджеста» (указывает остальные операции) передаётся вместе с подписью. В PKCS #7 для поддержки схемы подписи RSASSA-PSS требуется указать идентификатор объекта для операций RSASSA-PSS после хэш-функции (как RSAEncryption OID в схеме RSASSA-PKCS1-v1_5). Синтаксис криптографических сообщений (Cryptographic Message Syntax или CMS) S/MIME [RFC5652] использует иной подход. Хотя идентификатор хэш-функции размещается перед сообщением, идентификатор алгоритма для всей схемы подписи может передаваться вместе с подписью CMS (это делается для подписей DSA). В соответствии с этим соглашением id-RSASSA-PSS OID может служить для идентификации подписей RSASSA-PSS в CMS. Поскольку CMS считается преемником PKCS #7 и новые разработки, такие как поддержка RSASSA-PSS, будут выполняться в соответствии с CMS, а не PKCS #7, OID для «остатка» RSASSA-PSS не задан в этой версии PKCS #1.

A.2.4. RSASSA-PKCS-v1_5

Идентификатору RSASSA-PKCS1-v1_5 нужно иметь одно из приведённых в таблице значений. Выбор OID зависит от выбора алгоритма хэширования — MD2, MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 или SHA-512/256. Отметим, что при использовании MD2 или MD5 OID совпадает с применяемым в PKCS #1 v1.5. Для каждого OID в связанном поле параметров значения типа AlgorithmIdentifier нужно указывать значение типа NULL.

Алгоритм хэширования	OID
MD2	md2WithRSAEncryption ::= {pkcs-1 2}
MD5	md5WithRSAEncryption ::= {pkcs-1 4}
SHA-1	sha1WithRSAEncryption ::= {pkcs-1 5}
SHA-224⁸	sha224WithRSAEncryption ::= {pkcs-1 14}
SHA-256	sha256WithRSAEncryption ::= {pkcs-1 11}
SHA-384	sha384WithRSAEncryption ::= {pkcs-1 12}
SHA-512	sha512WithRSAEncryption ::= {pkcs-1 13}
SHA-512/224	sha512-224WithRSAEncryption ::= {pkcs-1 15}
SHA-512/256	sha512-256WithRSAEncryption ::= {pkcs-1 16}

Метод кодирования EMSA-PKCS1-v1_5 включает значение ASN.1 типа DigestInfo, с синтаксисом

       DigestInfo ::= SEQUENCE {
           digestAlgorithm DigestAlgorithm,
           digest OCTET STRING
       }

Поле digestAlgorithm задаёт хэш-функцию и нужно указывать идентификатор алгоритма с OID из набора PKCS1-v1-5DigestAlgorithms (см. Приложение B.1).

       DigestAlgorithm ::= AlgorithmIdentifier {
          {PKCS1-v1-5DigestAlgorithms}
       }

       PKCS1-v1-5DigestAlgorithms    ALGORITHM-IDENTIFIER ::= {
           { OID id-md2        PARAMETERS NULL }|
           { OID id-md5        PARAMETERS NULL }|
           { OID id-sha1       PARAMETERS NULL }|
           { OID id-sha224     PARAMETERS NULL }|
           { OID id-sha256     PARAMETERS NULL }|
           { OID id-sha384     PARAMETERS NULL }|
           { OID id-sha512     PARAMETERS NULL }|
           { OID id-sha512-224 PARAMETERS NULL }|
           { OID id-sha512-256 PARAMETERS NULL }
       }

Приложение B. Вспомогательные методы

В этом приложении приведено несколько примеров базовых функций, поддерживающих схемы шифрования из раздела 9. Представлен ряд методов, обеспечивающих совместимость с имеющимися приложениями, а также переход на новые методы. Хотя эти вспомогательные методы подходят для реализации в приложениях, ни один из них не является обязательным для реализации. Ожидается, что будут разработаны профили для PKCS #1 v2.2, которые зададут конкретные вспомогательные методы.

В приложении также указаны идентификаторы объектов для вспомогательных методов.

B.1. Хэш-функции

Хэш-функции применяются в операциях из разделов 7 и 9. Эти функции являются детерминированными, т. е. вывод функции полностью определяется входными данными. Хэш-функции принимают строку октетов переменного размера и дают на выходе строку октетов фиксированного размера. Применяемым в операциях из разделов 7 и 9 хэш-функциям, как правило, следует быть стойкими к коллизиям. Это означает невозможность найти два разных набора входных данных, дающих на выходе одинаковое значение. Устойчивая к коллизиям хэш-функция также обладает желаемым свойством необратимости, т. е. невозможности подобрать входные данные, которые дадут на выходе заданное хэш-значение. В дополнение к этим требованиям хэш-функции следует поддерживать функцию генерации маски (Приложение B.2) с псевдослучайным значением на выходе.

В качестве примеров для методов кодирования в этом документе указаны 9 хэш-функций — MD2 [RFC1319] (отменена [RFC6149]), MD5 [RFC1321], SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512-224 и SHA-512-256 [SHS]. Для схемы шифрования RSAES-OAEP и метода кодирования EMSA-PSS рекомендуются только SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512-224 и SHA-512-256, а для метода кодирования EMSA-PKCS1-v1_5 рекомендуются в новых приложениях SHA-224, SHA-256, SHA-384, SHA-512, SHA-512-224 и SHA-512-256. Функции MD2, MD5, SHA-1 рекомендуются лишь для совместимости с имеющимися приложениями на основе PKCS #1 v1.5.

Ниже представлены идентификаторы объектов id-md2, id-md5, id-sha1, id-sha224, id-sha256, id-sha384, id-sha512, id-sha512-224, id-sha512-256 для соответствующих хэш-функций.

       id-md2      OBJECT IDENTIFIER ::= {
           iso (1) member-body (2) us (840) rsadsi (113549)
           digestAlgorithm (2) 2
       }

       id-md5      OBJECT IDENTIFIER ::= {
           iso (1) member-body (2) us (840) rsadsi (113549)
           digestAlgorithm (2) 5
       }

       id-sha1    OBJECT IDENTIFIER ::= {
           iso(1) identified-organization(3) oiw(14) secsig(3)
            algorithms(2) 26
       }

       id-sha224    OBJECT IDENTIFIER ::= {
           joint-iso-itu-t (2) country (16) us (840) organization (1)
           gov (101) csor (3) nistalgorithm (4) hashalgs (2) 4
       }

       id-sha256    OBJECT IDENTIFIER ::= {
           joint-iso-itu-t (2) country (16) us (840) organization (1)
           gov (101) csor (3) nistalgorithm (4) hashalgs (2) 1
       }

       id-sha384    OBJECT IDENTIFIER ::= {
           joint-iso-itu-t (2) country (16) us (840) organization (1)
           gov (101) csor (3) nistalgorithm (4) hashalgs (2) 2
       }

       id-sha512    OBJECT IDENTIFIER ::= {
           joint-iso-itu-t (2) country (16) us (840) organization (1)
           gov (101) csor (3) nistalgorithm (4) hashalgs (2) 3
       }

       id-sha512-224    OBJECT IDENTIFIER ::= {
           joint-iso-itu-t (2) country (16) us (840) organization (1)
           gov (101) csor (3) nistalgorithm (4) hashalgs (2) 5
       }

       id-sha512-256    OBJECT IDENTIFIER ::= {
           joint-iso-itu-t (2) country (16) us (840) organization (1)
           gov (101) csor (3) nistalgorithm (4) hashalgs (2) 6
       }

Полю параметров, связанному с OID в значении типа AlgorithmIdentifier, нужно иметь значение типа NULL. Полю параметров, связанному с id-md2 и id-md5 в значении типа AlgorithmIdentifier, нужно иметь значение типа NULL. Поле параметров, связанное с id-sha1, id-sha224, id-sha256, id-sha384, id-sha512, id-sha512-224, id-sha512-256 обычно следует опускать, но при наличии в нем нужно указывать значение типа NULL. Это предназначено для соответствия определениям, исходно опубликованным NIST. Для алгоритмов SHA реализации должны воспринимать значения AlgorithmIdentifier без параметров и с параметрами NULL.

Исключение. При форматировании DigestInfoValue в EMSA-PKCS1-v1_5 (см. параграф 9.2) полю параметров, связанному с id-sha1, id-sha224, id-sha256, id-sha384, id-sha512, id-sha512-224, id-sha512-256, нужно иметь значение типа NULL для поддержки совместимости с имеющимися реализациями и численными информационными значениями, уже опубликованными для EMSA-PKCS1-v1_5 и отражёнными в стандарте IEEE 1363a [IEEE1363A].

Примечание. В PKCS #1 версии 1.5 допускалось использование схем подписи MD4. Криптоанализ MD4 значительно продвинулся за последние годы, например, в работе Dobbertin [MD4] показано, как найти коллизии для MD4, и отмечено, что первые два раунда MD4 не являются необратимыми [MD4FIRST]. В соответствии с этими и другими результатами (например, [MD4LAST]) MD4 больше не рекомендуется.

Были достигнуты успехи в криптоанализе MD2 и MD5, особенно после обнаружения Стивенсом (Stevens) с соавторами [PREFIX] коллизий для выбранных префиксов MD5. MD2 и MD5 следует считать криптографически взломанными и удалять из имеющихся приложений. Эта версия стандарта поддерживает их лишь для совместимости.

Были достигнуты успехи и в криптоанализе SHA-1. В частности результаты Wang и соавторов [SHA1CRYPT] (независимо проверенные M. Cochran в работе [COCHRAN]) по использованию дифференциального пути для поиска коллизий SHA-1 показали значительное снижение стойкости алгоритма хэширования SHA-1. Однако это снижение не так велико, чтобы оправдать исключение SHA-1 из имеющихся приложений, но использовать этот алгоритм рекомендуется лишь для совместимости с прежними версиями.

Для решения отмеченных проблем рекомендуется применять в новых приложениях только алгоритмы SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 и SHA-512/256.На сегодняшний день лучшими (известными) атаками с коллизиями на эти хэш-функции являются базовые атаки со сложностью 2^(L/2), где L — число битов вывода хэш-функции. Для описанных в документе схем подписи атаки с коллизиями легко перевести в подделку подписи, поэтому значению L/2 следует быть по меньшей мере равным желаемому уровню безопасности в битах для схемы подписи (уровень безопасности B битов означает, что лучшая атака имеет сложность 2^B). Такое же эмпирическое правило применимо и для RSAES-OAEP, рекомендуется делать размер затравки в битах (равен числу битов в выводе хэш-функции) вдвое больше желаемого уровня безопасности в битах.⁹

B.2. Функции создания маски

Функция генерации маски принимает строку октетов переменной длины и желаемый размер вывода, выдавая строку октетов указанного размера. Размеры входной и выходной строки могут ограничиваться, но эти границы обычно очень велики. Функции генерации маски являются детерминированными и выходная строка октетов полностью определяется входной строкой. Выводу функции следует быть псевдослучайным, чтобы по одной части вывода (но не входных данных) невозможно было предсказать другую часть. Доказуемая безопасность RSAES-OAEP и RSASSA-PSS основана на случайной природе вывода функции генерации маски, которая зависит от случайного характера базовой хэш-функции.

Ниже описана одна из функций генерации маски (MGF1) на основе хэш-функции. MGF1 соответствует функциям генерации маски, заданным в стандартах IEEE 1363 [IEEE1363] и ANSI X9.44 [ANSIX944]. В будущих версиях этого документа могут быть определены другие функции генерации маски.

B.2.1. MGF1

Функция генерации маски MGF1 основана на функции хэширования.

MGF1 (mgfSeed, maskLen)

Опции

Hash

функция хэширования (hLen указывает размер вывода функции)

Вход

mgfSeed

затравка (seed), из которой создаётся маска, в форме строки октетов

maskLen

предусмотренный размер маски в октетах (не более 2^32 hLen)

Выход

mask

строка октетов маски размером maskLen

Ошибка: mask too long

Этапы

Если maskLen > 2^32 hLen, вывод сообщения об ошибке «mask too long» и остановка.
В качестве T принимается пустая строка октетов.
Для значения счётчика от 0 до \ceil (maskLen / hLen) — 1 выполняются указанные ниже операции.
1. Преобразование значения счётчика в строку октетов C размером 4 октета (см. параграф 4.1)
```
    C = I2OSP (counter, 4)
```
1. Конкатенация хэш-значения затравки mgfSeed и строки C со строкой октетов T
```
    T = T || Hash(mgfSeed || C)
```
Вывод начальных maskLen октетов как строки октетов маски T.

Приведённый ниже идентификатор объекта id-mgf1 указывает функцию генерации маски MGF1.

      id-mgf1    OBJECT IDENTIFIER ::= { pkcs-1 8 }

Полю параметров, связанному с OID в значении AlgorithmIdentifier, нужно иметь тип hashAlgorithm, указывающий хэш-функцию, применяемую в MGF1.

Приложение C. Модуль ASN.1

   -- Модуль ASN.1 PKCS #1 v2.2
   -- Дата выпуска 27 октября 2012 г.

   -- Модуль проверен на соответствие стандарту ASN.1 с помощью ASN.1 OSS

   PKCS-1 {
       iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
       modules(0) pkcs-1(1)
   }

   DEFINITIONS EXPLICIT TAGS ::=

   BEGIN

   -- EXPORTS ALL
   -- Все определённые в модуле типы и значения экспортируются для
   -- использования в других модулях ASN.1.

   IMPORTS

   id-sha224, id-sha256, id-sha384, id-sha512, id-sha512-224,
   id-sha512-256
       FROM NIST-SHA2 {
           joint-iso-itu-t(2) country(16) us(840) organization(1)
           gov(101) csor(3) nistalgorithm(4) hashAlgs(2)
       };

   -- ===============================
   -- Идентификаторы базовых объектов
   -- ===============================

   -- DER-представление в шестнадцатеричном виде:
   -- (0x)06 08
   --        2A 86 48 86 F7 0D 01 01
   --
   pkcs-1    OBJECT IDENTIFIER ::= {
       iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1
   }

   --
   -- При использовании rsaEncryption в AlgorithmIdentifier
   -- параметры ДОЛЖНЫ присутствовать и ДОЛЖНЫ иметь значение NULL.
   --
   rsaEncryption    OBJECT IDENTIFIER ::= { pkcs-1 1 }

   --
   -- При использовании id-RSAES-OAEP в AlgorithmIdentifier
   -- параметры ДОЛЖНЫ присутствовать и ДОЛЖНЫ быть RSAES-OAEP-params.
   --
   id-RSAES-OAEP    OBJECT IDENTIFIER ::= { pkcs-1 7 }

   --
   -- При использовании id-pSpecified в AlgorithmIdentifier
   -- параметры ДОЛЖНЫ быть строкой октетов (OCTET STRING).
   --
   id-pSpecified    OBJECT IDENTIFIER ::= { pkcs-1 9 }

   --
   -- При использовании id-RSASSA-PSS в AlgorithmIdentifier
   -- параметры ДОЛЖНЫ присутствовать и ДОЛЖНЫ быть RSASSA-PSS-params.
   --
   id-RSASSA-PSS    OBJECT IDENTIFIER ::= { pkcs-1 10 }

   --
   -- При использовании указанных ниже OID в AlgorithmIdentifier
   -- параметры ДОЛЖНЫ присутствовать и ДОЛЖНЫ быть NULL.
   --
   md2WithRSAEncryption         OBJECT IDENTIFIER ::= { pkcs-1 2 }
   md5WithRSAEncryption         OBJECT IDENTIFIER ::= { pkcs-1 4 }
   sha1WithRSAEncryption        OBJECT IDENTIFIER ::= { pkcs-1 5 }
   sha224WithRSAEncryption      OBJECT IDENTIFIER ::= { pkcs-1 14 }
   sha256WithRSAEncryption      OBJECT IDENTIFIER ::= { pkcs-1 11 }
   sha384WithRSAEncryption      OBJECT IDENTIFIER ::= { pkcs-1 12 }
   sha512WithRSAEncryption      OBJECT IDENTIFIER ::= { pkcs-1 13 }
   sha512-224WithRSAEncryption  OBJECT IDENTIFIER ::= { pkcs-1 15 }
   sha512-256WithRSAEncryption  OBJECT IDENTIFIER ::= { pkcs-1 16 }

   --
   -- Этот OID реально относится к модулю с secsig OID.
   --
   id-sha1    OBJECT IDENTIFIER ::= {
       iso(1) identified-organization(3) oiw(14) secsig(3) algorithms(2)
       26
   }

   --
   -- OID для MD2 и MD5, разрешённых лишь в EMSA-PKCS1-v1_5.
   --
   id-md2 OBJECT IDENTIFIER ::= {
       iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 2
   }

   id-md5 OBJECT IDENTIFIER ::= {
       iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5
   }

   --
   -- При использовании id-mgf1 в AlgorithmIdentifier параметры ДОЛЖНЫ
   -- присутствовать и ДОЛЖНЫ быть HashAlgorithm, например, sha1.
   --
   id-mgf1    OBJECT IDENTIFIER ::= { pkcs-1 8 }

   -- ================
   --   Полезные типы
   -- ================
   ALGORITHM-IDENTIFIER ::= CLASS {
       &id    OBJECT IDENTIFIER  UNIQUE,
       &Type  OPTIONAL
   }
       WITH SYNTAX { OID &id [PARAMETERS &Type] }

   -- Параметр InfoObjectSet в следующих определениях позволяет задавать
   -- разные объекты информации для наборов алгоритмов, такие как
   -- DigestAlgorithms    ALGORITHM-IDENTIFIER ::= {
   --     { OID id-md2  PARAMETERS NULL }|
   --     { OID id-md5  PARAMETERS NULL }|
   --     { OID id-sha1 PARAMETERS NULL }
   -- }
   --
   AlgorithmIdentifier { ALGORITHM-IDENTIFIER:InfoObjectSet } ::=
       SEQUENCE {
         algorithm
             ALGORITHM-IDENTIFIER.&id({InfoObjectSet}),
         parameters
             ALGORITHM-IDENTIFIER.&Type({InfoObjectSet}{@.algorithm})
               OPTIONAL
   }

   -- ==============
   --   Алгоритмы
   -- ==============

   --
   -- Разрешённые алгоритмы цифровых дайджестов EME-OAEP и EMSA-PSS.
   --
   OAEP-PSSDigestAlgorithms    ALGORITHM-IDENTIFIER ::= {
       { OID id-sha1       PARAMETERS NULL }|
       { OID id-sha224     PARAMETERS NULL }|
       { OID id-sha256     PARAMETERS NULL }|
       { OID id-sha384     PARAMETERS NULL }|
       { OID id-sha512     PARAMETERS NULL }|
       { OID id-sha512-224 PARAMETERS NULL }|
       { OID id-sha512-256 PARAMETERS NULL },
       ...  -- Для будущих расширений --
   }

   --
   -- Разрешённые алгоритмы цифровых дайджестов EMSA-PKCS1-v1_5.
   --
   PKCS1-v1-5DigestAlgorithms    ALGORITHM-IDENTIFIER ::= {
       { OID id-md2        PARAMETERS NULL }|
       { OID id-md5        PARAMETERS NULL }|
       { OID id-sha1       PARAMETERS NULL }|
       { OID id-sha224     PARAMETERS NULL }|
       { OID id-sha256     PARAMETERS NULL }|
       { OID id-sha384     PARAMETERS NULL }|
       { OID id-sha512     PARAMETERS NULL }|
       { OID id-sha512-224 PARAMETERS NULL }|
       { OID id-sha512-256 PARAMETERS NULL }
   }

   -- При использовании id-md2 и id-md5 в AlgorithmIdentifier в поле
   -- параметров нужно использовать значение типа NULL.

   -- При использовании id-sha1, id-sha224, id-sha256, id-sha384, 
   -- id-sha512, id-sha512-224 и id-sha512-256 в AlgorithmIdentifier
   -- (опциональные) параметры СЛЕДУЕТ пропускать, но при наличии в
   -- них НУЖНО устанавливать значение типа NULL. Однако реализации
   -- ДОЛЖНЫ воспринимать значения AlgorithmIdentifier как без 
   -- параметров, так и с параметрами NULL.

   -- Исключение. При форматировании DigestInfoValue в EMSA-PKCS1-v1_5
   -- (параграф 9.2) в поле параметров, связанном с id-sha1, id-sha224, 
   -- id-sha256, id-sha384, id-sha512, id-sha512-224 и id-sha512-256
   -- НУЖНО указывать значение типа NULL. Это нужно для совместимости с
   -- имеющимися реализациями и численными значениями, опубликованными
   -- для EMSA-PKCS1-v1_5, которые отражены также в IEEE 1363a.

   sha1    HashAlgorithm ::= {
       algorithm   id-sha1,
       parameters  SHA1Parameters : NULL
   }

   HashAlgorithm ::= AlgorithmIdentifier { {OAEP-PSSDigestAlgorithms} }

   SHA1Parameters ::= NULL

   --
   -- Разрешённые алгоритмы для функции генерации маски.
   -- При идентификаторе id-mgf1 параметры - это HashAlgorithm.
   --
   PKCS1MGFAlgorithms    ALGORITHM-IDENTIFIER ::= {
       { OID id-mgf1 PARAMETERS HashAlgorithm },
       ...  -- Для будущих расширений --
   }

   --
   -- Принятый по умолчанию AlgorithmIdentifier для 
   -- id-RSAES-OAEP.maskGenAlgorithm и id-RSASSA-PSS.maskGenAlgorithm
   --
   mgf1SHA1    MaskGenAlgorithm ::= {
       algorithm   id-mgf1,
       parameters  HashAlgorithm : sha1
   }

   MaskGenAlgorithm ::= AlgorithmIdentifier { {PKCS1MGFAlgorithms} }

   --
   -- Разрешенный алгоритмы для pSourceAlgorithm.
   --
   PKCS1PSourceAlgorithms    ALGORITHM-IDENTIFIER ::= {
       { OID id-pSpecified PARAMETERS EncodingParameters },
       ...  -- Для будущих расширений --
   }

   EncodingParameters ::= OCTET STRING(SIZE(0..MAX))

   --
   -- Означает, что метка L является пустой строкой, поэтому дайджест
   -- пустой строки размещается в блоке RSA перед маскированием
   --
   pSpecifiedEmpty    PSourceAlgorithm ::= {
       algorithm   id-pSpecified,
       parameters  EncodingParameters : emptyString
   }

   PSourceAlgorithm ::= AlgorithmIdentifier { {PKCS1PSourceAlgorithms} }

   emptyString    EncodingParameters ::= ''H

   --
   -- Определения типов идентификаторов для PKCS #1 OID.
   --
   PKCS1Algorithms    ALGORITHM-IDENTIFIER ::= {
       { OID rsaEncryption                PARAMETERS NULL } |
       { OID md2WithRSAEncryption         PARAMETERS NULL } |
       { OID md5WithRSAEncryption         PARAMETERS NULL } |
       { OID sha1WithRSAEncryption        PARAMETERS NULL } |
       { OID sha224WithRSAEncryption      PARAMETERS NULL } |
       { OID sha256WithRSAEncryption      PARAMETERS NULL } |
       { OID sha384WithRSAEncryption      PARAMETERS NULL } |
       { OID sha512WithRSAEncryption      PARAMETERS NULL } |
       { OID sha512-224WithRSAEncryption  PARAMETERS NULL } |
       { OID sha512-256WithRSAEncryption  PARAMETERS NULL } |
       { OID id-RSAES-OAEP   PARAMETERS RSAES-OAEP-params } |
       PKCS1PSourceAlgorithms                               |
       { OID id-RSASSA-PSS   PARAMETERS RSASSA-PSS-params },
       ...  -- Для будущих расширений --
   }

   -- ====================
   --   Основные структуры
   -- ====================

   RSAPublicKey ::= SEQUENCE {
       modulus           INTEGER,  -- n
       publicExponent    INTEGER   -- e
   }

   --
   -- Представление секретного ключа RSA с информацией для 
   -- алгоритма CRT.
   --
   RSAPrivateKey ::= SEQUENCE {
       version           Version,
       modulus           INTEGER,  -- n
       publicExponent    INTEGER,  -- e
       privateExponent   INTEGER,  -- d
       prime1            INTEGER,  -- p
       prime2            INTEGER,  -- q
       exponent1         INTEGER,  -- d mod (p-1)
       exponent2         INTEGER,  -- d mod (q-1)
       coefficient       INTEGER,  -- (обращение q) mod p
       otherPrimeInfos   OtherPrimeInfos OPTIONAL
   }

   Version ::= INTEGER { two-prime(0), multi(1) }
       (CONSTRAINED BY
         {-- При наличии otherPrimeInfos версия ДОЛЖНА быть
             multi --})

   OtherPrimeInfos ::= SEQUENCE SIZE(1..MAX) OF OtherPrimeInfo


   OtherPrimeInfo ::= SEQUENCE {
       prime             INTEGER,  -- ri
       exponent          INTEGER,  -- di
       coefficient       INTEGER   -- ti
   }

   --
   -- AlgorithmIdentifier.parameters для id-RSAES-OAEP.
   -- Теги в этой последовательности (Sequence) являются явными.
   --
   RSAES-OAEP-params ::= SEQUENCE {
       hashAlgorithm      [0] HashAlgorithm     DEFAULT sha1,
       maskGenAlgorithm   [1] MaskGenAlgorithm  DEFAULT mgf1SHA1,
       pSourceAlgorithm   [2] PSourceAlgorithm  DEFAULT pSpecifiedEmpty
   }

   --
   -- Идентификатор принятого по умолчанию алгоритма RSAES-OAEP.
   -- Шестнадцатеричное DER-представление приведено ниже
   -- (0x)30 0D
   --        06 09
   --           2A 86 48 86 F7 0D 01 01 07
   --        30 00
   -- DER-представление принятых по умолчанию значений пусто.
   --
   rSAES-OAEP-Default-Identifier    RSAES-AlgorithmIdentifier ::= {
       algorithm   id-RSAES-OAEP,
       parameters  RSAES-OAEP-params : {
           hashAlgorithm       sha1,
           maskGenAlgorithm    mgf1SHA1,
           pSourceAlgorithm    pSpecifiedEmpty
       }
   }

   RSAES-AlgorithmIdentifier ::= AlgorithmIdentifier {
       {PKCS1Algorithms}
   }

   --
   -- AlgorithmIdentifier.parameters для id-RSASSA-PSS.
   -- Теги в этой последовательности (Sequence) являются явными.
   --
   RSASSA-PSS-params ::= SEQUENCE {
       hashAlgorithm      [0] HashAlgorithm      DEFAULT sha1,
       maskGenAlgorithm   [1] MaskGenAlgorithm   DEFAULT mgf1SHA1,
       saltLength         [2] INTEGER            DEFAULT 20,
       trailerField       [3] TrailerField       DEFAULT trailerFieldBC
   }

   TrailerField ::= INTEGER { trailerFieldBC(1) }

   --
   -- Идентификатор принятого по умолчанию алгоритма RSASSA-PSS.
   -- Шестнадцатеричное DER-представление приведено ниже
   -- (0x)30 0D
   --        06 09
   --           2A 86 48 86 F7 0D 01 01 0A
   --        30 00
   -- DER-представление принятых по умолчанию значений пусто.
   --
   rSASSA-PSS-Default-Identifier    RSASSA-AlgorithmIdentifier ::= {
       algorithm   id-RSASSA-PSS,
       parameters  RSASSA-PSS-params : {
           hashAlgorithm       sha1,
           maskGenAlgorithm    mgf1SHA1,
           saltLength          20,
           trailerField        trailerFieldBC
       }
   }

   RSASSA-AlgorithmIdentifier ::= AlgorithmIdentifier {
       {PKCS1Algorithms}
   }

   --
   -- Синтаксис идентификатора хэширования EMSA-PKCS1-v1_5.
   --
   DigestInfo ::= SEQUENCE {
       digestAlgorithm DigestAlgorithm,
       digest OCTET STRING
   }

   DigestAlgorithm ::= AlgorithmIdentifier {
       {PKCS1-v1-5DigestAlgorithms}
   }

   END

Приложение D. История выпусков PKCS #1

Версии 1.0 — 1.5

Версии 1.0 — 1.3 были распространены участникам конференций RSA Data Security, Inc. по криптографии с открытым ключом в феврале и марте 1991 г. Версия 1.4 была частью первого общедоступного выпуска PKCS от 3 июня 1991 г. и опубликована с документе SEC-SIG-91-18 семинара NIST/OSI Implementors’ Workshop.

Версия 1.5 включала некоторые редакторские правки, в том числе ссылки и добавление истории выпусков. Ниже указаны наиболее важные изменения.

В раздел 10 «MD4 with RSA» добавлено описание процессов подписания и проверки.
В раздел 11 добавлен идентификатор md4WithRSAEncryption.

Версия 1.5 была опубликована в [RFC2313] (позднее отменён [RFC2437]).

Версия 2.0

В версию 2.0 внесены существенные редакторские правки в части структуры документа и включена схема шифрования RSAES-OAEP. В этой версии по-прежнему поддерживались процесс шифрования и подписи из версии 1.5, но применение алгоритма MD4 было исключено из-за достижений криптоанализа за прошедшие годы. Версия 2.0 была опубликована в [RFC2437] (позднее отменён [RFC3447]).

Версия 2.1

В версии 2.1 добавлена поддержка многофакторного RSA и схема подписи RSASSA-PSS с приложением (appendix), а также внесены редакторские правки. В этой версии по-прежнему поддерживались схемы версии 2.0. Версия 2.1 была опубликована в [RFC3447].

Версия 2.2

В версии 2.2 обновлён список разрешённых алгоритмов хэширования в соответствии с FIPS 180-4 [SHS] (добавлены алгоритмы SHA-224, SHA-512-224, SHA-512-256). Внесены также указанные ниже важные изменения.

Добавлены идентификаторы объектов для sha224WithRSAEncryption, sha512-224WithRSAEncryption, sha512-256WithRSAEncryption.
В этой версии по-прежнему поддерживаются схемы версии 2.1.

Приложение E. PKCS

Стандарты криптографии с открытым ключом (Public-Key Cryptography Standard или PKCS) разработаны RSA Laboratories совместно с разработчиками защищённых систем всего мира с целью ускорения внедрения криптографии с открытым ключом. Опубликованные впервые в 1991 г. как результат встреч с небольшой группой первых пользователей технологии с открытым ключом, документы PKCS получили широкое распространение и были реализованы. Решения серии PKCS стали частью многих официальных и фактических стандартов, включая документы ANSI X9 и IEEE P1363, PKIX, Secure Electronic Transaction (SET), S/MIME, SSL/TLS, Wireless Application Protocol (WAP) / WAP Transport Layer Security (WTLS).

Дальнейшая разработка большинства документов PKCS происходит в рамках IETF. Приветствуются предложения по совершенствованию.

Благодарности

Этот документ основан на результатах RSA Laboratories, исследовательского центра RSA Security Inc.

Адреса авторов

Kathleen M. Moriarty (editor)

EMC Corporation

176 South Street

Hopkinton, MA 01748

United States of America

Email: kathleen.moriarty@emc.com

Burt Kaliski

Verisign

12061 Bluemont Way

Reston, VA 20190

United States of America

Email: bkaliski@verisign.com

URI: http://verisignlabs.com

Jakob Jonsson

Subset AB

Munkbrogtan 4

Stockholm SE-11127

Sweden

Phone: +46 8 428 687 43

Email: jakob.jonsson@subset.se

Andreas Rusch

RSA

345 Queen Street

Brisbane, QLD 4000

Australia

Email: andreas.rusch@rsa.com

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

3Integer Factorization Encryption Primitive using RSA — примитив шифрования с целочисленной факторизаций, использующий RSA.

4Integer Factorization Decryption Primitive using RSA — примитив расшифровки с целочисленной факторизаций, использующий RSA.

5Integer Factorization Signature Primitive using RSA, version 1 — примитив подписи с целочисленной факторизаций, использующий RSA, версия 1.

6Integer Factorization Verification Primitive using RSA, version 1 — примитив проверки с целочисленной факторизаций, использующий RSA, версия 1

7В оригинале ошибочно говорится о схеме шифрования, см. https://errata.rfc-editor.org/eid5111/. Прим. перев.

8В оригинале ошибочно указано SHA-256, см. https://errata.rfc-editor.org/eid5154/. Прим. перев.

9В оригинале этот абзац содержал ошибки, см. https://errata.rfc-editor.org/eid5577/. Прим. перев.

1. Введение

1.1. Уровни требований

2. Обозначения

3. Типы ключей

3.1. Открытый ключ RSA

3.2. Секретный ключ RSA

4. Примитивы преобразования данных

4.1. I2OSP

4.2. OS2IP

5. Криптографические примитивы

5.1. Примитивы шифрования и расшифровки

5.1.1. RSAEP

5.1.2. RSADP

5.2. Примитивы подписи и проверки

5.2.1. RSASP1

5.2.2. RSAVP1

6. Обзор схем

7. Схемы шифрования

7.1. RSAES-OAEP

7.1.1. Шифрование

7.1.2. Расшифровка

7.2. RSAES-PKCS1-v1_5

7.2.1. Шифрование

7.2.2. Расшифровка

8. Схема подписи с приложением

8.1. RSASSA-PSS

8.1.1. Создание подписи

8.1.2. Проверка подписи

8.2. RSASSA-PKCS1-v1_5

8.2.1. Создание подписи

8.2.2. Проверка подписи

9. Методы кодирования для подписей с приложением

9.1. EMSA-PSS

9.1.1. Кодирование

9.1.2. Проверка

9.2. EMSA-PKCS1-v1_5

10. Вопросы безопасности

11. Литература

11.1. Нормативные документы

11.2. Дополнительная литература

Приложение A. Синтаксис ASN.1

A.1. Представление ключей RSA

A.1.1. Синтаксис открытого ключа RSA

A.1.2. Синтаксис секретного ключа RSA

A.2. Идентификация схем

A.2.1. RSAES-OAEP

A.2.2. RSAES-PKCS-v1_5

A.2.3. RSASSA-PSS

A.2.4. RSASSA-PKCS-v1_5

Приложение B. Вспомогательные методы

B.1. Хэш-функции

B.2. Функции создания маски

B.2.1. MGF1

Приложение C. Модуль ASN.1

Приложение D. История выпусков PKCS #1

Приложение E. PKCS

Благодарности

Адреса авторов

Добавить комментарий Отменить ответ

Рубрики

Свежие записи

Архивы

Мета