Waarom zou ik niet ' t ik ECB-encryptie gebruiken?
Geplaatst op februari 18, 2021 door adminIk “gebruik Java om versleutelde strings te genereren, en ik krijg deze waarschuwing tijdens het bouwen:
ECB-coderingsmodus mag niet worden gebruikt
Dus ik vraag me af waarom ik geen ECB zou moeten gebruiken en wat ik in plaats daarvan kan gebruiken ?
Reacties
- Reacties zijn niet voor uitgebreide discussie; deze conversatie is verplaatst naar chat .
- Werk je met zoom?;)
Antwoord
Waarom zou “ik geen ECB-codering gebruiken?
De belangrijkste reden om de ECB-modus codering niet te gebruiken, is dat het niet semantisch veilig — dat wil zeggen, alleen het observeren van door de ECB versleutelde cijfertekst kan informatie over de platte tekst lekken (zelfs buiten de lengte, die alle versleutelingsschemas die willekeurig lange platte teksten accepteren, zullen tot op zekere hoogte lekken).
Specifiek Het probleem met de ECB-modus is dat het versleutelen van hetzelfde blok (van 8 of 16 bytes, of hoe groot de blokgrootte van de onderliggende code ook is) van leesbare tekst in de ECB-modus altijd hetzelfde blok met cijfertekst oplevert. Hierdoor kan een aanvaller:
- detecteren of twee door de ECB versleutelde berichten identiek zijn;
- detecteren of twee door de ECB versleutelde berichten een gemeenschappelijk voorvoegsel delen;
- detecteren of twee door de ECB versleutelde berichten andere gemeenschappelijke substrings delen, zolang die substrings maar op blokgrenzen zijn uitgelijnd; of
- detecteren of (en waar) een enkel door de ECB versleuteld bericht repetitieve gegevens bevat (zoals lange series spaties of nulbytes, herhaalde koptekstvelden of toevallig herhaalde zinnen in tekst).
Er “een mooie grafische demonstratie van deze zwakte op Wikipedia, waar dezelfde (onbewerkte, niet-gecomprimeerde) afbeelding wordt versleuteld met zowel de ECB-modus als een semantisch veilige coderingsmodus (zoals CBC, CTR, CFB of OFB):
Hoewel dit scenario enigszins kunstmatig is (men zou gewoonlijk geen onbewerkte afbeeldingen op deze manier versleutelen), demonstreert mooi het probleem met de ECB-modus: repetitieve gebieden in het invoerbeeld resulteren in repetitieve patronen in de versleutelde uitvoer, zodat veel grootschalige kenmerken van het beeld ondanks de versleuteling herkenbaar blijven. In de echte wereld valt een crypto-analist een ECB- gebaseerde codering dergelijke patronen zoeken in een hexadecimale dump van de cijfertekst, maar het principe is hetzelfde.
Een feitelijk geval van deze zwakte van de ECB-codering die bijdraagt aan een real-world gegevenscompromis is gegeven door het Adobe-wachtwoorddatabase-lek uit 2013 , zoals beschreven in dit antwoord . Hier was een element dat bijdroeg aan de ernst van het lek dat Adobe de wachtwoorden had gecodeerd in de ECB-modus in plaats van ze correct te hashen . Hierdoor konden de aanvallers snel wachtwoorden vinden die door meerdere accounts werden gedeeld, of een gemeenschappelijk voorvoegsel delen met andere wachtwoorden (zoals wachtwoord1 en wachtwoord2 ), en werd ook de geschatte lengte van elk wachtwoord onthuld. wachtwoord.
De ECB-coderingsmodus heeft ook andere zwakke punten, zoals het feit dat het “zeer kneedbaar is: zoals elk blok leesbare tekst wordt afzonderlijk versleuteld, een aanvaller kan gemakkelijk nieuwe geldige versleutelingsteksten genereren door blokken uit eerder waargenomen versleutelde teksten samen te voegen.
De maakbaarheid is echter alleen een probleem als ECB-versleuteling wordt gebruikt zonder een berichtverificatiecode , en wordt in deze situatie (tot op zekere hoogte) gedeeld door alle andere niet-geverifieerde versleutelingsmodi , zoals de eerder genoemde CBC, CTR, CFB en OFB. Het kan dus niet echt worden beschouwd als een specifieke zwakte van de ECB-modus, ook al is het vaak een bijkomend probleem wanneer ooit de ECB-modus wordt gebruikt.
Wat moet ik in plaats daarvan gebruiken?
U moet een geverifieerde codering modus, zoals GCM , EAX of OCB .
Persoonlijk ben ik voor korte berichten “nogal gesteld op SIV-modus ( RFC 5279 ), wat een extra laag van weerstand tegen misbruik biedt. (Veel andere versleutelingsmodi zullen nogal slecht breken als dezelfde IV / nonce per ongeluk wordt gebruikt om meerdere berichten te versleutelen. SIV-modus behoudt al zijn beveiligingseigenschappen in deze situatie, behalve dat het lekt of de versleutelde berichten identiek zijn.)
Je kunt ook elke traditionele semantisch veilige versleutelingsmodus gebruiken (zoals CBC of CTR ), gecombineerd met een berichtverificatiecode (zoals HMAC ) met behulp van de versleuteling -dan-MAC constructie. (Dat wil zeggen, u moet eerst het bericht versleutelen, dan een MAC van de cijfertekst berekenen en deze aan de cijfertekst toevoegen.) Zolang u ervoor zorgt dat u de MAC verifieert voordat u probeert het bericht te decoderen, zal deze constructie u beschermen tegen de verschillende kwetsbaarheden van deze modi voor actieve (gekozen cijfertekst) aanvallen.
Voor schijfversleuteling of soortgelijke toepassingen waarvoor de mogelijkheid nodig is om onderdelen te wijzigen van de cijfertekst zonder alle gegevens opnieuw te coderen, moet u een coderingsmodus gebruiken die voor dat doel is ontworpen, zoals XTS . Merk op dat dergelijke modi over het algemeen niet bestand zijn tegen actieve aanvallen en mogelijk andere zwakke punten hebben die u moet begrijpen voordat u ze gebruikt. Indien mogelijk moeten ze worden gecombineerd met een of andere vorm van integriteitsbescherming, zoals een MAC op een hash-structuur .
Opmerkingen
- Wat zou je suggereren in gevallen waarin men in staat wil zijn om blokken van een gegevensopslag in willekeurige volgorde te lezen / schrijven, bij voorkeur tijdens het maken van een all-ones blokmap naar een alles- degenen blokkeren? Mijn neiging zou zijn om te versleutelen door de blokgegevens te xorken met een heel eenvoudige hash van het bloknummer, de xor-bewerking ongedaan te maken / te herhalen als het een all-ones-blok oplevert, ECB te gebruiken op het resultaat en xoring met het complement van het resultaat van het versleutelen van een all-ones-blok [dat complement hoeft maar één keer voor elke sleutel te worden berekend]. Zou dat een goede benadering lijken?
- @supercat: Dat ' is in feite schijfversleuteling , dus u kunt daarvoor modi gebruiken. Ik geloof dat XTS als een goede keuze wordt beschouwd, hoewel het, zoals alle schijfversleutelingsmodi, zijn beperkingen heeft (die u moet begrijpen voordat u het gebruikt). Indien mogelijk moet het worden gecombineerd met een soort MAC om te verdedigen tegen actieve aanvallen.
- @IlmariKaronen: ik denk dat je " niet t gebruik van ECB " is een beetje overdreven. Ik begrijp de risicos, maar vaak (tenzij je document -wat je codeert- isn ' t erg geheim, en de tegenstander niet ' t heb te veel mogelijkheden, enz.), zou het goed moeten komen.
- @giorgim: Daar ' is echt geen goede reden om ECB te gebruiken (behalve als bouwsteen voor andere modi). Vrijwel elke cryptobibliotheek biedt ten minste CBC- of CTR-modus, en zo niet, dan zijn ze ' triviaal om zelf te implementeren. Sla er een HMAC (of CMAC) bovenop, en je ' bent klaar om te gaan.
- @giorgim: zelfs als je ' hebben geen enige MAC- of AE-modus beschikbaar, het gebruik van CBC is nog steeds strikt beter dan ECB. Als je een MAC-functie hebt, is CBC-then-MAC een prima AE-modus.
Answer
U dient de ECB-modus niet te gebruiken omdat het identieke berichtblokken (dwz de hoeveelheid gegevens die bij elke aanroep van de blokcijferaar wordt versleuteld) zal versleutelen naar identieke versleutelde tekstblokken. Dit is een probleem omdat het zal onthullen of dezelfde berichtblokken meerdere keren worden versleuteld. Wikipedia heeft een heel mooie illustratie van dit probleem .
Reacties
- Reacties zijn niet voor uitgebreide discussie; deze conversatie is verplaatst naar chat .
Antwoord
Zoals @Guut Boy het al zei, ECB is niet semantisch veilig, in de zin dat als een bericht met identieke blokken wordt versleuteld, een aanvaller een bepaald voordeel krijgt om informatie in leesbare tekst te hebben, door alleen CipherText te observeren.
Gebruik bij voorkeur de CBC-modus om lang bericht te versleutelen. Deze modus introduceert een extra parameter genaamd de IV (initiële waarde), je initialiseert met het sessienummer om aanvallen te voorkomen in het geval dat hetzelfde bericht twee keer wordt versleuteld.
Reacties
- IV staat voor initialisatie vector, niet initiële waarde.
- 1. Dit is geen goed advies. Gebruik encryptie zonder authenticatie negeert ongeveer een decennium aan advies van cryptografen. Het is beter om geauthenticeerde codering te gebruiken, zoals Ilmari Karonen aanbeveelt. 2. Dit antwoord lijkt te zijn vervangen door Ilmari Karonen ' s antwoord.
- Daarnaast is het een feit dat de IV onvoorspelbaar moet zijn voor een aanvaller (d.w.z. niet te onderscheiden van willekeurig), en dit antwoord zegt dat u het sessienummer moet gebruiken, dat gewoonlijk helemaal niet willekeurig is.
Geef een reactie