Varför ska jag inte ' t använda ECB-kryptering?
On februari 18, 2021 by adminJag använder Java för att generera krypterade strängar och jag får den här varningen vid byggtiden:
ECB-krypteringsläge ska inte användas
Så jag undrar varför jag inte ska använda ECB och vad jag kan använda istället ?
Kommentarer
- Kommentarer är inte för utökad diskussion; denna konversation har flyttats till chatt .
- Arbetar du vid zoom?;)
Svar
Varför ska jag inte använda ECB-kryptering?
Den främsta anledningen att inte använda ECB-läge -kryptering är att den inte är semantiskt säkert — det vill säga att bara observera ECB-krypterad chiffertext kan läcka information om klartext (även utanför dess längd, vilket alla krypteringsscheman som accepterar godtyckligt långa enkla texter läcker i viss utsträckning).
Specifikt problemet med ECB-läge är att kryptering av samma block (med 8 eller 16 byte, eller hur stor blockstorleken för den underliggande chiffran är) av vanlig text med ECB-läge alltid ger samma block av chiffertext. Detta kan göra det möjligt för en angripare att:
- upptäcka om två ECB-krypterade meddelanden är identiska;
- upptäcka om två ECB-krypterade meddelanden delar ett gemensamt prefix;
- upptäcka om två ECB-krypterade meddelanden delar andra vanliga underlag, så länge dessa underlag är inriktade vid blockgränser; eller
- upptäcka om (och var) ett enda ECB-krypterat meddelande innehåller repetitiva data (såsom långa körningar av mellanslag eller nullbyte, upprepade rubrikfält eller tillfälligt upprepade fraser i text).
Det finns en bra grafisk demonstration av denna svaghet på Wikipedia, där samma (råa, okomprimerade) bild krypteras med både ECB-läge och ett semantiskt säkert chiffreringsläge (såsom CBC, CTR, CFB eller OFB):
Även om detta scenario är något artificiellt (man skulle vanligtvis inte kryptera råa bilder som detta), visar snyggt problemet med ECB-läge: repetitiva områden i den inmatade bilden resulterar i repetitiva mönster i den krypterade utdata, så att många storskaliga funktioner i bilden förblir igenkännliga trots krypteringen. baserad kryptering snarare skulle leta efter sådana mönster i en hex-dumpning av krypteringstexten, men principen är densamma.
Ett faktiskt fall av denna svaghet i ECB-kryptering som bidrar till en verklig datakompromiss är ges av Adobes lösenordsdatabasläcka , som beskrivs i detta svar . Här bidrog ett element till läckans svårighetsgrad att Adobe, i stället för att hashade dem ordentligt , hade krypterat lösenorden med ECB-läge. Detta gjorde det möjligt för angriparna att snabbt hitta lösenord som delas av flera konton eller dela ett gemensamt prefix med andra lösenord (som lösenord1 och lösenord2 ), och avslöjade också den ungefärliga längden på varje lösenord.
ECB-krypteringsläget har också andra svagheter, till exempel det faktum att det är mycket smidigt : som vardera block of plaintext är separat krypterat, en angripare kan enkelt generera nya giltiga ciphertexts genom att sammanföra block från tidigare observerade ciphertexts.
Men smidigheten är bara ett problem om ECB-kryptering används utan meddelandeautentiseringskod , och delas i denna situation (till viss del) av alla andra icke-autentiserade krypteringslägen , som ovan nämnda CBC, CTR, CFB och OFB. Det kan alltså inte betraktas som en specifik svaghet i ECB-läget, även om det tenderar att vara en ytterligare fråga när någonsin används ECB-läge.
Vad ska jag använda istället?
Du bör använda valfri autentiserad kryptering läge, till exempel GCM , EAX eller OCB .
Personligen, för korta meddelanden, är jag ganska förtjust i SIV-läge ( RFC 5279 ), vilket ger ett extra lager av motstånd mot missbruk. (Många andra krypteringslägen kommer att brytas ganska dåligt om samma IV / nonce av misstag används för att kryptera flera meddelanden. SIV-läge behåller alla sina säkerhetsegenskaper i denna situation, förutom att läcka om de krypterade meddelandena är identiska.)
Du kan också använda vilket traditionellt semantiskt säkert krypteringsläge som helst (t.ex. CBC eller CTR ), kombinerat med en meddelandeautentiseringskod (t.ex. HMAC ) med Kryptera -då-MAC konstruktion. (Det vill säga du bör först kryptera meddelandet, sedan beräkna en MAC för ciphertext och lägga till den i ciphertext.) Så länge du ser till att verifiera MAC innan du försöker dekryptera meddelandet, kommer denna konstruktion att skydda dig från de olika sårbarheterna i dessa lägen för aktiva (valt ciphertext) attacker.
För skivkryptering eller liknande applikationer som kräver förmåga att ändra delar i krypteringstexten utan att kryptera all data igen, bör du använda ett krypteringsläge som är utformat för detta ändamål, till exempel XTS . Observera att sådana lägen i allmänhet saknar motstånd mot aktiva attacker och kan ha andra svagheter som bör förstås innan du använder dem. Om möjligt bör de kombineras med någon form av integritetsskydd, till exempel en MAC på ett hashträd .
Kommentarer
- Vad skulle du föreslå i fall där man vill kunna läsa / skriva block i ett datalager i godtycklig sekvens, helst samtidigt som man gör en all-block-karta till en all- de blockerar? Min benägenhet skulle vara att kryptera genom att xora blockdata med en mycket enkel hash av blocknumret, ångra / upprepa xor-operationen om det ger ett all-block med ECB på resultatet och xoring med komplementet till resultatet att kryptera ett all-ones-block [som komplement behöver bara beräknas en gång för varje nyckel]. Skulle det verka som ett bra tillvägagångssätt?
- @supercat: Att ' är i grund och botten skivkryptering , så du kan använda lägen som är utformade för det. Jag tror att XTS anses vara ett bra val, även om det, som alla disk krypteringslägen, har sina begränsningar (som du bör förstå innan du använder det). Om möjligt bör det kombineras med en MAC av något slag för att försvara sig mot aktiva attacker.
- @IlmariKaronen: Jag tror att säga " don ' att använda ECB " är lite överdrivet. Jag förstår riskerna, men många gånger (såvida inte ditt dokument – vad du krypterar – inte är ' t mycket hemligt, och motståndaren inte ' t har för många funktioner osv.), du borde vara ok.
- @giorgim: Det finns ' egentligen ingen bra anledning att använda ECB (utom som en byggsten för andra lägen). Nästan alla kryptobibliotek erbjuder åtminstone CBC- eller CTR-läge, och om inte, ' är triviala för att implementera dig själv. Slå en HMAC (eller CMAC) ovanpå det och du ' är bra att gå.
- @giorgim: Även om du inte ' t något MAC- eller AE-läge tillgängligt, med CBC är fortfarande strikt bättre än ECB. Om du har en MAC-funktion är CBC-då-MAC ett perfekt bra AE-läge.
Svar
Du ska inte använda ECB-läge eftersom det kommer att kryptera identiska meddelandeblock (dvs. mängden data som krypteras vid varje anrop av blockkodningen) till identiska kodblock. Detta är ett problem eftersom det kommer att avslöja om samma meddelandeblock krypteras flera gånger. Wikipedia har en väldigt fin illustration av detta problem .
Kommentarer
- Kommentarer är inte för längre diskussion; den här konversationen har flyttats till chatt .
Svar
Som @Guut Boy nämnde det, är ECB inte semantiskt säker, i den meningen att om ett meddelande med identiska block är krypterat, så får en angripare en viss fördel att ha information i klartext, genom att bara observera CipherText.
Använd helst CBC-läge för att kryptera långa meddelanden. Detta läge introducerar en ytterligare parameter som kallas IV (Initial Value), du initialiserar med sessionsnumret för att förhindra attacker vid kryptering av samma meddelande två gånger.
Kommentarer
- IV står för initialiseringsvektor, inte initialvärde.
- 1. Detta är inte bra råd. Användning av kryptering utan autentisering bortser från ungefär ett decennium av råd från kryptografer. Det är bättre att använda autentiserad kryptering, som Ilmari Karonen rekommenderar. 2. Det här svaret verkar överträffas av Ilmari Karonen ' s svar.
- Förutom det är faktum att IV måste vara oförutsägbar för en angripare (dvs. som inte kan särskiljas från slumpmässigt), och det här svaret säger att du ska använda sessionsnumret, vilket vanligtvis inte är slumpmässigt alls.
Lämna ett svar