Jsem zvědavý na algoritmus, který by byl vhodný pro následující scénář:
- 32bitový „prostý text“ vstup převzatý z čítače
- 32 nebo 64bitový výstup „ciphertext“
- Mělo by být možné dešifrovat výstup pomocí klíče (a případně několika dalších skrytých parametrů, například offset a aktuální čítač) a vrátit původní hodnotu 32bitového čítače
- Uživatel nikdy nepozoruje vstup, ale může obdržet libovolný počet výstupů, případně sekvenčních. I tak by neměl být schopen vědět, které indexy mají.
- Mělo by být obtížné odhadnout další výstupy, které odpovídají platným hodnotám čítače.
Moje netrénovaná intuice spočívá v tom, že klíč a výstupy jsou větší než vstupní prostor, mělo by být docela snadné mít „dobré“ výsledky, alespoň pro prvních pár výstupů. Zdá se však také logické, že s dostatečným počtem vzorků lze klíč a indexy snadno vypočítat, ale očekávám většinu případů použít l es než 100 hodnot.
Moje otázky jsou:
- Existují nějaké existující algoritmy, které fungují pro tento scénář?
- Jak těžké by bylo crack? Tj. Spočítejte hodnoty, které dešifrují platné indexy.
- Jak moc má držení více vzorků vliv na účinnost jejich rozluštění?
-
Co je špatného naivního přístupu jako:
u64 output = input repeat 64x output = ((output ^ key) + key) rotate-left 37Za předpokladu, že se sčítání zalomí kolem 64bitových celočíselných hranic. Zdá se, jako by to důkladně promíchalo náhodný klíč s jediným vstupem, ale s více než jedním výstup by mohl rychle zvýšit informace, které útočník vlastní, i když bych nevěděl jak. Je zřejmé, že to bude rozbité, jen se to snažím naučit.
- Použil bych pro otáčení doleva hodnotu závislou na klíči, například
(((key & 0xFFFE)+1) * 37) - Jaké přístupy, zdroje atd. Byste použili k analýze algoritmu a návrhu lepšího?
Komentáře
- Toto je XY problém tak, jak ho popisujete. CSPRNG (všimněte si S) se ' vůbec nezdá být dobrým řešením. Požadavek na velikost klíče je trochu divný, proč není možné použít větší velikosti klíče?
- Předpokládám, že velikost klíče není nezbytná. Doufal jsem, že 64bitový klíč bude stačit k zašifrování 32bitové hodnoty.
Odpověď
- Existují nějaké existující algoritmy, které fungují pro tento scénář?
Ano, ve skutečnosti , existuje řada 64bitových blokových šifer. Standardní moudrost spočívá v tom, že nejsou podporovány pro obecné použití, protože standardní režimy blokové šifry mají sklon k úniku informací, když se přiblížíte k hranici narozenin (v tomto případě přibližně 30 Gbytů); pro váš případ použití by to však buďte znepokojeni.
Zde je několik možností:
-
3DES (aka TDES); toto je DES aplikovaný třikrát se třemi různými klíči; to má tu výhodu velmi dobře prostudován.
-
Speck , který má sady parametrů se 64bitovými blokovými šiframi. Výhodou je nejrychlejší alternativa a byla navržena lidmi, kteří vědí, že to dělají, a to díky překvapivé míře dešifrování.
-
Šifra FPE (například FF1, který dokáže zpracovat libovolnou velikost bloku (včetně 64 bitů). To má tu výhodu, že umožňují možnost vylepšení (což je vhodné místo pro umístění „dalších skrytých parametrů“, pokud se rozhodnete, že je to výhoda ). Své pomalejší než alternativy; s FF1 pochází zabezpečení ze základního zabezpečení AES a prokazatelného zabezpečení struktury Feistel.
Nyní to trvá klíče delší než 64 bitů; běžná moudrost je, že 64bitový klíč prostě není dost dlouhý.
- Jak těžké by bylo prolomit? Tj. Spočítat hodnoty, které dešifrují platné indexy.
U kterékoli z výše uvedených možností by jedinou praktickou možností, kterou by protivník měl, bylo náhodně hádejte šifrovací texty a doufejte, že narazíte na ten, který dešifruje platný index.
- nakolik majetek na účinnost jeho prolomení má vliv více vzorků?
U některého z výše uvedených případů bude mít obrovské množství vzorků útok stále nemožný.
- Co se děje s naivním přístupem jako …
Šifry ARX (vlastně jakákoli šifra, ale zejména ARX) jsou složité, aby se daly správně. Zejména šifry ARX nemají tendenci narušovat diferenciální a lineární charakteristiky (což znamená, že design by opravdu musel být dobře prostudován, aby se ujistil, že ano).
- Jaké přístupy, zdroje atd. byste použili k analýze algoritmu a návrhu lepšího?
Navrhuji, abyste šli s designem, který již byl analyzován; výše uvádíme tři.
Komentáře
- Já ' d preferuji např. Blowfish před 3DES, pokud dojde ke změně relativně malého klíčového vstupu. Zabezpečení 3DES by Pochybujte, i když byl klíč rozšířen na 128 bitů (nebo spíše 112 bitů, samozřejmě).
- @MaartenBodewes: citujete někoho, kdo ukazuje, že 3DES s neznámý klíč je odlišitelný od náhodné sudé permutace?
- Ne, samozřejmě že ne. Nicméně ' bych raději ani nemusel uvažovat, pokud moje šifrování má ~ 80bitová nebo ~ 112bitová síla při napájení 128bitového nebo 192bitového klíče (' nemám pochyb o tom, že byste to dokázali, ale hej, my nejsou všichni pončo). A velikost klíče se zdá být problémem v této otázce. V tomto případě je zbytečné vyhodit paritní bity zbytečné.
- Mohl byste rozvinout tvrzení " Nyní to trvá klíče delší než 64 bitů; běžná moudrost je, že 64bitový klíč prostě není dost dlouhý. "? Které algoritmy vyžadují klíče, jejichž délky, a 64bitové klíče nejsou dostatečně dlouhé, na co přesně?
- @shader: klíče pouze 64 bitů jsou zranitelné při hledání hrubou silou od velkých (dobře financovaných) protivníků. Protože je obecně snadné použít poněkud větší klíče (např. 128 bitů), které nejsou ' t nikomu zranitelné, obecně se rozhodneme pro bezpečnější možnost (i když nemám bezprostřední obavy, že NSA bude mít zájem na nás zaútočit, nebo jestli se Amazon rozhodne věnovat nám celý svůj cloud …