NIST frigiver endelig version af SHA-3

Den kryptografiske hash-algoritme SHA-3, der har været ni år undervejs, er blevet frigivet i en endelig version. Forgængeren, SHA-2, er dog stadig sikker, oplyser standardiseringsorganisationen NIST.

Den amerikanske standardiseringsorganisation National Institute of Standards and Technology (NIST) har frigivet den endelige udgave af Secure Hash Algorithm-3 (SHA-3), afløseren for den kryptografiske hash-algoritme SHA-2

I en pressemeddelelse oplyser NIST, at SHA-3 har været ni år undervejs, og at det er den første kryptografiske hash-algoritme fra NIST, som er blevet til gennem en offentlig konkurrence. 64 projekter var tilmeldt konkurrencen, hvor vinderalgoritmen blev Keccak.

Et hold med fire personer fra DTU og tre fra Østrig deltog også i konkurrencen med algoritmen Grøstl. Den havnede blandt de fem bedste SHA-3-bud, men måtte se sig slået ved konkurrencens afslutning i 2012 af algoritmen Keccak, som blandt andet kryptologen Joan Daemen står bag.

Læs også: Skuffet DTU-hold hårsbred fra sejr i international algoritmedyst

NIST oplyser, at den endelige udgave af SHA-3 ikke adskiller sig nævneværdigt fra det udkast til algoritmen, der blev frigivet til offentligheden i maj 2014.

SHA-3 specificerer en familie af funktioner baseret på Kecak, oplyser NIST.

Og i den forbindelse påpeger organisationen, at SHA-3 ikke er den eneste familie af hash-funktioner, som NIST anerkender, men at den nuværende SHA2-familie fortsat også bliver betragtet som sikker.

»SHA-3 er meget forskellig fra SHA-2, hvad designet angår,« siger Shu-jen Chang fra NIST ifølge pressemeddelelsen og fortsætter:

»Den erstatter ikke SHA-2, som ikke har udvist problemer, men tilbyder en backup. Det tager år at udvikle en ny standard, og vi ville gerne være forberedte i fald, der opstår problemer.«

Shang oplyser videre, at de to standarder vil komplettere hinanden og tilbyde flere muligheder til både hardware- og software-designere.

Eksempelvis skulle nogle SHA-3-funktioner kunne implementeres uden ekstra krebsløbsfunktionalitet på en chip, hvilket - ifølge NIST-meddelelsen - kan gøre SHA-3-funktionerne til brugbare alternativer, hvad kryptering på meget små enheder angår.

Kryptografiske hash-algoritmer forvandler en input-værdi til en output-værdi, kaldet et message-digest, som i udgangspunktet er entydig, og som ikke kan tilbageføres til den oprindelige værdi.

Det kan eksempelvis bruges til at validere integriteten af en besked, en fil eller andet ved at beregne hash-værdien før og efter en transmission.

Et andet scenarie for brug af kryptografiske hashværdier er lagring af passwords, kortnumre eller andre følsomme oplysninger.

Ved at suse inputtet gennem en kryptografisk hash-algoritme og lagre message-digestet i stedet for det oprindelige input, kan brugerindtastede passwords valideres op mod hash-værdien, selvom passwords ikke ligger i klar tekst. Det kan give et ekstra lag af sikkerhed, såfremt databasen bliver kompromitteret.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (9)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Casper Thomsen

> Et andet scenarie for brug af kryptografiske hashværdier er lagring af
> passwords, kortnumre eller andre følsomme oplysninger.
>
> Ved at suse inputtet gennem en kryptografisk hash-algoritme og lagre
> message-digestet i stedet for det oprindelige input, kan brugerindtastede
> passwords valideres op mod hash-værdien, selvom passwords ikke ligger i klar
> tekst. Det kan give et ekstra lag af sikkerhed, såfremt databasen bliver
> kompromitteret.

Nu skal man passe på hvad der evt. måtte være ment med dette. Men, for en sikkerhedsskyld: Brug ALDRIG SHA-noget-som-helst-hjemmebryg til kodeord eller kortnumre. SHA-x er hurtig. Hvis databasen lækkes skal det være langsomt at tygge sig igennem dem. Brug scrypt, bcrypt, PBKDF2 eller en af vennerne. (Også selvom vi for nylig har hørt at Nets antageligt bruger en enkelt runde SHA-256 når de sender kortnumrene rundt til e-kvittering m.fl. Det. Er. Forkert.) Brug i det hele taget et færdigt lib til kodeord. Du har oddsene meget imod dig for at lave det rigtigt og sikkert.

Ud over at bruge en torx-skruetrækker til at få skruet din torx-skrue i (i stedet for din gode gamle SHA-hamm^Whøvl) så skal der selvsagt saltes og pebres alt hvad den kan trække. (Ja, både en individuel salt på hvert kodeord og en hemmelig salt, også kendt som "peber".)

Tillad mig at opfordre til at være ualmindeligt påpasselig ift. at forklare hvad man kan bruge kryptografiske stumper til.

  • 7
  • 0
Steen Thomassen

Nu skal man passe på hvad der evt. måtte være ment med dette. Men, for en sikkerhedsskyld: Brug ALDRIG SHA-noget-som-helst-hjemmebryg til kodeord eller kortnumre.


Hvorfor ikke? Har du noget information som du vil dele, som jeg ikke ved. Den gammel SHA-2 er stadig sikker nok. Og SHA-3 har været igennem en del reviews før det blev valgt til standard. Har de andre du nævner været igennem det samme behandling? (SHA-0 er død og SHA-1 er under afvikling)

  • 0
  • 0
Casper Thomsen

Mit svar står såmænd i sætningen lige efter det du hev ud som et citat, nemlig: "SHA-x er hurtig. Hvis databasen lækkes skal det være langsomt at tygge sig igennem dem."

SHA-(2|3) er helt fint til hvad den skal bruges til, men sha256("kodeord") er ikke en acceptabel måde at gemme kodeord på. Brug gerne en times tid på at læse tilfældige kilder på søgestrengen why is sha wrong for password storage.

Eksemplet med sha256(kortnummer) er helt til grin. De første 4 cifre er 4571 (på Visa/Dankort, som er størstedelen af kortene). Derefter 4 som er reg.nr. -- lad os være pessimistisk og antage at 1/10 er brugt. Altså er der 16-4-1-1 = 10 (det sidste "-1" pga. LUHN) cifre at traske igennem. Med en nogenlunde nymodens GPU tager det ikke et minut at have lavet alle 10^10 SHA256-hashes.

  • 3
  • 0
Casper Thomsen

> Men det er heller ikke det, som sker. Der laves en SHA-256(kortnummer|salt).

Korrekt. Men det er effektivt det e-kvittering mv. ser, fordi de jo i sagens natur kender salten (eller rettere peberen, når nu det ikke er en unik pr. kortnummer, men én fælles hemmelig). Så e-kvittering mv. kan brute-force'e alle kortnumrene på under et minut. (Outsidere er ikke de eneste angribere der findes.)

De burde have gjort brug af scrypt, bcrypt eller PBKDF2.

  • 3
  • 0
Bjarne Nielsen

Den bliver dels genereret ude i terminalen, og den bliver også genereret, når man opretter sig som bruger hos en udbyder af digitale kvitteringer.

Der er stadig ikke noget som siger, at saltet er kendt i videre kredse. Dels siger der ikke noget om, hvor hash genereres (det snildt være, at det for kvitteringsservices sker via Nets), og dels er der ikke noget som forhindrer at saltet ligger beskyttet på samme eller lignende måde hos udbyderne af digitale kvitteringer, som det ligger beskyttet i terminalerne.

  • 1
  • 0
Steen Thomassen

Mit svar står såmænd i sætningen lige efter det du hev ud som et citat, nemlig: "SHA-x er hurtig. Hvis databasen lækkes skal det være langsomt at tygge sig igennem dem."

SHA-(2|3) er helt fint til hvad den skal bruges til, men sha256("kodeord") er ikke en acceptabel måde at gemme kodeord på. Brug gerne en times tid på at læse tilfældige kilder på søgestrengen why is sha wrong for password storage.


Så har jeg dykket ned i materialet.

Jeg tjekkede, hvad for en algoritme, som bruges på min Debian - der står "$6$" i /etc/shadow ud for min konto. Og det står for SHA-512. Så SHA-512 bruges i en meget udbredt operativsystem! Søgning på "bcrypt sha512" gav mig et svar.

Over tid kan selv en langsom algorime som bcrypt blive hurtigere efterhånden som tekniken bliver bedre. Og omvendt kan man gøre sha-512 langsommere til passwords ved at kode et password i mange runder. I Linux's pam-modul er default er sat til 5000 og det kan konfigures til en højere værdi, hvis man ønsker det. Og derved gøre mere tidskrævede at gætte et password.

Omkring Dansk Supermarked: Vi ved ikke om deres salt opbevares i klartekst eller i en chip hos eKvittering. Hvis det er det sidste er bedre end det er i klartekst. Men vi ved det ikke! Jeg har prøvet at finde guidelines til det uden resultat.

Man kan stille spørgsmål om de valg man gjort til standarden bag "Purchase Secure Application Module". Det er vel EMV som står bag den. Og Nets bruger den fordi det er en standard, som butikkernes terminalerne håndterer. Men dem, som står bag PSAM, har valgt det kun skal være en simpel hash - og så her er SHA-256 jo en standard.

  • 2
  • 0
Log ind eller Opret konto for at kommentere