Voi începe cu o comparație funcțională a RSAES-PKCS1-v1_5 cu RSAES-OAEP.
Ultimul este aproape substitutul modern al primului.
În primul rând, este practic imposibil să faci o bibliotecă care să implementeze decriptarea RSAES-PKCS1-v1_5 care să asigure securitatea împotriva atacurilor pe canalele laterale. Multe încercări de a obține securitate la nivel de aplicație au eșuat: un adversar capabil să facă un număr modest de interogări către un dispozitiv care efectuează decriptarea și să observe comportamentul acestuia (cod de eroare, dimensiunea pachetului, sincronizare, accesări pe disc, cache, sunet de alimentare...) adesea reușește [adică reușește să decripteze un mesaj pe care l-au interceptat sau să semneze un mesaj dacă cheia este cu dublă utilizare]. Atacul CCA al lui Bleichenbacher are atât de multe variante încât este greu de urmărit. Contrast cu RSAES-OAEP: o cantitate limitată de îngrijire în implementarea unei biblioteci previne atacul echivalent.
De asemenea, RSAES-PKCS1-v1_5 este definit pentru a permite aleatorie până la 64 de biți, ceea ce nu este suficient pentru standardele moderne pentru a preveni în mod robust testarea unei presupuneri exacte a textului simplu. Singura modalitate de a remedia acest lucru este de a preveni criptarea mesajelor prea aproape de dimensiunea maximă permisă.
RSAES-OAEP are o dovadă de securitate (în ipoteza că problema RSA este grea, iar hash-ul poate fi modelat ca o funcție pseudo-aleatorie, iar implementarea nu are un canal lateral). RSAES-PKCS1-v1_5 nu.
Un dezavantaj al RSAES-OAEP este că permite mesaje mai mici pentru același modul, dar aceasta este rareori o problemă în practică, deoarece atunci când dimensiunea mesajului crește, folosim criptare hibridă.
recomandări existente (de exemplu, CMS, PKIX) privind utilizarea și instanțierea RSAES-OAEP și RSASSA-PSS
După cum s-a arătat în cometariu la întrebarea, la cele mai bune practici actuale este să folosiți MGF1 cu același hash ca și pentru restul construcției. SHA-256 este comun, SHA-512 ar fi cel mai bine. Cea mai frecventă abatere de la aceasta este utilizarea SHA-1 în MGF1 pentru RSAES-OAEP, deoarece API-ul Java face o greșeală ușoară (vezi acest). Asta e încă sigur din câte știm.
Pentru RSASSA-PSS, o practică comună (dar nu cea mai bună) este să lăsați câmpul de sare gol, adică folosirea $sLen=0$ în EMSA-PSS.
Folosirea SHAKE-{128,256} ca MGF ar fi bună în teorie, dar nu a ajuns să se practice în aplicațiile pe care le cunosc și s-ar putea să nu o fac niciodată.
Există ID-uri atribuite (de la IANA sau organizații similare)?
Sunt OIDs pentru RSAES-OAEP, RSASSA-PSS, MGF1, SHA-256 și SHA-512. Acum, cum ar trebui utilizate aceste OID-uri în combinație, de ex. un certificat X.509 și există ceva care va continua să funcționeze dacă se încearcă asta? Trec.
