Az adatfolyam és a blokk-cifrák előnyei és hátrányai

Noha mindkettő szimmetrikus titkosítás, az adatfolyam-titkosítások “végtelen” kriptográfiai kulcsfolyam előállítása, és ennek felhasználása egy-egy bit vagy byte titkosításához (hasonlóan az egyszeri padhoz), míg a blokkosírók egyszerre nagyobb adatdarabokon (azaz blokkon) dolgoznak, gyakran blokkokat kombinálva a további biztonság érdekében (pl. AES CBC módban).

• Az adatfolyam-titkosítások általában gyorsabbak, mint a blokkolás, de ennek megvan a saját ára.
• A blokkosírok általában több memóriát igényelnek, mivel nagyobb adatdarabokon dolgoznak, és gyakran “átviszik” az előző blokkokat, míg mivel a stream-cifrák egyszerre csak néhány biten dolgoznak, viszonylag alacsony a memóriaigényük (ezért olcsóbbak olyan korlátozott esetekben, mint a beágyazott eszközök, a firmware és az esp. hardverek). .
• Az adatfolyam-rejtjeleket nehezebben lehet helyesen megvalósítani, és a használat alapján gyengeségekre hajlamosak – mivel az alapelvek hasonlóak az egyszeri padhoz, a kulcsfolyamnak nagyon szigorú követelményei vannak. Másrészt ez ” s általában a trükkös rész, és letölthető pl egy külső doboz.
• Mivel a blokkosírok egyszerre egy teljes blokkot titkosítanak (és ezen felül “visszajelzési” módjaik vannak, amelyek a leginkább ajánlottak), érzékenyebbek a zajra az átvitel során, vagyis ha elrontja a adatok, az összes többi valószínűleg helyrehozhatatlan. Míg a stream cifrákkal a bájtok egyedileg vannak titkosítva, nincs kapcsolat más adatrészekkel (a legtöbb cifrában / módban), és gyakran támogatják a vonal megszakításait.
• Továbbá a stream-rejtjelek nem nyújtanak integritás-védelmet vagy hitelesítést, míg egyes blokkos rejtjelek (az üzemmódtól függően) a titoktartás mellett az integritás védelmét is biztosíthatják.
• Mindezek miatt , a stream cifrák általában a legjobbak azokban az esetekben, amikor az adatok mennyisége vagy ismeretlen, vagy folyamatos – például hálózati adatfolyamok. Blokkoló titkosítások, vagy hasznosabbak, ha az adatmennyiség előre ismert – például fájl, adatmezők vagy kérési / válaszprotokollok, például HTTP, ahol a teljes üzenet hossza már a kezdet.

Megjegyzések

• A 2. pont nem pontos. A memória különbsége a ” ” átvitele miatt az előző blokkokból elhanyagolható és sokkal kisebb, mint az algoritmus és az algoritmus közötti memória különbség ( pl. hasonlítsa össze az RC4-et, annak 256 bájtos belső állapotával, az AES-szel, 0 implicit belső állapotgal egyes implikációkban). Az utolsó golyó hamis megkülönböztetéseket tartalmaz, és rossz tanács.
• @ D.W. A 2. golyó ” volt, általában “, mivel jellemzően ez a helyzet (de elfogadom, hogy nem szigorúan pontos).
• @DW van-e alapja az utolsó golyóhoz fűzött megjegyzéséhez? Hol van a hamis megkülönböztetés, és miért mondja, hogy ez rossz tanács?
• igen, van alapom az utolsó lövedékkel kapcsolatos megjegyzésemhez. Csak úgy tűnik, összezavarodott. A blokkos titkosítások alkalmasak az adatok streamingjére; lásd például a CBC módot, a CTR módot stb. a különféle működési módokról, amelyek jól működnek az adatok streamingjével. A blokkosírások nem korlátozódnak azokra az esetekre, amikor az adatok mennyisége előre ismert.

A blokk titkosítás egy sokoldalú algoritmus, amely egy kulcs- azoknak az értékeknek a függõ permutációja, amelyek rögzített bitszámú szekvenciák (úgynevezett “blokkok”). Sokféle kriptográfiai protokollban különféle szerepkörökhöz használható. Az egyik ilyen szerep a hosszú adatfolyamok tömeges titkosítása; egy ilyen dolog eléréséhez a blokkos kódot megfelelő működési móddal (más néven “láncolási mód”) kell használni, a hagyományos a CBC, és a trendi újabb mód a CTR.

A adatfolyam titkosítás egy speciális algoritmus a hosszú adatfolyamok tömeges titkosítására. Az ötlet az, hogy a blokkos titkosítás sokoldalúságának elvesztésével hatékonyabb algoritmust lehetne létrehozni (azaz olyat, amely gyorsabban titkosítja az adatokat ).

Mindkét blokkos rejtjel patakorientált titkosítási móddal és adatfolyam-titkosítókkal biztonsági problémák léphetnek fel, ha ugyanazt a kulcsot kétszer használják, két különálló adatfolyamhoz, megfelelő, egyedi / véletlenszerű Initialization Vector nélkül. A CBC titkosításhoz a IV-nek új, egységesen véletlenszerű bitek sorozatának kell lennie, ugyanolyan méretű, mint egy blokk, minden új üzenethez. A jó stream cifrák elfogadják a IV. A RC4 nevű hagyományos adatfolyam-kódolás IV-nélküli (specifikációja nem tartalmazza, hogy hova és hogyan lehetne egy IV-et beilleszteni), ami sok káoszhoz vezetett és egy rossz név a stream cifrák fogalmának.

Újabb, biztonságosabb (és gyorsabb) stream cifrákért lásd a eSTREAM portfóliót . Ezek az algoritmusok sok kriptográfus által meglehetősen alapos elemzésen mentek keresztül, és “meglehetősen biztonságosnak” tekinthetők.

A stream titkosítás Pszeudorandom számgenerátorrá alakítható. a nulla érték hosszú bájtsorainak titkosításával. Valójában sok (de nem az összes) adatfolyam-titkosítás belsőleg PRNG-ként működik, és kulcsfüggő pszeudo-véletlen byte-ok hosszú sorozatát generálja, amelyet később (bitenként XOR-nal) kombinálnak az adatokkal a titkosításhoz (vagy visszafejtéshez), tehát a nulla bájt titkosítása ekvivalens az XOR teljes kihagyásával. Ezért a stream-rejtjeleket gyakran használják egyéni PRNG-ként.

Megjegyzések

• Elfelejtette megemlíteni, hogy melyik általában biztonságosabb (stream vs blokk).
• Nem felejtettem el, mert az állításnak nincs általános értelme. Mind a blokkos, mind pedig az adatfolyam-titkosítás megfelelő biztonságot nyújthat, ha megfelelően alkalmazzák őket, és ha nincsenek trukturális gyengeségek.
• ” a blokkos titkosítás sokoldalúsága ” problémám van ezzel a résszel. Mi teszi a blokkosírást eredendően sokoldalúbbá? A blokkos titkosítások felhasználhatók mind az adatfolyamok (pl. TLS), mind a csomagolt adatok (pl. ESP) titkosítására és hitelesítésére, és a stream-rejtjeleknél (pl. TLS vagy DTLS) is azonosak. Vannak esetek, amikor a stream titkosítás ” természetesebbnek tűnik ” (pl. Hang titkosítása), vagy egy blokkos titkosítás inkább ” natural ” (pl. Lemezek titkosítása), de egyszerűen nem látok ‘ sok rést az ésszerű alkalmazásokban egyikre sem.

A stream stifrák egyik előnye, amelyekről korábban nem volt szó, hogy nem “nincs szükség kitöltésre (a blokkosírok teljes blokkon működnek, így ha nincs elegendő adatod, akkor valahogy többet kell generálnod). És meglepetés (nem igazán, a kriptográfia az a terület, ahol Murphy mindenhol megtalálható), a kitöltés elvégezhető helytelen, például a Oracle Attack gyakorlati kitöltése példában.

A blokkosírok biztonsága is nagyban függ a működési móduktól. az EKB-t néha itt-ott használják, és nem sokkal jobb, mint a kriptográfia hiánya t mindet.

Alapvetően nem mondhatod, hogy “egyik jobb, mint a másik, és egy teljes kriptoszisztémát kell megvizsgálnod a biztonsági megítéléshez.

Megjegyzések

• az első bekezdésedhez: vannak olyan működési módok a blokkos cifrák számára, amelyeknek nem szükséges

A Stream Ciphers titkosítja a sima szöveges adatokat véletlenszerű bitfolyammal (általában XOR-nal, mert könnyen megfordítható). Ha rendelkezik 128 bites adattal, akkor egy 128 bites psedurandom strem-et (a kulcsát) használja a titkosításhoz.

A Block Ciphers a sima szöveges adatokat blokkonként egyszerre titkosítja ugyanazzal az átalakítással (a kulcs alapján) ).Tehát megvan a 128 bites adata, a titkosítás blokkokra bontja őket (például 4 32 bites blokk), és ugyanazt az átalakítást alkalmazza minden blokkra, amely 4 titkosított blokkot kap, és ez együttesen alkotja a végső kriptogramot.

természetesen a blokk-cifrák biztonságosabbak, de a hardver komplexitása szempontjából drágábbak. Az adatfolyam-ciferek gyorsabbak és “olcsóbbak”, de hajlamosak lehetnek biztonsági problémákra , ha helytelenül hajtják végre őket.

Megjegyzések

• Az utolsó bekezdés számos ténybeli hibát tartalmaz. A blokkosírások általában nem biztonságosabbak, hardverben sem feltétlenül rosszabbak. Az adatfolyam-titkosítások nem feltétlenül gyorsabbak vagy olcsóbbak.
• @DW: ennek ellenére az adatfolyam-titkosítás általában gyorsabb vagy olcsóbb, mint a blokkos titkosítás, mert az ‘ s az üzlet: kevésbé sokoldalú algoritmus kereskedett a jobb teljesítmény érdekében. Az AES / CTR-nél lassabb és drágább adatfolyam-kódolás egyáltalán nem szokott megszokni.
• Elfelejtette megemlíteni, hogy melyik általában biztonságosabb (stream vs blokk).

Az adatok (a titkosítandó dolgok) általában patakokban érkeznek. Titkosításához használnunk kell egy adatfolyam-titkosítást, vagyis egy adatfolyamban történő felhasználásra alkalmas titkosítási algoritmust. Az adatfolyam tetszőleges, változó vagy meghatározatlan hosszúságú bitek (vagy bájtok) sorozata.

A legjobb titkosítások, amelyeket eddig feltaláltunk, általában a blokkos rejtjelek. A blokkos titkosítás egyetlen rögzített méretű adatblokk titkosítására képes; és a körülöttünk lévő bizonyítékok alapján nyilvánvalóan könnyebb jó blokkosírókat építeni, mint stream-re.

Jó hír azonban. Ha adott blokk-rejtjelet használunk bizonyos meghatározott mintákban (“működési mód”), és speciális kitöltési stratégiák segítségével bármilyen blokk-titkot stream-titkosítóvá alakíthatunk! Ez azt jelenti, hogy a jobb titkosításokat, amelyek blokkos titkosítások, használhatjuk az adatok titkosításához, amelyek többsége patakokban érkezik.

Megjegyzések

• a második mondat félrevezetőnek tűnik. Titkosíthatja az adatfolyam-adatot egy blokkos titkosítással, számos szokásos működési mód bármelyikének használatával: pl. CBC mód, CTR mód stb. Az AES-CBC továbbra is blokk titkosítás. Valójában a blokkos kódolók szinte minden szokásos működési módja már támogatja az adatfolyamot. Ráadásul a blokkjelzés nem biztonságos működési mód nélkül, ezért ‘ nem tetszik, hogy a működési mód olyan opcionális dolog, amelyre csak akkor van szükség, amikor a streaming adatokat titkosítani szeretné .