Az adatfolyam-titkosítás és a blokkjelzés közötti különbség

A blokkos titkosítás a $ k $ -bit és $ n $ -bit (sima szöveg) determinisztikus és kiszámítható függvénye blokkok $ n $ bites (titkosított) blokkokra. (Általánosságban elmondható, hogy a blokkoknak nem kell bit méretűnek lenniük, $ n $ -karakter-blokkok is ide illenek). Ez azt jelenti, ha titkosít ugyanaz a sima szövegblokk ugyanazzal a kulccsal, ugyanazt az eredményt kapja. (Általában azt is szeretnénk, hogy a függvény invertálható legyen, vagyis hogy a kulcs és a rejtjeles szöveg blokk esetén ki tudjuk számítani a sima szöveget.)

Egy (bármilyen méretű) üzenet tényleges titkosításához vagy visszafejtéséhez nem kell ” t ne használja közvetlenül a blokk titkosítást, de helyezze üzemmódba . A legegyszerűbb ilyen mód az elektronikus kódkönyv mód (ECB) lenne, amely egyszerűen blokkokra vágja az üzenetet, minden blokkra alkalmazza a titkosítást. és kimeneti az eredményül kapott blokkokat. (Ez általában nem biztonságos mód.)

Néhány olyan korai titkosítási séma, mint például a Caesar által használt, “blokk titkosításnak, 1 karakteres blokkokkal az EBB-ben” -mode “. Vagy általában minden, aminek van kódkönyve .

Általában más működési módokat használunk, amelyek közé tartozik egy inicializáló vektor és valamilyen visszajelzés, így minden blokk minden üzenet különböző módon van titkosítva.

A adatfolyam-titkosítás egy olyan függvény, amely a $ k $ bites kulcsokat és tetszőleges hosszúságú szöveges szövegeket közvetlenül (azonos tetszőleges hosszúságú) titkosított szöveggé alakítja, ilyen úgy, hogy a sima szöveges térkép előtagjai a rejtjelszöveg előtagjaihoz, vagyis kiszámíthatjuk a rejtjelszöveg kezdő részét, mielőtt a sima szöveg hátralévő része ismert. (Gyakran előfordulhat, hogy az üzenetek mérete korlátozódik valamilyen “blokkméret” többszörösére is, de általában kisebb blokkokkal, például egész bájttal vagy hasonlóval.)

Ha a sima szöveg egy része megismétlődik, a megfelelő rejtjeles szöveg általában nem ugyanaz – az üzenet különböző részeit különböző módon titkosítják.

Az ilyen adatfolyam-cifrák gyakran úgy működnek, hogy a tényleges kulcsból létrehoznak egy kulcsfolyamot (és esetleg egy inicializáló vektort ), majd egyszerűen XOR-t készítsen az üzenettel – ezeket hívjuk szinkronfolyam-rejtjeleknek . Más adatfolyam-titkosítók az előző részektől függően megváltoztathatják az üzenet jövőbeli részeinek titkosítását.

Bizonyos blokkos titkosítási üzemmódok szinkron adatfolyam-titkosítást hoznak létre, például CTR és OFB mód.

Soha ne használja fel újra a szinkron adatfolyam-titkosítás kulcsát (és adott esetben a IV-et) (amely streaming titkosításokat is tartalmaz a streaming üzemmódokban) különböző üzenetekhez, mivel ez kompromisszumokhoz vezethet. (És még ugyanarra az üzenetre is megmutatja, hogy megismételted az üzenetet.)

Ne feledje, hogy a tényleges használat során MAC-re is szükséged lesz, pl. integritásvédelem az üzenetedhez. (Egyes sémák megszakadnak például egy választott titkosított szöveges támadás esetén, és egy ilyen MAC ezt megakadályozza (ha az üzenetet csak a MAC ellenőrzése után adja át a visszafejtőnek).)

Megjegyzések

• Mikor választana a stream vagy a block között? Van-e különbség a biztonságban? Vagy a titkosítás sebessége?
• @anoopelias A blokkos titkosítások általában lassúak a Stream titkosításokhoz képest. Ezenkívül nem vagyok biztos benne, de úgy gondolom, hogy az adatfolyam-titkosítók jól szolgálják az információbiztonságot, míg a blokkosírások a számítástechnikai biztonságot
• Az utolsó bekezdést illetően – kérem, adjon meg egy linket egy példához MAC hozzáadása megvédi a választott titkosítási támadást?

Matematikailag a blokk titkosítás csak egy kulcsos pszeudorandom permutáció család a $ n $ -bit blokkok $ \ {0,1 \} ^ n $ halmazában. (A gyakorlatban általában az inverz permutáció kiszámításának hatékony módjára is szükségünk van.) A blokkos titkosítás önmagában nem túl hasznos a gyakorlati kriptográfia számára, legalábbis, hacsak nem véletlenül kell apró titkosítást végezni. üzenetek, amelyek mindegyike egyetlen blokkba illeszkedik.

Kiderült azonban, hogy a blokkosírok rendkívül sokoldalú építőelemek más kriptográfiai eszközök elkészítéséhez: ha már van egy jó blokkos titkosítás, egyszerűen felépíthet bármit a stream-rejtjelektől a hash-függvényekig, az üzenet-hitelesítési kódokig, a kulcs-levezetési függvényekig, az álvéletlenszerű számgenerátorokig, az entrópiatárakig stb. Csak egy blokkos titkosítás alapján.

Nem feltétlenül mindegyik alkalmazás szükségük van egy blokkos rejtjelre; például sok közülük bármely álvéletlen függvényen alapulhat, amelyeknek nem kell permutációnak lenniük (de kényelmesen “sa lemma , amely szerint egy álszúrásos permutáció mégis működni fog.) Emellett sok konstrukció közvetett; például létrehozhat egy kulcsszármazási függvényt egy üzenet hitelesítési kódból, amelyet kivonat egy hash függvényből, amelyet — tud létrehozni, de — nem kell egy blokkból felépítenie rejtjel. De mégis, ha van blokkos titkosítása, akkor az összes többi részét megépítheti .

Ezenkívül ezek a konstrukciók általában (feltételes) biztonsági bizonyítékokkal rendelkeznek, amelyek csökkentik a biztonságot. a felépített függvényeké az alapul szolgáló blokkos titkosításéhoz. Ezért nem kell elvégeznie a fáradságos és megbízhatatlan feladatot, hogy ezeket a funkciókat külön-külön kriptanalizálja —, hanem minden erőfeszítését a blokkosírásra koncentrálhatja, annak tudatában, hogy a blokkos titkosítás biztonságával szemben támasztott bármely bizalma közvetlenül az összes azon alapuló funkció bizalmává válik.

Nyilvánvaló, hogy mindez nagyon kényelmes, ha mondjuk dolgozol rajta egy kis beágyazott platform, ahol nehéz és drága lehet hatékony és biztonságos kódot tartalmazni különálló kriptográfiai primitívekhez. De még akkor is, ha Ön nem ilyen korlátozott platformon van, az alacsony szintű kriptokód megírása és elemzése fáradságos lehet, mivel oda kell figyelni például az oldalsó csatorna támadásokra . Könnyebb korlátozni magad korlátozott számú alacsony szintű építőelemre, és ezekből mindent felépíteni.

Ezenkívül még gyors, sok memóriával rendelkező platformokon is, az asztali CPU-khoz hasonlóan az alacsony szintű kriptográfiai műveletek közvetlen hardveres végrehajtása sokkal gyorsabb lehet, mint a szoftveres végrehajtás —, de néhányuknál többet nem célszerű megtenni . Sokoldalúsága miatt a blokkosírok kiválóan alkalmasak hardveres megvalósításra (mint például a modern x86-os CPU-k AES utasításkészletében .

Mi a helyzet akkor a stream-rejtjelekkel?

Matematikailag egy stream-rejtjel — szintén kulcsos invertálható álvéletlen függvénycsalád, de tetszőleges hosszúságú bitláncok $ \ {0,1 \} ^ * $ halmazán, nem pedig korlátozott hosszúságú blokkokon.

(Van itt néhány finomság; például a legtöbb stream-rejtjeles konstrukció megköveteli, hogy a bemenet egyedi nonce értéket tartalmazzon, és nem garantálja a biztonságot — abban az értelemben, hogy megkülönböztethetetlen egy valóban véletlenszerű függvénytől —, ha ugyanazt a nonce-t két különböző bemenetre használják. a (z) $ \ {0,1 \} ^ * $ értéktől az invertálható függvényekig nincs egységes eloszlás a véletlenszerű függvények kiválasztásához, alaposan meg kell határoznunk, hogy mit jelent az, hogy egy adatfolyam titkosító “véletlenszerűen megkülönböztethetetlennek” tűnik, és ennek a definíciónak van gyakorlati biztonsági vonatkozásai —, például a legtöbb adatfolyam-titkosító kiszivárogtatja az üzenet hosszát. Gyakorlatilag általában azt is megköveteljük, hogy az adatfolyam-titkosítók, valójában legyen “streaming” abban az értelemben, hogy önkényesen hosszú bemeneti bitfolyamok titkosíthatók — és visszafejthetők — az o használatával általában állandó tárolás és az idő hossza az üzenet hosszában.)

Természetesen a stream titkosítások sokkal azonnal hasznosabbak, mint a blokkos titkosítások: közvetlenül felhasználhatja őket bármilyen hosszúságú üzenetek titkosításához. Kiderült azonban, hogy ezek sokkal kevésbé hasznosak más kriptográfiai eszközök építőelemeként is: ha van blokk titkosítás, akkor könnyen fordítsd stream stifrá , míg egy tetszőleges stream cifrát blokk titkosítássá nehéz, ha nem lehetetlen .

Miért zavarják tehát az emberek egyáltalán a dedikált adatfolyam-titkosításokat, ha a blokkos titkosítók ugyanolyan jól képesek elvégezni a munkát? Ennek oka elsősorban a sebesség: néha gyors titkosításra van szükség a sok adat titkosításához, és vannak olyanok, amelyek igazán gyors dedikált adatfolyam-rejtjelezés. Ezek a tervek némelyikét nagyon kompakt módon tervezik megvalósítani, akár szoftveresen, akár hardveresen, akár mindkettőben, így ha valóban csak adatfolyam-rejtjelre van szüksége, spóroljon a kód / áramkör méretén, ha egy ilyen titkosítást használ egy általános blokkos titkosításon alapuló helyett.

Amit azonban gyorsasággal és tömörséggel nyer, azt sokoldalúságában elveszíti. xample, úgy tűnik, nincs “egyszerű módja annak, hogy hash függvényt készítsen egy stream titkosításból , tehát ha szükséged van valamire (és gyakran csináld, mert a hash függvények amellett, hogy önmagukban is hasznosak, más kriptográfiai eszközök általános építőkövei is), külön kell végrehajtanod őket. És találd ki, a legtöbb hash függvény blokk titkosításokon alapul, így ha van ilyen, akkor ugyanazt a blokk titkosítást is felhasználhatja a titkosításhoz (hacsak nem igazán kell a dedikált stream titkosítás nyers sebessége).

Megjegyzések

• Azt kérdeztem, hogy szükséges-e két különböző kifejezés. Az Ön fejtegetése szerint a stream titkosítás egyszerűen egy blokkos titkosítás speciális esete, azaz egy olyan korlátozó esetre, ahol a n a {0,1} ^ n halmazban 1. Tehát azzal érvelnék, hogy ne tartsam fenn az áramot a terminológiák megkülönböztetése.
• @ Mok-KongShen Valójában a stream titkosítás nem egyszerűen 1 blokk méretű blokk titkosítás (a klasszikus monoalfabetikus titkosítások kivételével, amelyek feltételezhetők mindkettőnek). Az adatfolyam-rejtjel általában a stream bitjeit / bájtjait / … másképp fordítja, a titkosítás aktuális belső állapotától függően, míg egy blokk titkosítás ugyanahhoz a bemenethez ugyanolyan kimenettel rendelkezik (és ezért általában egy ” működési mód ” stream titkosítás létrehozásához).
• @PauloEbermann. IMHO válaszolt nekem a CodesinChaos kérdésére, amely a ” dinamikát és a változékonyságot “.
• @ Mok-KongShen Nem nem ‘ t. A dedikált adatfolyam-titkosítás egyetlen előnye a blokk-titkosítással szemben megfelelő módban a teljesítmény. ‘ Nem hagyhatja figyelmen kívül a láncolási módokat, mivel senki sem használ megfelelő láncolás nélkül blokkjeleket.
• @CodesInChaos. A különböző alkalmazások eltérő teljesítménykövetelményekkel rendelkeznek. Titkosítani pl. egy e-mail, nem kell ‘ szüksége a teljesítményre, amely kívánatos lenne mondjuk egy videofájl titkosításához.

A blokk titkosítás önmagában n biteket társít n bitet egy kulcs segítségével. azaz pszeudo-véletlenszerű permutációval rendelkezik. Nem fogad hosszabb vagy rövidebb szövegeket.

Az üzenet tényleges titkosításához mindig láncolási módra van szükség. Az EKB egy ilyen láncolási mód (és nagyon rossz), és ez nem a tiszta blokkos titkosítás. Még az EKB is “kiegészítő feldolgozási műveletekből” áll. Ezeknek a láncolási módoknak meglehetősen eltérő tulajdonságaik lehetnek.

Az egyik legnépszerűbb láncolási mód, a Counter mode (CTR) szinkron adatfolyam-titkosítást készít egy blokkos titkosításból.Egy másik mód, a CFB létrehoz egy önszinkronizáló adatfolyam-titkosítást, amelynek tulajdonságai valahol a CBC és a szinkron stream-rejtjelek között vannak.

Tehát az a feltételezésed, hogy a stream és a blockciphers között nincsenek titkosítók, nem igazán igaz. Cryptographers inkább csak a jól megértett blokkosírási primitívből építse fel őket, egy teljesen új rendszer létrehozása helyett.

Vigenère-t stream-titkosításnak nevezném, bár túl rövid időtartammal. A 26 szimbólum kódolást használja a 2 szimbólum kódolás helyett, de ez nem azt jelenti, hogy ez nem egy stream titkosítás. Nézze meg a Solitaire / Pontifex webhelyet, és keresse meg a 26 szimbólummal ellátott adatfolyam modern felépítését.

Megjegyzések

• Ha nem ‘ nem tévedek, ” láncolva ” a blokktitkosítást általában a ” blokkláncolás ” összefüggésben alkalmazzák, vagyis az egymást követő blokkokat egymástól függővé teszik annak érdekében, hogy a elemzés nehezebb. Tehát az IMHO EKB-nak értelemszerűen nem lenne láncolási hatása.
• Téved. A jó láncolási módnak megvannak ezek a tulajdonságai, de rossz módok továbbra is léteznek!

A titkosításnak két alapvető típusa van.

1. Szimmetrikus. Ugyanazt a kulcsot használja a titkosításhoz és a visszafejtéshez.
2. Aszimmetrikus. Két különböző kulcsot (nyilvános és privát) használ a titkosításhoz és a visszafejtéshez.

A Block Cipher és a Stream Cipher a szimmetrikus titkosítás részét képezi. A Stream Cipher egy kiterjesztett kulcstáramot generál a felhasználó által megadott kulcsból, majd XoR-t szöveges szöveggel (titkosításhoz) / rejtjelezett szöveggel (visszafejtéshez).

Míg a Block Cipher az adatblokkot veszi bemenetként, futtasson rajta több kört a billentyűkeverés mellett, és készítsen Cipher szöveget A blokkos cifráknak különféle működési módjai vannak, amelyek közül a számláló (CTR) mód hasonlóan működik, mint az adatfolyam-titkosítás. Egy szekvenciális számot adunk meg a blokkos titkosításhoz, és annak kimenetét Plaintext-szel Xore-oljuk, hogy Ciphertext-t készítsünk. Ebben a működési módban csak a blokkos titkosítás kódjára van szükség. Nincs szükség visszafejtő kódra, a visszafejtéshez egyszerűen meg kell adnunk ugyanazt a sorozatszámot a titkosítás blokkolásához, és a kimenetét Ciphertext-tel Xore-zoljuk, hogy sima szöveget kapjunk. Valamikor a számlálóval együtt használnak egy átugrást, ezért adja meg a blokkos titkosítást két részre osztva, azaz egy fix javításra és növekményes számlálóra.

Egyéb működési mód a következők: –

1. EKB (bizalmas jellegű)
2. CBC és CTR (bizalmas jellegű és szektorilag biztonságos a kiválasztott Plaintext Attack ellen)
3. EAX, CCM és GCM (hitelesített titkosítást biztosít)

További részletek ITT