Om de authenticatietag in de Galois / Counter-modus (GCM) te berekenen, wordt eerst een MAC berekend met behulp van GHASH over het cijfer tekst en de aanvullende gegevens. Daarna wordt deze MAC versleuteld met GCTR (met de eerste teller).

Mijn vraag is: waarom is deze laatste versleutelingsstap nodig? Wat zou het beveiligingsprobleem zijn als ik de uitvoer van GHASH rechtstreeks als authenticatietag zou gebruiken?

Answer

Wat zou het beveiligingsprobleem zijn als ik de uitvoer van GHASH gewoon rechtstreeks als authenticatietag zou gebruiken?

Dan kan iemand die naar versleutelde berichten luistert $ H $ herstellen, waarvan er één correct is.

De uitvoer van GHASH is een openbare polynoom (gebaseerd op de cijfertekst en de AAD), geëvalueerd op een geheime waarde $ H $ . Het blijkt dat, gegeven een dergelijk polynoom, $ H $ efficiënt kan worden hersteld, ofwel door het polynoom te herschrijven als $ \ mathrm {GHASH} (H) + \ mathrm {Tag} = 0 $ , en de wortels daarvan terugvinden (wat kan worden gedaan in een eindig veld), of nog gemakkelijker, twee van dergelijke cijferteksten ophalen, beide herschrijven ze gebruiken en een uitgebreide Euclidische waarde gebruiken om hun gemeenschappelijke root te herstellen.

Gegeven $ H $ kan een aanvaller triviaal willekeurige wijzigingen aanbrengen in versleutelde berichten ; ja, dat is slecht.

Opmerkingen

  • Nog een vraag: waarom is het nodig om GCTR te gebruiken om het GHASH-blok te versleutelen in plaats van alleen $ Enc_H (GHASH) $ als de tag? Op die manier zou GMAC kunnen worden gebruikt zonder dat er een IV nodig is.
  • @mat: je bedoelt het verzenden van $ GHASH $ via AES (met $ H $ als sleutel )? Nou, eigenlijk zou dat soort dingen werken (nou, ik zou ' niet $ H $ als een sleutel gebruiken, maar anders dan dat …) en zou het een conservatiever ontwerp; GCM was echter oorspronkelijk ontworpen als een pipe-lineable-modus; dat wil zeggen, het zou kunnen worden geïmplementeerd met een AES-hardware-implementatie waarbij we elke klokcyclus het volgende leesbare tekstblok aan de hardware geven, en elke klokcyclus, de cijfertekst van 10-14 cycli geleden komt tevoorschijn. Door een codering op de GHASH uit te voeren, ' blokkeren we de pijplijn …
  • Ik bedoel gewoon een simpele ECB-codering (met ofwel $ H $ of $ K $ als sleutel) van de GHASH in plaats van dit te doen met GCTR. Ik zou het voordeel kunnen hebben dat GMAC gemakkelijker te gebruiken zou zijn, omdat het ' geen nonce meer nodig heeft. De pijplijn is hier geen probleem, aangezien de versleuteling van de tag sowieso de allerlaatste stap is die in GCM wordt gedaan, dus de pijplijn is in dit stadium zeker leeg.
  • @David 天宇 Wong: vooral prestatie ( GHASH is vergelijkbaar, niet-gecodeerde hashes zijn doorgaans ' t)
  • @David 天宇 Wong: oh, juist, dat ook …

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *