Начну с функционального сравнения RSAES-PKCS1-v1_5 с РГАЭС-ОАЭП.
Последний является современной почти заменой первого.
Прежде всего, практически невозможно создать библиотеку, реализующую расшифровку RSAES-PKCS1-v1_5, обеспечивающую защиту от атак по сторонним каналам. Многие попытки обеспечить безопасность на уровне приложений потерпели неудачу: злоумышленник может сделать небольшое количество запросов к устройству, выполняющему дешифрование, и наблюдать за его поведением (код ошибки, размер пакета, время, доступ к диску, кеш, звук источника питания…) часто удается [то есть удается расшифровать одно сообщение, которое они перехватили, или подписать одно сообщение, если ключ имеет двойное назначение]. Атака Блейхенбахера CCA имеет так много вариаций, что трудно уследить. В отличие от RSAES-OAEP: ограниченное внимание к реализации библиотеки предотвращает эквивалентную атаку.
Кроме того, RSAES-PKCS1-v1_5 определен так, чтобы допускать 64-битную случайность, чего недостаточно по современным стандартам для надежного предотвращения проверки точного предположения открытого текста. Единственный способ исправить это — запретить шифрование сообщений слишком близко к максимально допустимому размеру.
RSAES-OAEP имеет доказательство безопасности (в предположении, что проблема RSA сложна, а хеш может быть смоделирован как псевдослучайная функция, а реализация не имеет побочного канала). RSAES-PKCS1-v1_5 — нет.
Одним из недостатков RSAES-OAEP является то, что он позволяет использовать меньшие сообщения для того же модуля, но на практике это редко является проблемой, поскольку при увеличении размера сообщения мы используем гибридное шифрование.
существующие рекомендации (например, CMS, PKIX) по использованию и внедрению RSAES-OAEP и RSASSA-PSS
Как указано в комментарий на вопрос, т. текущая передовая практика заключается в использовании MGF1 с тем же хэшем, что и для остальной части конструкции. SHA-256 распространен, лучше всего SHA-512. Наиболее распространенным отклонением от этого является использование SHA-1 в MGF1 для RSAES-OAEP, потому что Java API допускает легкую ошибку (см. это). Это все еще безопасно, насколько нам известно.
За РСАССА-ПСС, обычная (но не лучшая) практика - оставить поле соли пустым, то есть использовать $sLen=0$ в ЭМСА-ПСС.
Использование SHAKE-{128,256} в качестве MGF было бы разумным в теории, но не применялось на практике в известных мне приложениях и, возможно, никогда не будет.
Имеются ли назначенные идентификаторы (от IANA или аналогичных организаций)?
Есть OIDс для РГАЭС-ОАЭП, РСАССА-ПСС, MGF1, ША-256 и ША-512. Теперь, как эти OID должны использоваться в комбинации, например. сертификат X.509, и есть ли что-то, что будет продолжать работать, если это попытаются сделать? Я пас.
