Neobsahuje názory Henryka Laholy

Mikroblognutí z adresního řádku prohlížeče

Trošku přepracovaný cizí nápad...

Na počátku byla moje knihovnička pro mikroblogy. Tu použil Timy a stvořil formulář pro odesílání, a to včetně návodu, jak si udělat twitterovátko (to jsou novotvary!) v příkazním řádku a la vyhledávání v Opeře. Mrkněte se, nápad to je zajímavý...

Koukali jsme na to s Davidem Grudlem a shodli se, že nápad to je dobrý. Ovšem nelíbila se mi jedna věc. Davidovi se zcela zjevně nelíbila taky, protože před pár minutami přišel s vlastním řešením, kdy řeší totéž co já, ale jinou cestou. Dostaneme se k tomu.

O co jde? Nelíbí se mi představa, že posílám jméno a heslo otevřeným kanálem. Co s tím?

  • A: Mohu si vše přesunout na svůj server
  • B: Mohu jméno a heslo zašifrovat

Pokud chci, aby služba byla "obecně použitelná", tak nelze nasadit řešení A, protože ne každý má svůj server. Přemýšlel jsem tedy, jak udělat řešení B.

Nakonec jsem zvolil následující postup, s mírnými obměnami použitelný i v jiných případech (podobně řeším např. trvalé přihlášení):

1. Uživatel si na zabezpečené stránce vygeneruje svůj klíč, který obsahuje jeho přihlašovací údaje. Klíč obsahuje jméno, heslo, a protože mám třídu pro pět mikroblogů, tak i server. Údaje jsou v klíči zašifrovány metodou AES256. Jméno a heslo tak jdou po síti jen jednou, navíc šifrovaným spojením a nejsou ukládány do logu.

2. Vygenerovaný klíč pak uživatel může použít k posílání svých textů na Twitter, Jaiku, Pownce, Tumblr či Teidu. Prostě jen zadá adresu http://apps.php-suit.com/microblog/index.php?kod=klíč&text=TEXT. Aplikace dekóduje z klíče potřebné údaje a pošle data tam, kam má.

Tím se vyhnete nutnosti posílat otevřeným textem jméno a heslo, vaše údaje nejsou nikde logovány a případný man-in-the-middle, který odchytí váš požadavek, nezíská plný přístup k vašemu účtu, maximálně tak pošle příspěvek vaším jménem.

Ironické je, že nakonec je vaše heslo na cestě z aplikace na cílový server opět přenášeno jako prostý text. Ale takový je už život. :) Za domácí úkol zjistím, jestli by šlo přistupovat na API mikroblogovacích serverů přes SSL. (Aktualizace: David hlásí, že na Twitter to jde. Aktualizace 2: Jinam to nejde.)

Formulář je na odesílací stránce, tak si to můžete i vyzkoušet... Pokud chcete zkusit přímo ten řádek, nezapomeňte text url-enkódovat a zapsat ho v kódování UTF-8. Předpokládám, že nebude problém si upravit moje řešení pro Operu dle Timyho návodu, určitě by nebyl ani velký problém napsat generátor "vyhledávacích modulů" pro Firefox/IE, takže by bylo možné twitterovat (powncovat, jajkat, ...) z hledacího políčka prohlížeče...

Na závěr se podívejte na Davidovo řešení, ovšem způsobem A (a pouze pro Twitter, ovšem úprava pro další systémy bude jistě triviální).

Samosebou, takový přístup je možný pouze ve světě, kde věříte, že provozovatel podobné služby nemá důvod si vaše údaje zapisovat. Pokud nevěříte, použijte Davidovo řešení a použijte vlastní server.

Popsané řešení je jen hříčka s hesly, ale třeba inspiruje. A mimochodem – schválně, jak VY řešíte trvalé přihlášení uživatele? ;)

Dne 4.07.2008

Twittni

Přidej do: Přidat na Conota Linkuj si ! asdf.sk StumbleUpon Toolbar Stumble It!

Komentáře

[1] (David Grudl - WWW) 04.07.2008, 19:58:57 [X] [D]
Řekli jsme si to přes Jabber, ale to mou potřebu komentovat neukojilo ;) - z pohledu uživatele je mi fuk, jestli své heslo vykecám Timymu nebo tobě přes SSL, obě řešení mají stejný nedostatek.

[2] (Arthur Dent [openID] - Mail - WWW) 04.07.2008, 20:10:47 [X] [D]
[1] A co třeba Googlu, tomu ho řekneš? :) Takový ten firefoxí plugin na úschovu/obnovu profilu od Google je taky moc hezkej...

A kdyby to generování klíče nedělal Dent, ale komerční firma? Pak bys to řekl? A kdyby se ta firma jmenovala třeba Verisign? :)

A co kdyby se jmenovala Hostmonster? ;)

[3] (Tonda - Mail - WWW) 04.07.2008, 20:46:04 [X] [D]
[2]Přesně tak, pak klidně - Dent je úplně něco jiného a malého. :)

[4] (Arthur Dent [openID] - Mail - WWW) 04.07.2008, 20:54:44 [X] [D]
[3] A v čem že je přesně ten rozdíl? A z čeho pramení víra, že malí logují a ukládají, ale velcí ne? Nebo snad je víra opřena o přesvědčení, že "velcí mají tolik dat, že na jednoho Tondu nepřijdou"? ;)

Pfilosofická otázka... :) Myslím, že za pár let, s novými "antiblablabla" zákony na "ochranu obecného blaha", bude každý muset svá hesla nahlásit na nějaký centrální úřad.

[5] (David Grudl - WWW) 04.07.2008, 21:58:03 [X] [D]
[2] Když budeš velká firma a budeš mít na konci Inc. a pěkně poprosíš, tak řeknu, co by ne!

[6] (Arthur Dent [openID] - Mail - WWW) 04.07.2008, 22:03:14 [X] [D]
[5] I kdepak, to jsou jen takové svalnaté řečičky. V praxi stačí, když budu mít s.r.o. a provozovat hostingovou společnost. Jaký je pak rozdíl v tom "poslat heslo na můj server přes SSL" nebo "uložit ho (třeba) ke Kalužovi"? ;)

[7] (mike ) 04.07.2008, 22:17:28 [X] [D]
[4] Vira je oprena o presvedceni, ze velci si to nemohou dovolit. Protoze kdyby se na to prislo, tak by z toho meli velky pruser (a mohli by firmu zabalit). A jelikoz jsou velci, tak by se na to drive nebo pozdeji prislo (nespokojeny zamestnanec, konkurence).

[8] (Tonda - Mail - WWW) 04.07.2008, 22:28:13 [X] [D]
[4]Něco je na tom co píšeš v tom komentáři a něco víc na tom co píše [7].

Malí samozřejmě taky logujou, mám někde v databázi uložený hesla většiny spolužáku (třídní galerie). Asi nejde o to, že by se lidi báli, že ty hesla zneužiješ (je v tvým zájmu to neudělat), ale o tom, že tě by tě to učinilo "osobou, které je možné svěřit hesla" a tím by se ti dosalo respektu, který ti nikdo nechce dát. :))

[9] (Arthur Dent [openID] - Mail - WWW) 04.07.2008, 23:09:21 [X] [D]
[8] Nevidět si do huby a komentovat... :-/ Mám to vzít bod po bodu ("kde se bere přesvědčení, že malí logují a velcí ne" vs "malí samozřejmě taky logujou" - hezká odpověď, ale poněkud mimo, že?) nebo to můžeme uzavřít s tím, že plácáš a nevíš o čem?

S dovolením - měl jsem v ruce mzdové údaje velké státní organizace (100k lidí). Pět let jsem spravoval Bloguje, kde prošlo několik desítek tisíc uživatelů. Několik set z nich v té databázi mělo i heslo a přístup na své FTP. U petice, kterou jsem spolupořádal, jsme měli v databázi 35.000 adres lidí. Ničí heslo či údaje jsem za celou dobu nezneužil a nikdo se nerozpakoval je do systému, který jsem spravoval, poskytnout.

Řeči o respektu, který mi někdo nechce dát jsou od studenta s databází hesel svých spolužáků poněkud nemístné. Až budeš mít za sebou polovinu té zodpovědnosti k cizím údajům, kterou jsem veřejně osvědčil já, tak pak mi napiš něco o respektu!

[10] (David Grudl - WWW) 05.07.2008, 05:42:59 [X] [D]
Téma slepé důvěry v naprosto cizí lidi je velmi zajímavé a vždy mě překvapí, jak i velmi inteligentní lidé jsou schopni jednat zcela iracionálně (http://www.marigold.cz...ine-zalohy nebo totéž v bledě modrém http://breclavsky.denik.cz...3.html), ale do této roviny jsem svým prvním komentářem brousit nechtěl. Jde mi o technickou stránku věci. Pokud by Timyho formulář šel otevřít přes https (možná i jde, nezkoušel jsem), tak nevidím rozdíl mezi mezi oběma řešeními - tedy jen ten, že tvé je komplikovanější.

[11] (Piki - Mail - WWW) 05.07.2008, 10:02:15 [X] [D]
Už sa tu rozbehla diskusia o absurdnej a iracionálnej dôvere v iného, ktorá je podložená typom právnickej či fyzickej osoby, historickými skúsenosťami tretích strán, pridám jeden aktuálny príklad. Stačí jeden sudca, ktorý stále nezaregistroval existenciu hrubej výpočtovej sily (využiteľnej napríklad na analýzu terabajtov dát v reálnom čase) a Google bude odovzdávať dáta o svojich užívateľoch tretej strane.

Jediným riešením je "informovaná dôvera" (na spôsob informovaného súhlasu) Dôverujem, že nezneužije, ale keby áno, chápem aké mi z toho hrozia problémy. Z tohoto pohľadu je potom jedno, či je zvolené riešenie A alebo B, pretože dôraz a rozhodovanie sa tak prenáša na "stojí mi použitie novej služby za to riziko prezradenia hesla/citlivých údajov" a nie na to, či "zverujem údaje do dôveryhodných rúk".

[12] (Arthur Dent [openID] - Mail - WWW) 05.07.2008, 10:29:41 [X] [D]
[10] Ale notak... :) Rozdíl je v řešení "man-in-the-middle" problému. Celá hříčka má následující pointu: Pokud posíláš citlivá data v GET, tak je lépe posílat je kryptovaně, obzvlášť když je možno ty kryptované údaje vygenerovat jednou, pomocí bezpečného kanálu, a použít víckrát. Šmytec.

Do věcí jako úroveň zabezpečení údajů, posílaných jednotlivým API, jsem se pouštět nechtěl, ale možná to udělám.

[11] Děkuji, konečně komentář, od něhož je možno se odpíchnout. Vidím analogii s použitím platebních karet na internetu: "Stojí mi výhody, co mi přinese PayPal, za to, abych jim prozradil informace o mé platební kartě?" S tím rozdílem, že tohle číslo bych rozhodně nenechal ani ve skriptech na hostingu ležících. ;)

Různá hesla přinášejí různé problémy. Dovedu si představit, že odcizené heslo k mailu nadělá moře problémů, na druhou stranu mě nebude pálit, když někdo odhalí moje heslo do linkovací služby, tam jsem žádné citlivé údaje nenechal. A tak dál... :)

[13] (Timy - Mail - WWW) 05.07.2008, 11:01:43 [X] [D]
[12] Ale já to v tom formuláři neposílám jako GET, ale jako POST :-).

[14] (Arthur Dent [openID] - Mail - WWW) 05.07.2008, 11:04:00 [X] [D]
[13] Ano, já vím, a omlouvám se, ta věta měla znít "Pokud posíláš citlivá data v HTTP požadavku NEBO PŘÍMO V GET, tak je lépe..." atd.

[15] (David Grudl - WWW) 05.07.2008, 21:15:52 [X] [D]
[12][14] pokud používáš protokol HTTPS, tak žádný man-in-middle není. Ale souhlas, už to nepitvejme ;)

[16] (Arthur Dent [openID] - Mail - WWW) 05.07.2008, 22:10:32 [X] [D]
[15] A pokud tam ty data odvezeš na disketě (a po cestě ti ji neukradnou), tak to je úplně nejbezpečnější! Achich ouvej. A co když není HTTPS k dispozici? Ostatně, v dnešním článku jsem právě na tohle narazil.

Davide, rád bych se vrátil od slovíčkaření a bazírování na kravinkách k meritu věci. Otázka totiž zní: Jak udělat veřejnou službu třetí strany, která by byla bezpečná "jak jen to jde". V našem konkrétním případě: Jak nabídnout služby tvého skriptu lidem, co nemají vlastní server?

(Nejde o nic nového, stejnou otázku jsem řešil s Bloguje: "Proč, když si každý může nainstalovat Bloxxy?" - Protože ne každý má vlastní hosting/server/schopnosti!)

Pokud zní tvá odpověď: "Nelze" nebo "pouze máš-li za firmou Inc.", tak opravdu nemá smysl diskutovat dál. ;)

A ještě PS v tvém stylu: Víš, že SSL není stoprocentně bezpečné, že? :)

[17] (David Grudl - WWW) 05.07.2008, 23:09:00 [X] [D]
[16] hele, v klídečku, jo? O žádné slovíčkaření mi nejde ([10] "Jde mi o technickou stránku věci").

Takže ještě jednou - pokud Timyho skript přesuneš na HTTPS, můžeš si nejen odpustit generování šifrovaného tokenu, ale celá komunikace bude mnohem lépe zabezpečená.

Chceš říct, že napadnout SSL komunikaci je snažší, než rozšifrovat krátký token? Nebo dokonce, že napadnout SSL komunikaci je snažší, než ukrást token přenášený přes nezabezpečený protokol a navíc v URL?

U tvého řešení stačí naslouchat komunikaci nebo projít logy na proxy, abych mohl psát na Twitter pod cizí identitou. Už chápeš?

[18] (Arthur Dent [openID] - Mail - WWW) 05.07.2008, 23:31:49 [X] [D]
[17] Takže ještě jednou já: "Pokud Timyho skript přesunu na HTTPS" - je tam? Není. Vyhneš se tak výhradě, kterou jsi mi předložil hned na začátku v [1], tedy "nebudu Dentovi nebo Timymu posílat heslo!"? Ne. Tak - jaká je pointa, prosím, když nejde, jak říkáš, o slovíčkaření? :)

Jistě, HTTPS je zatím nejbezpečnější způsob komunikace, na druhou stranu - který z webů (2.0 už vůbec) používá SSL pro přenos přihlašovacích údajů? Za domácí úkol napiš tři důvody, proč tomu tak je. :)

Ad mé řešení a možnosti psát pod cizí identitou: Gratuluju k postřehu ;), ale myslím, že byl zmíněn už v článku, konkrétně zde: "případný man-in-the-middle, který odchytí váš požadavek, nezíská plný přístup k vašemu účtu, maximálně tak pošle příspěvek vaším jménem."

Ještě jednou si prosím přečti poslední odstavec článku. Hříčka s hesly. Inspirace... Možný přístup u služeb třetích stran, atd.

Ano, souhlasím s tebou: Nejjistější je komunikovat napřímo se službou přes HTTPS. Když to služba neumožňuje, tak je jistější posílat nějaký šifrovaný token než plain text. Když služba neumožňuje posílat tokeny, může tenhle způsob nabídnout třetí strana, ale je tam riziko kompromitace hesla. Konkrétní případ má své mouchy, včetně minimální užitečnosti :), ale taky proto jsem to nazval hříčkou a věcí pro inspiraci.

Myslím, že oba víme, jak se věci mají, proto mne tvá ofenzivní argumentace poněkud překvapuje... :)

[19] (Arthur Dent [openID] - Mail - WWW) 05.07.2008, 23:43:56 [X] [D]
[17] Pardon, teď jsem si to pročetl zpětně a uvědomil jsem si, na cos narážel, takže beru zpět některé formulace v [18]...

Ano, pokud Timyho skript přesunu na https, tak bude bezpečnější. Pokud bude mé řešení taky na https, bude stejně bezpečné, ale komplikovanější. Stále zůstává ta výhrada z [1] o posílání hesla.

Na druhou stranu si dovedu velmi dobře představit případ, kdy se hodí moje řešení. Mám ho tu reálně na stole: Embedded zařízení s jednočipem a Ethernet rozhraním, které posílá zprávy na mikroblog (ano, naše lednička má mikroblog). V takovém zařízení se HTTPS opravdu blbě implementuje, takže posílání přes jednoduché HTTP a GET je ideální variantou, a tam je šifrované jméno+heslo v tokenu docela postačující bezpečnostní opatření. Tak jsem to myslel s tou inspirací.

[20] (David Grudl - WWW) 06.07.2008, 00:18:39 [X] [D]
[19] díky za pochopení.

Ale stále chybí krůček. I když své řešení přesuneš na https, je tu stále problém s tokeny v URL. Ty zanechávají stopu na řadě míst, od keše prohlížeče až po Apache log. Tyto tokeny stačí k tomu, abych mohl posílat zprávu pod cizí identitou. Timyho řešení tímto netrpí.

Dále tyto tokeny lze poměrně "snadno" rozšifrovat (protože si přes tvou aplikaci mohu pro svůj vstup vygenerovat šifrovaný výstup a klíč není konstantní, předpokládám, prostě plaintext known útok). Jak snadno, to neumím odhadnout, ale jde řádově o snazší oříšek, než kompromitovat SSL komunikaci, která se zahajuje výměnou klíčů.

[21] (David Grudl - WWW) 06.07.2008, 00:19:52 [X] [D]
[20] má být ...klíč JE konstantní...

[22] (Arthur Dent [openID] - Mail - WWW) 06.07.2008, 00:37:20 [X] [D]
[20] Ad token v URL: Ano, ale... :) Serverlog je akademická otázka, vzhledem k výhradě z [1]. Cache prohlížeče je vážnější výhrada. Timyho řešení via POST tímto netrpí, trpí ale "posíláním hesla v plaintextu". ;) Když se vrátím ke svému příkladu, tak by implementace via HTTP + data a token v POST mohla být rozumným kompromisem.

Ad rozšifrování tokenu: Zkus si vygenerovat dva, tři, čtyři tokeny pro stejné údaje. Nejde o "plaintext known", protože ty ten plaintext neznáš. A napovím: Víš jaký je rozdíl mezi DES a TripleDES? :)

[23] (David Grudl - WWW) 06.07.2008, 00:59:54 [X] [D]
[22] tady nejde jen o serverlog, ale o každý log na cestě od prohlížeče až po server. Vzhledem k charakteru služby je znalost tokenu dost závažný problém, blížící se znalosti hesla.

Tedy ano, pokud bys své řešení přesunul na SSL a upravil na POST, bude fous bezpečnější, než Timyho řešení přesunuté na SSL. Za stávající situace lze jen těžko, težko rozhodnout, co je lepší.

ad rozšifrování tokenu: chápu Known-Plaintext attack tak, že stačí znát alespoň část plaintextu (ale chceš-li, označujme to jako Partial Known-Plaintext attack). Dále je kombinovaný s Chosen-plaintext attack (nebo Chosen-partial-plaintext attack). Složitost odhalení klíče je skutečně spíš otázka na kryptologa, nechci o tom vůbec spekulovat. Pozeptám se na to.

[24] (Arthur Dent [openID] - Mail - WWW) 06.07.2008, 01:22:08 [X] [D]
[23] Jojo, o logách na proxy žádná, to už tu ale taky padlo...

Rozdíl je v tom, že znalost tokenu poslouží leda tak k poslání textu. Nelze se s ním přihlásit ke službě, "unést" účet, změnit osobní údaje apod., jde s ním jen a pouze poslat ten text. Případná oběť v takovém případě nepřijde o účet, může heslo změnit a token tak zneplatnit, takže škody jsou ve srovnání s prozrazením hesla minimální.

K tomu tokenu: Nejsem kryptolog a jeho názor by mě opravdu zajímal. Takže když se budeš ptát, tak: Jméno a heslo je nejprve zašifrováno Caesarovou šifrou (prostý posun), pak doplněno redundantními daty, zašifrováno AES256 a pak ještě jednou prohnáno AES256. Domnívám se, že v takovém případě je known plaintext útok obtížný (neznáš ani část textu pro tu "nejsvrchnější" AES šifru), ale nejsem kryptolog a jeho odpověď by mě opravdu zajímala (a asi nejen mě).

[25] (David Grudl - WWW) 06.07.2008, 01:48:50 [X] [D]
Ještě ad [1]:

V článku píšeš: "Koukali jsme na to s Davidem ... ovšem nelíbila se mi jedna věc. Davidovi se zcela zjevně nelíbila taky, protože před pár minutami přišel s vlastním řešením, kdy řeší totéž co já, ale jinou cestou."

V tom je zakopanej pes! Mně se totiž evidentně nelíbila úplně jiná věc, než tobě :-) Nelíbílo se mi prostě a jednoduše to, že posílám někomu, pro nějž nejsem anonymní, své heslo. Jsem navíc ten případ člověka, který má u každé služby jiné heslo, silné heslo a hesla nepíše tam, kde to není bezpodmínečně nutné.

Pro mě je tedy ideální řešení umístit odesíladlo na localhost. Obecné řešení by bylo realizovatelné jedině za spolupráce s Twitterem - upravili by API tak, že místa hesla budou přijímat jiný token, například nějaký hash.

[26] (David Grudl - WWW) 06.07.2008, 01:52:20 [X] [D]
...i když právě teď mě napadlo, jak to vyřešit obecně i se stávajícím API, aniž by bylo nutné heslo kamkoliv odesílat!

Arthure, přijdeš na to?

[27] (Arthur Dent [openID] - Mail - WWW) 06.07.2008, 02:01:25 [X] [D]
[26] Ne, nepřijdu, vůbec netuším, kterým směrem míříš a co přesně je to TO, co řešíš. Navíc koukám na Přátele, ležím, smrkám, kašlu, slzej mi oči a bolí mě hlava, takže na nějaké mentální cvičení v tuhle chvíli kašlu (a smrkám a slzím)... Ale nahoď, třeba se chytím. ;)

[28] (David Grudl - WWW) 06.07.2008, 02:17:23 [X] [D]
[27] tak já to prozradím :-)

Jde o to, že heslo se vůbec neodešle (ani jako součást formuláře nebo URL), ale bude zapsáno ve fragmentu (tedy za znakem #).

Cílová stránka bude obsahovat pouze JavaScript, který vezme zprávu (u URL nebo POST) a přihlašovací údaje (z window.location.hash), postaví přes DOM formulář cílený na https://twitter.com/{nejakeurl} a odešle jej. Odesílatelem je v tomto případě klientův počítač.

[29] (Arthur Dent [openID] - Mail - WWW) 06.07.2008, 02:36:25 [X] [D]
[28] Elegantní, klobouk dolů. Pokud tedy nějaký prohlížeč není tak aktivní a nepošle i fragment. :)

[30] (Mormegil [openID] ) 07.07.2008, 13:10:06 [X] [D]
[24] Ten popis je mi trochu podezřelý. 1. K čemu je tam ta Caesarova šifra? Zvýšení bezpečnosti bych od ní neočekával. Doplnění redundantními daty taky zní trochu fishy. No a dvojnásobné šifrování není o moc lepší – jednak (pokud se nepletu, což je klidně možné) dosud nebylo dokázáno, že AES není grupa, jednak je dvojité šifrování náchylné k tzv. meet-in-the-middle útoku, viz Merkle, Hellman: On the Security of Multiple Encryption, Comm. ACM, v. 24, n. 7, 1981, pp. 465–467 [http://jdem.cz/aanc3], příp. Schneier: Applied Cryptography, kap. 8.2.1, pp. 165–166

[31] (Arthur Dent [openID] - Mail - WWW) 07.07.2008, 17:42:59 [X] [D]
[30] Proto říkám, že by mě zajímal názor kryptografa. A pokud by ho dokázal napsat bez grup a lidsky popsat, jaké je nebezpečí v meet-in-the-middle, tak by to bylo skvělé :)

Caesarova šifra je lehké ztížení onoho "known plain text". Nebo ne?

[32] (Mormegil [openID] ) 07.07.2008, 18:41:02 [X] [D]
[31] (Aby to náhodou tak nevyznělo, rozhodně nejsem nějaký kryptograf (ani kryptolog ;-) )!)

Pokud by AES byla grupa, pak by veškeré podobné „zvětšování klíče“ opakovaným šifrováním typu E(k1, E(k2, x)) bylo zhola zbytečné, protože pro každé dva klíče k1, k2 by existoval klíč k12, pro který by E(k1, E(k2, x)) = E(k12, x). Příkladem je sčítání použité u Caesarovy šifry: nemá smysl snažit se „ztížit“ Caesarovu šifru tím, že ji použiju dvakrát s různými klíči, protože výsledkem je pořád jenom normální Caesarova šifra, jenom s jiným klíčem (rovným součtu obou klíčů), tzn. složitost šifry jsem nijak nezvýšil. A to, zda AES je či není grupa, tedy zda má či nemá smysl takto opakovaně šifrovat, zatím není dokázáno (AFAIK). Oproti tomu DES bylo tuším přímo navrženo tak, aby to pokud možno grupa nebyla, a posléze to bylo dokázáno [http://jdem.cz/aanu8], takže má smysl dělat věci jako 3DES.

Meet-in-the-middle útok nahrazuje délku útoku pamětí; spočívá v tom, že při known plaintext útoku zkouším šifrovat i dešifrovat současně a „uprostřed se potkat“. Funguje to tak, že pro všechny možné „půlklíče“ šifruji původní otevřený text a uchovávám si výsledky. Poté pro všechny možné půlklíče naopak dešifruji šifrový text a dívám se, jestli výsledek nemám v té tabulce z prvního kroku. Pokud ano, je možné, že jsem právě nalezl dvojici těch půlklíčů a ověřím ji na další dvojici otevřeného a šifrového textu (lze očekávat jistý nemalý počet podobných falešných pozitiv). Samozřejmě, že spotřeba paměti pro podobný útok je obrovská, ale z teoretického hlediska to ukazuje, že takové zdvojnásobení nemá příliš velký užitek, takže to nestojí za to. Meet-in-the-middle útok je také důvodem, proč se nepoužívá 2DES, ale 3DES, který je proti tomuto konkrétnímu útoku výrazně odolnější. Viz též [http://en.wikipedia.org...le_attack]

Navrhovat šifry tím, že do nich takhle naházím pár „lehkých ztížení“, je v podstatě jenom „security through obscurity“ [http://en.wikipedia.org...obscurity], takže jistě, o jistou konstantu to útok ztíží, ale komu záleží na konstantách ;-)

Shrnuto: použij nějaký normální hotový algoritmus; pokud nestačí obyčejný AES, tak je to dost velký problém, který nelze vyřešit nějakým kryptokutilstvím. (IMHO)

[33] (Arthur Dent [openID] - Mail - WWW) 07.07.2008, 21:33:38 [X] [D]
[32] Ano. Děkuji za vysvětlení. Je mi to jedno, pro popisované účely je to dostatečné. :)