Puncte:2

Cât de importantă este verificarea în timp constant a etichetei lHash în RSA-OAEP?

drapel vu

În implementarea proiectului meu hobbyist al RSA-OAEP, am omis suportul pentru etichete la început. Am setat eticheta la șir gol la criptare și am ignorat eticheta la decriptare.

Acum adaug o funcție specială pentru a seta și a testa eticheta, dar încă nu este în timp constant. Nota de securitate din PKCS#1v2.2 spune că verificarea etichetei împreună cu alte verificări ale textului cifrat ar trebui să se facă ca un pas de timp constant atomic.

Î1: Deci vreau să întreb: cât de periculos este să verifici eticheta în timp constant?

Mă gândesc la o etichetă secretă pre-partajată ghicită de un străin cu cheia publică de criptare ca un scenariu, Q2: mai sunt si altii?

fgrieu avatar
drapel ng
Întrebarea folosește RSA-OAEP unde în mod clar înseamnă [RSAES-OAEP](https://pkcs1.grieu.fr/page=#%5B%7B%22num%22%3A44%2C%22gen%22%3A0%7D% 2C%7B%22name%22%3A%22XYZ%22%7D%2C118%2C640%2Cnull%5D). Acea licență este bună și comună.Cu toate acestea, trebuie remarcat faptul că RSAES-OAEP este reducerea la practica a [RSA-OAEP](https://cseweb.ucsd.edu//~mihir/papers/oaep.pdf) și are câteva diferențe, inclusiv introducerea etichetelor.
Puncte:2
drapel ng

cat de periculos este sa verifici eticheta nu in timp constant?

Din cate pot spune nu prea multe, atata timp cat eticheta este publica, iar aceasta verificare se face si nu este conditionata de verificarea octetului 0x00 din stanga rezultatului decriptarii RSA raw/manual. $c^d\bmod n$. Acest lucru se aplică indiferent dacă operația de decriptare are suport pentru etichete.


The notă de securitate în PKCS#1v2.2 mentionat in intrebare suna:

Notă. Trebuie avut grijă să se asigure că un adversar nu poate distinge diferitele condiții de eroare din Pasul 3.f, fie prin mesaj de eroare sau prin sincronizare, sau, mai general, să învețe informații parțiale despre mesajul codificat. EM. În caz contrar, un adversar poate obține informații utile despre decriptarea textului cifrat C, ceea ce duce la un atac cu text cifrat ales, cum ar fi cel observat de Manger.35].

Nota respectivă se referă de fapt la testul (îngroșat mai jos) de la sfârșitul pasului 3.g al operației de decriptare:

Separa DB într-un șir de octet lHashâ de lungime hLen, un șir de umplutură (posibil gol). PS format din octeți cu valoarea hexazecimală 0x00 și un mesaj M as
     DB = lHashâ || PS || 0x01 || M .
Dacă nu există un octet cu valoare hexazecimală 0x01 de separat PS din M, dacă lHash nu este egal lHashâ, sau daca Y este diferit de zero, scoateți „eroare de decriptare” și opriți.

âverifica etichetaâ în întrebare se referă la compararea lHash (hash-ul etichetei sau al șirului gol este că nu există etichetă) și lHashâ. Octetul Y este cel din stânga șirului de octeți reprezentând $c^d\bmod n$ în notație big-endian pe tot atâtea octeți cât este necesar pentru a reprezenta modulul public $n$, și $c$ în esență este textul cifrat prezentat motorului de decriptare.

Dacă efectuăm comparația de lHashâ și lHash numai conditionat daca comparatia de Y la 0x00 reușește (de exemplu, dacă comparăm Y || lHashâ la 0x00 || lHash cu memcmp al bibliotecii standard C), atunci ne aflăm tocmai în condițiile cerute de Atacul lui Manger, care permite descifrarea unui mesaj prin trimiterea iterativă a criptogramelor incorecte la un dispozitiv de decriptare și observând reacția acestuia.

Dacă efectuăm comparația de lHashâ la lHash în timp non-constant dar indiferent dacă Y se potrivește cu 0x00 (și efectuează acel test de Y și este o agregare cu testul de lHashâ în timp constant, sau efectuați acel test de Y conditionat daca comparatia de lHashâ la lHash reușește), situația nu este nici pe departe la fel de rea, deoarece variația noastră de timp nu dă nicio idee despre dacă Y se potrivește cu 0x00, care este ceea ce adversarul dorește cel mai mult să știe. Chiar dacă adversarul încă obține informații parțiale despre EM, nu văd că un atac poate fi făcut să funcționeze, chiar și cu mult mai multe interogări către motorul de decriptare, deoarece fiecare octet de lHashâ la momentul comparației depinde de fiecare bit de EM pe langa cei din Y.

Nu se verifică lHashâ nu este o implementare corectă a RSAES-OAEP fără suport de etichetă (în acest caz, comparația trebuie efectuată împotriva hash-ului șirului gol) și este probabil să activeze atacul lui Manger.


Mă pot gândi la o etichetă secretă pre-partajată care este ghicită de un străin cu cheia publică de criptare ca un scenariu.

Imaginea mea mentală pentru etichetă este că este a public constantă menită să permită ca o singură pereche de chei publice/private să fie utilizată în diferite contexte independente. Acest lucru este util pentru a evita atacurile care transmit an extern text cifrat autentificat (de exemplu, semnat de autor) într-un context care nu este destinat să-l primească. Nu mi-am dat seama niciodată că eticheta (sau hash-ul) poate fi un secret pre-partajat și folosit pentru a autentifica criptogramele trimise la un dispozitiv de decriptare RSAES-OAEP. Dacă există o dovadă de securitate a RSAES-OAEP sub acea utilizare, am ratat-o. Și într-adevăr este atunci ultra-critic că comparația între lHashâ și lHash este în timp constant.

Mai sunt și alții?

Lângă Atacul lui Manger considerat mai sus, nu vad niciunul.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.