AES GCM vs AES CTR

[bakalakadaka]

Mam v Go spravene dve kniznice ktore umoznuju sifrovanie pomocou AES. Jedna pouziva GCM, druha pouziva CTR.
GCM je blokova sifra ktora vyuziva pevnu sirku bloku(bytova dlzka dat) ktory nasledne ohashuje, pre zvysenu bezpecnost, a uchova tuto informaciu v headery.

CTR na druhu stranu je "streamova" sifra ktora nepotrebuje pevnu sirku a robi len XOR.

Ja som si spravil kniznicu pre GCM ktora umoznuje streamovanie vdaka vnutornemu bufferu, takze je pre mna jedno ktoru kniznicu pouzijem. Ale nechcem mixovat sifry v systeme a preto by som chcel zvolit jednu formu a druhu nepouzivat.

Zaujimalo by ma pre a proti pre CTR a GCM. Napriklad GCM ma sice ten vnutorny hash ale prakticky je to v com lepsie nez CTR, ak sa bavime o vysledku sifrovania - povedzme ze sa jedna o subor. Obe formy subor vedia zasifrovat aj odsifrovat a robit nahodne citanie a apendovat. Navyse z principu CTR bude vykonnesia nez GCM, aj kod je znacne jednoduchsi.

Obe sifry pouzivaju nonce akurat ze GCM si ju sama uklada v headery kazdeho bloku(12b nonce + 16b hash alebo iv?) kdezto pri CTR sa vecsinou musi manualne prefixnut na zaciatok suboru alebo niekam kde ju kod vie najst pre odsifrovanie. Ale v principe tam nejak moc rozdiel nie je.

Prakticky ma asi zaujima ci mozem narazit na nejake edge case problemy ako apendovanie suboru a podobne. Zatial som na nic nenarazil ale to neznamena ze sa nieco take nemoze stat. Niekde na Stackoverflow som cital ze niektore tie sifry pouzivaju kontinualitu streamu takze nie je mozne napriklad apendnut subor bez toho aby sa naparsoval cely existujuci obsah. Tie blokove sifry ale su myslim prave opacne, ze od toho su tie bloky ze kazdy moze existovat samostatne a teda sa moze aj sifrovat paralelne, ale popravde nie som vobec v tomto vzdelany dostatocne(asi ako vecsina).

Primarne mi ide o to aby som skratka mohol v pohode pracovat so subormy(vytvorit, apendovat, seekovat) a datami(tzn spracovat cely []byte) a napriklad tie subory aj streamovat ako http response. Proste take tie banalne veci.

[Reklama]

[alex6bbc]

k appendovani, a vadilo by ti mit jeden achiv podobny tar s nesifrovanym indexem, kde zacinaji jednotlive bloky dat/soubory a ty by byly zasifrovane kus po kuse (blok/soubor) a na zaklade indexu, by sis mohl seeknout a vytahnout treba jen jeden kus a odsifrovat.

no a nebo mas zasifrovany cely archiv, ale pak musis odsifrovat cely archiv, appendovat a zase zasifrovat. to je podle me slozitejsi.

[bakalakadaka]

k appendovani, a vadilo by ti mit jeden achiv podobny tar s nesifrovanym indexem, kde zacinaji jednotlive bloky dat/soubory a ty by byly zasifrovane kus po kuse (blok/soubor) a na zaklade indexu, by sis mohl seeknout a vytahnout treba jen jeden kus a odsifrovat.

no a nebo mas zasifrovany cely archiv, ale pak musis odsifrovat cely archiv, appendovat a zase zasifrovat. to je podle me slozitejsi.

Ako som pisal, aktualne s apendovanim problem nemam.

V praxi pri tom GCM to funguje tak ze sa vezme velkost suboru, vypocita sa kolko pevnych blokov sa v nom nachadza a podla toho sa naseekuje na posledny blok, ten sa nacita, odsifruje a potom sa k nemu len dopisuju nove data a postupne sa to len zapisuje do suboru. Inak povedane ide len o to ze sa musi seekovat na zaciatok vloku ktory obsahuje ziadany usek suboru a ten blok ma potom offset aby sa vratili spravne data(kedze ten blok ma AES header)

Cize to je v pohode. Slo mi skor len o to GCM vs CTR, prakticky ci to CTR ma nejaku slabinu oproti GCM pripadne ake problemy mozu vzniknut ak sa bavime o beznej praci so subormi. Primarne vlastne mi asi ide o to ze som cital ze niektore tie AES verzie musia byt konsekutivne, cize predosly blok sa pouziva ako "seed" pre nasledovny blok. V takom pripade by som mal problem ak aktualizujem obsah neajkeho suboru napriklad tak by som ho uz nevedel precitat.

[alex6bbc]

k appendovani, a vadilo by ti mit jeden achiv podobny tar s nesifrovanym indexem, kde zacinaji jednotlive bloky dat/soubory a ty by byly zasifrovane kus po kuse (blok/soubor) a na zaklade indexu, by sis mohl seeknout a vytahnout treba jen jeden kus a odsifrovat.

no a nebo mas zasifrovany cely archiv, ale pak musis odsifrovat cely archiv, appendovat a zase zasifrovat. to je podle me slozitejsi.

kdysi jsem delal vykonove testy zda mame ukladat data do vlastniho archivu podobnemu tar s indexem, seekem apod.
nakonec vyslo, ze nejjednodussi je mit soubory normalne v souborovem systemu a jen si vhodne udelat adresare :-)

Ako som pisal, aktualne s apendovanim problem nemam.

V praxi pri tom GCM to funguje tak ze sa vezme velkost suboru, vypocita sa kolko pevnych blokov sa v nom nachadza a podla toho sa naseekuje na posledny blok, ten sa nacita, odsifruje a potom sa k nemu len dopisuju nove data a postupne sa to len zapisuje do suboru. Inak povedane ide len o to ze sa musi seekovat na zaciatok vloku ktory obsahuje ziadany usek suboru a ten blok ma potom offset aby sa vratili spravne data(kedze ten blok ma AES header)

Cize to je v pohode. Slo mi skor len o to GCM vs CTR, prakticky ci to CTR ma nejaku slabinu oproti GCM pripadne ake problemy mozu vzniknut ak sa bavime o beznej praci so subormi. Primarne vlastne mi asi ide o to ze som cital ze niektore tie AES verzie musia byt konsekutivne, cize predosly blok sa pouziva ako "seed" pre nasledovny blok. V takom pripade by som mal problem ak aktualizujem obsah neajkeho suboru napriklad tak by som ho uz nevedel precitat.

kdysi jsem zkoumal zda je rychlejsi mit data v archivu, podobnemu formatu tar s vlastnim indexem, seekovanim, appendem atd. a vyslo, ze je nejjednodussi to sypat normalne jako soubory do filesystemu a staci mit rozumne udelane adresare a bylo to i rychlejsi.

[RDa]

kdysi jsem zkoumal zda je rychlejsi mit data v archivu, podobnemu formatu tar s vlastnim indexem, seekovanim, appendem atd. a vyslo, ze je nejjednodussi to sypat normalne jako soubory do filesystemu a staci mit rozumne udelane adresare a bylo to i rychlejsi.

To plati jen do doby, nez takovej archiv potrebujes prenest na jinej disk. FS se ti useekuje k smrti a kazdy soubor potrebuje minimalne 2-3 IOPS, takze to leze z disku fakt pomalu.

Oproti tomu pak stoji jednosouborovej archiv, ktery se cte sekvencne, a seek se pouzije jen tolikrat, kolik append sessions jsi tam udelal a tim fragmentoval archivni soubor.

Zcela ten samej problem a vyhody/nevyhody maji pak videa, ktere jsou one-file per-frame (cDNG) vs one-file per-clip (MOV).

[Reklama]

[_Jenda]

Jak sis předpokládám přečetl, mělo by to být v každém úvodním popisu, CTR je neautentizované. Dokonce má tu vlastnost, že když překlopím bit v zašifrovaných datech, tak se překlopí odpovídající bit po dešifrování. To lze zneužít buď tak, že když kus dat znám, tak z nich můžu vyrobit libovolná jiná data (vyXORováním jejich rozdílem), nebo tak, že pokud data neznám, ale zpracováváš je automaticky opakovaně a poskytuješ nějaké chybové hlášky (vč. informace o tom jak dlouho zpracování trvalo), můžu zkoušet měnit jednotlivé bity a podle chybové hlášky usuzovat, jestli například nevyšlo CRC, nebo proces zpracování selhal až někde dále. A v některých případech tímto mohu data dešifrovat.

Tj. pokud data nemůže útočník změnit (šifrování lokálního disku či záloh uložených bezpečně vedle počítače), je to celkem jedno; pokud je měnit může (např. libovolný síťový přenos), tak k CTR potřebuješ přidat autentizaci - (H)MAC.

[bakalakadaka]

Cize GCM na uschovu a CTR na stream. Chapem. Pouzivam tu GCM verziu takze prakticky nemusim nic menit.