GCM (Galois / Counter Mode), erityisesti yhdessä AES: n kanssa, on ollut käytännössä kultastandardi jo vuosia. Salaa ja todenna yhdellä askeleella, se on aivan liian mahtavaa, ja AEAD: n kaltaiset termit vaikuttavat hyvin tytön vaikuttamiseen, joten siitä olisi hyötyä. Mutta vitsi sivuun …
Olen ”ve mietin aina, mikä tekee siitä niin erikoisen, ja mitä kauemmin ajattelen sitä, sitä vähemmän ymmärrän. Jos katsot sitä, niin taika ei ole ollenkaan niin mahtava. Tai ehkä, ehkä olen liian tyhmä nappaamaan sitä (tästä syystä kysymykseni).
Ajatukseni:
Ensinnäkin GCM on laskuritilan muoto. Mikä tarkoittaa, että toisin kuin esim. salauslohkoketju, yhden lohkon lähtö riippuu tarkalleen yhdestä tulolohkosta. Pahempaa, vielä: Voit muokata yhtä bittiä ja purettu tulos eroaa tarkalleen siinä bitissä. Koska jos olet rehellinen, laskuritilassa oleva salakoodaus ei ole lainkaan ” -lohkosala ”, vaan (näppäilevä) PRNG jota seuraa XOR-operaatio. Pohjimmiltaan ” estetty ” virran salaus. Ei tarvitse paljon kuvitella tilannetta, jossa joku voisi käyttää tätä väärin vaihtaakseen viestejä haitallisella tavalla (esim. Muutos ” tapahtuma: +5000 \ $ ” – ” -tapahtuma: -5,000 \ $ ”). Lohkosalauksilla on yleensä luontainen ominaisuus muuttua täydelliseksi katkelmaksi. kun käännät yhden bitin (plus ketjuttamalla koko viestin loppuosan). Se on oikeastaan varsin mukava, toivottava ominaisuus, jonka heitimme vain yli laidan ilman mitään hyvää syytä.
Toki, todentajan kanssa , yllä olevaa hyökkäystä on vaikea saavuttaa, koska peukalointi havaitaan. Mutta pohjimmiltaan todentaja korjaa vain ongelman, jonka mukaan toimintatilan valinta käyttöön .
GHASH on MAC, joka tukee ylimääräisiä todennettuja tietoja. Sen perusteella, mitä voin kertoa, se on suorastaan valhe. Tai kutsu sitä ” optimistiseksi liioitteluksi ”, jos haluat. Se on vain pakkaustoiminto, jonka takana on ei-intuitiivinen matematiikka (muille kuin matemaatikoille), mutta loppujen lopuksi se ei tee muuta kuin yksinkertainen kertolasku ja heittää pois puolet syötbiteistä ekvivalentilla ” ylivuoto ”. Juuri mitä tavallisemmalla matematiikalla voidaan tehdä kahdella rivillä C-koodia lohkoa kohti kymmenessä jaksossa (tai jos olet kunnossa käyttämällä 32-bittisiä kertoja pikemminkin kuin 64, voidaan tehdä rinnakkain esim. AVX2: lla ” s vpmulld kahdelle täydelliselle lohkolle ~ 4 jaksossa).
Ne, jotka vielä muistavat IDEAa, muistavat, että he käyttivät lisäysmoodia 2 16 ja kertolasku modia 2 16 + 1 S-laatikoina, joilla oli mukava ominaisuus olla palautettavissa (välttämätön, jos haluat purkaa salauksen). Onneksi tätä ei voitu laajentaa 32-bittiseksi, koska 2 32 +1 ei ole ”ta” alkuluku, joten kaikki syötteet eivät ole taatusti suhteellisen tärkeitä sille, joten sinulla on vaikeuksia operaation kääntämisessä. Mutta … se on mahtavaa hienoa meidän tapauksessamme, emme halua Pakkaustoimintomme on käänteinen! Joten todella, ” yksinkertainen ”, tavallisen kertolaskun pitäisi tehdä myös temppu?
Joten, tämä yksinkertainen, ei-erikoinen, ei taikaa-pakkaus funktio sattuu olemaan alustettu avaimella ja IV, mikä satunnaisesti tekee lopullisen lähtöavaimen riippuvaiseksi tavalla tai toisella, joten että tavallisesta toiminnosta tulee tehokkaasti MAC. Jos sinulla on ” ylimääräisiä tietoja ”, syötät ne vain hashiin ennen tietojen salaamista. Jälleen, tämä ei ole jotain erikoista.
Kaiken kaikkiaan se ei ole mitään, mitä et voisi saavuttaa melko paljon kaikilla muilla hajautusfunktioilla .
Nyt Galois / counter olettaa, että laskuritilaa käytetään. Laskuritilalla (ja sen johdannaisilla) sekä GHASH: lla on se etu, että voit salata / purkaa lohkoja rinnakkain. GHASH on myös triviaalisesti rinnastettavissa.
Jee, suorituskyky Mutta olkaamme rehellisiä, onko tämä todella etu vai pikemminkin valtava haitta ?
Onko väliä kuinka kauan gigatavun tai teratavun kokoisen salauksen purkaminen kestää ja kuinka hyvin voit rinnastaa tämän työn? Tai sovelluksia, joissa haluat ehdottomasti pystyä ” etsimään ” satunnaisiin paikkoihin? No, on sovelluksia, joissa sillä voi olla merkitystä, varmasti. Koko levyn salaus tulee mieleen. Mutta siinä tapauksessa et halua käyttää GCM: ää, koska haluat, että syötekoko ja ulostulon koko ovat samat.
Varatulla palvelimella (tai VPN: llä) on merkitystä, tai niin näyttää siltä , mutta nämä voivat joka tapauksessa käsitellä mitä tahansa rinnakkain, koska niillä on useita samanaikaisia yhteyksiä.Joten riippumatta siitä, voitko rinnastaa yhden virran, ei ole mitään eroa yleisesti. Entä sovellukset, joissa on vain vähän yhteyksiä? No, et tavallisesti lähetä teratavua dataa sisäänkirjautumispäätteen kautta, ja jos teet niin, Internet-yhteytesi on silti todennäköisesti rajoittava tekijä joka tapauksessa, koska yhden ytimen suorituskyky ylittää helposti GbE-kaistanleveyden jopa 7–8-vuotiaissa työpöydän prosessoreissa. .
Selvä, saatat joutua odottamaan 2–3 sekuntia kauemmin, kun purat salatun 2 Tt 7z-tiedoston kiintolevylle (jos tuhansien hakemistomerkintöjen luominen ei todellakaan ole pullonkaula, johon olen taipuvainen kuinka usein olet tehnyt niin viimeisen vuoden aikana? Minä: nolla kertaa.
Ainoat, joille se todella vaikuttaa, ovat ” pahikset ” eli tarkalleen ne, joille et halua elää helppoa elämää. Tosiaan, jos pystyt triviaalisesti rinnakkaistumaan, hyökkäykset ovat paljon helpompia. Heitä huone täynnä omistettuja laitteita (grafiikkasuoritimia, FPGA: ita, mitä tahansa) ongelmalle ja anna sen jauhaa. Ei solmujen välistä yhteyttä tarvita? No, täydellinen, se ei voi tulla paremmaksi.
Onko tämä todella etu? En tiedä, minusta se näyttää valtavalta haitalta. Jos jotain, haluaisin tehdä rinnakkaistamisesta mahdollisimman vaikeaa, ei mahdollisimman helppoa.
Joten … tarpeeksi pohdintaa ja kysymykseen:
Mikä on olennainen asia, joka puuttuu GCM: stä, mikä tekee siitä niin mahtavan, että sinun pitäisi ehdottomasti käyttää sitä?
Kommentit
- Mutta kuka on ” pahiksia ” on mahdotonta määritellä. Ja sillä on valtava vaikutus hallituksen suosituksiin ja tämän foorumin vastauksiin.
Vastaa
TL; DR: GCM tarjoaa erinomaisen suorituskyvyn parhailla suojausominaisuuksilla, joita odotamme salauksilta tänään (AEAD).
GCM käyttää CTR: ää virran salauksen rakentamiseen. Tämä on hyvin tutkittu menetelmä, jolla on vain yksi haittapuoli: se tarvitsee ehdottomasti jonkin verran todennusta estääkseen bittien kääntämisen. Ennen GCM: ää ratkaisu oli CTR-sitten-MAC. Yksi stream-salausten tärkeimmistä eduista on täytehyökkäysten puuttuminen (koska täytettä ei tarvita). Toinen etu on, että AES-CTR voi hyötyä AES-NI-ohjeista.
GCM on CTR-sitten-MAC, parempi suorituskyky . Yksi avainparannus CRT-sitten-MAC: iin verrattuna on kyky päällekkäin salauksen ja todennuksen suorittamisen kanssa. Lisäksi se on osoittautunut turvalliseksi konkreettisessa turvallisuusmallissa, eikä patentit ole sen rasittamia, joten sen käyttö ei ole järkevää.
Siinä on joitain haittoja: se ei ole tehokas upotetussa laitteistossa ja sitä on vaikea toteuttaa tehokkaasti. Viimeistä asiaa torjutaan käyttämällä muiden kirjoittamia kirjastoja. Nämä ovat kuitenkin syitä, miksi xchacha20-poly1305 tuli suosituksi GCM: ssä.
Kommentit
- Väitän toisen syyn, miksi ChaCha20 on saavuttanut suosiota, koska se ei ole ei AES. Älä ’ saa minut väärin, AES on hieno algoritmi, mutta kirjaimellisesti kaikkien muniemme sijoittaminen yhteen koriin ei ehkä ole älykkäin idea kaikista ideoista. Ja yhden hyvin testatun algoritmin käyttäminen AES: n lisäksi on varsin arvokasta.
- @ MechMK1 Olen kanssasi samaa mieltä , mutta en kirjoittanut, että ne ovat kaikki ChaCha20: n ’ suosion syitä, koska se ’ s ei tässä esitetty kysymys hat GCM: ää ei pidetä ” mahtavana ” kuin OP ajattelee.
- Ehdottomasti totta. Se ’ ei ole kultainen hanhi, mutta kukaan ei koskaan ammuttu niin sanotun AES-GCM: n käytöstä.
- Ja se ’ eivät ole patenttien rasittamia.
- @StephenTouset Kiitos, muokkain viestiäni sisällyttämään kommenttisi.
Vastaa
Ensinnäkin GCM on eräänlainen laskutila. Mikä tarkoittaa, että toisin kuin esim. salauslohkoketju, yhden lohkon lähtö riippuu tarkalleen yhdestä tulolohkosta. Pahempaa, vielä: Voit muokata yhtä bittiä ja purettu tulos eroaa tarkalleen siinä bitissä. Koska jos olet rehellinen, laskuritilassa oleva salakoodaus ei ole lainkaan ”salakoodaus”, vaan (avain) PRNG, jota seuraa XOR-operaatio. Pohjimmiltaan ”blocky” stream salaus. Ei tarvitse paljon kuvitella tilannetta, jossa joku voisi käyttää tätä väärin vaihtaakseen viestejä haitallisella tavalla (esim. Muuta tapahtuma: +5,000 \ $ ”arvoksi” tapahtuma: -5000 \ $ ”).
Viestitodennus, jonka GCM kerää napsautussuhteen päälle, tekee sen muokattavuudesta merkityksetöntä.
Lohkosalauksilla on yleensä synnynnäinen ominaisuus muuttua täydelliseksi hämmennykseksi, kun käännät yhtä bittiä (plus ketjuttamalla koko viestin loppuosa) . Se on oikeastaan melko mukava, toivottava ominaisuus, jonka heitimme vain yli laidan ilman mitään hyvää syytä.
Tämä on hyvin, hyvin väärin. Ensinnäkin , CBC-tila kärsii myös eräänlaisesta muovattavuuden heikkoudesta; jos käännät yhden bitin salatusta tekstistä, sekoitat vain yhden lohkon ja käännä vastaava verkkolohkon bitti. Ja CBC: tä vastaan on muitakin muovautumishyökkäyksiä; katso esimerkiksi EFail-hyökkäys .
Yleisemmin, epävirallinen ajatuksesi viesteistä, jotka ”muuttuvat täydelliseksi katkelmaksi”, ei ole tarpeeksi hyvä. Tarvitsemme ehdottomasti tietokoneita, jotta mekaanisesti löydetään selvä ”kyllä / ei” vastaus, kun salattu viesti on väärennetty. Luottaa siihen, että ihminen on silmukassa riittävän aikaisin havaitsemaan ”katkeruutta”, ei ole tarpeeksi.
GHASH on MAC, joka tukee ylimääräisiä todennettuja tietoja. Sen perusteella, mitä voin kertoa, se on suorastaan valhe. Tai kutsu sitä ”optimistiseksi liioitteluksi”, jos haluat. Se on vain pakkaustoiminto, jonka takana on ei-intuitiivinen matematiikka (muille kuin matemaatikoille), mutta loppujen lopuksi se ei tee muuta kuin yksinkertainen kertolasku ja heittää pois puolet tulobiteistä ”ylivuotoa” vastaavalla tavalla.
MAC ei toimi, koska käyttäjät eivät ymmärrä matematiikkaa. Se on kuin sanoa, että ihmiset eivät voi katsoa satelliitti-TV: tä, koska he eivät ”ei tiedä laskua. Äärelliset kenttä-MAC: t ovat vakiorakenne, joka tunnetaan jo vuosikymmenien ajan.
Juuri mitä, tavallisemmalla matematiikalla, voidaan tehdä kahdella rivillä C koodi lohkoa kohti kymmenessä jaksossa (tai jos sinulla on OK käyttää 32-bittisiä kertoja 64: n sijasta, voidaan tehdä rinnakkain esim. AVX2: n vpmulld: n kanssa kahdelle täydelliselle lohkolle ~ 4 jaksossa).
Käydään todellista keskustelua siitä, ovatko Galois-kenttiin kuten GHASH perustuvat MAC: t vai prime-kenttiin perustuvat MAC: t, kuten Poly1305, käytännöllisempi valinta. Monet niistä riippuvat kompromisseista. MAC: iden suunnittelun välillä ohjelmistojen ja laitteistojen toteuttamisen korostamiseksi; esim. Galois-kenttäkertomukset ovat ohjelmistoissa painajaisia, mutta paljon yksinkertaisempia kuin laitteistojen aritmeettiset kertolaskut. Hyvä osa kompromisseista riippuu myös haavoittuvuudesta sivukanavan hyökkäyksille, esim. tehoanalyysi .
Mutta ei ole keskustelua siitä, ovatko Galois- vai prime-kentät pohjimmiltaan epäpäteviä nd. Matematiikka tarkistaa molemmat.
Jee, suorituskyky! Mutta olkaamme rehellisiä, onko tämä todella etu vai pikemminkin valtava haitta?
Kerro se insinöörien loputtomille paraateille vuosikymmenien ajan ovat vastustaneet salauksen lisäämistä tuotteisiin suorituskyvyn takia. Ja älä ajattele vain tehokkaita tietokoneita; ajattele upotettuja laitteita ja pelkää hyvin esineiden internetiä.
Tarkoitan, että tämä ei ole lainkaan kuollut asia. Muutaman viime vuoden aikana käytiin vilkasta keskustelua ja uuden salakirjoitusrakenteen kehittäminen tukemaan koko levyn salausta alhaisimmissa Android-laitteissa, jotka arvioitiin ei tarpeeksi tehokas Androidin aiemmin tarjoamille AES-pohjaisille algoritmeille.
Ainoat, joille [suorituskyky] todella vaikuttaa, ovat ”pahikset”, eli juuri ne, joille et halua saada helppo elämä. Tosiaankin, jos pystyt triviaalisesti rinnakkaistumaan, hyökkäykset ovat paljon helpompia. Heitä ongelma täynnä omistettua laitteistoa (grafiikkasuoritimia, FPGA: ita tai muuta) ja anna sen jauhua.
Salaajat ratkaisevat tämän käyttämällä riittävän suuria avainkokoja, eivätkä salausta hidastamalla. Hoito, jonka nostat esiin, syntyy salasanapohjaisessa salauksessa, jossa et ”Sinulla ei ole tarpeeksi entrooppisia salaisia avaimia. 256-bittiset symmetriset avaimet ovat ikuisesti yli tarpeeksi suuria voittamaan universumissamme olevat raakavoimat.
Mikä on olennainen asia, joka puuttuu GCM: stä, mikä tekee siitä niin mahtavan, että sinun pitäisi ehdottomasti käyttää sitä?
Sinun ei tarvitse ehdottomasti käyttää GCM: ää Se on samaan aikaan:
- Fundamentall y ääni ja erittäin laajalti tuettu laitteistossa;
- Useiden haittojen takia, joita et tuonut esiin, kuten huono ohjelmiston suorituskyky ja katastrofaalinen aitouden epäonnistuminen uudelleenkäytön yhteydessä, jotka usein hylkäävät sen joissakin käytännön yhteyksissä .
Jos sinulla on laitteistoa, jolla on natiivi AES-GCM -tuki, ja tarkasti tarkastettua ohjelmistoa, joka hyödyntää sitä, ei ole viisasta olla sitä ilman parhaita ehdokkaita.