Hur osäker är AES-128-CTR för att kryptera någon form av data med filformatet Ethereum keystore?
On november 18, 2020 by adminJag använder filformatet Ethereum keystore för att kryptera alla andra data, såsom vanlig text eller JSON.
Här är ett exempel på pseudokod för implementeringen:
MY_PASSWORD = "VeryDifficultPasword432131!@!#%" MY_TEXT = "This is my secret text" iv = randomBytes(16) kdfparams = { dklen: 32, n: 262144, r: 1, p: 8, salt: randomBytes(32) } key = scrypt(MY_PASSWORD, kdfparams) ciphertext = encryptCipheriv("aes-128-ctr", MY_TEXT, key, iv) mac = sha3(key[16:32], ciphertext)
Med den här koden kan jag skapa keystore-filen som ser ut så här:
{ "crypto" : { "cipher" : "aes-128-ctr", "cipherparams" : { "iv" : "83dbcc02d8ccb40e466191a123791e0e" }, "ciphertext" : "d172bf743a674da9cdad04534d56926ef8358534d458fffccd4e6ad2fbde479c", "kdf" : "scrypt", "kdfparams" : { "dklen" : 32, "n" : 262144, "r" : 1, "p" : 8, "salt" : "ab0c7876052600dd703518d6fc3fe8984592145b591fc8fb5c6d43190334ba19" }, "mac": "102aedfe8c308c735a76295f9908d9b7de40fb1c07f2f71e05de7a0b2f323a12" } }
Detta är standardfilen som lagrar miljontals dollar i Ethers.
Frågor:
- Är det säkert?
- Om inte, varför?
- Om ja, är också säker kryptering av vanlig text eller JSON (inget hexadecimalt format)?
- Är säkert att ställa in en mindre
kdfparams.n
?
Redigera: För att klargöra varför jag frågar detta beror på att en annan person sa detta:
Detta är inte säkert alls. Denna implementering innehåller många grundläggande fel. Ett exempel är att använda en osäker slumptalsgenerator som helt förstör krypteringens säkerhet. Ett annat använder AES- 128-CTR utan autentisering.
Kommentarer
- Definiera först ” säker ” . Men med någon rimlig definition av det, med ett lösenord i samma liga som ’ 1234 ’, och klartext som är stor och överflödig, inget användbart är säkert.
- Säker när det gäller mycket mycket svårt att bryta även om det är en bra kryptograf och mig redigera för att klargöra att det skulle vara ett mycket starkt lösenord.
- Definiera nu ” bryt ” . Finns det att hitta det ursprungliga lösenordet? Gissar du klartext från en ciphertext? Gissar du en del av klartext från många ciphertext-delar som vissa? Gissa en klartext från många ciphertext och alla andra klartext? Kan vi få hjälp från en körbar körning på samma maskin (och om ja, exakt vilken processor med vilken mikrokodlapp? Används AES-NI?). Kan vi använda EMI som en sidokanal? En keylogger, hårdvara eller sotfare? Faktiskt, vad ’ är implementeringen av randomBytes, som har inflytande?
- Du kan inte svara på den här frågan genom att titta på psuedocode. Den faktiska implementeringen kan innehålla alla möjliga sårbarheter och sidokanaler . Säkerhet är inte heller en binär, det ’ är en fråga om hur långt du ’ är villig att gå för att skydda mot allt mer exotiska attacker .
- @ fgrieu ledsen, den enda frågan jag kan svara är: nodejs.org / api / … @EllaRose Jag antar att biblioteken jag använder inte har sårbarheter. Så min pseudokod ovan är bara en implementering av dessa bibliotekfunktioner, en sådan randomBytes.
Svar
Det värsta rent kryptografisk svaghet är lösenordet (1). De värsta (och mycket värre) praktiska svagheterna är sannolikt i implementeringen (6) (7), och de (4) (5) som kryptografer avfärdar som utanför krypteringsomfånget (frågan är det enda uttalade målet).
Kandidater för svagheter, från kryptografiska (men fortfarande att överväga) till implementering:
- Lösenordet: det är svårt att komma ihåg ett lösenord med över 48 bitar entropi ( att ”ungefär motsvarar ett 16-siffrigt nummer, som 3141592653589793 eller 2718281828459045, och mer än vad som förutses av den obligatoriska XKCD ). Använda N = 262144 = 2 18 , r = 1, p = 8 = 2 3 , köper åtminstone 18 + 3 + 1 = 22 bitar (se detta ) jämfört med en rak SHA-256-hash följt av AES-128, antar jag ungefär 32 bitar starkare, så kan nyckeln vara ungefär 80-bitars bra, vilket är inte helt okrossbar av brute force men ändå ganska säker.
- AES-128: den här har en 128-bitars nyckel, ingen känd rent kryptoanalytisk attackera bättre än brute force, och är därmed mycket bättre än lösenordet.
- CTR-läge: med AES: s 128-bitarsblock skulle det enda sättet återanvändning av nyckelström kunna sparka in vara ett dåligt slumptal generator för IV (se 6)
- Storleken på klartext kan utan problem härledas från chiffertextens storlek. Detta är uttryckligen inte en teoretisk svaghet för kryptering, eftersom längden är utesluten från vad en kodning ska dölja om klartext. Det kan dock vara en praktisk svaghet. Säg att analys av krypteringstext drar slutsatsen att det är 17267095423 oktetter; och det existerar, någonstans i åklagaren uppvisar en fil med exakt den storleken, som bevisligen föregår sökning och beslag av ciffertexten, och som enbart kvarhållande är olagligt.
- Brist på upptäckt av (avsiktlig eller oavsiktlig) chiffertextändring, vilket motsvarar förutsägbar förändring i klartext: återigen är detta uttryckligen inte en teoretisk svaghet i kryptering, men kan tillåta vissa attacker om motståndaren kan ändra krypteringstexten (exempel: om klartexten är en körbar eller PDF med en känd bråkdel, kan det tillåta att ändra vad den körbara filen gör till vad som helst, eller göra PDF-visningen som vad som helst). Autentiserad kryptering ( AES-GCM ..) löser det.
- Slumpmässig talgenerator: om detta är dåligt eller sämre fastnar mer eller mindre (obligatoriskt XKCD och Dilbert som vänder sig till verkligheten alltför ofta), vilket skulle möjliggöra återställning av klartext i många scenarier, inklusive upprepad kryptering av olika engelska texter eller e-postadresser med samma lösenord.
- En sidokanal, det är i stort sett talar oförutsedd eller obetydlig läcka av information i implementerings- eller användningssammanhang. Det finns så många:
- Återställning av lösenord från lösenordshållaren genom att utnyttja ett procedurmål (lösenord på en postnota, huvudlösenordslista), gummislangskryptanalys (obligatorisk XKCD ), rättsliga varianter (med användning av uttryck på samma sätt som förakt för domstol ), mutor, kemisk impregnering ..
- Återställning av lösenord med shoulder surfing , key logger (mjukvara eller hårdvara), kamera, mikrofon (en bra ljudinspelning av ljudet av tangenter när du anger ett lösenord läcker mycket information om lösenordet, särskilt när det är korrelerat med känt tangentbordsinmatning av samma operatör under samma förhållanden).
- Rak kompromiss av klartext som visas på skärmen (med TEMPEST varianter av det), skrivs ut medan de sänds till en skrivare eller fjärråtkomst av ett nätverk, eller bara ”tillfälligt” lagras ..
- Rak kompromiss mellan operativsystemet för maskinen ine gör kryptering eller dekryptering (att få tillfällig root-åtkomst räcker, betyder i 7.7 är spel för angriparen).
- Kryptanalytisk sidokanal på avstånd, inklusive DPA och den elektromagnetiska varianten DEMA och hypotetiskt timing om maskinen som gör kryptering / dekryptering nås av ett nätverk och inte använder AES-instruktioner .
- Kryptanalytisk sidokanal från en process som körs på samma maskinvara (inklusive en annan virtuell dator), inklusive cachebaserad inriktning för AES när AES inte används instruktioner eller mer allmänna (Meltdown, Spectre) som är raseri idag.
- Utnyttjande av olika programvarufel; det är enormt.
Kommentarer
- Det skulle vara mer användbart om jag har lösenordet före krypteringen? Som att använda sha eller md5?
key = scrypt(sha(MY_PASSWORD), kdfparams)
- @EnZo: Hashing-lösenordet före inmatning i scrypt ändrar inte mycket svårigheten att attackera lösenordet ( punkt 1). För att förbättra detta behöver man ett bättre lösenord, en bättre parametrering för scrypt eller ett bättre lösenordsbaserat nyckelavledningsschema (Argon? Balloon?)
Svar
Det huvudsakliga säkerhetselementet som kan attackeras i ovanstående schema är – naturligtvis – lösenfrasen. Nu är saltet viktigt för att undvika regnbågsattacker men annars är det lägger inte till så mycket säkerhet. Om saltet och lösenordet är ganska unika är nyckeln också unik. I så fall är IV inte så viktigt.
Så även om det är dåligt att använda en osäker slumptalsgenerator kommer det förmodligen inte att ha så mycket inflytande på den praktiska säkerheten. , indikerar det att dåliga metoder verkligen har implementerats. Vad händer om lösenfrasen genererades med samma osäkra slumpmässiga generator? Vad händer om andra implementeringsfel dyker upp?
Att använda icke-autentiserad ciphertext är mer ett problem, eftersom det skulle göra det möjligt för motståndaren att ändra klartext för varje bit. Motståndaren kan helt enkelt invertera valfri ciphertextbit och klartextbiten i samma position kommer också att vändas. Detta skulle innebära att du skulle få ett fel eller ett problem när du använder plånboken. Sekretessen för innehållet i plånboken förloras sannolikt inte men att använda autentiserad kryptering är verkligen bästa praxis.
Kommentarer
- Tack! Kan du förklara knappt hur man uppnår autentiserad ciphertext med det här läget? Jag ska redigera den exemplen ovan eftersom jag tror är relaterat till den ursprungliga mac-egenskapen som jag tog bort från den ursprungliga keystore-filen.
- CTR-läge är det underliggande läget för CCM, GCM, EAX, SIV och en hel massa andra autentiserade cifrar. En kombination av CTR-läge med en (H) MAC kan dock också vara säker.Båda producerar en autentiseringsbricka med ungefär samma storlek / säkerhet. CCM och EAX är lite mer än specifika kombinationer av CTR och en MAC där samma nyckel kan användas för chiffrering och MAC.
- Observera att jag ’ har besvarade den här frågan efter bästa förmåga och använde generisk kunskap om chiffer (inte så mycket Ethereum). Ella Rose har rätt att vi inte kan dra slutsatsen om säkerheten i systemet från den information som vi fick i frågan. Så jag ’ fokuserade enbart på användningen av CTR.
- Det slumpmässiga tycks förlita sig – i slutändan – på systemet slumpmässigt. Ofta är system slumpmässiga källor relativt säkra och termen CSPRNG nämns verkligen av källan. Så påståendet att det inte är slumpmässigt är fel, om inte systemet slumpmässigt inte är bra implementerat eller sådd.
- Att skapa en MAC från SHA-3 rekommenderas inte, KMAC borde ha använts istället (det antagligen var helt enkelt ’ ännu inte specificerat vid den tidpunkten). Men jag kan inte tänka mig någon situation där användningen av sammankopplingen av nyckeln och chiffertexten någonsin skulle utgöra ett problem.
Lämna ett svar