Splittet fra PHP > Dine PHP koder

[FraXinuS]

<?php
 /**
  * Get a key from a secret.
  * What we do is create two different hashes from the secret, combine them
  * and pick out the number of characters we need.
  * We used the raw binary output of the hash function for maximum
  * bit strength (we have 255 chars to choose from, instead of 16).
  *
  * @param string $secret
  *   The secret to generate a key from.
  *
  * @param integer $ks
  *   The key size.
  *
  * @return binary
  *   Key created from secret.
  */
 private static function getKey($secret, $ks) {
   /* Split the secret into two parts. */
   $secretSplit = floor(strlen($secret));
   $secret1 = substr($secret, 0, $secretSplit);
   $secret2 = substr($secret, $secretSplit);

   /* Hash the two parts seperatly and return the result in raw format. */
   $key1 = hash('sha256', $secret1, true);
   $key2 = hash('sha256', $secret2, true);

   /* Return the part of the key we need. */
   return substr($key2.$key1, 0, $ks);
 }

 

Til feks. kryptering.

 

Jeg skjønner ikke helt poenget med denne funksjonen.

 

For det første er det vel syntax error med private static utenfor en class.

For det andre så vil den første delen av nøkkelen, eller hele avhengig av størrelsen på $ks, alltid være den samme, da den første halvdelen alltid er en hash av en tom streng.

[xqus]

Jeg skjønner ikke helt poenget med denne funksjonen.

 

For det første er det vel syntax error med private static utenfor en class.

For det andre så vil den første delen av nøkkelen, eller hele avhengig av størrelsen på $ks, alltid være den samme, da den første halvdelen alltid er en hash av en tom streng.

 

Ja.. funksjonen hører da såklart til i en klasse.

 

Og det andre har du helt rett i, veldig bra sett...

Det skal jo såklart være:

$secretSplit = floor(strlen($secret)/2);

 

Poenget, forøvig er hvis du for eksempel har tenkt å bruke kryptere ting, så trenger du en måte å lage nøkkel fra en "hemlighet".

[JohndoeMAKT]

<?php
 /**
  * Get a key from a secret.
  * What we do is create two different hashes from the secret, combine them
  * and pick out the number of characters we need.

Eh. Reduserer ikke dette potensielt entropien og gjør egentlig ingenting for å forbedre den?

Endret 17. august 2011 av JohndoeMAKT

[xqus]

<?php
 /**
  * Get a key from a secret.
  * What we do is create two different hashes from the secret, combine them
  * and pick out the number of characters we need.

Eh. Reduserer ikke dette potensielt entropien og gjør egentlig ingenting for å forbedre den?

 

Hvordan da? Funksjonen er ikke ment for å øke entropien, bare beholde den.

[Jonas]

Hvordan da? Funksjonen er ikke ment for å øke entropien, bare beholde den.

Spørsmålet er vel heller hvordan i all verden denne funksjonen skal hjelpe til med sikkerhet. Hvorfor splitte en streng i to og ta hashen av delene hver for seg? Tror du det bedrer sikkerheten på noen måte? Dessuten ser det ut som funksjonen ikke oppfører seg helt som du har tenkt, som JohndoeMAKT allerede har nevnt.

Endret 21. august 2011 av Jonas

[JohndoeMAKT]

Hvordan da? Funksjonen er ikke ment for å øke entropien, bare beholde den.

Hva er det egentlig du mener den funksjonen gjør som er en fordel? «Get a key from a secret» Hva er forskjellen mellom en «key» og en «secret»?

[xqus]

Hva er det egentlig du mener den funksjonen gjør som er en fordel? «Get a key from a secret» Hva er forskjellen mellom en «key» og en «secret»?

Forskjellen er at en "key" i dette tilfellet er en ferdig formatert nøkkel som trygt kan benyttes i mcrypt biblioteket. Den gjør at du slipper å tenke på nøkkellengde. Du kan fint ha en "secret" som er bare 4 tegn, selv om krypteringsalgoritmen benytter en 128 tegns nøkkel.

 

Spørsmålet er vel heller hvordan i all verden denne funksjonen skal hjelpe til med sikkerhet. Hvorfor splitte en streng i to og ta hashen av delene hver for seg? Tror du det bedrer sikkerheten på noen måte? Dessuten ser det ut som funksjonen ikke oppfører seg helt som du har tenkt, som JohndoeMAKT allerede har nevnt.

Grunnen til at den splittes er egentlig bare for å få en større binærnøkkel. Akkurat den delen bedrer ikke sikkerheten nei, den bare øker nøkkellengden dersom det behøves. Jeg innser at med korte nøkler kan det ha en negativ effekt, men er fremdeles mye bedre enn den vanlige metoden: $key = md5($secret);

 

For øvrig er det mange gode kommentarer på http://no2.php.net/manual/en/function.mcrypt-module-open.php som tar opp akkurat dette emnet.

[JohndoeMAKT]

Forskjellen er at en "key" i dette tilfellet er en ferdig formatert nøkkel som trygt kan benyttes i mcrypt biblioteket. Den gjør at du slipper å tenke på nøkkellengde.

Med mindre du skal snakke med andre biblioteker enn mcrypt trenger du uansett ikke tenke på nøkkellengde. Og dette øker ikke den kompatibiliteten.

 

Du kan fint ha en "secret" som er bare 4 tegn, selv om krypteringsalgoritmen benytter en 128 tegns nøkkel.

Men nøkkelens styrke er fortsatt bare "fire tegn" uansett om du hasher den, deler den i 14, ganger hver bit med 3.14 og runder av til nærmeste toerpotens. Selv om du fyller hele nøkkellengden er styrken fortsatt de fire tegnene.

 

Med mindre dette er security by obscurity, men er det det du er ute etter er det lite vits å bruke et lib fra nettet.

[xqus]

Nøkkellengde varierer fra algoritme til algoritme. Å bruke en nøkkel som er kortere eller lenger enn nøkkellengde kan gjøre algoritmen sårbar.

 

Dette forenkler og er som sagt ikke ment til å øke bitstyrken til nøkkelen, bare beholde den og sørge for at lengden er korrekt.

[Jonas]

Å bruke en nøkkel som er kortere eller lenger enn nøkkellengde kan gjøre algoritmen sårbar.

Say what? Hvordan kan en nøkkel være kortere enn nøkkellengden? Eller lenger, for den saks skyld.

 

Dette forenkler og er som sagt ikke ment til å øke bitstyrken til nøkkelen, bare beholde den og sørge for at lengden er korrekt.

Isåfall, hvordan er getKey bedre enn noe så enkelt som hash('sha256', $value, true)?

[xqus]

Say what? Hvordan kan en nøkkel være kortere enn nøkkellengden? Eller lenger, for den saks skyld.

Beklager, ideell nøkkellengde.

 

Isåfall, hvordan er getKey bedre enn noe så enkelt som hash('sha256', $value, true)?

Eneste forskjellen er at du får nøkkelengder opp til 64 tegn, og ikke bare 32.

[Ernie]

Dette forenkler og er som sagt ikke ment til å øke bitstyrken til nøkkelen, bare beholde den og sørge for at lengden er korrekt.

Dette er helt feil. Du beholder aldeles ikke nøkkelkompleksiteten ved å kjøre det igjennom en «hash»-funksjon, du bare slører det hele til («security by obscurity»). Har du eksempelvis 4 byte (32 bit) inn i en «hash»-funksjon som gir ut 256 bit, er nøkkelen din effektivt fortsatt 32 bit. Såfremt metoden for å komme frem til nøkkelen som benyttes i kryperingen er kjent, har du da 2^32 mulige verdier inn i stedet for 2^256. Den eneste måten for å beholde nøkkelkompleksiteten er å ha en nøkkel som har 2^n mulige verdier inn, hvor n er nøkkellengden.

 

Red.: Det går forsåvidt an å beholde nøkkelkompleksiteten med en dårlig nøkkel inn. En teknikk for det er «key stretching»

Endret 22. august 2011 av Ernie

[xqus]

Dette forenkler og er som sagt ikke ment til å øke bitstyrken til nøkkelen, bare beholde den og sørge for at lengden er korrekt.

Dette er helt feil. Du beholder aldeles ikke nøkkelkompleksiteten ved å kjøre det igjennom en «hash»-funksjon, du bare slører det hele til («security by obscurity»). Har du eksempelvis 4 byte (32 bit) inn i en «hash»-funksjon som gir ut 256 bit, er nøkkelen din effektivt fortsatt 32 bit. Såfremt metoden for å komme frem til nøkkelen som benyttes i kryperingen er kjent, har du da 2^32 mulige verdier inn i stedet for 2^256. Den eneste måten for å beholde nøkkelkompleksiteten er å ha en nøkkel som har 2^n mulige verdier inn, hvor n er nøkkellengden.

 

Red.: Det går forsåvidt an å beholde nøkkelkompleksiteten med en dårlig nøkkel inn. En teknikk for det er «key stretching»

 

Du sier at hvis jeg har 32 bit inn, så har jeg fortsatt 32 bit ut. Hvordan kan du da si at jeg ikke beholder nøkkelkompleksiteten? 32 bit er vel ikke mindre kompleks enn 32 bit?

Jeg påstår ikke jeg er noe kryptografisk geni, jeg ønsker bare å lære.

[JohndoeMAKT]

Nøkkellengde varierer fra algoritme til algoritme. Å bruke en nøkkel som er kortere eller lenger enn nøkkellengde kan gjøre algoritmen sårbar.

Kan er et nøkkelord her. (*badumtish*)

 

Say what? Hvordan kan en nøkkel være kortere enn nøkkellengden? Eller lenger, for den saks skyld.

Det vanlige er å padde nøkkel opp til nøkkellengde. mcrypt null-padder, Bouncy Castle av gammel versjon bruker paddingmetoden definert i PKCS#5 mens nyere og .NET bruker PKCS#7 om jeg husker rett. (Når jeg har kommunisert med .NET- og Java-utviklere har jeg fått de til å bruke null-padding i sine verktøy for kompabilitet med mine data.

 

Jeg har aldri hørt at null-padding av key er et problem ved bruk av AES hvertfall.

 

Du sier at hvis jeg har 32 bit inn, så har jeg fortsatt 32 bit ut. Hvordan kan du da si at jeg ikke beholder nøkkelkompleksiteten? 32 bit er vel ikke mindre kompleks enn 32 bit? Jeg påstår ikke jeg er noe kryptografisk geni, jeg ønsker bare å lære.

 

substring(hash(16bit) . hash(16bit), <100%) kan være av lavere kompleksitet enn 32 bit og hvertfall ikke høyere.

[xqus]

Nøkkellengde varierer fra algoritme til algoritme. Å bruke en nøkkel som er kortere eller lenger enn nøkkellengde kan gjøre algoritmen sårbar.

Kan er et nøkkelord her. (*badumtish*)

Jeg tør ikke spekulere i dette. Det går langt over min forstand. Sikkert over presten sin også. Jeg har tatt utgangspunkt i det som har stått i PHP manualen og forbedret det.

 

Say what? Hvordan kan en nøkkel være kortere enn nøkkellengden? Eller lenger, for den saks skyld.

Det vanlige er å padde nøkkel opp til nøkkellengde. mcrypt null-padder, Bouncy Castle av gammel versjon bruker paddingmetoden definert i PKCS#5 mens nyere og .NET bruker PKCS#7 om jeg husker rett. (Når jeg har kommunisert med .NET- og Java-utviklere har jeg fått de til å bruke null-padding i sine verktøy for kompabilitet med mine data.

 

Jeg har aldri hørt at null-padding av key er et problem ved bruk av AES hvertfall.

Jeg var klar over at data ble paddet for å få korrekt størrelse på blokker, men har ikke hørt så mye om key padding, men når du sier det så høres jo det fornuftig ut.

 

Du sier at hvis jeg har 32 bit inn, så har jeg fortsatt 32 bit ut. Hvordan kan du da si at jeg ikke beholder nøkkelkompleksiteten? 32 bit er vel ikke mindre kompleks enn 32 bit? Jeg påstår ikke jeg er noe kryptografisk geni, jeg ønsker bare å lære.

 

substring(hash(16bit) . hash(16bit), <100%) kan være av lavere kompleksitet enn 32 bit og hvertfall ikke høyere.

 

Nå er vel sha-256 32 bit i utgangspunktet. Men jeg kjøper teorien din. Jeg var inne på tanken å ta annenhver byte fra hvert hash for å beholde entropi, men har egentlig bestemt meg for å droppe hele funksjonen og heller bare padde nøkkelen dersom nødvendig.

[JohndoeMAKT]

Jeg tror å holde det så enkelt som mulig er det beste. (Med mindre security by obscurity er målet. (Noe som på ingen måte trenger å være negativt))

[Terrasque]

Du sier at hvis jeg har 32 bit inn, så har jeg fortsatt 32 bit ut. Hvordan kan du da si at jeg ikke beholder nøkkelkompleksiteten? 32 bit er vel ikke mindre kompleks enn 32 bit?

Jeg påstår ikke jeg er noe kryptografisk geni, jeg ønsker bare å lære.

 

Du returnerer bare en substring av hash'en?

 

Uansett, bruk heller hash() med sha512 Hvis du trenger dobbel lengde med data av det sha256 bruker, så bruker du sha512, ikke sha256 to ganger..

[Ernie]

Dette forenkler og er som sagt ikke ment til å øke bitstyrken til nøkkelen, bare beholde den og sørge for at lengden er korrekt.

Dette er helt feil. Du beholder aldeles ikke nøkkelkompleksiteten ved å kjøre det igjennom en «hash»-funksjon, du bare slører det hele til («security by obscurity»). Har du eksempelvis 4 byte (32 bit) inn i en «hash»-funksjon som gir ut 256 bit, er nøkkelen din effektivt fortsatt 32 bit. Såfremt metoden for å komme frem til nøkkelen som benyttes i kryperingen er kjent, har du da 2^32 mulige verdier inn i stedet for 2^256. Den eneste måten for å beholde nøkkelkompleksiteten er å ha en nøkkel som har 2^n mulige verdier inn, hvor n er nøkkellengden.

 

Red.: Det går forsåvidt an å beholde nøkkelkompleksiteten med en dårlig nøkkel inn. En teknikk for det er «key stretching»

 

Du sier at hvis jeg har 32 bit inn, så har jeg fortsatt 32 bit ut. Hvordan kan du da si at jeg ikke beholder nøkkelkompleksiteten? 32 bit er vel ikke mindre kompleks enn 32 bit?

Jeg påstår ikke jeg er noe kryptografisk geni, jeg ønsker bare å lære.

Vel, da skjønte du litt mer enn det virket som. I det minste ser du at den effektive nøkkelen har kompleksitet på 32 bit hvis funksjonen blir matet det inn.

 

Nei, sånn sett mister du ikke kompleksitet. Derimot forsyner du en krypteringsfunksjon med en dårligere nøkkel enn den bør være. I stedet for å balle med en «hash»-funksjon kunne du likegodt bare lagt på NULL-byter (eller et annet bestemt tegn) for å oppnå ønske nøkkellengde. I forhold til sikkerheten er det iallfall minimal forskjell. Skal man mate en krypteringsfunksjon med dårlige nøkler (noe det er hvis lengden er kort) bør man benytte andre metoder for å oppnå at «brute force»-angrep på selve sluttnøkkelen (det du mater inn i krypteringen) er det raskeste angrepet, ikke det å angripe metoden for å komme frem til den nøkkelen. «Key stretching» er en måte å løse problemet på.

 

Uansett, benytter man kryptering er det gjerne en grunn til at man gjør det, og da passer det dårlig med en dårlig, kort nøkkel fordi man har mulighet til å velge nettopp en kort nøkkel.