Otázka:
Je to způsob, jak implementovat CTR kolem systému, který implementuje pouze CBC, CFB, CTS, ECB a OFB?
jnm2
2011-06-17 15:47:42 UTC
view on stackexchange narkive permalink

Šifrovací knihovna v mém programovacím jazyce nepodporuje CTR, ačkoli podporuje CBC, CFB, CTS, ECB a OFB. Předpokládám, že je teoreticky možné bezpečně implementovat CTR kolem jednoho z těchto dalších režimů.

Takže mě zajímá, jsou tyto citace popisující správnou implementaci CTR z hlediska bezpečnosti? Pokud jsem četl, myslím, že jsou, ale chci se jen ujistit, že mi něco nechybí.

Studoval jsem trochu víc a zjistil jsem, že bloková transformace pro CTR režim je opravdu jen výsledkem toho, že XOR provede prostý text s AES ECB transformací monotinicky rostoucího počitadla. S tímto porozuměním jsem dokázal docela snadno implementovat režim AES CTR nad režim AES ECB, který je zabudován do .NET BCL.

A,

Je možné implementovat AES krypto v režimu CTR pomocí třídy AesManaged, i když to vyžaduje nějakou práci navíc. Chcete-li implementovat režim CTR s třídou .NET AesManaged, udělám to takto: Použijte CipherMode.ECB, PaddingMode.None. [V režimu CTR není nutná žádná výplň, protože vždy šifrujeme 16bajtový čítač.] Při šifrování volejte CreateEncryptor (). Pomocí výsledné ICryptoTransform pro každý blok transformujte nonce 16 bajtů (stejné jako velikost bloku AES) a poté XOR výsledek této transformace s holým textem, abyste získali ciphertext. Zvyšuje nonce po každém bloku. Pokračujte, dokud už nebudou žádné bloky - nezapomeňte na finální transformaci bloku pro poslední blok 16 nebo méně bajtů.

Jedna věc, když citát říká „přírůstek“ jaký by to měl být přírůstek? Určitě ne lineární?

Jeden odpovědět:
Thomas Pornin
2011-06-17 17:30:46 UTC
view on stackexchange narkive permalink

Texty, které citujete, jsou správné: Režim CTR je ve skutečnosti o šifrování postupných hodnot čítače a XORování výsledného proudu bajtů s daty k šifrování.

Režim CTR je „schválený“ provozní režim, jak uvádí NIST. Pro „přírůstek“ může jít o jakýkoli způsob procházení 128bitovými hodnotami, jak chcete (předpokládám blokovou šifru se 128bitovými bloky, například AES), ale pokud hledáte interoperabilitu, pak „the“ standardní režim CTR je následující:

  • Počítadlo je 128bitové celé číslo bez znaménka, tj. hodnota mezi 0 a 2 128 sup> -1 .
  • Čítač je kódován jako posloupnost 16 bajtů pomocí konvence big-endian (nejvýznamnější je první bajt).
  • Počáteční hodnota ( IV) je kódování big-endian první hodnoty čítače; jinými slovy, s AES / CTR je prvních 16 bajtů šifrovaného textu výsledkem XOR prvních 16 bajtů prostého textu se šifrováním IV (jako 16bajtový blok).

Protože většina programovacích jazyků nemá 128bitové celočíselné hodnoty, přírůstek čítače se obvykle provádí bajt po bajtu (počínaje bajtem 15, přírůstek; pokud je výsledek 0, je přenos a pokračujete s bajtem 14 atd., jinak se prostě zastavte).

Zabezpečení režimu CTR se spoléhá na to, že nikdy nebude mít pro daný klíč dvakrát stejnou hodnotu čítače. 128bitové bloky jsou velký prostor; náhodná a jednotná volba IV je dostatečná k zajištění této politiky opětovného použití. Použití režimu CTR s blokovou šifrou, která má menší bloky (např. 3DES a její 64bitové bloky), může být nebezpečné, protože prostor 264 není tak velký.

Jedním ze způsobů prohlížení režimu CTR je, že se z blokové šifry stává generátor pro dlouhý proud pseudonáhodných bajtů; XORing tohoto streamu s daty k šifrování z něj dělá streamovou šifru.

Měl jsem dojem, že režim CTR zahrnoval zřetězení nonce a counter, přičemž nonce nepůsobil jako počáteční hodnota čítače.Pokud si vzpomínám, je to provedeno tímto způsobem, aby se odstranily požadavky skutečně náhodné nonce.Nonce může být libovolná hodnota, která je jedinečná, i když se dvě nonce liší pouze o 1 (což by byla katastrofa, kdyby byly nonces použity jako počáteční hodnota čítače).


ⓘ
Tyto otázky a odpovědi byly automaticky přeloženy z anglického jazyka.Původní obsah je k dispozici na webu stackexchange, za který děkujeme za licenci cc by-sa 3.0, pod kterou je distribuován.
Loading...