Puncte:1

Cum este reprezentat secretul partajat ECDH în SoftHSM

drapel ve

Lucrez la implementarea ECDH cu unele HSM. Conform teoriei din spatele ECDH, secretul partajat generat este un punct pe curba eliptică (x, y), care este exact ceea ce este returnat de HSM.

Dar când testez cu SoftHSM prin biblioteca PKCS#11, funcția ECDH returnează o cheie simetrică direct chiar și cu parametrul KDF setat la nul. Am făcut câteva cercetări și am descoperit că câțiva octeți ai secretului partajat sunt returnați ca valoare a cheii simetrice: https://github.com/google/boringssl/blob/master/include/openssl/ecdh.h#L82

Cu toate acestea, sunt confuz cum poate fi efectuată o astfel de operațiune asupra secretului partajat dacă este reprezentat sub forma unui punct EC (x, y).

Știe cineva cum SoftHSM gestionează ECDH cu parametrul KDF ca nul? Mai ales, în ce formă este secretul partajat după ce a fost generat în SoftHSM, dar înainte de a fi procesat și introdus într-un obiect cheie?

Mulțumiri

Maarten Bodewes avatar
drapel in
De obicei, coordonatele X, Y sunt codificate ca valori întregi mari, fără semn, dimensiuni static, și apoi concatenate. Octeții sunt apoi luați din partea stângă. Dacă ar trebui să ghicesc că asta ar fi ceea ce face o bibliotecă, dar pentru a fi sigur că ar trebui să te uiți în codul sursă *sau* să-l testezi cu o altă bibliotecă/pereche de chei.
drapel cn
Multe implementări ECDH calculează doar o coordonată a secretului partajat.
kelalaka avatar
drapel in
https://github.com/opendnssec/SoftHSMv2
Maarten Bodewes avatar
drapel in
@CodesInChaos Hei, mă bucur că încă ești aici! Da, m-am întrebat dacă ar fi trebuit să menționez că asta e o altă opțiune, că se folosește doar coordonatele X. Dar hei, când vine din partea stângă, sperăm că nu va face o mare diferență (desigur că o parte ar putea folosi doar X pentru derivarea cheii, iar cealaltă X și Y).
Fan Zhang avatar
drapel ve
Mulțumesc @MaartenBodewes pentru răspuns.M-am uitat în codul SoftHSM și face cam ceea ce ați spus, luând o anumită lungime din secretul generat. Dar sunt confuz cum secretul generat se transformă dintr-un punct EC în octeți. Sunt x și y transformați în octeți și concatenați sau există o metodă specifică? De exemplu, ECPublicKey este format ca tag + x + y. Mulțumiri!
Fan Zhang avatar
drapel ve
Mulțumesc @CodesInChaos pentru răspuns. If I have a generated secret as (64830192060261760049283727294808668110354933976341491567578109548061246609139, 59423428101938593951845145007294894818095890801518227616691263742277914054172) and want an AES128 key, you mean most implementations take the x coordinate and convert it into a byte array and then extract the first 128 bits of it? Mulțumiri
Maarten Bodewes avatar
drapel in
După cum se indică în primul comentariu, de obicei, acestea nu sunt transformate în codificare DER, ci păstrate în numere întregi cu semn static. Ar fi ciudat să codificați punctul cu octeți de date falși, deoarece nu doriți să aveți codificarea etichetei și a lungimii ca parte a cheii simetrice, doriți în mare parte date randomizate. Un KDF cu siguranță ar ajuta. Rețineți că coordonatele Y pot fi calculate din coordonatele X, așa că nu va avea prea mult sens să o includeți într-o cheie sau în materialul de introducere a codului de codare al unui KDF. Acesta este motivul pentru care multe implementări iau doar X, mai degrabă decât X și Y.

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.