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 ... 318 319 [320] 321 322 ... 375
4786
Vývoj / Re:Digitální podpis PDF v PHP
« kdy: 19. 10. 2015, 14:10:50 »
Pak už podle mne zbývá jenom podívat se na zdroják té funkce, jaké kroky postupně dělá, a zkusit zjistit, kde přesně to končí chybu – např. ty jednotlivé kroky provést zvlášť. Případně jestli tam je možné zapnout vyšší úroveň logování, abyste zjistil, co se provedlo a co ne. Protože ta funkce musí jenom při načítání privátního klíče najít soubor, otevřít a přečíst ho, dekódovat ten formát PKCS8 nebo PKCS1, čímž teprve získá data k rozšifrování a ta rozšifrovat zadaným heslem. Z té hlášky vůbec není jasné, ve které fázi k té chybě dojde a kde tedy hledat problém.

4787
Vývoj / Re:PHP - Digitální podpis pdf souboru
« kdy: 18. 10. 2015, 16:43:08 »
To je divné, nedivil bych se, kdyby s tímhle openssl neumělo pracovat. Zkuste ten začátek smazat, aby tam zůstaly jen ty řádky s BEGIN a END a ta data mezi nimi. Také je mi divné to „RSA“, to je podle mne privátní klíč ve formátu PKCS1, který používaly staré verze OpenSSL, novější používají PKCS8, kde je typ klíče uložen uvnitř těch dat. Používáte nejnovější verzi OpenSSL?

4788
Vývoj / Re:PHP - Digitální podpis pdf souboru
« kdy: 18. 10. 2015, 16:22:30 »
Ten soubor s privátním klíčem, který se snažíte použít, tedy vypadá následovně?

Kód: [Vybrat]
-----BEGIN PRIVATE KEY-----
…data zakódovaná v BASE64…
-----END PRIVATE KEY-----
Tj. nic dalšího v tom souboru není?

4789
Software / Re:Bezpečnost GPG šifrování
« kdy: 18. 10. 2015, 15:20:56 »
Záleží tedy na povaze těch informací – pokud i po letech může jejich vyzrazení ohrozit tvůj život nebo vážně ohrozit tvoje postavení, tak bych je nikomu nedůvěryhodnému ani v zašifrované podobě nedával – zálohuj radši na druhý disk a ten ulož u někoho, komu věříš nebo ho dobře zabal a někde zahrabej. Pro menší objemy stačí flashka nebo SD karta. Nezapomínej ale na průběžnou kontrolu a obměnu médií – aby se ti nestalo, že k tomu za dvacet let přijdeš a nepůjde to přečíst.

Pokud se někdo takhle ptá, je řádově větší nebezpečí, že ta data získá někdo přímo z jeho disku nebo z disku uloženého u někoho, komu věří, než že by je získal přímo z Dropboxu (bez přičinění dotyčného, např. úniku hesla). Takže pro tebou uvedený příklad použití by ta data stejně musela být šifrovaná i na tom vlastním disku a na disku uloženém někde jinde. A hlavně by bylo potřeba s těmi daty pracovat v důvěryhodném prostředí.

Jinak GPG používá všeobecně uznávané a používané algoritmy, bezpečnost závisí především na těch algoritmech – chyba v GPG by vás mohla ohrozit jedině při samotném šifrování nebo dešifrování. A nebo v případě, že by ty algoritmy používalo špatně, ale na to už by se asi dávno přišlo. Takže důležitá je spíš volba konkrétních algoritmů, a pak hesla nebo klíče. Klíč bude vždy delší a bezpečnější, jenže pak zase musíte řešit, kam uložit ten klíč. Nicméně zrovna v kombinaci s Dropboxem je to dobrá volba – na Dropbox uložíte jen šifrovaná data, klíč tam dát nesmíte, ale ten bude oproti datům malý, takže ho můžete bezpečně uložit třeba i vytištěný v trezoru (lépe na více místech). Pokud byste použil heslo, určitě použijte kombinaci malých a velkých písmen, symbolů i číslic (ale bacha na použitou klávesnici, abyste zadával opravdu ty znaky, které si myslíte, že zadáváte). Ale opět pozor na zapamatování nebo uložení hesla, mělo by být unikátní, pro tu zálohu ho asi nebudete moc používat, takže ho snadno zapomenete – opět bude lepší mít ho někde bezpečně uložené. A pak nemá smysl šetřit na znacích, pokud bude mít třeba 20 znaků, jste bezpečně za hranicí toho, co by se dalo dnešními prostředky prolomit. (Ale nemá smysl zase přidávat zbytečně další desítky znaků, protože u delších hesel by útok stejně musel být veden jiným způsobem, než hádáním hesla, takže delším heslem už to nevylepšíte.)

4790
Vývoj / Re:Vizualizace kryptografického otisku (Hashe)
« kdy: 18. 10. 2015, 10:24:16 »
Zde se ovšem bavíme o zcela specifickém algoritmu na generování obrázků, který je zkonstruován tak, aby k tomuhle nedocházelo, ne o nějaké krajinomalbě.
„Tohle“ je vnímání obrazu lidským mozkem. Ten specifický algoritmus asi není implementován v lidském mozku, že?

Dokážeš rozlišit bilion obrázků?

Rozhodně lépe, než bilion stejně-dlouhých alfanumerických stringů.
No to určitě. Když ty stringy budou nějak rozumně zformátované, můžete je porovnávat znak po znaku. To na obrázku dokážete udělat jedině tehdy, pokud budou také zobrazovat po sobě jdoucí symboly. Lépe se to bude porovnávat, pokud použijete nějaké symboly, které už člověk zná, z jedné množiny, takové, které umí snadno pojmenovat. Jaká je největší množina takových znaků? Ano, alfanumerické znaky.

Abych ho mohl porovnávat, musím ho prvně přečíst. Pak ho musím udržet v paměti a pak ho musím porovnat znak za znakem s tím, který jsem tam viděl dříve. Pak musím rozhodnout, jestli je stejný.
Nemusíte. Když si přečtete zadání, ty dva obrázky mají být zobrazené vedle sebe. Takže si přečtete nějakou skupinu znaků, kterou si snadno zapamatujete, porovnáte s druhou stranou. A pokročíte na další skupinu znaků. Obrázek takhle dokážete porovnat jedině tehdy, pokud bude zobrazovat posloupnost symbolů. V opačném případě si totiž už po prvnímporovnání nebudete pamatovat, kde jste vlastně skončil.

Možná jsem výjimka, ale dokážu prostě porovnávat dva obrazy a jejich podobnost v hlavě přímo, doslova je vidím.
Jedině že byste měl fotografickou paměť. Jinak na těch obrázcích dokážete porovnat pár znaků – jednotky, nanejvýš nízké desítky. K čemu bude nějaký šestibitový hash?

4791
Vývoj / Re:PHP - Digitální podpis pdf souboru
« kdy: 17. 10. 2015, 23:04:34 »
Mně je tam tedy podezřelý ten převod privátního klíče do PKCS7. PKCS7 je formát uložená zpráv, tj. např. šifrovaný/podepsaný e-mail, případně se v něm ukládají sady certifikátů (buď certifikační cesta nebo CRL). Ale že by v PKCS7 byl uložen privátní klíč, to se mi moc nezdá.

Nicméně ten příkaz, který jste použil, podle mne jenom z PFX souboru extrahoval privátní klíč a uložil ho nešifrovaný do souboru key.pem. Pokud jste ten soubor pak přejmenoval na private.pem a máte ho uložený ve správném umístění, mělo by to být v pořádku.

To realpath() vám vrací správnou cestu?

Jinak dokumentace té funkce openssl_pkcs7_sign je opravdu fascinující. Nicméně ve všech příkladech tam v parametru pro privátní klíč předávají pole, ve kterém je na první pozici cesta k souboru s klíčem a na druhém heslo ke klíči. Zkuste si ten privátní klíč vyexportovat s nějakým heslem a použít tuhle variantu. Některé knihovny bez hesla neumějí pracovat.

4792
Vývoj / Re:Vizualizace kryptografického otisku (Hashe)
« kdy: 17. 10. 2015, 21:52:00 »
Oproti tomu zapamatovat si obrázek je podstatně jednodušší, což mám potvrzeno praxí, protože to používám.
To je ovšem jenom chyba v pozorování. Zkusil podstrčil vám někdy někdo podobný obrázek, jestli byste si všiml rozdílu? Nezkusil. Kdybyste si to vyzkoušel, nestačil byste se divit, u jak rozdílného obrázku jste si stále ještě myslel, že je to ten, který si pamatujete. Zvlášť když očekáváte, že by to měl být ten samý obrázek.

Obrázek má podstatně větší prostor všech možných kombinací, než kdy bude mít string o 32 znacích.
V tom problém není. Problém je v tom, že lidský mozek drtivou většinu těch informací zahodí. Můžete si to velice snadno vyzkoušet. Vezměte si nějaký nekomprimovaný obrázek, a ten uložte jako JPEG, klidně s 90% kvalitou. Pokud jako obrázek nezvolíte něco velikosti poštovní známky, ale třeba nějakou fotku, budete mít dva různé obrázky, s různými informacemi – a do toho rozdílu by se vám hashů vešlo spousta. Když se ale na ty obrázky podíváte, na první pohled nepoznáte žádný rozdíl.

4793
Vývoj / Re:Vizualizace kryptografického otisku (Hashe)
« kdy: 17. 10. 2015, 09:00:27 »
Mezi námi, zkonstruovat hash tak, aby se lišil v jednom bajtu nebo dokonce bitu je docela obtížné, nebo nemožné.
U hashovacích funkcí, které dnes považujeme za bezpečné, to můžeme považovat za nemožné. Jenže úplně něco jiného je zkonstruovat hash, který povede na obrázek, který bude na první pohled podobný. To je podle mého názoru velmi snadné, protože stačí vytvořit (podle mého názoru) pár desítek nebo stovek libovolných hashů a jeden z nich povede na podobný obrázek. No a ty náhodné hashe jednoduše vytvoříte tak, že vytvoříte tolik vstupů, které vyhovují vašim potřebám (tj. jsou tam potřebné údaje a ostatní údaje se mění) a klasicky je zahashujete.

Těžko někdo bude k právě vloženému dokumentu provádět hledání hodně podobného hashe, když je to mnohdy operace na několik let či staletí.
No právě. Jenže vy to celé chcete oslabit k nepoužitelnosti tím, že místo aby útočník roky (se započtením rozvoje techniky a prolamování hashovacích funkcí) vytvářel dokument s podobným hashem, bude pár sekund vytvářet dokument s podobným obrázkem.

Stačí si uvědomit jednoduchou věc. Hashe fungují na tom principu, že prostor možných hashů je nepředstavitelně obrovský. Naproti tomu prostor obrázků, které jsou na první pohled nezaměnitelné, je malinký. Ty obrázky můžete nahradit krátkým hashem, který bude mít zhruba stejně velký prostor hodnot, jako ty obrázky. I takové CRC-32, což ani není hash, vám dá řádově víc výstupů, než kolik dokážete vytvořit obrázků, které budou na první pohled různé. Pokud chcete to zabezpečení postavit na obrázcích, představujte si, že to  místo toho zabezpečujete CRC-32. Stačí vám to?

4794
Vývoj / Re:Vizualizace kryptografického otisku (Hashe)
« kdy: 16. 10. 2015, 21:31:57 »
jednotlivé čáry navazují jedna na druhou, vznikají různé a v mnoha případech hodně odlišné tvary
Jo takhle, ty čáry na sebe mají navazovat. Takže to prostě bude změť čar přes sebe. Čemuž by se dalo zabránit tím, že se nebude dělit 360 stupňů, ale jen 180, takže rozdíl by byl jen  o něco víc než 10 stupňů. Nebo by zůstal 22,5 stupňů, ale čárek by bylo 64 (pro 256bitový hash).

To ale není podstatné. Podstatné je to, že sice v mnoha případech mohou existovat hodně odlišné tvary, ale zároveň v mnoha případech ty tvary budou podobné. A vzhledem k tomu, že to budou převážně hodně divné tvary, stačí útočníkovi ten tvar napodobit jen trochu.

Je to zatím na vodě, to je jasné, chce to na tom zapracovat. Ale ten azimut je prostě super :)
Na tom, že na první pohled odlišnými obrázky dokážete prezentovat jenom pár bitů informace, nezmění jakákoli práce vůbec nic. A víc bitů informace zase naopak znamená vznik obrázků, které jsou podobné. Pro člověka bude mnohem těžší najít změnu v něčem tak nejednoznačném, jako jsou nejasné tvary v obrázku, než najít změnu v nějakém znaku, na které je člověk zvyklý.

4795
Vývoj / Re:Vizualizace kryptografického otisku (Hashe)
« kdy: 16. 10. 2015, 20:51:19 »
Když použijete jenom 256bitový hash a každá čárka bude reprezentovat jeden bajt (jak je popsáno v tom návrhu), bude to 32 čárek. I když ten hash změníte víc než jen v jednom písmenu, ty obrázky budou pořád podobné. Uživatel by je rozlišil jedině tehdy, pokud bude kontrolovat 32 čárek jednu po druhé.

4796
Vývoj / Re:Vizualizace kryptografického otisku (Hashe)
« kdy: 16. 10. 2015, 19:39:55 »
Vypište ten hash hexadecimálně třeba po čtyřech číslicích třeba čtyři skupiny na řádku. Nebo nějak podobně, prostě hexadecimální výpis zformátovaný pro snadné čtení.

Porovnáním nějakých obrázků ten hash efektivně zmenšíte na pár bitů, protože kdyby byl delší, začnou si ty obrázky být podobné a útočník může relativně snadno vygenerovat vstup, který bude dávat jiný hash ale podobný obrázek. Třeba pokud byste dal dohromady 256 různých obrázků (fotek), budete mít s výběrem dost práce, a přitom byste takhle dokázal odlišit jen osmibitové hashe.

4797
Vývoj / Re:Java Applet a zjištění MAC
« kdy: 07. 10. 2015, 14:36:38 »
Appletem to pujde, a jestli bude podepsany bude to i bez otazek uzivateli jestli se ma spustit. Certifikat kterym se aplet podepise muze byt podepsany i vlastni selfsigned autoritou, ale jeji root certifikat potom musi byt naimportovany v duveryhodnych autoritach. Data pak jdou pomoci volani js predat i z5 do stranky ve ktere byl aplet spusten. Neco podobneho uz sem nekolikrat delal.

Bez otázek uživateli to už naštěstí nejde. A hlavně, jak jsem psal, applet nebude fungovat v Chrome a zanedlouho nejspíš také ve Firefoxu (a v MSIE jsou Java Applety myslím také defaultně vypnuté). Předávat data zpět do stránky JavaScriptem v tomto případě podle mne není potřeba, aplikace to může odeslat rovnou na server (a stránka případně přečíst odsud), takže je lepší použít Java WebStart.

4798
Vývoj / Re:Java Applet
« kdy: 06. 10. 2015, 08:15:19 »
Applet viewer už nejde použít? To by bylo přesně to, co tazatel požaduje, ne?
Jde, ale to musí uživatel spustit ručně z příkazové řádky. To pak vůbec není potřeba používat Java Applet, ale může to být normální Java aplikace. Tazateli jde předpokládám o to, aby to uživatel mohl co nejjednodušeji spustit přímo z webu.

4799
Sítě / Re:Debian a problém s aliasy veřejných IP
« kdy: 03. 09. 2015, 17:52:02 »
Žádné rozhraní eth0:0 v Linuxu neexistuje už patnáct let. eth0:0 je jen způsob, jak ifconfig mate administrátory, kteří používají zastaralé nástroje. Podívejte se na konfiguraci IP adres příkazem ip addr, tak uvidíte, jak to máte skutečně nakonfigurované.

Přes iptables a NAT s tím nice neuděláte, nemůžete nastavovat IP adresu, kterou nemá přiřazené žádné zařízení v daném počítači. I kdyby se vám podařilo změnit takhle odchozí paket, odpověď se k vám nikdy nedostane.

Dnes máte rozhraní eth0 přiřazené tři IP adresy x.x.x.107, x.x.x.108 a x.x.x.109, normálně tam přidejte čtvrtou 10.0.1.120. Pomocí ip rule pak určíte, kdy se má ta odchozí adresa 10.0.1.120 použít.

4800
Sítě / Re:Přesměrování provozu na firemní proxy
« kdy: 02. 09. 2015, 18:24:08 »
Dekuju ta odpovedi ale stale nejsem moudry jeslti existuje nejake reseni, abych nemusel pro kazdou novou aplikaci nebo nastroj nastavovat proxy zvlast. Chapu to spravne ze to nejde ?
Existuje protokol WPAD, pomocí kterého by si měl klient umět najít proxy sám. V Linuxu by měl program použít nastavení proměnných prostředí http_proxy a https_proxy (pozor na to, kde je nastavujete - pokud si je nastavíte v shellu a mimo shell si pustíte nějaký program - typicky nějakou GUI aplikaci z desktopu, ta GUI aplikace ty proměnné prostředí nebude mít nastavené). Ale všechno to záleží na podpoře v daném klientovi, pokud to neumí, tak s tím nic neuděláte.

Stran: 1 ... 318 319 [320] 321 322 ... 375