Puncte:4

Riscurile utilizării SHA1 în loc de SHA256 pentru RSA cu umplutură OAEP

drapel us

În prezent, implementez o criptare simplă bazată pe RSA, după cum urmează în PHP (folosind openssl_public_encrypt):

// $sRawText este șirul de text de criptat.
// $sPublicKey este cheia publică stocată pe server.
openssl_public_encrypt($sRawText, $sRezultat, $sPublicKey, OPENSSL_PKCS1_OAEP_PADDING);
// $sResult este rezultatul criptat care este apoi stocat.

M-am asigurat că folosesc opțiunea de umplutură OAEP, totuși umplutura se face cu SHA1 în loc de SHA256. PHP nu are o opțiune de umplutură încorporată care acceptă SHA256. De exemplu, biblioteca de criptografie a lui Python folosește SHA256 astfel:

din cryptography.hazmat.primitive import serialization
din cryptography.hazmat.primitives import hashes
din criptografie.hazmat.primitives.padding asimetric import
ciphertext = cheie_publică.encrypt(
    mesaj,
    padding.OAEP(
        mgf=padding.MGF1(algoritm=hashes.SHA256()),
        algoritm=hashes.SHA256(),
        label=Niciuna
    )
)

Singurele opțiuni pentru mine pentru a obține SHA256 pe PHP sunt să folosesc o bibliotecă terță parte, cum ar fi PHPSecLib sau EasyRSA. Am întâmpinat blocaje după câteva ore în care am încercat să instalez și să folosesc oricare dintre ele în mediul meu de găzduire partajată. (Ar fi ideal dacă aș putea pune un fișier .php care avea RSA într-un singur loc.)

Datele sunt criptate într-o bază de date pe un server online, iar asta trebuie să se întâmple în PHP, astfel încât să pot introduce noi intrări atunci când utilizatorii se înscriu (folosind cheia publică). Aș dori să mă asigur că, dacă datele criptate ale bazei de date și cheia publică ajung în mâini nefaste cu acces la un nivel rezonabil de putere de calcul, datele vor rămâne private (la fel de sigure ca un atac cu forță brută). Datele aflate în mâini greșite pot fi abuzate de utilizatorii de phishing sau pot crea afirmații false frauduloase.

Stocarea pe partea clientului nu funcționează, deoarece datele sunt deja în baza de date în prezent și am nevoie de anumite câmpuri, cum ar fi informații de contact, pentru a contacta utilizatorul. În plus, cred că majoritatea clienților vor pierde datele, care sunt irecuperabile și trebuie să fie în continuare disponibile peste câțiva ani. Cu toate acestea, nu vreau să am încredere deplină în mediul serverului, așa că aș dori să minimizez suprafața de atac doar la momentele specifice în care datele sunt utilizate. Este mult mai ușor pentru mine să păstrez acea cheie privată și frază de acces offline și în siguranță, decât să încerc să securizez o bază de date dinamică care se schimbă constant și trebuie stocată redundant.

Plănuiesc să fac toată manipularea datelor criptate offline și să folosesc întotdeauna câmpurile criptate ale bazei de date pentru verificare (adică datele se potrivesc cu ceea ce a introdus utilizatorul) sau pentru a număra intrările.Unele câmpuri din baza de date nu sunt sensibile, deci nu sunt criptate, iar altele, precum parolele, sunt hashing.

Ceea ce vreau să știu este, dacă voi continua cu implementarea de umplutură SHA1, la ce fel de atacuri m-ar deschide împotriva unui adversar cu datele criptate ale bazei de date și cheia publică. Cum ar proceda ei la aceste atacuri? Umplutura SHA256 ajută la protejarea mai bună a datelor și cum?

Multumesc mult!

kelalaka avatar
drapel in
Mulțumiri. Totuși, este sigur, deoarece MGF nu este o modalitate standard de a găsi coliziuni SHA-1. cu toate acestea, găsiți o modalitate de a migra` Migrați pentru a utiliza SHA-256; găsi modalități de a-l folosi.
drapel us
Înțeleg că SHA-256 este o alegere recomandată. Cu toate acestea, aș dori să înțeleg de ce și care este riscul cu SHA-1. Este MGF o funcție generatoare de moment?
Puncte:5
drapel cn

Puteți utiliza SHA-1 sau MD5 pentru OAEP. Nu te va expune la niciun atac.

OAEP folosește funcțiile hash pentru două lucruri: pentru a hash eticheta și ca parte a funcției de generare a măștilor, care, în practică, este întotdeauna MGF1 al unei anumite funcții hash.

Pentru etichetă, funcția hash este folosită doar pentru a transforma eticheta într-un separator de domeniu de text cifrat: la decriptare, un text cifrat cu hash de etichetă greșit este detectat ca nevalid. Atâta timp cât nu construiți eticheta din piese care pot fi furnizate de un adversar, nu riscați coliziuni. Și dacă construiți eticheta într-un mod complex și vă bazați pe ea pentru securitate, probabil că ar trebui să aveți o semnătură oricum.

Pentru MGF1, funcția hash este folosită ca un oracol aleatoriu. Proprietățile sale ca hash nu sunt relevante. Fostele funcții hash populare care au devenit depreciate sunt depreciate deoarece există atacuri concrete împotriva proprietăților lor ca funcții hash (în special, rezistența la coliziune). Cu toate acestea, ca oracole aleatorii, ele sunt considerate în continuare la fel de bune ca întotdeauna. (Au un defect cunoscut, care este extensia de lungime, și se aplică și lui SHA2, care nu are nicio defecțiune cunoscută ca funcție hash. Dar extensia de lungime nu se aplică oricum la MGF1 în OAEP, deoarece este folosită pe o intrare de dimensiune fixă ​​pentru o anumită cheie RSA.)

Utilizarea SHA-1 într-o construcție criptografică poate face auditorii să se încrunte și poate face ca sistemul dumneavoastră să nu fie conform cu anumite standarde de securitate. În ceea ce privește securitatea, este un pic o distragere a atenției, dar nu o vulnerabilitate.

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.