Kuinka epävarmaa on AES-128-CTR: n salaaminen kaikenlaisille tiedoille Ethereum-avaimetalletiedostomuodolla?
On marraskuu 18, 2020 by adminKäytän Ethereumin avaimetalletiedostomuotoa muiden tietojen, kuten pelkkän tekstin tai JSON: n salaamiseen.
Tässä on esimerkki toteutuksen pseudokoodi:
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)
Tällä koodilla voin luoda avaimetalletiedoston, joka näyttää tältä:
{ "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" } }
Tämä on vakiotiedosto, joka tallentaa miljoonia dollareita ihmisiä Eetteriin.
Kysymykset:
- Onko tämä turvallinen?
- Jos ei, miksi?
- Jos kyllä, onko myös turvallisen tekstin tai JSON: n salaus (ei heksadesimaalimuotoa)?
- Onko turvallista asettaa pienempi
kdfparams.n
?
Muokkaa: Selvennän, miksi kysyn, koska toinen henkilö sanoi tämän:
Tämä ei ole lainkaan turvallista. Tämä toteutus sisältää monia perusvirheitä. Yksi esimerkki on turvattoman satunnaislukugeneraattorin käyttö, joka tuhoaa täysin salauksen turvallisuuden. Toinen käyttää AES- 128-klikkausprosentti ilman todennusta.
Kommentit
- Määritä ensin ” suojattu ” . Mutta millä tahansa kohtuullisella määritelmällä, salasanalla samassa liigassa kuin ’ 1234 ’ ja selkeä teksti, joka on suuri ja tarpeeton, mikään käyttökelpoinen ei ole turvallista.
- Turvallinen erittäin vaikeasti hajoava, vaikka se onkin hyvä kryptografi Et me muokata selventääksesi, että salasana olisi erittäin vahva.
- Määritä nyt ” break ” . Löydetäänkö alkuperäinen salasana? Arvaatko selkeän tekstin yhdestä salatekstistä? Arvaatko joitain selkeää tekstiä monien salattujen tekstien jakamisesta, että jotkut? Arvaatko yhden selkeän tekstin monista salateksteistä ja kaikki muut selvät tekstit? Voimmeko saada apua suoritettavasta tiedostosta, joka toimii samalla koneella (ja jos kyllä, mitä CPU: ta ja mitä mikrokoodipaketteja käytetään AES-NI: tä?). Voimmeko käyttää EMIä sivukanavana? Näppäinlukija, laitteisto vai sotfare? Mikä ’ on randomBytes-toteutus, jolla on vaikutusta?
- Et voi vastata tähän kysymykseen katsomalla psuedocode-koodia. Varsinainen toteutus voi sisältää kaikenlaisia haavoittuvuuksia ja sivukanavia . Turvallisuus ei myöskään ole binaarinen, sillä ’ on väliä kuinka pitkälle ’ olet valmis menemään suojautumaan yhä useammilta eksoottiset hyökkäykset .
- @ fgrieu anteeksi, ainoa kysymys, johon voin vastata, on: nodejs.org / api / … @EllaRose Oletan, että käyttämissäni kirjastoissa ei ole haavoittuvuuksia. Joten yllä oleva pseudokoodini on vain näiden kirjastofunktioiden toteutus, sellaiset satunnaiset tavut.
Vastaa
Pahin puhtaasti salauksen heikkous on salasana (1). Pahimmat (ja paljon pahemmat) käytännön heikkoudet ovat todennäköisesti toteutuksessa (6) (7) ja ne (4) (5), jotka kryptografit hylkäävät salauksen ulkopuolella (kysymyksen ainoa tavoite).
Ehdokkaita heikkouksiin, salauksesta (mutta vielä harkittavaksi) toteutukseen:
- Salasana: on vaikea muistaa salasanaa, jossa on yli 48 bittiä entropiaa ( se vastaa suunnilleen 16-numeroista lukua, kuten 3141592653589793 tai 2718281828459045, ja enemmän kuin pakollinen XKCD on suunnitellut. Käyttämällä N = 262144 = 2 18 , r = 1, p = 8 = 2 3 , ostaa vähintään 18 + 3 + 1 = 22 bittiä (katso tämä ) verrattuna suoraan SHA-256-hashiin, jota seuraa AES-128, luulen noin 32 bittiä vahvempi, joten avain voi olla noin 80-bittinen, mikä on ei ole täysin särkymätön raakan voiman avulla, mutta silti melko turvallinen.
- AES-128: tällä on 128-bittinen avain, ei tunnettua puhtaasti kryptanalyyttisenä hyökkäys paremmin kuin raakaa voimaa ja on siten paljon parempi kuin salasana.
- CTR-tila: AES: n 128-bittisen eston avulla ainoa tapa, jolla avaimen virta voidaan käyttää uudelleen, olisi huono satunnaisluku generaattori IV: lle (katso 6)
- Selkokielisen tekstin koko voidaan vaivattomasti päätellä salaustekstin koosta. Tämä ei ole nimenomaisesti ole salauksen teoreettinen heikkous, koska pituus on suljettu pois siitä, mitä salauksen on tarkoitus piilottaa selkokielisestä tekstistä. Se voi kuitenkin olla käytännöllinen heikkous. Sanokooditekstin analyysin perusteella voidaan päätellä, että se on 17267095423 oktetit; ja on olemassa, jossain syyttäjän asiakirjoissa on täsmälleen tämän kokoinen tiedosto, joka on selvästi aikaisempi kuin salakirjoituksen etsiminen ja takavarikointi, ja joka pelkkä säilöönotto on laitonta.
- (tarkoituksellisen tai vahingossa tapahtuvan) salakirjoitemuutoksen havaitseminen puuttuu, mikä vastaa selkeän tekstin ennustettavissa olevaa muutosta: tämä ei taas ole selkeästi teoreettista salauksen heikkoutta, mutta voi sallia joitain hyökkäyksiä jos vastustaja voi muuttaa salaustekstiä (esimerkki: jos selkokielinen teksti on suoritettava tiedosto tai PDF, jolla on tiedossa oleva murto-osa, se voi sallia sen, mitä suoritettava tiedosto tekee mihin tahansa kohtaan, tai saada PDF-tiedoston näyttämään kaikesta). Todennettu salaus ( AES-GCM ..) ratkaisee sen.
- Satunnaislukugeneraattori: jos tämä on huono tai huonompi, jumittuu enemmän tai vähemmän (pakollinen XKCD ja Dilbert jotka kääntyvät todellisuuteen aivan liian usein), mikä mahdollistaisi selkeän tekstin palauttamisen monissa tilanteissa, mukaan lukien eri englanninkielisten tekstien tai sähköpostiosoitteiden salaaminen toistuvasti samalla salasanalla.
- Sivukanava, joka on laajasti odottamattomien tai ennakoimattomien tietovuotojen puhuminen toteutuksen tai käytön yhteydessä. Niitä on niin monta:
- Salasanan palauttaminen salasanan haltijalta hyödyntämällä menettelytapaa (salasana postit-muistiinpanossa, pääsalasanaluettelo), kumiletkun salausanalyysi (pakollinen XKCD ), lailliset vaihtoehdot (mukaan lukien ilmaisujen käyttäminen tuomioistuimen halveksuntaa varten), lahjonta, kemiallinen kyllästäminen.
- Salasanan palauttaminen hevosurffaus , avainten kirjaaja (ohjelmisto tai laitteisto), kamera, mikrofoni (hyvä äänen sieppaus näppäinten ääni salasanaa syötettäessä vuotaa paljon tietoa salasanasta, varsinkin kun se korreloi saman operaattorin tunnetun näppäimistön syötteen kanssa samoissa olosuhteissa).
- Selkeän tekstin suora kompromissi näytöllä ( TEMPEST -vaihtoehdot), tulostettu, lähetetty tulostimeen tai verkon kautta etäkäyttöön tai vain ”väliaikaisesti” tallennettu.
- Suora kompromissi koneen käyttöjärjestelmästä salaus tai salauksen purku (väliaikaisen pääkäyttäjän saaminen riittää, 7.7 tarkoittaa hyökkääjän pelaamista).
- Cryptanalytic sivukanava etäisyydellä, mukaan lukien DPA ja sähkömagneettinen muunnos DEMA ja hypoteettisesti ajoitus , jos salauksen / salauksen purkamisen suorittavaan koneeseen pääsee verkosta eikä se käytä AES-ohjeet .
- Salausanalyyttinen sivukanava prosessista, joka toimii samalla laitteistolla (mukaan lukien toinen virtuaalikone), mukaan lukien välimuistipohjainen kohdistus AES: lle, kun et käytä AES: ää ohjeet tai yleisemmät ohjeet (Meltdown, Spectre), jotka ovat nykyään kaikki raivoa.
- Erilaisten ohjelmistovirheiden hyödyntäminen; se on valtava.
Kommentit
- Olisi hyödyllisempää, jos hajautan salasanan Ennen salausta? Kuten sha: n tai md5: n käyttäminen?
key = scrypt(sha(MY_PASSWORD), kdfparams)
- @EnZo: Salasanan hajauttaminen ennen salauksen kirjoittamista ei muuta paljoa salasanan hyökkäysvaikeuksia ( kohta 1). Tämän parantamiseksi tarvitaan parempi salasana, parempi parametrisointi scryptille tai parempi salasanapohjainen avainten derivaatiojärjestelmä (Argon? Balloon?)
Vastaus
Tärkein turvaelementti, johon voidaan hyökätä yllä olevassa järjestelmässä, on tietysti salasana. Nyt suola on tärkeä sateenkaaren pöytähyökkäysten välttämiseksi, mutta muuten se on ei lisää niin paljon turvallisuutta. Jos suola ja salasana ovat kohtuullisen ainutlaatuiset, myös avain on ainutlaatuinen. Tällöin IV ei ole niin tärkeä.
Joten vaikka epävarman satunnaislukugeneraattorin käyttö on huono, sillä ei todennäköisesti ole niin paljon vaikutusta käytännön turvallisuuteen. , se osoittaa, että huonoja käytäntöjä on todellakin otettu käyttöön. Entä jos tunnuslause luotiin samalla turvattomalla satunnaisgeneraattorilla? Entä jos muut toteutusvirheet näkyvät?
Todentamattoman salaustekstin käyttö on enemmän ongelma, kuten se antaisi vastustajalle mahdollisuuden muuttaa jokaisen bitin selkokielistä tekstiä. Vastustaja voi yksinkertaisesti kääntää minkä tahansa salaustekstibitin ja selkokielinen bitti samassa asennossa myös kääntyy. Tämä tarkoittaisi, että saat virheilmoituksen tai ongelman lompakkoa käytettäessä. Lompakon sisällön luottamuksellisuus ei todennäköisesti menetetä, mutta todennetun salauksen käyttö on varmasti paras käytäntö.
Kommentit
- Kiitos! Voisitko selittää tuskin miten saavuttaa todennettu salakirjoitus tässä tilassa? Aion muokata sitä Yllä olevia esimerkkejä, koska mielestäni se liittyy alkuperäiseen mac-ominaisuuteen, jonka poistin alkuperäisestä avaimenvarastotiedostosta.
- CTR-tila on CCM: n, GCM: n, EAX: n, SIV: n ja koko joukon muita todennettuja tiloja. salaus. CTR-tilan ja (H) MAC: n yhdistelmä voi kuitenkin olla myös turvallinen.Molemmat tuottavat todennuskoodin, jolla on suunnilleen sama koko / suojaus. CCM ja EAX ovat vain muutamia CTR: n ja MAC: n erityisiä yhdistelmiä, joissa samaa avainta voidaan käyttää salaukseen ja MAC: ään.
- Huomaa, että I ’ ve vastasi tähän kysymykseen parhaani mukaan käyttäen yleistä salaustietoa (ei niin paljon Ethereumia). Ella Rose on oikeassa, että emme voi päätellä järjestelmän turvallisuutta kysymyksessä meille annettujen tietojen perusteella. Joten olen ’ keskittynyt yksinomaan napsautussuhteen käyttöön.
- No, satunnainen näyttää luottavan – lopulta – järjestelmän satunnaisuuteen. Usein järjestelmän satunnaiset lähteet ovat suhteellisen turvallisia, ja lähde tosiaankin mainitsee termin CSPRNG. Joten väite, että se ei ole satunnainen, on väärä, ellei järjestelmän satunnaisuutta ole otettu käyttöön tai siemennetty hyvin.
- MAC: n luomista suoraan SHA-3: sta ei suositella, sen sijaan olisi pitänyt käyttää KMAC: ää (se todennäköisesti yksinkertaisesti ei ollut ’ t määritelty vielä tuolloin). Mutta en voi ajatella tilanteita, joissa avaimen ja salakirjoituksen yhdistämisen käyttö aiheuttaisi koskaan ongelmaa.
Vastaa