AES, inden det blev standartiseret som AES, understøttede nøgler op til 2048 bits. Jeg har selv en Raptor Eagle firewall med 2048 bits AES.
NSA var aktivt med i standartiseringsprocessen... go figure.
menu close Teknologiens Mediehus
»Hvorfor bruger man ikke altid 8192-bit nøgler til AES og RSA?« cirka sådan lød spørgsmålet for et par dage siden. På overfladen et enkelt spørgsmål det er ligetil at besvare: Det tager for lang tid i forhold til hvad vi tror der er behov for.
Men under overfladen lurer der en række lige så indlysende spørgsmål som for eksempel hvorfor 256-bit er nok til AES, mens en RSA nøgle skal være på mindst 2048 bit eller hvorfor man ikke bare lige kan bruge AES med en 8192-bit nøgle. Det første er stadigvæk forholdsvist enkelt at svare på, mens det sidste kræver en del indsigt i AES-algoritmen, hvis man ikke skal ende med en mere usikker kryptering.
Jeg har interesseret mig en del for kryptografi og tror derfor at jeg har nogenlunde styr på området. Men hvad bør en gennemsnitslig udvikler eller systemadministrator vide om kryptografi? Kan man som administrator nøjes med at have en liste over godkendte konfigurationsparametre liggende og kan man som udvikler nøjes med at vide hvordan man salter og hasher et kodeord?
Hvis man som udvikler har bare det mindste behov for at bruge kryptografi, om det så er kryptering eller håndtering af kodeord, så synes jeg ikke det er godt nok. Selv vil jeg gerne anbefale bogen Cryptography Engineering af Niels Ferguson, Bruce Schneier og Tadayoshi Kohno. Har I andre gode anbefalinger?
AES, inden det blev standartiseret som AES, understøttede nøgler op til 2048 bits. Jeg har selv en Raptor Eagle firewall med 2048 bits AES.
NSA var aktivt med i standartiseringsprocessen... go figure.
Det bedste råd jeg har fået er "Hvis du ikke er ekspert i kryptografi skal du bruge et library eller noget kode som nogen der har forstand på det har lavet" Det er et godt råd, fordi der er så mange fejlmuligheder og gotchas at chancen for at man får skrevet noget der er fejlfrit er meget lille.
I kryptografi og authentication skal der som bekendt kun en enkelt fejl til før det hele ramler og din brugerdatabase/kunders kreditkortnumre/hemmelige noter ligger som en torrent på thepiratebay. Fakta er at det er meget få mennesker der er i stand til at skrive denne kode.
Max, det er selvfølgelig helt og aldeles korrekt, og der findes jo heldigvis fornuftige kryptobiblioteker at bruge løs af nu om dage. Men det er desværre kun en nødventig, langt fra en tilstrækkelig, betingelse for at slutresultatet bliver i orden.
Altså, hvad jeg har set derude! Store, kendte og i egen forståelse professionelle foretagender som har slået op i deres håndbøger, benyttet deres libraries og kodet best practice langt hen ad vejen, men så er ekspertisen, tålmodigheden eller kontrakten sluppet op, for kundernes passwords er alligevel endt i plaintext i en MySQL-base. Jeg har for ikke så forfærdelig længe siden haft et tilfælde i hænderne hvor massevis af danske journalister havde konti i sådan en biks. De fleste af dem bruger gmail-adresser eller lignende som brugernavne, og uden tvivl uændrede adgangskoder over hele linjen. Det er bare at logge ind og gå i gang hvis man er til den slags. Jeg påtalte problemstillingen, men blev - surprise, surprise - mødt af en uinteresseret og fjendtlig holdning, så de kan selv ligge og rode med deres lort, kan de.
Der forekommmer lignende i den offentlige it, nok oven i købet masser af det vil jeg gætte på, for dér er der jo slet ingen som nogensinde har et endeligt ansvar, og der er en udtalt mangel på beslutningstagere med skyggen af indsigt i teknologierne de har ansvar for. Hvis ikke vi allesammen er på Pirate Bay allerede med vores skat og sygdom og folkeregister, så kommer vi der uden tvivl snart.
AES, inden det blev standartiseret som AES, understøttede nøgler op til 2048 bits.
Samtlige referencer jeg kan finde til Rijndael beskriver at både key-size og block-size skal vælges blandt størelserne 128, 160, 192, 224 eller 256 bits, men mange implementationer springer tilsyneladende 160- og 224-bitudgaverne over.
Har du nogle referencer til hvor mange runder AES-2048 skulle være og hvordan key-schedule delen af algoritmen udvides til 2048 bit-nøgler?
Det vil jeg gerne se en reference på!
Rijndael går op til 256 bit, har aldrig set andet.
Og jeg har faktisk læst de oprindelige Rijndael udgivelser
Jeg kan kun støtte op om rådet om, at man skal bruge standard-libraries hvor muligt, og virkelig prøve at "tvinge" best practices igennem. Men det kan godt være svært. Min bedste erfaring er at bruge forskellige argumenter over for forskellige mennesker: Nogle gange handler det om lovgivning (vi MÅ ikke opbevare de data sådan), nogle gange om best practices som udvikler (man bør virkelig gøre sådan her ifølge ...), nogle gange om moral, nogle gange om penge (din virksomhed går ned hvis disse informationer bliver lækket).
Mht. nøglestørrelse: AES er symmetrisk kryptering, så der er det ikke så vigtigt med en stor nøgle, 256 bit er tilstrækkeligt. RSA er public-key, hvor man altså kender den offentlige nøgle, som alligevel gør det relativt (!) lettere at knække. Derfor bruges her større nøgler. Jeg er dog ikke kryptomand, men det er sådan jeg har forstået det. :)
Samtlige referencer jeg kan finde til Rijndael beskriver at både key-size og block-size skal vælges blandt størelserne 128, 160, 192, 224 eller 256 bits, men mange implementationer springer tilsyneladende 160- og 224-bitudgaverne over.
Jeg er ikke nogen cryptoekspert men mener bare at det er ret påfaldende at lige så snart NIST har fat i kryptering så kommer der sære begrænsninger.
Jeg skal se om jeg kan få liv i den PC som kørte Raptor Eagle... men jeg lover intet for bundkortet døde på den.
Min anbefaling: hvis du skal kode noget, så brug kun et kompletwrappende stdlib som keyczar [0] eller NaCl [1] - selv om det er et HELVEDE typisk til interoperabilitet med eksisterende systemer.
[0] https://code.google.com/p/keyczar/
[1] http://nacl.cr.yp.to/
Har I andre gode anbefalinger?
Et lille gratis kursus på universitetsniveau, måske?
Coursera udbyder "Cryptography I" fra den 1. april.
Man kan også følge en Cybersecurity Specialization.
Jeg har ikke prøvet nogen af delene, men jeg har dem (et stykke nede) på min to-do liste.
Det er svært at bruge krypto rigtigt!
Jeg anbefaler typisk "24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them" ISBN-13: 978-0071626750 - og den bog som allerede er nævnt. Ligesom det ser godt ud det nye site https://bettercrypto.org/
Så er man igang, og BURDE opdage at det er sværere end man måske tror!
Min anbefaling: hvis du skal kode noget, så brug kun et kompletwrappende stdlib som keyczar [0] eller NaCl [1] - selv om det er et HELVEDE typisk til interoperabilitet med eksisterende systemer.
I stedet for NaCl brug Sodium[0], det samme lib bare lettere at udvikle med og shippe som en del af sit program.
Jeg har bladret lidt rundt i den anbefalede bog Cryptography Engineering og den virker god. Det virker fornuftigt at alle systemudviklere i dag bør have en basisviden om kryptering - måske ikke for at gøre data NSA sikre men for at sikre at data ikke uden videre kan læses af almindeligt uvedkommende.
Jeg faldt blot over disse lidt ufrivilligt morsomme steder i teksten: "Even the existing functions in the SHA family have not been analyzed nearly enough, but at least they have been standardized by NIST, and they were developed by the NSA (1)". Og fodnoten: "(1) Whatever you may think about the NSA, so far the cryptography it has published has been quite decent." Yep. Men ikke nødvendigvis på den måde vi troede.
Og der er også denne: "None of the published designs for larger hash functions have received much public analysis; at least the SHA-2 family has been vetted by the NSA, which generally seems to know what it is doing." Yep. Det er fuldstændigt korrekt. De ved hvad de laver.
:-)
Det bedste råd jeg har fået er "Hvis du ikke er ekspert i kryptografi skal du bruge et library eller noget kode som nogen der har forstand på det har lavet"
Problemet er at de fleste libraries giver udvikleren en antal kombinationsmuligheder der får en kasse Lego-klodser til at minde om et samlesæt fra et Kinder-æg.
Det der gør kryptografi ekstra svært er at mange kritiske fejl opstår fordi man sætte byggeklodserne forkert sammen end fordi man laver dumme fejl i implementationen af de enkelte moduler. For eksempel fordi man vælger et dårligt IV eller vælger at transformere sine data på en dårlig måde før man bruger en rigtig hash-funktion. (For slet ikke at tale om folk der vælger ECB-mode fordi det er den først dokumenterede).
Keyczar og NaCl, som Christian Panton henviser til, er absolut skridt i den rigtige retning. Men endnu vælger folk langt oftere libraries som OpenSSL og Crypto++ der muligvis gør det lettere at implementere eksisterende designs, men som giver for mange kombinationsmuligheder hvis man forsøger at stykke et nyt design sammen fra begyndelsen af.
Jeg tror ikke at Keyczar og NaCl er nok til at udviklere kan undgå at skulle vide noget grundlæggende om kryptografi. Men de vil absolut gøre det lettere altid bare at vælge den nuværende anbefalede løsning.
Det der gør kryptografi ekstra svært er at mange kritiske fejl opstår fordi man sætte byggeklodserne forkert sammen end fordi man laver dumme fejl i implementationen af de enkelte moduler.
Det er absolut en af de allerstørste problemer på området: Alt for mange knapper at dreje på som kræver en up-to-date phd at vide hvordan man skal dreje på.
Jeg har endnu ikke set en SSL/TLS implementering jeg tør stole på.
Komplexiteten i sig selv er også helt ude i hampen.
OpenSSL er omkring 1000 kildetekstfiler med 380.000 linier kode.
OpenSSL er omkring 1000 kildetekstfiler med 380.000 linier kode.
Joe... jae... men det er jo ikke 1000 kildetekstfiler til at implementere et enkelt use case.
Jeg skal ikke forsvare kvaliteten af OpenSSLs kode. Jeg har ikke kigget i den.
Men jeg bemærker at ethvert projekt af "swiss army knife" typen med et plugin-interface som der over tid bliver tilføjet talrige moduler til jo nemt kan vokse til 1000 kildetekst filer uden at ret mange af dem er i sving i hvert use case.
Der er givetvis talrige filer med sjældent brugte algoritme-implementationer i OpenSSL de fleste aldrig ville savne hvis de forsvandt.
"(1) Whatever you may think about the NSA, so far the cryptography it has published has been quite decent." Yep. Men ikke nødvendigvis på den måde vi troede.
Tænker du på noget bestemt?
Jeg tror det mest velkendte eksempel hvor NSA har været involveret i at pille ved selve den offentliggjorte algoritmen var da IBM ændrede lidt på valget af S-box værdier for DES.
Siden har det så vist sig at NSA og IBM havde kendskab til differential kryptoanalyse og at de nye S-boxe var mere modstandsdygtige over for den type angreb.
"Håb er ikke viden siger farmor" for nu at citere CCC :-)
Næe nej... men der er sandelig forskel på at sige at OpenSSL er et problem fordi der er for meget krypto-kode som ikke er kigget igennem i lang tid og på at påstå at det simpelthen invokerer andre algoritmer end man beder det om.
Så kunne du tilsvarende argumentere med at Linux umuligt kan være stabilt, for kernen indeholder over 40.000 filer og selvom din hardware angiveligt er velunderstøttet, så har du ikke "viden", men kun "håb" om at den ikke kalder tilfældige mindre stabile driver i ny og næ.
Men den slags burde jo være betydeligt nemmere at overbevise sig selv om ved at kigge på koden end at verificere selve krypto-koden. Så istedet for at antyde at OpenSSL kunne finde på at kalde algoritmer man eksplicit havde bedt om ikke blev brugt, så kunne man vel relativt nemt opnå "viden" om hvorvidt det forholdt sig sådan ved at se efter.
Jeg mener... meget kan du sikkert med rette beskylde OpenSSL for, men hvis argumentet er at vi ikke kan vide noget om noget simpelthen fordi der er for mange filer, såe...
"Tænker du på noget bestemt?"
Ja. Jeg tænker på at ingen på det tidspunkt åbenbart tænkte ret meget over at det ikke var i NSA's interesse at lave ubrydelig kryptering - hvor ligetil den konklusion ellers må være. Derfor forekommer det med den nuværende viden mindre interessant at NSA har valideret en krypteringsteknik. Nu forekommer det vel direkte suspekt.
Jeg arbejdede med sikkerhed på det tidspunkt hvor public/private-key krypto blev mere moderne og kendt. På det tidspunkt ønskede NSA "key escrow" så de havde adgang til krypterede data. Men pludselig arbejde de ikke så hårdt for sagen længere. På det tidspunkt noterede jeg bare at det var lidt underligt og tænkte ikke så meget mere over det. Nu kan man tænke lidt videre over mulige årsager.
En anden ting der slår mig ved bogen Cryptography Engineering er den usikkerhed der er forbundet med de forskellige algoritmer. Der er ikke meget ifølge bogen som er dybt matematisk valideret forekommer det mig. Jeg opfatter det ikke som værende ensbetydende med at de algoritmer forfatterne foreslår er dårlige. Tværtimod. Men sagen er at algoritmerne kan siges sandsynligvis ikke at have åbenbare og kendte svagheder. Algoritmerne er gode men det er ukendt om der er teknikker som kan bryde dem.
Set i lyset af at vi nu ved at NSA angiveligt har flere matematikere og kryptoanalytikere end resten af verden tilsammen, så er det ikke sikkert man kan regne med at være NSA-sikker. Men man kan gøre sit bedste og følge best practice og dermed have et højt sikkerhedsniveau overfor almindeligt uvedkommende.
Min egen konklusion er at det bedste ville være at man havde en beskrivelse af best practice for håndtering af kryptering i forskellige situationer. Altså, brug dette library, følg disse trin etc. Hvis der er noget jeg udleder af bogen, som det også er konkluderet i denne debat, så er det at kryptering skal laves rigtigt. Man kommer nemt til at lave fejl hvis man ikke med stor sikkerhed ved hvad man gør.
Når det er sagt så ved jeg fra min fortid med sikkerhed at sikkerhedssystemerne skal nå dybere end blot at kryptere en kommunikationslinje og data. Crackere vil først søge at omgå sikkerhedssystemet før man forsøger at bryde det. Det er et interessant og vanskeligt område hvor der nok burde være mere og bedre information tilgængelig for systemudviklere, programmører m.v. fordi at der er meget andet at tænke på i et udviklingsforløb.
Jeg kan varmt anbefale coursera kurset Cryptography I.
Forelæseren brænder for emnet og kommer med flere eksempler
på hvor små fejl der skal til for at ødelægge sikkerheden. Hans
mantra, som gentages igen og igen er 'never ever implement your
own cryptography algorithm'.
Så hvis ikke andet sidder fast så har man forhåbentlig lært det.
+1 til Cryptography Engineering (ikke Applied Cryptography, med mindre du husker ikke at lave dit eget efter du har læst den!), nacl/sodium og Stanford Crypto I/II.
Gambling with Secrets er en god, letforståelig intro til "Hvad er RSA?", "Hvad er forskellen på public-key og secret-key crypto?"
Når jeg introducerer folk til kryptografi anbefaler jeg som regel Gambling with Secrets -> tag Cryptography I -> begynd med sodium hvis du skal lave dine egne 'high-level'-konstruktioner i et rigtigt program."
Ja. Jeg tænker på at ingen på det tidspunkt åbenbart tænkte ret meget over at det ikke var i NSA's interesse at lave ubrydelig kryptering - hvor ligetil den konklusion ellers må være.
Tænk, det er min opfattelse at de fleste anså ændringerne af DES som meget suspekt indtil differential kryptoanalyse blev genopfundet uden for NSA og man opdagede at ændringerne gjorde DES mere modstandsdygtig mod denne type angreb.
Det er i NSA's interesse at have adgang til stærk kryptering, men det er ikke i NSA's interesse at dele det når de finder svagheder eller nye teoretiske angrebsmuligheder.
Jeg tror at fodnoterne i Cryptography Engineering skal tages meget for pålydende. Det er med rette at folk ser med mistro på hvad der komemr ud fra NSA, men netop når de gælder teoretisk kryptografi så plejer de at have ret (selvom resten af verden først indser det med et par års forsinkelse).
Det forudsætter selvfølgelig at man har tillid til at folk som Bruce Schneier ikke bare er købt af NSA til at fremstå som uafhængig ekspert...
Kommentarerne var primært ment humoristisk ud fra hvordan verden nu ser ud post-Snowden. Det forekommer mig vanskeligt at tillægge NSA motiver ud over hvad der er deres opgave, at beskytte egne og staten USA's interesser - og måske til dels amerikanske virksomheder.
"man opdagede at ændringerne gjorde DES mere modstandsdygtig mod denne type angreb."
Jeg har læst lidt op på dette ud fra WIkipedia. Her står også: "NSA worked closely with IBM to strengthen the algorithm against all except brute force attacks and to strengthen substitution tables, called S-boxes. Conversely, NSA tried to convince IBM to reduce the length of the key from 64 to 48 bits. Ultimately they compromised on a 56-bit key." Det forekommer at NSA ikke styrkede algoritmen på alle punkter. Desuden var 70'erne en anden tid mht elektronisk kommunikation.
"Det er i NSA's interesse at have adgang til stærk kryptering, men det er ikke i NSA's interesse at dele det når de finder svagheder eller nye teoretiske angrebsmuligheder."
Ja, men det må igen være til eget, militærets og dermed statens brug. Det er derfor NSA's validering af kryptografiske teknologier ikke nødvendigvis er sket for at glæde hele verden. Man gjorde også hvad man kunne for at hemmeligholde differential kryptanalyse.
" … men netop når de gælder teoretisk kryptografi så plejer de at have ret (selvom resten af verden først indser det med et par års forsinkelse)."
Det er muligt. Men hvad er det vi som udenforstående ikke ved? har du nogle kilder der belyser hvad NSA gør?
"Det forudsætter selvfølgelig at man har tillid til at folk som Bruce Schneier ikke bare er købt af NSA til at fremstå som uafhængig ekspert."
Det er rigtigt. Men jeg har ikke sagt noget om dette. Jeg stiller bare spørgsmålet om hvordan vi nu post-Snowden forholder os til valideringer fra NSA og specielt hvordan vi forholder os til og bruger kryptografi generelt.
- Danmarks største job- og karrieresite for ingeniører og it-professionelle.
