RSA PKCS#1 v1.5 долгое время был стандартным способом упаковки данных перед асимметричным шифрованием. Его задача — подготовить сообщение так, чтобы оно могло быть безопасно обработано математикой RSA, которая сама по себе работает только с числами фиксированной длины.
Формат выглядит как структура:
EM = 0x00 || 0x02 || PS || 0x00 || Mгде:
0x00 0x02 — фиксированные байты, обозначающие тип
шифрованияPS — паддинг из случайных байтов (padding string)0x00 — разделительM — исходное сообщениеКлючевой элемент здесь — паддинг PS, который заполняется
случайными значениями и должен быть достаточно длинным, чтобы сообщение
не помещалось в исходный блок без расширения.
Именно эта конструкция стала источником целого класса атак.
Главная проблема PKCS#1 v1.5 заключается не в математике RSA, а в том, как реализована обработка ошибок при расшифровке.
Если система при расшифровке ведёт себя по-разному в зависимости от корректности паддинга (например, возвращает разные ошибки или различается время ответа), атакующий получает так называемый oracle padding — побочный канал информации.
На основе этого можно восстановить зашифрованный текст, не имея приватного ключа.
Одной из самых известных атак на PKCS#1 v1.5 стала атака Bleichenbacher.
Её суть:
Эта атака показала, что даже небольшая утечка информации о корректности формата делает RSA PKCS#1 v1.5 принципиально небезопасным в интерактивных протоколах.
После публикации атак стало ясно, что PKCS#1 v1.5 особенно опасен в следующих сценариях:
Даже если ошибки не отображаются напрямую, различия во времени ответа могут быть достаточны для атаки.
Несмотря на известность уязвимости, PKCS#1 v1.5 продолжал использоваться по нескольким причинам:
Однако криптография показывает жесткое правило: устаревшие схемы с доказанными побочными каналами нельзя «починить» настройками — их нужно заменять.
Optimal Asymmetric Encryption Padding (OAEP) был разработан как более безопасная схема упаковки данных для RSA.
В отличие от PKCS#1 v1.5, OAEP использует не просто паддинг, а криптографически обоснованную конструкцию с хэш-функциями и маскирующими генераторами.
Упрощённо структура выглядит так:
OAEP спроектирован так, чтобы любые ошибки декодирования не давали атакующему полезной информации.
При корректной реализации OAEP обеспечивает IND-CCA безопасность (indistinguishability under chosen ciphertext attack).
Использование хэшей делает структуру сообщения нечитаемой без ключа даже частично.
Ключевая идея OAEP — устранить возможность частичной проверки корректности структуры ciphertext.
В PKCS#1 v1.5 можно определить:
В OAEP:
В экосистеме JavaScript криптографические библиотеки (в том числе JOSE) используют RSA в основном в двух контекстах:
Именно здесь выбор между PKCS#1 v1.5 и OAEP критичен.
В современных спецификациях JOSE:
RSA1_5 — устаревший и небезопасный режимRSA-OAEP — рекомендуемый вариантRSA-OAEP-256 — усиленная версия с SHA-256Даже если протокол формально защищён, использование PKCS#1 v1.5 приводит к рискам:
Злоумышленник может подбирать ciphertext и наблюдать поведение сервера.
Разные типы ошибок дешифрования становятся информационным каналом.
Многие старые системы до сих пор используют RSA1_5, что заставляет разработчиков поддерживать небезопасный режим.
В библиотеке JOSE выбор алгоритма влияет напрямую на безопасность JWE:
alg: RSA1_5
alg: RSA-OAEP
alg: RSA-OAEP-256
Криптографическая безопасность RSA сегодня определяется не размером ключа, а тем, как используется padding.
PKCS#1 v1.5:
OAEP:
RSA без корректного padding — математически корректен, но криптографически небезопасен. PKCS#1 v1.5 оказался переходным стандартом, который не выдержал требований активных атакующих моделей.
OAEP стал ответом на фундаментальную проблему: необходимость скрыть структуру сообщения так, чтобы никакой побочный канал не позволял извлечь информацию о plaintext даже при контролируемых ошибках дешифрования.