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 - PCnity

Stran: 1 ... 21 22 [23] 24 25 ... 46
331
/dev/urandom

332
Este k P=NP... Samotny dokaz alebo fakt ze P by sa rovnalo NP este dieru do sveta neurobi... A nie nesuhlasim ze by potom bolo hladanie kolizii lahsie. Ono to len dokaze ze existuje sposob ako to spravit lahkym. Ten sposob by vsak aj tak prov neikto musel vynajst. A nakolko sa dodnes naslo vela security expertov co dokazali ze daky algoritmus nie je dobry aj bez toho aby bolo dokazane ze P=NP alebo opak, nic by to nezmenilo.

333
Ide cisto o to ze pokial mas zdrojove subory velke 2^niekolko miliard a hash sumu velku 2^128 musis mat kolizie. A stojim si za vyjadrenim ze aj ak pouzijes vela hashovacich funkcii, vzdy najdes koliziu nakolko je moznosti na strane vstupnych dat relativne nekonecno.

A ak sa mi teraz niekto bude snazit oponovat, vlastne chce tvrdit ze niekolko TiB zdrojovych dat by vedel bestratovo komprimovat na 2^128 bitov... Kedze by podla neho nedoslo ku kolizii, bolo by mozne z tych 2^128 bitov presne dostat spat vstupne data [ano, hash, ale hoci aj brute forcovanim]. Lenze tak to proste NIE JE. Pretoze mapujes mnozinu n na mnozinu m, pricom plati ze mnozina n < m, cize to nemoze byt 1:1 ale 1:X, cize to X vyjadruje pocet roznych vstupnych dat ktore vypluju tu istu kontrolu sumu.

Preto hovorim ze najdes koliziu VZDY a je uplne jedno kolo hash funkcii pouzjes, pretoze ratame s 2 premisami:

1) Vstupne data mozu byt nekonecne velke
2) Kontrolne sumy musia byt RADOVO mensie

Pokial vyhodis jednu z tych 2 podmienok, nemusia existovat kolizie. Pokial tie podmienky zachovas, MUSIA existovat kolizie.

334
Dodatok: A je uplne jedno ci pouzijes jednu alebo x hashovacich funkcii!

335
Este raz napisem to co nie je mozne vyvratit.
Kedze hash na to aby mal pre nas zmysel MUSI byt radovo mensi ako vstupne subory (128KiB vs. TiB, etc), musia nutne existovat kolizie. Presne ako bolo spomenute hore.

Pokial chceme kolizie 100% vylucit, mozeme predsa rovno porovnavat zdrojovy subor bit po bite!

336
Je uplne jedno kolko a akych metod sa pouzije. Kym plati ze kontrolna suma je radovo mensia vstupne data, nutne musi existovat kolizia. Zaroven nemoze existovat obrana.

337
Pokud by existovala kombinace metod, pro kterou neexistuje "univerzální" kolize, pak je spojte a máte neprůstřelnou metodu.

To je pravda, to mi vůbec nedošlo. Pokud je hash kratší než data, tak k tomu dojít musí. Jak jednoduchý ten důkaz byl :)

No jo, tak jednoduché to není. On ten dotyčný hledá kolizi pro určitý vstup, ne pro libovolný vstup.

No ono to je len o daco zlozitejsie, nakolko mozes zobrat funkcne execko a do neho implantovat binarny balast ako data bez toho aby si stratil funkcionalitu binarky. Cize by bolo treba do prcesu kraftovania noveho execka proste implmenetovat process v ktorom cast zostane staticka a cast sa bude menit/pridavat.

338
Samozřejmě, že existují kolize afektující všechny metody najednou. Pokud by existovala kombinace metod, pro kterou neexistuje "univerzální" kolize, pak je spojte a máte neprůstřelnou metodu. Už z porovnání délky původního souboru a výsledného otisku je zřejmé, že neprůstřelná metoda neexistuje a tudíž pro libovolnou množinu metod musí existovat kolize, která ovlivní všechny najednou.
Perfektne vyjardene. Perfektnu metodu nedosiahneme nikdy, nakolko uz podstaty pouzivania vyplyva ze by suma mala byt radovo mensia ako vstupne data. A v momente ako by neikto chcel pouizit sumu rovnu alebo vacsiu, stratilo by to uplne zmysel.

339
Pokial spravne chapem kolizie, tak nakolko z n bitov dat spravis m bitov dat, pricom m moze byt vacie, mensie alebo rovne n, je kolizii nekonecne vela.

Cize kebyze mas dany exe subor s MD5 sumou x a ty zoberies vlastny exe subor do ktoreho by si vedel niekde umiestnit velke mnozstvo dat bez toho aby sa stratila funkcionalita [podla mna sa to da, napr. self. extracting zip], skor ci neskor by si po generovani tychto dat vedel spravit exe subor s rovnakou MD5 sumou.

Pravdaze to skor-ci-neskor je velmi relative a zavisi od tvojho vypoctoveho vykonu. Pravdepodobne vsak neumerne dlho pokial nemas nejaky vzorec [ak by aj P=NP, prv by niekto ten vzorec musel najst].

O to zaujimavejsie by to vsak bolo kebyze sa snazis dosiahnut koliziu 2 hashovacish funkcii naraz. Nakolko nadalej plati vyrok ze hash kolizii je nekonecne vela, logicky z toho vyplyva ze by si zase raz skor ci neskor nasiel source data ktore by mali uplne rovnaku MD5 aj SHA sumu ako ta ktoru potreujes... Len tu sa uz asi bavime na velmi velmi teroretickej urovni.

Kazdopadne statement je: Da sa to, len to je sakra zlozite a vypoctovo narocne. Pre bezneho cloveka _dnes_ nedosiahnutelne.

340
Odkladiště / Re:Cenzura od Antiku
« kdy: 28. 12. 2011, 16:59:08 »
[Tak blokovat IP TV stream tym ze signal caka VLAN tagging tiez asi nebude najbezpecnejsi sposob]

K blokovaniu portov... A kde je net neutrality? Ake pravo ma poskytovatel blokovat porty? Prestduj si zmluvu. Ak si kupim pristup na internet, chcem pristup na internet a nie len "internet - {TCP/25}". Mam obdobny problem s Telekom Austria/A1 ale zatial len v stave tahajuceho sa support ticketu ze mi limituju pocet spojeni in aj out (Po X otvorenych TCP spojeni uz dalsie neotvorim, proste timeoutne). Tiez sa tu mienim odvolavat na zmluvu a buzerovat ich az do moemntu kym to nedaju niekde verejne vidiet . [do podmienok]

341
Odkladiště / Re:Cenzura od Antiku
« kdy: 27. 12. 2011, 16:06:16 »
Komplex spravcu siete ktory chce mat vsetko pod kontrolou... Ak mas alternativu, chod od nich prec.

342
Server / Re:Bezpečnější prostředí pro webové aplikace
« kdy: 01. 12. 2011, 17:03:02 »
Budem velmi rad az raz budem moct. Aktualne mame nasadene len NIDS (snort). Ale je to tema ktorej sa mienim venovat ked bude cas :)

343
Server / Re:Bezpečnější prostředí pro webové aplikace
« kdy: 01. 12. 2011, 15:17:21 »
Neviem si pomoct... Ale pokial je to najhodnodtnejsie v databaze tej webovej aplikacie, zameral by som sa hlavne na tu aplikaciu samu. Vsemozne veci ako prehodit SSH port a podobne sa viac dotykaju script kiddies...
Ked mam pristup k PHP exec alebo system, mam vyhrate. Skor ci neskor najdem vhodny exploit a /tmp je skoro vzdy zapisovatelne :)
Staci netcat a bindovat bash. Jednym smerom alebo opacny, je jedno.

Moje best practices su:

*chroot
*ro fs az na absolutne potrebne minimum
*rw fs ak je nutny (ak sessions nie su v memcached alebo koli uploadom) tak s nosuid a noexec!
*updaty, updaty, upday!
*Stale cledovat ci nie zverejneny novy 0day alebo hocikay zavaznejsi bug pre dany projekt [sql injection, eval(), ...]
*Urcite sa vyhrat napriklad s PHP diable functions
*Mozno by ani aplikacny firewall neskodil ktory by sledoval na zaciatok aspon GET requesty a pokial niekto donekocena sekvence meni nejake id vo velkom rozsahu, cez iptables bloknut IP a notifikacia admina.

344
Sítě / Re: Pomalé pripájanie na SSH
« kdy: 23. 11. 2011, 22:28:42 »
Urcite je vypnuty reverse lookup? Toto je bod kde by som ho cakal.

345
Server / Re: port mit-ml-dev na webhostingu
« kdy: 22. 11. 2011, 18:36:47 »
A mozes nam lenivcom napisat co je mit-ml-dev? Okrem toho ze je to TCP/85 a UDP/85 co vidiet v prehlade google vysledkov...
U mna na tych portoch (TCP/81 a vyssie) bezia jednotlive HTTP backendy za NGiNX a nemam pocit ze by mi prave na ne chodil nejaky cudny traffic. I ked mozno by som musel mat log na debug aby sa objavili HTTP nekonformne poziadavky.

Stran: 1 ... 21 22 [23] 24 25 ... 46