Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: 1 ... 308 309 [310] 311 312 ... 375
4636
Vývoj / Re:Jak se vyhnout frustraci s Java eventy?
« kdy: 02. 02. 2016, 21:47:37 »
Jenže to budu muset do jediného objektu zakomponovat více parametrů, v případě že jich posílám víc. Můžeš mi říct, jak si takovuto skvělou věcí pomůžu a jak mi toto vylepší kód?
Jakých víc parametrů, koho posíláte víc? Chcete z jednoho objektu posílat různé typy událostí? No tak si prostě implementujte třídu s metodami zaregistrujPosluchace(TypUdalosti, Posluchac), odregistrujPosluchace(typUdalosti, Posluchac) a posliUdalost(TypUdalosti, Data), implementaci téhle třídy si vložte do každé třídy, která má umět posílat události, a delegujte na tu třídu volání metod zaregistrujPosluchace a odregistrujPosluchace. A ty dvě metody si dejte do interface, který označí všechny třídy, které umí posílat události.

4637
Vývoj / Re:Jak se vyhnout frustraci s Java eventy?
« kdy: 02. 02. 2016, 21:43:20 »
Stačí trochu zagooglit, ne?

Kód: [Vybrat]
private Collection<T> observers = Collections.synchronizedList(new ArrayList<>());

BTW: Trochu mi uniká, proč děláš kolekci observerů a ne jejich abonentů...
Což je z implementací s bezpečným konkurenčním přístupem to nejhorší řešení. Protože se zamyká jakýkoli přístup k té kolekci, což není potřeba. Z té kolekce se asi bude mnohem častěji číst a jenom málokdy se do ní bude zapisovat. A je úplně zbytečné, aby na sebe jednotliví čtenáři čekali, klidně mohou číst paralelně, konkurenční přístup je potřeba hlídat jenom v okamžiku, kdy se do kolekce zapisuje, plus v případě událostí bude potřeba asi synchronizovat tak, aby čtení z kolekce ve workflow navazujícím na přidání posluchače vždy vracelo i toho nově přidaného posluchače – jinak by se mohly některé události ztrácet. Obvykle se to dělá ve stejném vláknu (i kvůli optimalizaci), ale bůhví, jaké s tím má Zelenáč plány. Ale ani tenhle požadavek nevyžaduje řadit veškeré přístupy ke kolekci za sebe.

4638
Vývoj / Re:Jak se vyhnout frustraci s Java eventy?
« kdy: 02. 02. 2016, 20:35:41 »
Kód: [Vybrat]
protected Collection<T> observers = new ArrayList<>();

Proč tu kolekci observers nemáš synchronized?

Ono je to celé špatně. Místo synchronized  kolekce by bylo lepší použít některou z kolekcí java.util.concurrent. Navíc tam nemá žádné čtení kolekce, takže je ta kolekce úplně zbytečná. Místo toho si stěžuje, že nemá vícenásobnou dědičnost, aby si v tom kódu udělal ještě větší guláš.

Řešením by byla třída, která bude obhospodařovat posluchače – bude je umět zaregistrovat a odregistrovat a bude umět všem registrovaným posluchačům poslat zprávu. Zároveň si ošetří konkurenční přístup. To je kód právě pro jednu třídu, není potřeba žádná vícenásobná dědičnost a ta třída se použije ve třídách, které potřebují posílat nějaké události registrovaným posluchačům. (Ano, v jiných jazycích by se to dalo řešit vícenásobnou dědičností místo kompozice, ale to by bylo porušení principu single responsibility.)

4639
Vývoj / Re:Jak se vyhnout frustraci s Java eventy?
« kdy: 02. 02. 2016, 20:26:08 »
Je účelem tohoto tématu, abyste předváděl, jak to opravdu neumíte a nechcete umět, nebo se chcete něco naučit? Zatím to vypadá na to první.

4640
Vývoj / Re:Spojení hashovacích funkcí
« kdy: 02. 02. 2016, 19:45:58 »
Pro ty, kteří pochybují nad kvalitou MD5 i SHA-1: Zkuste si jen tak cvičně prolomit CRC32. Všichni víme, že to jde, ale už málokdo tuší, kolik to dá práce než doladíme změněný dokument tak, aby CRC sedělo a přitom to nebylo nijak nápadné.

A pak si uvědomte, že MD5 a výše jsou o mnoho řádů lepší...
A pak si uvědomte, jestli jste ochotni těmhle domácím pokusům svěřit celý svůj bankovní účet.

Kryptografie má bohužel tu nevýhodu, že je obrovský prostor mezi tím, co lze chápat „selským rozumem“ a vyzkoušet si doma, a co je  profesionální použití. Když bude mít někdo v domácí databázi problém s deseti tisíci záznamy, asi celkem bez problémů představí, že může existovat databáze s deseti miliony záznamů. Když má někdo doma 10 TB filmů, asi si dokáže představit 1 TB (!) firemní diskové pole. Ale v kryptografii jsou to pokusy s prvočísly 13 a 17 a zkoušení kombinací CRC16 hrubou silou, pak dlouho dlouho dlouho nebezpečno, a pak teprve bezpečná kryptografie. To, že SHA-1 by měla v ideálním případě sílu 280, ale jsou známy útoky oslabující ji na někde kolem 255, se opravdu těžko představuje, zvlášť když je to pořád ještě za hranicí toho, co by si někdo jen tak vyzkoušel pro dobrý pocit z toho, že prakticky prolomil SHA-1.

4641
Vývoj / Re:Spojení hashovacích funkcí
« kdy: 02. 02. 2016, 17:02:58 »
Je mi jasne ze sa da pridavat bordel (a odoberat, aj ked to je uz tahsie "asi") aby boli kolizie, preco sa o danom dokumente nepusti nejake info ktore neni hashovane, pomerne jenoznacne, a nikto tam nic moc nepomeni?
Hashovací funkce bere na vstupu libovolnou posloupnost bajtů, na výstupu je přesně daný počet bajtů (šlo by to obecně i s bity, ale dnes se prakticky používají jen funkce, kde je počet bitů zaokrouhlen na bajty). Jakým způsobem se s tím dál pracuje, jak ten hash uložíte atd., to už je záležitost konkrétní implementace.

Proti útokům typu „tady je dokument, k němu chci jiný se stejným hashem“ by kontrola délky souboru byla většinou docela účinná obrana, proti útoku typu „útočník vytvoří jeden dokument, nechá ho podepsat, a pak k hashi předloží druhý“ by to tak slavné nebylo.

Ale hlavně je zbytečné vymýšlet pochybné obezličky k používání slabých hashovacích funkcí, které budou fungovat jen za specifických podmínek, když máme k dispozici dostatečně silné hashovací funkce.

4642
Vývoj / Re:Java se vyhnout frustraci s Java eventy?
« kdy: 02. 02. 2016, 15:34:59 »
Navíc píšu to, jak si můžete ráčit všimnou, ze studijních důvodů - jinak bych se neštval s Javou.

Pokud to píšete ze studijních důvodů, doporučoval bych naučit se v Javě programovat a naučit se používat IDE. Zatím to vypadá, že studujete to, zda se v Javě dá programovat, i když to neumíte a umět nechcete – ano, dá, a jako v kterémkoli jiném jazyce, výsledek bude stát za … vy víte co.

4643
Vývoj / Re:Spojení hashovacích funkcí
« kdy: 02. 02. 2016, 14:51:48 »
My se tu bavíme o něčem jiném, víte to?
Nebavíme. Váš argument „na mém počítači kolize nevygeneruji, tudíž je to bezpečná hashovací funkce“ přece musí platit úplně stejně pro SHA-1 jako pro MD5+SHA-1.

Tohle jsem nikdy neřekl. Se lhářem a manipulátorem se tímto odmítám bavit.
Tak co tedy chcete dokázat tím svým „Ukažte jinak jsou to jen plky“ nebo „pokud tvrdíte, že někdo takovou kolizi umí vypočítat, dodejte relevantní podklady, já proto rád zajistím potřebný HW“? Myslel jsem, že chcete předvést výpočet těch kolizí.

4644
Vývoj / Re:Spojení hashovacích funkcí
« kdy: 02. 02. 2016, 14:28:30 »
My se tu bavíme o něčem jiném, víte to?
Nebavíme. Váš argument „na mém počítači kolize nevygeneruji, tudíž je to bezpečná hashovací funkce“ přece musí platit úplně stejně pro SHA-1 jako pro MD5+SHA-1.

4645
Vývoj / Re:Java se vyhnout frustraci s Java eventy?
« kdy: 02. 02. 2016, 14:25:39 »
Za prvé bych doporučil nevynalézat kolo a použít na to komunikaci hotovou knihovnu – doporučuju Netty. Dále píšete o správném objektovém programování, to nejde dohromady s tím, že třída reaguje na 20 událostí. Ve správném objektovém programování má třída jednu zodpovědnost, bude tudíž mít jen pár metod nebo reagovat jen na pár událostí.

Co s takovýmto hrozivým programátorem?
Buď se to programátor naučí, nebo bude lepší, když bude dělat něco jiného.

4646
Vývoj / Re:Spojení hashovacích funkcí
« kdy: 02. 02. 2016, 13:19:08 »
Už vidím jak to nekonečno budete řešit :D... A vo tom to je. Ukažte jinak jsou to jen plky.
Klidně si dál používejte SHA-1 s odůvodněním, že na svém domácím počítači nedokážete vygenerovat kolizi, tím pádem je to  bezpečné. Odborníci na kryptografii mají na kryptografické hashovací funkce přeci jen o něco vyšší nároky, než to, co zvládne či nezvládne vaše pécéčko.

4647
Vývoj / Re:Spojení hashovacích funkcí
« kdy: 02. 02. 2016, 12:21:00 »
nevíme jestli to je zatím
Což je dostatečný důvod, proč to nepoužívat. Po roce 2005 také nikdo nevěděl, zda oslabení SHA-1 „o pár bitů“ je konečné, nebo jestli se podaří ho prolomit dál. Ale už ta znalost oslabení, které bylo nedostatečné pro praktický útok, stačilo k tomu, aby byla SHA-1 zavržena.

nebo to není možné, protože ty matematické funkce nemají v takovém případě průniky
To by byly hodně špatné hashovací funkce, kdyby pro nekonečně mnoho vstupů nedávaly náhodně rozložené výstupy, ale takové výstupy, aby se to „nepotkalo“ s tou druhou hashovací funkcí.

4648
Vývoj / Re:Spojení hashovacích funkcí
« kdy: 02. 02. 2016, 12:12:12 »
Když dokážete generovat libovolný počet kolizí, je jasné, že mezi těmi kolizemi budou i takové, které mají stejný hash pro jinou hashovací funkci.

Cite needed. Jirsák řekl, proto to tak musí být :D. Komplex božství?
To triviálně plyne z definice hashovací funkce. Hashovací funkce má na vstupu nekonečnou množinu potenciálních vstupů, na výstupu je konečná množina všech možných hashů dané funkce, její maximální možná velikost je jedním z podstatných znaků dané hashovací funkce (např. u MD5 je to 2128, u SHA-1 2160). Je zřejmé, že při mapování z nekonečné množiny na množinu konečnou musí docházet ke kolizím, dokonce těch kolizí je nekonečné množství.
To, že při nekonečném množství vstupů dostanete na výstupu hashovací funkce kolize, je tak základní znalost, že pokud ji nevíte, nemá vůbec smysl, abyste se do nějaké diskuse o hashovacích funkcích pouštěl.

4649
Vývoj / Re:Spojení hashovacích funkcí
« kdy: 02. 02. 2016, 12:04:31 »
Co som tym chcel povedat bolo ako pisali niektory prave to ze, podla mna najst koliziu pre MD5 na fakture ja kludne mozne v rade minut, a mozno aj na SHA-1, ale aby ta KOLIZIA BOLA ROVNAKA pri zmene originalneho vstupu to si neviem predstavit.

A to - to si neviem predstavit :) com chcel len vediet ci mam taku zlu predstavivovst ja :) a niekto vie viac, alebo mam v podstate pravdu, len je to neekonomicke (dva hashe pocitat a spajat -> komplikovanejsie ako jeden dobry) a zbytocne dlhe?.
To si nikdo neuměl představit ani u MD5 nebo SHA-1 – protože řešení hrubou silou pořád znamená otestovat nepředstavitelný počet vstupních dokumentů, než se trefíte do takového, který bude mít stejný hash. Jenže se ukázalo, že není nutné to řešit hrubou silou, že jsou v algoritmech chyby, které umožňují „zkratky“ – umožňují generovat vstupní dokumenty tak, že je vyšší pravděpodobnost, že se trefíte do správného hashe. Samozřejmě je možné, že ty „zkratky“ pro MD5 a SHA-1 jsou navzájem nekompatibilní, že nedokážete generovat vstupní dokumenty, u kterých bude ta vyšší pravděpodobnost jako pro MD5 tak pro SHA-1. Ale také je možné, že takováhle zkratka společná pro MD5 i SHA-1 existuje. A to nikdo nebude riskovat.

No a otazka je ci je toto bezpecne. Nie som matematik a co to som kukal aj online ale ako sa hladaju prelinajuce sa kolizie dvoch hashovych funkcii mi pride velmi velmi narocne :)
Hashovací funkce musí být zaručeně bezpečné na několik let dopředu. Takže u nich neplatí, že pokud není znám žádný prakticky proveditelný útok, jsou považovány za bezpečné – naopak, už jenom pokud panuje podezření, že by mohl existovat nějaký teoretický útok, ta funkce je označena za slabou a je doporučeno přestat ji používat. Přesně to se stalo s MD5 i SHA-1 – ty byly nejprve označeny za slabé a bylo doporučeno přestat je používat, teprve po té byly představeny teoretické koncepty útoků, a na konec praktické útoky. Přičemž u MD5 jsou praktické útoky známy už dost dlouho. U SHA-1 bylo známo oslabení od roku 2005 (pořád to ale bylo málo na provedení praktických útoků), proto byl např. v ČR naplánován přechod na SHA-2 nejpozději k roku 2010, zprávy o tom, že by útok na SHA-1 mohl být prakticky proveditelný jsou až z roku 2015.
Nebo-li praktický útok proti SHA-1 je i dnes velmi náročný a těžko představitelný, přesto se SHA-1 (právem) hromadně opouští. Protože už se SHA-1 nedá věřit. A stejné je to s vaší kombinací MD5+SHA-1 – dnes je takový útok těžko představitelný a pravděpodobně je zatím neproveditelný. Jenže ty dvě výchozí funkce jsou považovány za slabé, tím pádem na nich nikdo nebude stavět něco, co by mělo odolat třeba deset patnáct let.
Nebo si to zkuste představit úplně jinak. Máte dva shnilé pilíře, ani jeden z nich už nedokáže unést most sám o sobě. Můžete je spojit do jednoho a nemáte žádnou konkrétní informaci o tom, že tohle spojení by most neuneslo. A vedle toho máte pilíř, u kterého víte, že shnilý není. Budete věnovat energii na ověření toho, zda most s tím spojením dvou shnilých pilířů opravdu nespadne, nebo ji radši budete věnovat tomu, abyste prověřil, že ten pilíř, který není shnilý, je opravdu v pořádku?

4650
Vývoj / Re:Spojení hashovacích funkcí
« kdy: 02. 02. 2016, 07:14:40 »
Vy to nechápete viďte. Jakýkoli výkon je vám momentálně úplně k ničemu, protože nenajdete možnost kolize takové, která bude pro oba algoritmy stejná. Pokud tvrdíte, že někdo takovou kolizi umí vypočítat, dodejte relevantní podklady, já proto rád zajistím potřebný HW.
Vaše tvrzení vychází z předpokladu, že nedokážeme v rozumném času hledat kolize pro dané hashovací funkce. Jenže lidé, kteří tomu rozumí, tenhle předpoklad pro MD5 a SHA-1 už nepovažují za splněný. Když dokážete generovat libovolný počet kolizí, je jasné, že mezi těmi kolizemi budou i takové, které mají stejný hash pro jinou hashovací funkci. To, že by to běžným postupem trvalo nepoužitelně dlouho, je irelevantní – to samé platí i pro MD5 i SHA-1 samotné. Jenže pro MD5 a SHA-1 byly vymyšleny „zkratky“, jak to generování kolizí podstatně urychlit. Nikdo nezkoumal, zda takové zkratky neexistují i pro MD5+SHA-1 – takže je bláhové spoléhat na to, že neexistují.

Původní otázka zněla, proč se MD5+SHA-1 nepoužívá, na to je odpověď jednoduchá – protože tu máme SHA-2 a další moderní hashovací funkce, u kterých víme, jak jsou asi bezpečné. Vedle toho je tu návrh na použití MD5+SHA-1, o jehož bezpečnosti nevíme vůbec nic, za to víme, že ty dvě složky mají slabiny, z toho MD5 vážné, takže o spojení takových prvků si nelze myslet nic dobrého.

Tazatel se možná ptal také na to, proč se další hashovací algoritmy vytvářejí. Proč se v době, kdy MD5 a SHA-1 byly ještě považovány za dost silné udělala soutěž na SHA-2, proč pak byla otevřena soutěž na SHA-3 a hashovací algoritmy vznikají stále nové. Na to je odpověď podobná – kombinaci MD5+SHA-1 nikdo nezkoumal, ale protože ji tvoří dvě oslabené hashovací funkce, dá se očekávat, že i to společné použití bude mít slabiny. A poč by se kryptologové zabývali hledáním praktických děr u něčeho, o čem si myslí, že nejspíš děravé bude, když místo toho mohou raději prověřovat funkce, kterým dnes věří.

Stran: 1 ... 308 309 [310] 311 312 ... 375