Puncte:1

Generarea și codificarea cheilor HMAC

drapel ng

Am această bucată de cod .NET care se bazează pe un Exemplu Microsoft despre cum să generați o cheie și să semnați folosind HMACSH256.

Dar am modificat puțin generarea cheii și am decis să folosesc Base64 pentru a transporta cheia ca șir:

Generare cheie:

octet[] cheie secretă = octet nou[64];

folosind (RNGCryptoServiceProvider rng = nou RNGCryptoServiceProvider())
{
    rng.GetBytes(secretkey);
    folosind (SHA512 mySHA256 = SHA512.Create())
    {
          var hashedKey = mySHA256.ComputeHash(secretkey);
          var encodedKey = Convert.ToBase64String(hashedKey);
          return encodedKey;
    }
}

Așadar, pe lângă generarea de octeți aleatori, am decis să trimit cheia cu SHA512. Apoi, codificarea Base64 pentru a obține reprezentarea finală a șirului, care va fi folosită numai în transport, deoarece înainte de utilizare, receptorul mesajului va decoda înapoi în rezumatul SHA512.

Aveți probleme cu felul în care o fac? Dacă nu mă înșel, tot ce va face hashingul este să introducă mai multă aleatorie, deoarece cheia va rămâne la lungimea de 64 de octeți. Merita?

De asemenea, există probleme cu transportul cheii ca șir Base64?

Mulțumesc și sper că cineva poate oferi feedback în acest sens. Sa ai una buna!

Puncte:1
drapel cn

tot ce va face hashingul este să introducă mai multă aleatorie

Nu. Nu poți introduce aleatorietatea printr-un proces determinist. Puteți introduce aleatorie doar cu o sursă reală de date aleatorii.

Puteți folosi un hash ca a componentă a unui generator pseudoaleator și un generator pseudoaleatoriu (securizat din punct de vedere criptografic!) este suficient de bun pentru criptografie unde este nevoie de aleatorie, dar o altă componentă vitală a unui generator pseudoaleator este un secret. Acest secret este starea generatorului aleatoriu, care este derivat dintr-o sămânță aleatorie: un generator pseudoaleatoriu nu creează aleatoriu, ci doar „îl „multipește” în sensul că poate transforma o cantitate mică de date aleatoare într-o cantitate mare. cantitatea de date aleatorii.

Hashingul unui șir aleatoriu reduce doar aleatoritatea acestuia: este teoretic posibil ca două șiruri de intrare să aibă același hash (nu veți găsi de fapt astfel de șiruri și nu suntem siguri că există, dar sunt șanse să existe). Aleatoria este redusă doar cu o cantitate mică, așa că aceasta nu este o vulnerabilitate reală a codului dvs., dar este o complicație inutilă și contraproductivă.

Modul de a maximiza aleatorietatea este de a obține rezultate de la un generator aleatoriu. Apel rng.GetBytes(secretkey) si opreste-te acolo.

Convertirea cheii în Base64 pentru transport și apoi înapoi în binar pentru utilizare nu are niciun impact asupra criptografiei. Este doar o codificare. Decodați-l: utilizarea Base64 ca cheie ar putea reduce securitatea, deoarece fiecare octet poate avea doar 1/4 din valorile posibile. (Modul în care HMAC își folosește cheia, de fapt nu ar conta dacă utilizați base64(random_bytes(64)) sau random_bytes(64) ca cheie; dar acest lucru ar conta, de exemplu, pentru o cheie AES, care nici măcar nu ar avea o lungime acceptabilă.)

danutz_plusplus avatar
drapel ng
Mulțumesc pentru postarea iluminatoare. Da, acum că o menționezi, este evident că, deoarece digest-ul este într-un spațiu redus de valori, teoretic va fi redus. Acum că mă gândesc bine, mi-a venit ideea dintr-un alt sistem în care am văzut că foloseau parole generate aleatoriu (să nu fie folosite de oameni efectivi) și au indexat valorile înainte de a le stoca. Dar acum că mă gândesc la asta, cred că asta a fost mai mult în scopul de a nu permite ingineria inversă a valorilor lor. Așa cum faci de obicei cu parolele.
danutz_plusplus avatar
drapel ng
Despre codificare, da, m-am gândit la fel de mult că trebuie să o decodez înainte de a o folosi. Din fericire, API-ul este suficient de inteligent încât să nu accepte nici măcar un șir. Acceptă doar un octet[].
danutz_plusplus avatar
drapel ng
De asemenea, vă rugăm să ignorați repetarea „acum că mă gândesc la asta”. Se pare că nu m-am gândit exact la răspuns și am continuat să-l editez până când a reușit să-și piardă aproape orice sens. :D Si acum nu il pot edita timp de 5 minute :D

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.