Dotaz: Jak šifrovat data tak, abych je nemohl sám dešifrovat

[perlil]

Ahoj. Mám aplikaci (skriptík) v PHP, který potřebuje odesílat něco na "servery". V podstatě se jedná o to, že vytvoří lokálně několik souborů, pomocí cronu se spouští bash skript, který připojí různá ssh sdílení a na ně to nasype. Potřeboval bych, aby některá (ne všechna) data v těchto souborech byla šifrovaná (není problém udělat pomocí PHP) tak, abych je nemohl dešifrovat já, ale pouze ty servery, na které to sypu. Logické řešení je asymetrická kryptografie. Jenže jsem četl, že z privátního klíče se dá vygenerovat veřejný, takže kdybych šifroval privátním klíčem a na všech serverech, kam to posílám byl veřejný, tak bych pořád i já (odesílatel) byl schopný vygenerovat si svůj veřejný klíč a data dešifrovat. A udělat to opačně mi přijde blbost - 1x šifrovat veřejným a Xkrát dešifrovat privátním.

Jak toto vyřešit?

Odpovědi

[Filip Jirsák]

Při použití asymetrické kryptografie se vždy šifruje veřejným klíčem a dešifruje privátním. Opačně je to nesmysl, veřejný klíč je veřejný od toho, že ho může znát každý - takže by každý mohl zprávu rozšifrovat.

[VM]

Co takhle šifrování veřejným klíčem přestat považovat za blbost?

[perlil]

To samo o sobě blbost není, ale takhle bude mít ten samý privátní klíč několik příjemců.

[Filip Jirsák]

Pokud všem posíláte stejná data, ničemu to nevadí. Pokud ne, šifrujte pro každého příjemce zvlášť, vždy jeho klíčem.

[Jendа]

Třeba gpg umí šifrovat více klíči. gpg -e -r klíč1 -r klíč2 -r klíč3

[Michal Kubeček]

z privátního klíče se dá vygenerovat veřejný

Striktně vzato nedá. Je ale obvyklé, že buď jsou v tom souboru oba nebo máte k němu i veřejný.

[Peter Fodrek]

Vzdy sa sa da z verejneho kluca ziskat sukromny a naopak. Len to trva, v bezpecnych siftach, min 102 rokov na beznom PC

[Heron]

102? Proč zrovna konkrétně 102? Pominu-li, že u skutečných šifer se to číslo blíží (zhora) spíše 10^9 roků.

[pavlix]

A tedy se to nedá, pokud to člověk posuzuje z praktického pohledu.

[Peter Fodrek]

pokial si kupite PC tak, to nema vyznam. Pokial si kupite superpocitac za par stoviek milionov USD a budete ho zivit, tak ten to stihne za 1,5 mesiaca.

To ci to je prakticky nemozne je funkciou 1. Vyznamu informacie, alebo moznych finacnych ziskov z desifrovania 2. Casu, ktory mate k dispozicii 3. Financii, ktore mate k dispozicii..

[Jendа]

Pokial si kupite superpocitac za par stoviek milionov USD a budete ho zivit, tak ten to stihne za 1,5 mesiaca.

Nevěřím. Největší známý současný botnet (Bitcoin) spočítal za dobu své existence „pouze“ 2^82 operací a stál ne stovky milionů, ale miliardu USD.

//kde se vzalo to číslo 1,5 měsíce? když prodloužím klíč o jeden bit, budou to najednou 3 měsíce? co když ho prodloužím o 8 bitů?

[Peter Fodrek]

nas ucli, ze 102 rokv je hrancia medzi sifrou, ktora je bezp[ecna a tou, ktora je nebezpecna. Ucili nas to v roku 1995. Teda uz dost davno. mozno sa standardy sprisnili

[Heron]

Zvláštní. Nechce se mi věřit, že by si lidé v roce 1995 nedovedli představit použít místo 1 počítače třeba těch 102 a mít to za snesitelný 1 rok.

V každém případě, dnes každá rozumná šifra má sílu takovou, že bruteforce attack by trval déle, než je doba existence celého vesmíru (13.7 mld let).

Rozumná šifra dneska začíná na bezpečnostní síle 112b (tedy AES něco jako 224 - používá se 256), a pokud má Jenda pravdu s těmi 82b operací u Bitcoinu, tak se pohybujeme o 112-82 = 30 (binárních) řádu jinde. Tedy 2^30 (1048576x výkon Bitcoinu - jak dlouho to běží a kolik je tam kompů netuším).

[Michal Kubeček]

Tedy 2^30 (1048576x výkon Bitcoinu

To by bylo 2^20. 2^30 je něco přes miliardu.

[Heron]

+1

Překlep v bc.

[Jendа]

(zdroj k tomu Bitcoinu - položka Total cummulative number of hashes)

[pavlix]

Taky nesmí člověk věřit každé kravině.

[Xerces]

Na to asi žádný standard není. Každopádně je to praktické pravidlo. Po 102 letech budu s největší pravděpodobností pod drnem a bude mi jedno jestli mě někdo bude žalovat za slabé zabezpečení.

[Sten]

Nebylo to 102 bitů? To by tehdy tak odpovídalo

[pavlix]

To je jak rádio jerevan.

[jekub]

takze ted uz jen 83

[a1]

OT: proc nesmite ta data desifrovat (kdyz mate stejne k dispozici plaintext) ??

[pavlix]

To je dobrá otázka.

[Michal Kubeček]

Např. proto, aby ten, kdo by později získal nad strojem kontrolu a dostal se tedy i ke klíči, nemohl dešifrovat starší data (předpokládám, že se plaintext verze ihned po zašifrování smaže).

[perlil]

přesně

[a1]

aha takze otazka nezni "abych je nemohl desifrovat ja" ale "aby je nemohl desifrovat utocnik" ;)

kazdopadne je to tu uz napsane 100 krat: asymetricka sifra

BTW: smazat plaintext muzu i bez toho aniz bych ho sifroval ;)

[Jendа]

BTW: smazat plaintext muzu i bez toho aniz bych ho sifroval ;)

No ale já ho pak budu asi někdy v budoucnu potřebovat . Třeba když by to byly logy. Takhle se to dá řešit klíčem v trezoru, ke kterému se útočník ani v případě kompromitace nedostane. Samozřejmě je pak potřeba dešifrování provádět na čistém systému…

[pavlix]

No ale já ho pak budu asi někdy v budoucnu potřebovat .

To měla být zřejmě narážka na to, že zašifrování neřeší uvedený problém a musí se nad tím přemýšlet.

[pavlix]

Řeknu to, co ostatní, jinými slovy. Asymetrická kryptografie se většinou používá tak, že jeden z klíču je privátní a druhý veřejný, přičemž klíče byly vygenerovány společně. Ty pojmy mají jasně definovaný význam ve smyslu že privátní klíč je potřeba skrývat, zatímco veřejný klíč není potřeba skrývat a v ideálním případě lze skutečně vystavit pro širokou veřejnost. Když pominu jemné nuance slova veřejný ve spojení veřejný klíč, vždy se jedná o ten klíč, který agent vydává protistraně, aby mohl privátní použít k podepisování nebo dešifrování. Data šifrovaná privátním klíčem jsou veřejná (a zjednodušeně řečeno podepsaná). Naopak kdokoli může šifrovat data veřejným klíčem, pokud mám být jejich jediným příjemcem.

Příjemci musejí mít buď každý svůj privátní klíč, nebo ve zjednodušeném případě jeden sdílený (bezpečně dopravený) privátní klíč a šifrování probíhá odpovídajícím veřejným klíčem.

Představa, že něco zašifruju privátním klíčem a budu to považovat za tajné, je jenom matení pojmů. Ale docela by mě zajímala odpověď na otázku výše, proč je potřeba abych nemohl číst zprávu, ke které mám nezašifrovaný originál, to jako požadavek nedává moc smysl.

[lertimir]

Spíše se obecně šifrují vlastní data symetrickými šiframi. Hlavně proto, že asymetrické šifry jsou násobně výpočetně (a tedy časově nebo v průtoku dat) náročnější než symetrické stejné bezpečnosti. Současný poměr je cca 10^4-10^5. A používá se náhodně generovaný jednorázový klíč relace. Asymetrická šifra se používá spolu s dalšími kryptografickými elementy na bezpečné ustavení tohoto klíče relace.

V případě tazatele je možné několik řešení.

1. Změna protokolu z "push" - skriptík odesílá, na "pull" skriptík uloží a servery si data stáhnou. V tom případě jeden veřejný klíč skriptíkového server se distribuuje na ostatní servery.
2. Řešení triviální. Každý server uloží na u skriptíku své veřejné klíče a ten bude každému posílat jinak zašifrovaná data.
3. Řešení pitomé. Rozdistribuji soukromý klíč na všechny servery. To nicméně stejně nepomůže, abych posílal jedna data, protože při procesu generování klíče relace se ustaví jiný klíč pro každý server. A kompromitace libovolného mista likviduje komunikaci ze všemi stranami.
4. Řešení sofistikované. Použít některý z "multi party key exchange protocols" Jako jsou dokumentovány třeba 1, 2, 3 a mnoho dalších článků. Ale to je trochu z kanónem na vrabce a navíc asi zcela za hranicemi tazatelových schopností, když ani nechápe, jak funguje asymetrické crypto.

[Jendа]

Řešení triviální. Každý server uloží na u skriptíku své veřejné klíče a ten bude každému posílat jinak zašifrovaná data.

Řešení ještě triviálnější: data se zašifrují jen jednou symetrickým klíčem a různá data na různé servery znamenají pouze jinak zašifrovaný tento jeden klíč. Takže overhead je minimální. Jak už jsem psal výše, třeba GPG tohle umí naprosto jednoduše.

[pavlix]

Výše jsi psal, že umí šifrovat více klíči, ale ne co to přesně znamená.

[pavlix]

Spíše se obecně šifrují vlastní data symetrickými šiframi. Hlavně proto, že asymetrické šifry jsou násobně výpočetně (a tedy časově nebo v průtoku dat) náročnější než symetrické stejné bezpečnosti. Současný poměr je cca 10^4-10^5. A používá se náhodně generovaný jednorázový klíč relace. Asymetrická šifra se používá spolu s dalšími kryptografickými elementy na bezpečné ustavení tohoto klíče relace.

To bych si v kontextu diskuze troufl označit za implementační detail.

Změna protokolu z "push" - skriptík odesílá, na "pull" skriptík uloží a servery si data stáhnou.

To z pohledu šifrování vůbec nic neřeší, je v podstatě jedno, kdo iniciuje spojení.

Řešení triviální. Každý server uloží na u skriptíku své veřejné klíče a ten bude každému posílat jinak zašifrovaná data.

To jsem psal.

Řešení pitomé. Rozdistribuji soukromý klíč na všechny servery.

To jsem taky psal.

To nicméně stejně nepomůže, abych posílal jedna data, protože při procesu generování klíče relace se ustaví jiný klíč pro každý server.

Nebo lze data jednou zašifrovat a rozeslat. Navíc je to úplně jedno, protože klíč použitý na úrovni relace je opět jen implementační detail, který člověk v podstatě nemusí řešit.

A kompromitace libovolného mista likviduje komunikaci ze všemi stranami.

Což je typický projev sdílených klíčů.

Řešení sofistikované. Použít některý z "multi party key exchange protocols" Jako jsou dokumentovány třeba 1, 2, 3 a mnoho dalších článků. Ale to je trochu z kanónem na vrabce a navíc asi zcela za hranicemi tazatelových schopností, když ani nechápe, jak funguje asymetrické crypto.

Souhlasím jak s kanónem na vrabce, tak s hranicemi tazatele.