Hlavní navigace

Vlákno názorů ke zprávičce Šifrování je velký problém, říká šéf FBI Christopher Wray od knezi - A nebo to jenom tak říká, aby nás...

  • Aktualita je stará, nové názory již nelze přidávat.
  • 25. 10. 2017 6:16

    MasoxCZ (neregistrovaný)

    I to je samozřejmě možné, protože jakmile bude zvládnuta technologie kvantových procesorů, bude veškerá dnes používaná kryptografie zranitelná. Mělo by pak stačit kvantovému louskáčku zašifrovaná data a úsek otevřených dat dlouhý alespoň jako klíč spolu s algoritmem použité šifry, a mělo by vypadnout jediné správné řešení.
    Aspoň takhle je to popisováno v literatuře, i když v praxi to taková zívačka není.

  • 25. 10. 2017 8:55

    Vít Šesták

    Veškerá? Co třeba AES256?

    Kvantové počítače podle současných poznatků dělají problém především asymetrické kryptografii, kde poskytují řešení běžně používaných problémů v polynomiálním čase. Ani tady to není úplně beznadějné, ale je fakt, že kvantové kryptografii odolná asymetrická kryptografie se moc nepoužívá.

    Kde to naopak není moc problém, je symetrická kryptografie a hashovací funkce. Ano, Groverův algoritmus dovede usnadnit bruteforce, ale stačí dvakrát delší klíč a máme vyřešeno. Problém to může trochu být u password-based encryption, kde bychom po uživatelích měli chtít delší hesla. Na druhou stranu, ani tady to nemusí být tak horké:

    * Paměťově náročný key-stretching může být na kvantových počítačích praktický problém. Lámání hesla tak může být u dnešních state-of-the-art schémat ještě nemalý čas pro kvantové počítače neřešitelné. Paradoxně tak může být rychlejší prolomit samotný klíč (AES128 na kvantovém počítači s cca 2^64 operacemi) než do relativně dobré heslo (na kvantovém počítači ještě nějaký čas neřešitelné, na klasickém by to trvalo dlouho).
    * Nejsem si jist, jak půjde Groverův algoritmus rozdělit na více kvantových počítačů, aniž bychom začali ztrácet jeho výhody. Možná ano, ale vůbec netuším jak.

  • 25. 10. 2017 20:34

    Vít Šesták

    Teoreticky by se dalo zkusit ti hrát s time-space-tradeoffem a prodloužit čas. Při vhodnému nárůstu časové náročnosti by to ale mohlo být nepoužitelné.

  • 25. 10. 2017 10:14

    Jarda_P

    Mělo by pak stačit kvantovému louskáčku zašifrovaná data a úsek otevřených dat dlouhý alespoň jako klíč spolu s algoritmem použité šifry, a mělo by vypadnout jediné správné řešení.

    To je podminka, kterou je tezke splnit. Oni lidi obvykle se zasifrovanymi daty neposilaji ten kus nesifrovanych dat o delce klice. Ostatne si nejsem jisty, ze pri splneni teto podminky by neslo tu sifru prolomit na obycejnem notebooku.

  • 26. 10. 2017 23:10

    Vít Šesták

    Té citované části textu jsem si původně ani nevšiml. Možné to samozřejmě je, otázka je, v jakém čase.

    Nejdříve klasické počítače: Tam to celkem jistě (podle současných poznatků) nejde. Kdyby to šlo, tu podmínku lze velmi snadno splnit a byl by to dost velký problém. Vemte si, kolik různých predikovatelných hlaviček se používá. A část plaintextu může útočník často ovlivnit. Představte si, budete si prohlížet tv.nova.cz (plain HTTP), já budu (třeba s pomocí Wi-Fi Pineapple) modifikovat komunikaci a vložím tam „<img src="https://­mail.google.com/?012345­67890123456789ab­cdef">“. Váš prohlížeč se nejspíš pokusí připojit na mail.google.com:443, udělat TLS handshake a poslat* „GET /?01234567890­123456789abcdef“, což je 256 bitů známého (a dokonce do jisté míry libovolně zvoleného) plaintextu. Tím jsem celkem jednoduše splnil precondition útoku. Pokud by se mi podařil, mohl bych si přečíst i zbytek požadavku, včetně hlavičky Cookie, což by pro krádež identity mohlo stačit.

    U kvantových počítačů taky nevím o ničm, co by tento útok umožňovalo, a to jsem se o možnosti kvantových počítačů zajímal právě s ohledem na kryptoanalýzu. Vím o dvou zajímavých kvantových algoritmech, a to Shorův algoritmus (faktorizace prvočísel nebo diskrétní logaritmus snad v O(n^3)) a Groverův algoritmus (bruteforce v O(2^(n/2)) místo O(2^n)). Rozhodně podle současných poznatků o nezvládají NP-úplné problémy v polynomiálním čase: https://en.m.wikipedia.org/wiki/Grover%27s_algorithm#Optimality

    *) Pro zjednodušení vynechám HTTP/2, nejsem si zde úplně jist detaily.

  • 27. 10. 2017 0:12

    Jarda_P

    A část plaintextu může útočník často ovlivnit. Představte si, budete si prohlížet tv.nova.cz (plain HTTP), já budu (třeba s pomocí Wi-Fi Pineapple) modifikovat komunikaci a vložím tam „<img src="https://­mail.google.com/?012345­67890123456789ab­cdef">“. Váš prohlížeč se nejspíš pokusí připojit na mail.google.com:443, udělat TLS handshake a poslat* „GET /?01234567890­123456789abcdef“, což je 256 bitů známého (a dokonce do jisté míry libovolně zvoleného) plaintextu. Tím jsem celkem jednoduše splnil precondition útoku. Pokud by se mi podařil, mohl bych si přečíst i zbytek požadavku, včetně hlavičky Cookie, což by pro krádež identity mohlo stačit.

    Nevim, v tom se moc nevyznam. Treba jste ucinil velky objev, ktery by ovsem soudruzi z tripismenkovych agentur ucinili jiz pred vami a pokud je to tak jednoduche, aktivne by to pouzivali.

    To, co popisujete, ale neni ten typ sifrovani, ktery soudruhum zpusobuje problemy. Ty jim delaji zasifrovane founy a nepochybne nejen ty, ale i vse, co dela end-to-end sifrovani. Tedy napriklad IM nebo sifrovany mail. A to i tehdy, kdyz ho nekdo posle pres webmail, vy se prohackujete pres TLS a ukradnete zpravu. Ta ovsem bude ASCI kodovana sifrovana zprava, ke ktere nemate klic a urcite nemate ten plaintex a nemate moznost ho ziskat. Muzete leda tak doufat, ze zprava zacina nejakym znamym oslovenim, tedy napriklad Hi, Hello, Cest praci...... To vam ale asi na rekonstrukci klice stacit nebude.

  • 27. 10. 2017 7:50

    Vít Šesták

    Nová ta technika určitě není [1] a dnes odolnost vůči known/chosen plaintext attack se bere jako jeden ze základních požadavků.

    V příspěvku výše jsem zmiňoval spíše symetrické šifry, kde máte typicky dost krátké klíče (128b–256b, tedy 16B–32B). V případě asymetrických by takovýto útok byla ještě větší bomba, protože při znalosti veřejného klíče si můžete takovýto crib vytvořit.

    Neříkám, že preconditions by byly splněny vždy (reálně má mnoho praktických útoků nějaké preconditions, jejichž splnění není samozřejmostí), ale dost často by se něco našlo. U šifrovaného telefonu by stačil nějaký typický soubor, u šifrovaného e-mailu by mohlo stačit i nějaké „--------------- original message -----------------“. U fotek by pomohly hlavičky. Uznávám, IM by mohl být trochu oříšek.

    [1] https://en.m.wikipedia.org/wiki/Gardening_(cryptanalysis)

  • 27. 10. 2017 10:44

    Jarda_P

    U šifrovaného telefonu by stačil nějaký typický soubor, u šifrovaného e-mailu by mohlo stačit i nějaké „--------------- original message -----------------“. U fotek by pomohly hlavičky.

    Za predpokladu, ze to sifruji po souborech. Cekal bych, ze maji spis sifrovane cele uloziste, takze smula.

  • 27. 10. 2017 13:14

    Jarda_P

    @Ondra Satai Nekola: Co presne je spatne na tvrzeni, ze telefon bude asi mit sifrovane cele uloziste a tim padem se nedostanu k hlavickam souboru? Umi Singh z takoveho telefonu vyextrahovat hlavicky souboru, pricemz nejak zahadne neumi vyextrahovat zbytek? A proc tedy tripismenkaci selhali pri louskani tisicu telefonu?

  • 27. 10. 2017 13:28

    Ondra Satai Nekola

    Singh je úvodní čtení pro lidi, co o tématu nic nevědí.

    Moderní šifry jsou navrhované, aby byly odolné vůči known plain text attack i chosen plaintext attack.

    Zrovna u tohohle (u jiných věcí ne!) je šifrování po souborech nebo celého device celkem šumák. Ono i při šifrování celého device by bylo těch míst, kde se může vyskytnout hlavička souboru, celkem málo.

  • 27. 10. 2017 13:45

    Jarda_P

    Proboha, ja nic takoveho netvrdim. Ja si akorat dovoluji nadhodit predpoklad, ze foun bude pravdepodobne mit sifrovane cele uloziste, takze nema smysl hovorit o tom, ze se nejak nekdo dostane k nejakym hlavickam. A kdyz uz do toho stouras, muzes si byt absolutne jisty, ze v takovem founu bude pouzita moderni sifra a navic nebude mit chybu v implementaci, ktera by ji oslabila? Pamatujes debiani verzi ssh?

  • 27. 10. 2017 17:27

    Vít Šesták

    > A kdyz uz do toho stouras, muzes si byt absolutne jisty, ze v takovem founu bude pouzita moderni sifra a navic nebude mit chybu v implementaci, ktera by ji oslabila?

    Ne. Ale to jsme tu nikdo netvrdili.

  • 27. 10. 2017 16:42

    Vít Šesták

    To záleží (třeba na Androidu N se zavedlo file-based-encryption kvůli DirectBootu[1]), ale ani s full-disk-encryption by to neměl být problém. Hlavičky FS, typické struktury, prvotní adresářová struktura… Můžete si zkusit spustit vbindiff na dvou různých raw blocích se stejným filesystémem (a ideálně podobnými parametry, hned na začátku toho bude dost podobného.

    [1] https://developer.android.com/training/articles/direct-boot.html

  • 27. 10. 2017 17:25

    Jarda_P

    ale ani s full-disk-encryption by to neměl být problém. Hlavičky FS, typické struktury, prvotní adresářová struktura… Můžete si zkusit spustit vbindiff na dvou různých raw blocích se stejným filesystémem (a ideálně podobnými parametry, hned na začátku toho bude dost podobného.

    To si nejak neumim predstavit. Kdyz budu mi sifrovane uloziste, tak tam ocekavam neco jako TC kontajner, ktery ani nemusi byt na formatovanem zarizeni. Na kazdem zarizeni ten kontajner bude sifrovan jinym klicem (a ten muze byt ulozen nekde v nejakem nedobytnem chipu, jako to ma ted tusim ajFoun). Jak muzu mit cokoliv podobneho, kdyz mam jiny klic? I kdyby na ulozisti byly same nuly, tak nemuze byt podobne a po nejake dobe pouzivani tam bude totalne nahodny bordel

  • 27. 10. 2017 17:56

    Vít Šesták

    Psal jsem o predikovatelnosti částí plaintextu, které by šly využít pro hypotetický known-plaintext-attack. Když porovnáte například dva různé nezašifrované ext4 pomocí vbindiff, najdete tam spoustu podobností.

    Když řešíme konkrétní telefon, může si útočník pořídit stejný model (ideálně se starším firmware kvůli rootování, pokud nejde odemknout bootloader), dumpnout si rozšifrovanou partition (tj. nějaké /dev/block/dm-???, nikoli zašifrované /dev/block/mmcblk???). V ní najde i třeba typ filesystému, label a další věci, které budou u toho modelu nejspíš stejné. Část z toho (např typ filesystému) lze zjistit i bez rootu, i to by mohlo stačit.

    Dost možná by to šlo i bez fyzického telefonu, stačilo by si stáhnout firmware (což u některých výrobců není problém), vytáhnout z něj konfiguraci pro vytváření filesystému a kernel. Pak to spustit na emulátoru.

    Tzv. cribů, tedy známých kouskú plaintextu, tu lze nasbírat celkem dost. Je to dost béžná věc, která je známá nejméně od druhé světové (vizte odkaz na Gardening výše). Co jsem v rychlosti našel, tak ani pro DES není známý prakticky proveditelný known-plaintext-attack rychlejší než bruteforce. Čím to bude? Žeby již v sedmdesátých letech brali v úvahu útoky použité za druhé světové války a snažili se šifru navrhnout tak, aby jim odolala?

  • 27. 10. 2017 18:37

    Jarda_P

    Když řešíme konkrétní telefon, může si útočník pořídit stejný model (ideálně se starším firmware kvůli rootování, pokud nejde odemknout bootloader), dumpnout si rozšifrovanou partition (tj. nějaké /dev/block/dm-???, nikoli zašifrované /dev/block/mmcblk???). V ní najde i třeba typ filesystému, label a další věci, které budou u toho modelu nejspíš stejné. Část z toho (např typ filesystému) lze zjistit i bez rootu, i to by mohlo stačit.

    To vam bude k cemu? Myslite, ze tech par kousku plaintextu, o kterych ani nemate zarucenou shodu na druhem founu a ani ne pri jine verzi firmware, bude stacit na rekonstrukci klice, ktery je mnohem delsi, nez tech par vasich ulovku? Na co si tedy ti tripismenkaci stezuji? Podeziram, ze to porad nebude tak jednoduche.

  • 27. 10. 2017 20:27

    Vít Šesták

    Nemyslím si, že by to stačilo na rekonstrukci klíče, s tím jste začal vy.

    A symetrické klíče nebývají až tak dlouhé, u AESu je to 128–256 bitů, což je 16–32 bajtů. To není moc. Jsem si jist, že tak dlouhý crib tam půjde najít i v kuse, aniž bych věděl něco o obsahu telefonu. Udělejte si vbindiff dvou různých partitions v ext4 (jeden z FS často používaných v Androidu, mám ho ostatně na svém telefonu v /data) a přesvěčte se sám. Já to už udělal, u dvou různých a různě velkých partitions na ext4.

    Souhlasím ale s tím, že tak jednoduché to nebude. Ne ale proto, že by se nedalo najít criby, ale proto, že bezpečnost uznávaných šifer už nějakou tu desítku let crib jen tak neohrozí.