Шифрування / розшифрування RSA

Генеруйте пари ключів RSA у браузері, шифруйте і розшифровуйте за RSA-OAEP, підписуйте за RSA-PSS або PKCS#1 v1.5 і перетворюйте ключі між форматами PEM SPKI, PKCS#8 і PKCS#1. Усе працює локально на рушії WebCrypto — ні ключ, ні повідомлення ніколи не покидають цю сторінку.
Для чого RSA: малі повідомлення та підписи, а не великі обсяги даних. RSA шифрує щонайбільше k−2·hashLen−2 байтів за виклик (190 байтів для 2048-бітного ключа з SHA-256) і приблизно в 1000× повільніший за AES. Реальні системи використовують гібридне шифрування: RSA обгортає випадковий ключ AES, AES шифрує дані (див. інструмент AES). Ця сторінка призначена для навчання, тестування й перевірки сумісності.
1. Згенеруйте пару ключів (WebCrypto, локально; чотири формати PEM створюються разом)
Розмір модуля:
2. Або імпортуйте наявний ключ (вставте будь-який із чотирьох форматів PEM)
3. Шифрування / розшифрування (RSA-OAEP) - напрямок залежить від поточного ключа: відкритий = шифрування, закритий = розшифрування
Хеш: Мітка:
PKCS#1 v1.5 шифрування навмисно не реалізовано: воно не має цілісності шифротексту і падає від атак оракула доповнення (Блейхенбахер). OAEP — єдиний режим шифрування, який має використовувати нова система.
4. Підписування (потрібен закритий ключ) - PSS (рандомізований, сучасний) або PKCS#1 v1.5 (детермінований, сумісний зі старим)
Схема: Хеш:
5. Перевірка (потрібен відкритий ключ) - вставте повідомлення і підпис
Схема: Хеш:
Скільки може нести один виклик RSA? Ліміт повідомлення OAEP = байти ключа − 2×байти хеша − 2:
МодульSHA-256SHA-384SHA-512
1024-бітний62 байти30 байтів0 байтів
2048-бітний190 байтів126 байтів62 байти
3072-бітний318 байтів254 байти190 байтів
4096-бітний446 байтів382 байти318 байтів
У підписів немає ліміту повідомлення — повідомлення спершу хешується; сам підпис завжди має рівно розмір ключа (256 байтів для 2048-бітного).
Ключі: сила і термін дії (NIST SP 800-57 Part 1 Rev. 5): 1024-бітний заборонено для нового використання після 2013; 2048-бітний — мінімум сьогодні і залишається прийнятним до 2030; 3072-бітний і більші — комфортний вибір для 2031+. 8192-бітний тут працює, але генерація може тривати хвилину або більше в браузері і дає безпеку, якої зараз ніхто не потребує — краще 3072/4096.
Сумісність з OpenSSL — PEM, які створює ця сторінка, проходять цикл у командному рядку:
openssl pkeyutl -encrypt -pubin -inkey pub.pem -pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha256 -pkeyopt rsa_mgf1_md:sha256
openssl pkeyutl -decrypt -inkey priv.pem -pkeyopt rsa_padding_mode:oaep ...
openssl dgst -sha256 -sign priv.pem -out msg.sig msg.txt (PKCS#1 v1.5)  /  openssl dgst -sha256 -verify pub.pem -signature msg.sig msg.txt
PSS: додайте -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:32 до обох викликів dgst. Перетворення формату ключа: openssl rsa -in key.pem -RSAPublicKey -out pubkey.pem робить SPKI ↔ PKCS#1 на диску; ця сторінка робить це в браузері.
Самоперевірка
Запускає рушій сторінки проти незалежних якорів: генерація ключів трьох розмірів модуля, цикли шифрування/розшифрування OAEP, підписування і перевірка PSS та PKCS#1 v1.5 для різних хешів, детермінований вектор підпису v1.5 побайтово (згенерований незалежною нативною реалізацією), фіксований шифротекст OAEP і підпис PSS, створені OpenSSL, які ця сторінка має розшифрувати/перевірити (сумісність між реалізаціями), цикли перетворення формату PEM і негативні тести (підроблений підпис, неправильний ключ мають не пройти). Нічого нікуди не надсилається.
Шифрування і підписи RSA пояснено з нуля
Одним реченням: RSA — це криптографія з відкритим ключем: будь-хто може зашифрувати для вас відкритим ключем або перевірити ваші підписи, але лише закритий ключ може розшифрувати або підписати — і його безпека ґрунтується на тому, що факторизація 2048-бітного числа на два прості — поза межами будь-якого існуючого комп'ютера.
Що насправді обчислює RSA

Два прості числа і люк. Ключ RSA починається з двох великих випадкових простих чисел p і q; їхній добуток n (модуль, звідси «2048-бітний ключ») публікується в відкритому ключі разом з експонентою e (майже завжди 65537). Закритий ключ — це d, модулярна обернена до e −, обчислена з p і q — плюс скорочення, виведені з простих чисел, які прискорюють операції із закритим ключем у 4×.

Шифрування і підписування — та сама експонентація. Шифрування блоку повідомлення m означає обчислення me mod n; розшифрування — cd mod n. Підписування попередньо відформатованого блоку закритою експонентою і перевірка відкритою — та сама операція в іншому напрямку. Усе інше на цій сторінці — OAEP, PSS, PKCS#1 — це про безпечне форматування блоку, щоб сира експонентація ніколи не була відкрита.

Чому це повільно. Одна операція RSA на 2048-бітному ключі коштує приблизно мільйон разів більше процесорного часу, ніж шифрування одного блоку за AES. Тому TLS використовує RSA (або ECC) лише щоб узгодити випадковий ключ AES, а потім переходить на AES. Те саме правило діє для всього, що ви будуєте: RSA для ключа, AES для даних.

Розмір ключа. Довжина модуля — це ручка безпеки: 1024-бітний за політикою зламаний (факторизація в межах досяжності держав), 2048-бітний ≈ 112-бітна симетрична стійкість, 3072-бітний ≈ 128-бітна, 15360-бітний відповідав би 256-бітному симетричному ключу. Примітка про постквантову епоху: алгоритм Шора повністю ламає RSA на великому квантовому комп'ютері — ще одна причина тримати терміни дії ключів обмеженими.

OAEP: єдине доповнення шифрування, яке варто використовувати

Проблема сирого RSA. Підручниковий RSA (me mod n над сирим повідомленням) детермінований і піддається маніпуляціям: однакові повідомлення шифруються однаково, зловмисник може помножити шифротекст на шифрування 2, щоб подвоїти відкритий текст, а короткі повідомлення падають методом «зустріч посередині». Його ніколи не можна використовувати напряму.

Що робить OAEP. OAEP (PKCS#1 v2, RFC 8017) змішує повідомлення з випадковим зерном через мережу Фейстеля на основі хешів перед експонентацією. Результат: шифрування рандомізоване (той самий відкритий текст дає щоразу інший шифротекст — запустіть зразок OAEP двічі і порівняйте), підробка виявляється під час розшифрування, а повідомлення має вміститися в модуль з місцем для хеша — обмеження k−2·hashLen−2, наведене вище в таблиці.

Мітка. Необов'язковий відкритий рядок, прив'язаний до доповнення. Обидві сторони мають надати однакову мітку, інакше розшифрування не вдасться — як AAD у AES-GCM, вона дозволяє прив'язати шифротекст до контексту (назви файлу, ідентифікатора алгоритму). Порожня — нормально.

Шифрування PKCS#1 v1.5 навмисно відсутнє. Доповнення 1993 року не має цілісності і протікає через поведінку помилок розшифрування (атака Блейхенбахера 1998 року перетворює оракул доповнення на повне розшифрування за кілька мільйонів підроблених шифротекстів; вона й досі ламає реальні системи як ROBOT, 2017). WebCrypto відмовляється це реалізовувати; так само й ця сторінка.

Підписи PSS проти PKCS#1 v1.5

Підписування = хеш, потім доповнення, потім експонентація. Обидві схеми хешують повідомлення (тут SHA-256/384/512), форматують дайджест у блок і застосовують закриту експонентку. Перевірка переформатовує блок відкритим ключем і порівнює. Різниця — у форматуванні:

СхемаВміст блокуВластивості
RSASSA-PKCS1-v1_5дайджест + заголовок digest-info, детермінованийКожен підпис того самого повідомлення побайтово ідентичний (перевірте самотест: його вектор v1.5 фіксований). Універсальна підтримка старих систем: сертифікати X.509, JWT RS*, TLS до 1.3. Відомої підробки немає, якщо перевірку реалізовано коректно.
RSA-PSSдайджест + випадкова сіль довжини хеша, маскування MGF1Рандомізований — кожен підпис відрізняється. Доведено безпечний у моделі випадкового оракула; вимагається в сертифікатах майбутнього TLS 1.3 і новіших протоколах. Верифікатор має знати довжину солі (ця сторінка використовує довжину хеша, поширений типовий варіант).

Яку обрати. Нові системи: PSS. Сумісність з наявними сертифікатами, JWT (RS256) або старими партнерами: v1.5. Обидві безпечні як схеми підписів — історія катастрофи v1.5 стосується *шифрувального* доповнення, іншої конструкції, попри подібну назву.

PKCS#1 проти PKCS#8 проти SPKI: чому один ключ має чотири PEM

PEM — це просто DER, загорнутий у base64. Файл PEM — це мітка плюс base64 структури DER (бінарний ASN.1). Мітка повідомляє, яка це структура — і саме в цьому вся різниця між чотирма форматами, які генерує ця сторінка:

Мітка PEMструктура DERМістить
-----BEGIN PUBLIC KEY-----SubjectPublicKeyInfo (SPKI)OID алгоритму + відкритий ключ (n, e). Типовий «відкритий ключ» всюди.
-----BEGIN RSA PUBLIC KEY-----PKCS#1 RSAPublicKeyГолий (n, e). Старі OpenSSL і деякі вбудовані стеки.
-----BEGIN PRIVATE KEY-----PKCS#8 PrivateKeyInfoOID алгоритму + закритий ключ. Контейнер, незалежний від алгоритму, сучасний типовий.
-----BEGIN RSA PRIVATE KEY-----PKCS#1 RSAPrivateKeyn, e, d, p, q, …. Класичний вивід genrsa з OpenSSL.

Той самий ключ, різні обгортки. Усі чотири блоки вище після «Згенерувати» містять той самий ключ — відкритий SPKI і відкритий PKCS#1 містять ідентичні n, e; закритий PKCS#8 і закритий PKCS#1 містять ідентичні закриті значення. Ця сторінка без втрат перетворює між ними в браузері (її самотест перевіряє перетворення в обидва боки). Плутанина форматів — найпоширеніша причина помилок «некоректний ключ» під час вставлення ключів між інструментами.

Зашифровані PEM (-----BEGIN ENCRYPTED PRIVATE KEY-----) — це PKCS#8 з шаром шифрування на основі пароля. Ця сторінка їх не приймає — спершу розшифруйте їх офлайн (openssl pkcs8 -in enc.pem -out plain.pem).

Типові помилки
  • Шифрування великих обсягів даних RSA. Понад жорсткий розмір OAEP це абсурдно повільно. Схема така: згенеруйте випадковий ключ AES, зашифруйте ключ AES за RSA-OAEP, зашифруйте дані AES-GCM, надішліть обидві частини.
  • Передача закритого ключа, бо «це тест». Зразкові ключі, вбудовані у вектори цієї сторінки, опубліковані навмисно — вони можуть підписувати лише тестові дані. Ваші ключі такими не є.
  • Перевірка закритим ключем. Зазвичай це «працює» математично, і деякі інструменти це дозволяють, але розповсюдження закритого ключа перевіряючим руйнує всю модель. Перевіряйте відкритим ключем (ця сторінка це забезпечує).
  • Порівняння підписів побайтово для перевірки коду. PSS (і OAEP) рандомізовані: два правильні запуски дають різні результати. Порівнюйте перевіркою, а не рівністю — лише підписи v1.5 детерміновані.
  • Ключі на 1024 біти «бо вони швидші». Вони також в межах досяжності добре фінансованої факторизації. Аргумент швидкості помер разом із гібридним шифруванням: RSA виконується один раз на сесію, а не на кожен байт.
  • Жорстко заданий розмір солі, відмінний від довжини хеша, для PSS. Верифікатор мусить погодитися; довжина хеша (вибір цієї сторінки і -sigopt rsa_pss_saltlen:32 OpenSSL) — сумісний типовий варіант.
Часті запитання (FAQ)

Чому моє розшифрування не вдалося з повідомленням «неправильний ключ, неправильний хеш або пошкоджений шифротекст»? Розшифрування OAEP не вдається, якщо будь-що з цього: це не відповідний закритий ключ, хеш відрізняється від боку шифрування, мітка відрізняється або змінено байт шифротексту. Помилка навмисно однакова у всіх випадках — показати, яка перевірка не пройшла, — саме є витоком оракула доповнення.

Чи можна отримати відкритий ключ із закритого? Так — приватні формати містять також n і e. Ця сторінка показує обидва після «Згенерувати»; OpenSSL робить це командою openssl pkey -in priv.pem -pubout.

Чому 65537 як експонента? Це просте число, має лише два біти 1 (швидке піднесення до степеня) і достатньо велике, щоб уникнути атак з малою експонентою, які вражають e=3. Це стандартний вибір з 1990-х; «дивна» експонента зазвичай означає слабкий або нестандартний ключ.

Чи RSA мертвий через квантові комп'ютери? Поки ні — не існує машини, що може виконати алгоритм Шора на 2048-бітному модулі. Але дані, які мають лишатися таємними до 2030-х і далі, уже мігрують; гібридні постквантові схеми — інженерна відповідь.

А що з openssl rsautl? Це застарілий предок pkeyutl. За замовчуванням він використовує доповнення шифрування v1.5 — ще одна причина, чому його вивели з ужитку.