Puncte:4

Se poate folosi o semnătură digitală pentru a genera o cheie pentru criptarea AES?

drapel gf
cjd

Caut să văd dacă utilizarea unei semnături digitale este o modalitate sigură și rezonabilă de a genera o cheie pentru criptarea AES.

A curge ar fi după cum urmează:

Un utilizator semnează un mesaj m cu cheia lor privată. Ei semnează de fapt hash de m dar acest lucru este luat în considerare ca parte a funcției de creare a semnăturii digitale. Aceasta returnează semnătura digitală s.

Prevăzut s rămâne secret, este s un rezumat sigur de utilizat pentru a crea o cheie k pentru AES.

Ei cheie k va fi creat după cum urmează:

const crypto = require('cripto');

crypto.scrypt(s, 'unique-salt', keyLength, (err, key) => {
    console.log(key.toString('hex')); // 12dd454fb...
});

Unde primul parametru al funcției s este semnătura digitală creată de utilizator.

Documentația pentru pachetul cripto Node nu specifică nicio cerință pentru acest parametru.

Înțeleg că, dacă semnătura digitală este obținută de altcineva, atunci acea persoană poate decripta și cripta mesajele, totuși același lucru se poate spune dacă acea persoană obține orice șir folosit ca parametru.

Deci cele două întrebări sunt:

  1. Este aceasta o modalitate sigură și potrivită de a genera o cheie pentru AES? Presupunând că semnăturile digitale sunt unice și greu de ghicit de către persoanele care nu au acces la cheia privată. Și presupunând că semnătura digitală folosită pentru a crea cheia este păstrată privată.

  2. Securitatea depinde de mesaj m care este semnat? Trebuie ținut secret și acest lucru? Presupunerea mea este că nu contează care este mesajul, deoarece chiar dacă Mallet cunoaște acest mesaj, nu pot crea semnătura digitală corectă, deoarece nu au cheia privată.

Mulțumesc

poncho avatar
drapel my
Va trebui să partajați acea cheie AES cu cineva care nu cunoaște cheia privată de semnătură (sau sistemul de semnătură este nedeterminist - adică semnătura generată variază de fiecare dată când o generați, chiar și pentru același mesaj)? Dacă o faceți și aveți un transport sigur adecvat, ar funcționa soluția alternativă de a alege o cheie AES complet aleatorie?
Maarten Bodewes avatar
drapel in
@poncho Pentru (EC)DSA Bănuiesc că aveți $r$ aleatoriu care pot fi partajați public. În mod similar, puteți partaja o sămânță sau aleatorii generate pentru RSA-PSS, un fel de sare pentru un KDF. Deci nu sunt sigur că o funcție deterministă este o cerință, doar că puteți găsi o implementare care vă permite să injectați valori aleatorii.
Maarten Bodewes avatar
drapel in
Cred că întrebarea se reduce la: poate fi folosită generarea semnăturii ca funcție de derivare a cheii (KDF).
poncho avatar
drapel my
@MaartenBodewes: pentru (EC)DSA, publicarea a două semnături diferite cu același $r$ este o idee **RAĂ**; Aș sta departe de asta. Pe de altă parte, există versiuni deterministe sigure ale (EC)DSA
Maarten Bodewes avatar
drapel in
@poncho Nu sugerez asta. Spun că ați putea folosi o valoare aleatorie pentru o singură semnătură/derivare a cheii și apoi luați $r$ (scuze, probabil $k$) pentru a genera aceeași valoare folosind cheia privată *și același mesaj*. Evident, ar trebui să păstrați confidențialitatea valorii de $s$ dacă mesajul se poate schimba (acea a fost ideea tot timpul dacă nu mă înșel). Dar odată ce aveți cheia simetrică, puteți utiliza oricum o valoare MAC pentru a vă asigura că ambele părți au aceeași cheie.
cjd avatar
drapel gf
cjd
@poncho deci nu. Singura persoană care va decripta vreodată datele va fi utilizatorul care le-a criptat inițial și care deține cheia privată. Deci e bine?
cjd avatar
drapel gf
cjd
@MaartenBodewes cheia va fi în continuare derivată de funcția scryprt. Dar semnătura este folosită ca parolă secretă pentru a generaliza cheia.
Maarten Bodewes avatar
drapel in
Am văzut asta în acțiune pentru o funcție de generare a semnăturii RSA folosind umplutura PKCS#1 v1.5. Asta în sine nu înseamnă că este sigur, desigur ;) De rău: dacă vrei să-ți patentezi schema, ai întârziat cel puțin 20 de ani...
Puncte:3
drapel in

Da, poți folosi asta. Prin definiție, un atacator nu ar trebui să poată veni cu o semnătură orice mesaj specific fără cheia privată. Deci, dacă acesta este cazul, atunci o semnătură poate fi într-adevăr folosită ca o cheie simetrică și știu de un caz în care a fost folosită așa (sau cel puțin ca o cheie secretă, mai degrabă decât o cheie secretă).

Cu toate acestea, ar trebui să fiți atenți când faceți acest lucru. Unii algoritmi de semnătură sunt indeterminiști și asta ar putea complica lucrurile. În cel mai rău caz, ar putea face algoritmul de semnătură complet nesigur. În cel mai bun caz, ar putea fi nevoit să modificați rutina de generare a semnăturii pentru a injecta o valoare de bază sau aleatorie. De asemenea, ar fi necesar să stocați acea valoare de bază sau aleatorie, iar acest lucru ar putea fi contrar cerințelor dvs. de utilizare. Rețineți că, dacă ceva despre generarea numerelor aleatoare este schimbat - algoritmul, mecanismul de extracție sau extracția întregului - atunci probabil că veți obține cheia greșită (și da, am văzut că se întâmplă acest lucru).

Cu toate acestea, dacă ați folosi o versiune deterministă a RSA (padding PKCS#1 v1.5) sau ECDSA deterministă, atunci ar trebui să fiți în regulă.


Cu toate acestea, aveți dreptate să utilizați un KDF după date. O cheie simetrică ar trebui să extragă toate aleatoriile din semnătură pentru a fi sigură (eventual urmată de extinderea cheii pentru a ajunge la dimensiunea potrivită, dar acest lucru nu este de obicei necesar).

cripta cu toate acestea, este utilizat în general pentru parole. Este în regulă, dar probabil că nu aveți nevoie de sare sau de factorul de lucru pentru a întinde cheia (deoarece cantitatea de aleatorie din semnătură ar trebui să fie oricum suficient de mare). Deci este bine dacă cripta este necesar, dar, în mod normal, preferați să utilizați un KBKDF, cum ar fi HKDF sau doar HKDF-Extract.

Dacă aveți acces la valoarea cheii private, ați putea la fel de bine să utilizați KDF pentru asta.


Cu siguranță aș recomanda să utilizați un algoritm de generare a semnăturii care are cel puțin aceeași putere ca și cheia simetrică. Același lucru este valabil și pentru funcția KDF, desigur; puteti gasi detalii la keylength.com.

Mai mult, poate doriți să rețineți că criptografia simetrică este greu de atacat cu un computer cuantic cu drepturi depline, în timp ce algoritmii asimetrici nu sunt (deși această schemă poate fi mai greu de atacat decât o schemă generică de generare a semnăturii, în funcție de modul în care este utilizată). ).


Încă o notă de implementare: funcțiile de generare a semnăturii nu se așteaptă să păstrați semnătura secretă. De exemplu, un modul hardware ar putea fi capabil să păstreze o cheie simetrică derivată în mod normal în interiorul HSM. Pe de altă parte, ar putea exporta o semnătură fără agitație, așa cum este valoarea semnăturii presupus a fi public.

Ar putea fi, de asemenea, posibile atacuri ale canalelor laterale asupra valorii semnăturii, este greu de spus în avans. Deci, deși această schemă ar trebui să fie teoretic solidă, este totuși foarte nerecomandabil să faceți acest lucru, cu excepția cazului în care nu există altă cale.

cjd avatar
drapel gf
cjd
Asta e grozav! Apreciez cu adevărat răspunsul detaliat. Mulțumesc.

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.