Elektronické podpisy a certifikáty.



Rád bych se zeptal, zda neznáte dobrou publikaci nebo web na téma elektronických podpisů a ověřených certifikátů. Co potřebuju. Znám přiměřeně princip asymetrické kryptografie, vím, co to je elektronický podpis, soukromý i veřejný klíč (certifikát). Znám právní pozadí a účel.  
  
Ale, nevím, jaký je rozdíl ve formátech certifikátů (DER x CER), případně ve formátech elektronických podpisů (p7s a další). Vím, jak podepsat nebo zašifrovat e-mail (to za mě udělá klient - OE apod.), ale nevím, jak podepsat nebo zašifrovat soubor (bez speciálního programu ve Windows). Tak bych rád věděl, zda to vůbec jde. Říkám si, že aspoň ověření integrity podepsaného souboru by nějak jít mělo, ale nevím, zda to je správná úvaha.  
  
Používám PGP, což je systém sám o sobě, dál program ELPI elpi.szm.sk, ... který slouží ke generování právě certifikátů X.509, šifrování a podepisování atd. Ale jím vygenerovaný certifikát ani po importu nějak nemůžu použít k podepsání mailu.   
  
Takže někde v té střední úrovni (jak se to chová v PC a jak s tím pracovat) mám zmatek. Na webu toho moc najít neumím, protože mi to vyhazuje buď matematickou teorii na obecné úrovni (což už nepotřebuju) nebo právní teorii (což nepotřebuju vůbec).  
  
Kdyby se tedy našel někdo, kdo zná dobrý zdroj, kde by bylo vysvětleno, k čemu je který formát certifikátu dobrý, jak se pozná, k čemu se dá použít, jak se podepisují soubory (pokud to vůbec jde) bylo by to moc fajn.  
  
Díky.
pokial ovládaš anglický jazyk aspoň na takej úrovni,že sa vieš vysomáriť z písaného textu,môžeš si podrobnosti naštudovať priamo napr. na www.verisign.com
<p>účelem certifikátů rozšířené validace je zviditelnit uživatele, instituci, které byly vydány. technické aspekty samotných certifikátů jsou kombinovány s vizuálními vodítky v uživatelském rozhraní aplikace, která je ověřuje: zelený pruh a viditelný název vedle umístění v prohlížeči.</p><p>například certifikát ev na <a href="http://www.paypal.com/">http://www.paypal.com/</a> způsobí, že prohlížeč zobrazí zelený pruh a zobrazí „paypal, inc.“ vedle toho. účelem je nejen propojit certifikát s vlastníkem domény (jako standardní certifikáty ověřené v doméně), ale také ho propojit s fyzičtější institucí (zde, paypal, inc.). k tomu musí certifikační autorita ověřit, že pojmenovaná instituce je skutečně ta, která vlastní doménu.</p><p>v konečném důsledku jde spíše o vytvoření autentičtějšího propojení mezi názvem domény a názvem společnosti, než o vytvoření „bezpečnějších“ certifikátů. z hlediska sady šifry (což je to, co určuje šifrovací algoritmus a velikost klíče), se certifikáty ev neliší od certifikátů dv (modrý pruh).</p><p>trochu ustoupíte, musíte si uvědomit, že účinnost https závisí na tom, že uživatel zkontroluje, zda je používán správně. (server nemá způsob, jak zjistit, zda se klient stal obětí útoku mitm jinak, pokud nepoužívají také klientské certifikáty.) to znamená, že uživatelé musí:</p><ul> <li>zkontrolovat, zda se používá https, když očekávají, že to bude,</li> <li>zkontrolovat, že neexistují žádná varování,</li> <li>zkontrolujte, zda web, který používají, je opravdu ten, který hodlá navštívit, což vede k několika bodům: <ul> <li>kontrola, že to je doménové jméno, které očekávají,</li> <li>ověření, zda název domény patří společnosti, kterou očekávají.</li> </ul> </li> </ul><p>účelem certifikátů ev je vyřešit tento poslední bod. pokud již víte, že <code>amazon.com</code> patří společnosti amazon.com, inc. nebo tomu <code>google.com</code> patří společnosti google inc., opravdu je nepotřebujete.</p><p>nejsem osobně přesvědčen, že tento přístup funguje úplně, protože mohou být zneužity (viz příklad natwest/rbs níže) a zdá se, že některé ca šíří vágní (a potenciálně zavádějící) informace o tom, co ve skutečnosti jsou, ve snaze propagovat jim.</p><p>obecně platí, že pokud vaši uživatelé již vědí, že vaše doménové jméno je vaše, nepotřebujete jej.</p><p>zde jsou další podrobnosti z <a href="https://security.stackexchange.com/a/13614/2435">předchozí odpověď, kterou jsem dal na podobnou otázk</a> :</p><blockquote> <p>[...]</p> <p>certifikáty ověřené doménou vám zaručují, že certifikát byl vydán vlastníkovi této domény. nic víc, ale nic méně (předpokládám, že validační postup zde byl správný). v mnoha případech to stačí. vše záleží na tom, zda web, který propagujete, musí být propojen s institucí, která je již dobře známa off-line. certifikáty, které jsou validovány proti organizaci (ov a ev certs), jsou užitečné zejména v případě, že potřebujete doménu také svázat s fyzickou organizací.</p> <p>například je užitečné, aby instituce, která byla původně známá prostřednictvím své budovy (např. bank of america), mohla říci, že certifikát pro <code>bankofamerica.com</code> je skutečně místem, kde jste dali své fyzické peníze. v tomto případě má smysl použít certifikát ov nebo ev. to může být také užitečné, pokud existuje nejasnost ohledně toho, která instituce je za názvem domény (např. <code>apple.com</code> a <code>apple.co.uk</code>), což je ještě důležitější, je podobné doménové jméno vlastněné soupeřem/útočníkem, který používá podobnost názvu pro špatné účely.</p> <p>v porovnání, <a href="https://www.google.com/"><code>www.google.com</code></a> je to, co definuje google pro veřejnost; google nemusí dokazovat, že <code>google.com</code> patří skutečnému googlu. výsledkem je, že používá certifikát ověřený doménou (stejný pro <code>amazon.com</code>).</p> <p>to je opět užitečné, pokud uživatel ví, jak to zkontrolovat. prohlížeče zde opravdu nepomáhají. firefox pouze říká, „který je spuštěn (neznámý)“, pokud chcete o certifikátu získat další podrobnosti na <code>www.google.com</code>, aniž bychom skutečně řekli, co se tím myslí.</p> <p>certifikáty s rozšířenou validací jsou pokusem o zlepšení, a to zpřísněním postupu validace organizace a zviditelněním výsledku: zelený pruh a viditelnější organizace.</p> <p>bohužel se to někdy používá způsobem, který zvyšuje zmatek, myslím. zde je příklad, který si můžete zkontrolovat sami: jedna z velkých britských bank (natwest) používá <a href="https://www.nwolb.com/"><code>https://www.nwolb.com/</code></a> pro on-line bankovní služby. není jasné, že doménové jméno patří natwestu (který také vlastní logičtější <code>natwest.co.uk</code> mimochodem). horší je, že rozšířená validace (pokud zaškrtnete jméno vedle zeleného pruhu) se provede proti „royal bank of scotland group plc“.</p> <p>pro ty, kteří sledují finanční zprávy, to dává smysl, protože jak rbs, tak natwest patří do stejné skupiny, ale technicky jsou rbs a natwest konkurenty (a oba mají pobočky na hlavní ulici ve velké británii - i když se to změní). pokud váš uživatel nemá takovou zvláštní znalost o tom, které skupiny obchodují pod tímto jménem, ​​měla by výstražná zvonit zazvonit skutečnost, že certifikát je vydán na jméno potenciálního konkurenta. pokud jste jako uživatel viděli certifikát na <code>gooooogle.com</code> vydáno společnosti microsoft nebo yahoo, i když je tato lišta zelená, neměli byste to považovat za web společnosti google.</p> <p>jeden bod, který je třeba mít na paměti u certifikátů ev, je to, že <a href="https://security.stackexchange.com/a/14064/2435">jejich konfigurace je pevně zakódována do prohlížečů</a> . toto je nastavení kompilace, které nelze později nakonfigurovat (na rozdíl od běžných důvěryhodných úložišť certifikátů, do kterých můžete přidat například vlastní institucionální certifikační úřad). z cyničtějšího hlediska by to někteří mohli považovat za vhodný způsob, jak si hlavní hráči udržet silnou pozici na trhu.</p> </blockquote> <p>„zástupný certifikát“ je certifikát, který obsahuje jako možný název serveru název obsahující „<code>*</code> "znak. podrobnosti jsou v <a href="http://tools.ietf.org/html/rfc2818#section-3.1">rfc 2818, oddíl 3.1</a> . sečteno a podtrženo: když certifikát serveru obsahuje <code>*.example.com</code>, bude přijato <strong>klienty</strong> jako platný certifikát pro jakýkoli server, jehož <em> zjevné jméno </em> odpovídá tomuto jménu.</p><p>v oblasti certifikace webových stránek existují čtyři hlavní aktéři:</p><ul> <li>samotný server ssl.</li> <li>prodejce webového prohlížeče, který bude klient používat.</li> <li>lidský uživatel, který do určité míry řídí, co bude klientský prohlížeč dělat.</li> <li>ca, který vydal certifikát serveru.</li> </ul><p>zástupné certifikáty nenaznačují další zranitelnosti serveru ssl; ssl server opravdu nemá zájem na pohledu na svůj vlastní certifikát. tento certifikát je ve prospěch klientů, aby je přesvědčil, že veřejný klíč obsažený v certifikátu je skutečně veřejným klíčem pravého serveru ssl. server ssl <em> zná </em> vlastní pár veřejných/soukromých klíčů a nemusí o tom být přesvědčen.</p><p>lidský uživatel netuší, co je veřejný klíč. co vidí, je ikona visacího zámku a co je důležitější, <strong>zamýšlený název server</strong>: to je jméno napravo od "<code>https://</code> "a před další" <code>/</code> ". webový prohlížeč <em> předpokládá </em> zpracování technických údajů o ověření správnosti názvu, tj. ověření certifikátu serveru a ověření, zda se název shoduje s názvem, který je zapíše-li se do uvedeného certifikátu. pokud prohlížeč tuto úlohu neprovede, bude považován za nedbalý a nepřevezme svou roli, což může mít vážné obchodní důsledky, možná i legální. obdobně je ca smluvně vázán dodržováním stanovených postupů pro identifikaci vlastníků ssl serverů, aby bylo pro útočníky obtížné získat falešné certifikáty (smlouva je mezi ca a jeho über-ca, rekurzivně, až na kořenovou ca, která je sama vázána paktem s os nebo prodejcem prohlížeče, který přijato za účelem zahrnutí kořenového klíče ca do os nebo prohlížeče za definovaných podmínek).</p><p>to znamená, že prohlížeč <em> </em> a <em> [~ # ~] ca [~ # ~] </em> musí v praxi , rozmazlovat uživatele procesem ověření. jsou více či méně povinni (ze zákona nebo, ještě přísněji, z obchodních důvodů), aby zabránili podvodníkovi uživatele pomocí falešných stránek, které vypadají oprávněně. hranice mezi úlohou uživatele a úlohou prohlížeče/ca není jasně definována a historicky se posunula. v days of yore, myslím asi před deseti lety, prohlížeče vytiskly pouze nezpracovanou url a bylo na lidském uživateli, aby v něm našel název serveru. to vedlo kované operátory webů (tj. „phishingové weby“) k použití url, které jsou technicky platné, ale zavádějící, jako je tato:</p><pre><code>https://www.paypal.com:payment-interface-login-session@xcvhjvb.com/confirm.html </code></pre><p>vzhledem k tomu, že lidští uživatelé jsou <em> lidé </em> a většina z nich čte zleva doprava (nejbohatší a naivní podvodné cíle jsou stále v západních zemích), začnou na vlevo, viz <code>www.paypal.com</code>, zastavte se u dvojtečky („příliš technické“) a buďte scammed.</p><p>v reakci na to dodavatelé prohlížečů uznali, že schopnosti lidských uživatelů analyzovat url nejsou tak dobré, jak se původně předpokládalo, a proto poslední prohlížeče zvýrazňují část domény. ve výše uvedeném případě by to bylo <code>xcvhjvb.com</code> a rozhodně ne nic s <code>paypal.com</code> v tom. nyní přichází část, kde <strong>zástupné certifikáty</strong> vstoupit do hry. pokud majitel <code>xcvhjvb.com</code> koupí zástupný certifikát obsahující "<code>*.xcvhjvb.com</code> ", pak může nastavit phishingový web s názvem:</p><pre><code>https://paypal-payment-interface-login-session.xcvhjvb.com/confirm.html </code></pre><p>který bude prohlížečem přijat (odpovídá názvu zástupného znaku) a bude stále pravděpodobně zachycovat nežádoucí uživatele (a je jich mnoho ...). toto jméno <em> mohl útočník koupit </em>, aniž by se uchýlil k zástupným znakům, ale pak by zaměstnanci ca viděli jméno se zjevným podvodným pokusem (dobrý ca <em> do </em> ověření platnosti každé žádosti o osvědčení člověkem nebo alespoň upozorňování na jména, která jsou velmi dlouhá a/nebo obsahují v nich známé názvy bank).</p><p>proto <strong>zástupné certifikáty snižují účinnost opatření proti podvodům na straně ca</strong>. je to jako prázdný podpis od ca. pokud budou pokusy o phishing na základě zástupných znaků běžnější, lze očekávat, že bude existovat jedno nebo několik z následujících opatření:</p><ul> <li>prohlížeče zvýrazňují pouze části názvu domény, které se shodují s <em> prvky, které nejsou v zástupném znaku </em> v certifikátu.</li> <li>ca vyžadují těžší papírování a smlouvy pro zástupné certifikáty (a ty budou dražší).</li> <li>prohlížeče zcela deaktivují podporu pro zástupné certifikáty.</li> </ul><p>ve skutečnosti očekávám, že všechna tři opatření budou použita v příštích letech. mohl bych se o tom úplně mýlit (to je problém s předpovídáním budoucnosti), ale tohle je pořád můj pocit střeva.</p><hr><p>můžeme také zdůraznit, že zástupné certifikáty jsou užitečné pro sdílení stejného páru klíčů mezi různými názvy serverů <em> </em>, což zvyšuje pravděpodobnost, že soukromý klíč bude sdílen mezi různými servery. <em> stroje </em>. cestování soukromými klíči je samo o sobě bezpečnostním rizikem; čím více soukromý klíč putuje, tím méně „soukromý“ zůstává.</p> Ukazuje se, že problém nesouvisí s podpisem vůbec - je to proto, že soubor XML je sestaven. Chcete-li se podívat na obsah tohoto souboru je nutné použít `aapt`nástroj. <p>samozřejmostí je autentizace klienta. může být použit ke zlepšení zabezpečení v kombinaci s přístupovým heslem nebo čipovou kartou nebo jako pohodlná náhrada za zadání hesla.</p><p>zajímavý návrh v tomto kontextu je <a href="http://webid.info/">webid single sign on protocol</a> .</p><p>hlavní problém s klientskými certifikáty je v tom, že je vázán na prohlížeč. takže pokud jste na jiném počítači, nemáte k nim přístup, pokud jste neučinili preventivní opatření.</p> tak se mi to povedlo, díky:

smazat certifikat v /etc/cockpit/ws-certs.d

reset cockpitu: systemctl restart cockpit

vytvoří se 2 soubory (.cert a .pem)

soubor .pem zkopírovat do windows a přejmenovat na .crt

import certifikátu jako kořenový důvěryhodný certifikát

problém byl opravdu v tom, že certi… <p>záleží na tom, jak moc chcete oddělit role.</p><p><strong> základní systém: </strong> váš „podpis“ je <a href="http://en.wikipedia.org/wiki/message\_authentication\_code"> mac </a> . „klíč api“ je tajná hodnota, se kterou se sdílí server a uživatel. normální mac algoritmy jako <a href="http://en.wikipedia.org/wiki/hmac"> hmac </a> mohou používat libovolné sekvence bitů jako klíč, takže klíč lze snadno vygenerovat pomocí <code>/dev/urandom</code> (linux, * bsd , macos x), volání <code>cryptgenrandom()</code> (win32) nebo pomocí <code>java.security.securerandom</code> (java).</p><p><strong> vylepšený systém: </strong> váš podpis je skutečný <a href="http://en.wikipedia.org/wiki/digital\_signature">digitální podpis</a> . to má smysl, pokud chcete oddělit generátor klíčů (který může vytvářet klíče, které bude server akceptovat), od samotného serveru (který ověřuje příchozí podpisy). klíče pro algoritmy podpisu jsou matematické objekty se spoustou vnitřní struktury a každý algoritmus zahrnuje specifický algoritmus generování klíčů. použijte knihovnu, která již implementuje potřebné bity (např. <a href="http://www.openssl.org/">openssl</a> ).</p><hr><p><strong> v každém případě </strong> je toho více než jen generování klíčů a podpisy. například se pravděpodobně chcete vyhnout <em>opakované útoky</em>: špatně zamýšlená třetí strana špehuje v síti a zaznamenává platnou žádost podepsanou běžným uživatelem. útočník později odešle požadavek znovu, doplněný jeho podpisem, aby se účinek replikoval. abyste se vyhnuli opakovaným útokům, musíte přidat nějaký externí protokol a tyto věci je obtížné udělat (není těžké definovat protokol; je <em>velmi</em> obtížné definovat <em>zabezpečené]</em> protokol). chytrá věc je proto opětovné použití existujícího, dobře prověřeného protokolu, což v praxi znamená <a href="http://en.wikipedia.org/wiki/transport\_layer\_security">ssl/tls</a> .</p><p>u ssl je „základní systém“ omezen na odesílání klíče api v záhlaví na začátku konverzace (to je přesně to, co se děje při ověřování hesla na webech https). "rozšířený systém" je pak "ssl s klientským certifikátem".</p> <p>za prvé si myslím, že odpověď skeptiků to do značné míry pokrývá: drm obtěžuje lidi. někteří z nás se aktivně vyhýbají nákupu zboží.</p><p>pokud jde o software, je to téměř nemožné. jedním schématem drm může být použití šifrování veřejným klíčem s obsahem šifrovaným symetrickými klíči (výkon symetrických šifrů je výrazně lepší než u většiny pk). šifrovat obsahový klíč soukromým klíčem a software pak může tento klíč veřejným klíčem dešifrovat a obsah dešifrovat.</p><p>což funguje, kromě toho, že se chystám provést program pomocí debuggeru nebo rozebrat váš kód, dokud nenajdu váš klíč, dešifrovat váš obsah a hra není hotová. crypto je pro přenos přes nezabezpečené sítě, nikoli pro bezpečné dešifrování a izolaci na nepřátelských systémech.</p><p>můžete tedy přes internet poslat spoustu různých klíčů pro různé části obsahu. no, vaši platící zákazníci s tím pravděpodobně budou mít problémy, ale mohu jen automatizovat proces ladění nebo připojit vaše přijímané události nebo cokoli jiného. ať tak či onak, mohu chytit ty klíče. není to snadné, ale lze to udělat.</p><p>další fází je tedy zabránit mi používat můj debugger nebo nějakým způsobem zavěsit vaše systémová volání, což je místo, kde začnete psát rootkity. jakmile se to stane, můžu disk odstavit v režimu offline a zkontrolovat/zakázat rootkit, nebo jej upravit tak, aby váš software věřil, že je bezpečný. ve skutečnosti mi to usnadní identifikaci toho, co chráníte.</p><p>existuje další případ, kdy je os komplikovaný a poskytuje nějakou formu zabezpečeného kontejneru. pokud je pro mě možné načíst kód do kruhu 0, stává se toto zabezpečení irelevantní. pokud ne, pokud mohu klonovat vaše jádro mikrok jádra a upravit jej tak, abych mohl načíst kód do kruhu 0, toto zabezpečení se opět stane irelevantní.</p><p>nyní musíte začít používat hardwarové ovládací prvky. jednoduše řečeno, protože mohu změnit operační systém jakýmkoli způsobem, prosím, pravděpodobně budete potřebovat hardwarově implementované drm, které nemám šanci modifikovat nebo číst. budete potřebovat, aby se vaše šifrování stalo na hardwaru tak, že nebude možné číst dešifrovaná data z operačního systému. budete potřebovat veřejný klíč, který jsem zmínil výše, aby zůstal na tomto hardwaru, ne na os.</p><p>v tuto chvíli jste mě osobně porazili, ale jsem si jist, že existují lidé, kteří jsou schopni upravit své kabely hdmi (nebo cokoli jiného) tak, aby rozdělili data na displej a na jiné zařízení, jako je úložiště.</p><p>problémem bude také způsob bezpečného uložení klíčů v zařízení. budete je muset zašifrovat! jinak připojím vaše úložné zařízení k offline systému. a uložte klíče ... počkejte ... podívejte se na vzorec?</p><p>jakmile máte fyzický přístup, hra končí.</p><p>nemyslím si, že drm je technicky možné. ať už použijete jakékoli metody, vždy bude existovat někdo s dostatečnou schopností zrušit tuto funkci, protože na určité úrovni musí být chráněný obsah pro jejich zobrazení dešifrován. to, zda mají motivaci, je jiná věc.</p><p>z pohledu softwarového inženýrství je to správné, aniž by to narušilo vaše uživatele, což jim umožnilo snadno přesunout jejich obsah na autorizovaná zařízení, podporovat nová zařízení ... všechny noční můry. kdo bude kupovat váš obsah, když nemáte podporu windows 8 připravenou ke spuštění? funguje váš obsah v mém systému windows xp)? co tím myslíte, že jej nepodporujete ?! pokud používáte hardware, máte problém s nasazením.</p><p>konečně drm je prostě hluboce nepopulární.</p> <p>to záleží na tom, zda máte obavy z odsouzení, nebo vyřizování pravděpodobné příčiny (v usa).</p><p>předpokládejme, že jste doma. spustíte vpn a připojíte se k poskytovateli vpn mimo lokalitu. pokud sleduji odchozí provoz (z vašeho domu), vím, že jste se právě připojili k určité ip adrese a že ip adresa je poskytovatel vpn. všechno uvnitř užitečného zatížení paketu je šifrováno.</p><p>poté se rozhodnete, když budete doma, zkontrolovat svůj e-mail. stává se, že sleduji odchozí provoz od poskytovatele vpn (který není šifrovaný). zaznamenávám to vše pomocí odfrknutí a spustím wireshark proti výstupu. vidím spojení s vaší e-mailovou adresou a napsaný e-mail. to může být chráněno ssl, pokud je to webmail. pokud se jedná o běžný e-mail, je to pravděpodobně prostý text. pokud to není prostý text, mohu se pokusit zachytit ho v přijímači. e-mail nemá žádný právní význam (tj. nepoužíváte jej k plánování něčeho nezákonného). všiml jsem si však skutečnosti, že zaměňujete použití jejich, tam a tam jsou. všimnu si také několika idiomů, které chcete použít.</p><p>během sledování odchozího provozu vidím, že váš účet psal několik e-mailů. zaznamenávám vzory překlepů a další postavy řeči. sbírám je po dobu jednoho měsíce nebo dvou.</p><p>potom jsem vložil položky, které si všimnu, do wireshark. přidávám několik věcí, o kterých je vám známo. pokaždé, když dojde k překlepu nebo použití idiomu (který používáte) najdete v obsahu jakéhokoli paketu, který vychází z vpn služby, kterou používáte, vidím to.</p><p>za další měsíc nebo dva mám spoustu datových bodů. některé jsou weby, na které jste šli, jiné ne. první věc, kterou udělám, je odstranění všech datových bodů, které opustily poskytovatele služeb vpn, když jste nebyli online (tj. neviděl jsem vás online z domova, nezapomeňte, že jsem začal sledováním tohoto připojení).</p><p>pak se podívám na zbývající provoz a uvidím, jestli mám nějaké body clusteru. spousta opakujících se témat. stejný předmět přes over. porovnávám to s vaším nešifrovaným provozem a vaším e-mailem.</p><p>neaplikoval jsem dostatek filtrů, abych tě izoloval od hluku (lidé, kteří používají stejné idiomy/pravopisné chyby jako ty), ale měl bych dobrý důvod pro pravděpodobnou příčinu. pokud mám dostatek referenčních bodů, je to jako otisk prstu.</p><p>v podstatě aplikuji bayesovskou analýzu na korpus práce, abych uvedl něco o pravděpodobnosti, že věřím, že příkladem bude člen souboru vytvořeného mým podezřelým. sbírka děl, která bych srovnávala, pochází z jakékoli práce, za kterou podezřelý veřejně uznal, že za ni odpovídá. tato analýza je dobře známa (a existuje i celá statistika stackexchange webu).</p><p>nechám tě odpovědět, s čím bych v tuto chvíli přišel?</p> <blockquote> <p>řekněme však, že chci, aby server šifroval data pomocí soukromého klíče a dešifroval je pomocí veřejného klíče, což je způsob distribuce dat, o kterých lze ověřit, že pocházejí ze správného serveru.</p> </blockquote><p>můžete to udělat - je to na velmi zjednodušující úrovni, jak funguje podepisování rsa (poznámka: zjednodušující - je toho o něco více).</p><blockquote> <p>namísto úpravy kódu, aby to bylo možné, mohu jednoduše publikovat soukromý klíč a udržet veřejný klíč v tajnosti? ovlivňuje to bezpečnost systému?</p> </blockquote><p>vy <strong> nemusíte </strong> vůbec publikovat soukromý klíč - rsa je permutace trapdoor, což znamená:</p><ul> <li>pokud zašifrujete veřejný klíč, můžete dešifrovat soukromým klíčem.</li> <li>pokud zašifrujete soukromý klíč, můžete jej dešifrovat pomocí veřejného klíče.</li> </ul><p>rsa tedy podporuje provádění podpisu i šifrování spoléhající se na to, že koncový uživatel má pouze veřejný klíč.</p><p>pokud si klient přeje ověřit data pocházející ze serveru, použijete druhý případ rsa a dešifrujte data podpisu pomocí veřejného klíče, který již máte.</p><p>navíc, protože se jedná o permutaci, neměli byste svůj kód vůbec upravovat. obě klávesy by měly fungovat pomocí stejné funkce. očekával bych, že každá slušná krypto knihovna bude mít api pro ověřování podpisů podle měnících se standardů, které existují - jedním z nich by pravděpodobně byla dobrá sázka.</p><p>rsa labs poskytují nice <a href="https://web.archive.org/web/20130718172549/https://www.rsa.com/rsalabs/node.asp?id=2182">vysvětlení</a> .</p><p>pokud to chcete rozšířit mezi servery nebo ověřit komunikaci klienta - vygenerujte klíče pro každou entitu a vyměňte veřejné. proces lze poté použít na obou koncích.</p><p>teoreticky jsou e a d vzájemně zaměnitelné (proto rsa funguje) (jeden musí být označen jako tajný a udržovaný v tajnosti), ale p a q musí <strong> vždy </strong> být udržované v tajnosti, protože vám umožňují odvodit d z e a naopak. při pochopení soukromého klíče však musíte být velmi opatrní - ukládá váš software v soukromém klíči p/q? pokud ano, nemůžete jej publikovat tak, jak je. také, když řeknu zaměnitelným - jakmile jednou publikujete jeden z těchto párů (e nebo d spolu s vaším modulem n), musíte chránit druhého <em> svým životem</em>. prakticky řečeno <a href="https://stackoverflow.com/questions/696472/given-a-private-key-is-it-possible-to-derive-its-public-key">jak graeme v komentářích odkazuje</a> e je často vybíráno jako malá/pevná hodnota. můj názor na zaměnitelnost e/d se zjevně nevztahuje, pokud je e snadno určitelné. dělat takovou věc má tedy potenciál k záměně a nesprávnému provedení. použijte knihovnu třetích stran/nezačněte publikovat soukromé klíče.</p> Napsal jsem generickou knihovnu GPG / PGP NPAPI pro použití v prohlížeči, který má veřejné metody pro většinu všechno, včetně rozšifrování a ověření.


Zdrojem plugin se nachází zde: <https://github.com/kylehuff/webpg-npapi>


Plugin je v současné době používá v WebPG rozšíření pro Chrome, zde se nachází: <https://chrome.google.com/webstore/detail/hhaopbphlojhnmbomffjcbnllcenbnih>


A je zdrojem rozšíření je najít zde: <https://github.com/kylehuff/webpg-chrome>


Oba jsou cross-platform pro Windows, Linux a OSX.