Kíváncsi vagyok egy olyan algoritmusra, amely jó lenne a következő szcenárióhoz:
- 32 bites “sima szöveg” bemenet, számlálóból vett
- 32 vagy 64 bites “ciphertext” kimenet
- Lehetővé kell tenni a kimenet visszafejtését a kulccsal (és esetleg néhány más rejtett paraméterrel, pl. egy offszet és egy aktuális számláló), és adja vissza az eredeti 32 bites számláló értéket
- A felhasználó soha nem figyeli a bemenetet, de akármennyi kimenetet is kaphat, esetleg szekvenciálisan. Ennek ellenére nem kellene tudni tudja, mely indexekkel rendelkezik.
- Nehéz lehet kitalálni más kimeneteket, amelyek megfelelnek az érvényes számlálóértékeknek.
Képzetlen megérzésem az, hogy mivel a kulcs és a kimenetek nagyobb, mint a bemeneti terület, meglehetősen könnyűnek kell lennie a “jó” eredmények elérésére, legalábbis az első néhány kimenet esetében. Ugyanakkor logikusnak tűnik az is, hogy elegendő minta mellett a kulcs és az indexek könnyen kiszámíthatók, de a legtöbb példára számítok használni l ess, mint 100 érték.
A kérdéseim a következők:
- Vannak-e olyan algoritmusok, amelyek működnek ebben a forgatókönyvben?
- Mennyire lenne nehéz rés? Vagyis, kiszámolja az értékeket, amelyek visszafejtik az érvényes indexeket.
- Mennyire befolyásolja a több minta birtoklása a feltörés hatékonyságát?
-
Mi a baj a naiv megközelítéssel? például:
u64 output = input repeat 64x output = ((output ^ key) + key) rotate-left 37Ha feltételezzük, hogy az összeadás körbeveszi a 64 bites egész határokat, úgy tűnik, mintha alaposan összekeverné a véletlenszerű kulcsot egyetlen bemenettel, de többel is rendelkezik A kimenet gyorsan növelheti a támadó birtokában lévő információkat, bár nem tudnám, hogyan. Nyilvánvaló, hogy törni fog, csak tanulni próbálok.
- Kulcsfüggő értéket használnék a bal oldali forgatáshoz, például
(((key & 0xFFFE)+1) * 37)jobb? Mennyire segít és miért? - Milyen megközelítéseket, erőforrásokat stb. Használna mind az algoritmus elemzéséhez, mind a jobb tervezéséhez?
Megjegyzések
- Ez nagyon XY probléma, ahogy leírja. Egy CSPRNG (vegye figyelembe az S-t) egyáltalán nem tűnik jó megoldásnak erre. A kulcsméret kérése kissé furcsa, miért nem lehet nagyobb kulcsméretet használni?
- Feltételezem, hogy a kulcsméret nem elengedhetetlen. Reméltem, hogy 64 bites kulcs elegendő egy 32 bites érték titkosításához.
Válasz
- Vannak létező algoritmusok, amelyek működnek ebben a forgatókönyvben?
Igen, valóban , számos 64 bites blokkos cifra létezik. A szokásos bölcsesség az, hogy nem ösztönzik őket általános használatra, mert a szokásos blokkos titkosítási módok általában elkezdik kiszivárogtatni az információkat, amikor a születésnapi határok közelében van (ebben az esetben kb. 30 Gbájt); aggodalomra ad okot.
Íme néhány lehetőség:
-
3DES (más néven TDES); ezt a DES-t háromszor alkalmazzák három különböző billentyűvel; ennek megvan az előnye nagyon jól tanulmányozott.
-
Speck , amelynek 64 bites blokkos titkosítóval rendelkező paraméterkészletei vannak. előnye, hogy a leggyorsabb alternatíva, és olyan emberek tervezték, akik tudják, hogy csinálják, és meglepő mennyiségű kriptanalízist hajtottak végre.
-
Egy FPE titkosítás (például Az FF1, amely bármilyen tetszőleges blokkméretet képes kezelni (beleértve a 64 bitet is). Ennek az az előnye, hogy lehetővé teszi a módosítást (amely kényelmes hely az “egyéb rejtett paraméterek” elhelyezésére, ha úgy dönt, hogy ez előny Ez lassabb, mint az alternatívák; az FF1 esetén a biztonság az AES mögöttes biztonságából, valamint a Feistel-szerkezet bizonyítható biztonságából származik.
Most ezek 64 bitnél hosszabb kulcsokat vesznek igénybe; a bölcsesség az, hogy a 64 bites kulcs éppen nem elég hosszú.
- Mennyire lenne nehéz feltörni? Vagyis számítsa ki azokat az értékeket, amelyek visszafejtik az érvényes indexeket. véletlenszerűen találd ki a rejtjelezési szövegeket, és remélem, hogy megbotlik egy olyanban, amely visszafejt egy érvényes indexet.
- Mennyibe kerül a több minta befolyásolja a feltörés hatékonyságát?
A fentiek bármelyikénél, ha hatalmas mennyiségű minta van, a támadás továbbra is megvalósíthatatlanná válik.
- Mi a baj egy olyan naiv megközelítéssel, mint …
Az ARX rejtjelek (valójában bármilyen titkosítás, de főleg az ARX) bonyolultak a helyes helyrehozáshoz. Különösen az ARX rejtjelek nem hajlandóak nagyszerűen megkülönböztetni a differenciális és lineáris jellemzőket (ami minden ilyenet jelent. a formatervezést valóban alaposan tanulmányozni kellene, hogy megbizonyosodhasson róla).
- Milyen megközelítéseket, erőforrásokat stb. használna mind az algoritmus elemzéséhez, mind a jobb tervezéséhez?
Javasolnám, hogy válasszon egy már elemzett tervet; felsorolok hármat fent.
Megjegyzések
- Én ' inkább a Blowfish-t részesíteném előnyben a 3DES-sel szemben, ha viszonylag kis kulcsbemenet változik. A 3DES biztonsága akkor is legyen kétséges, ha a kulcs 128 bitre bővült re (vagy inkább 112 bitre, természetesen).
- @MaartenBodewes: Van-e idézete bárkinek, aki megmutatja, hogy a 3DES egy ismeretlen kulcs különböztethető meg a véletlenszerű egyenletes permutációtól?
- Nem, természetesen nem. Azonban ' nem is kell okot adnom, ha a titkosításom ~ 80 bites vagy ~ 112 bites erősségű, ha 128 vagy 192 bites kulcsot táplálnak (én ' nem kételkedtem abban, hogy képes lesz rá, de hé, mi re nem minden poncsó). Úgy tűnik, hogy a kulcs mérete kérdéses. A paritásbitek eldobása ebben az esetben pazarló.
- Részletesen kifejtheti a " állítást. Ezek a kulcsok 64 bitnél hosszabb ideig tartanak; a bölcsesség az, hogy a 64 bites kulcs nem elég hosszú. "? Mely algoritmusokhoz milyen hosszúságú kulcsok szükségesek, és a 64 bites kulcsok mire nem elég hosszúak?
- @shader: a csak 64 bites kulcsok kiszolgáltatottak a nagy (jól finanszírozott) ellenfelek által végzett durva erőkeresésnek. Mivel általában elég könnyű valamivel nagyobb (pl. 128 bites) kulcsokat használni, amelyek nem ' senki számára sérülékenyek, általában a biztonságosabb opciót választjuk (akkor is, ha ' nem azonnal aggódik amiatt, hogy az NSA érdekelt lesz-e bennünket támadni, vagy ha az Amazon úgy dönt, hogy teljes felhőjét ránk fordítja …