Byla vydána verze 2.12.0 QEMU (Wikipedie). Přispělo 204 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn. Řešeny jsou také bezpečnostní chyby Meltdown a Spectre.
Google zveřejnil seznam 1 264 studentů přijatých do letošního Google Summer of Code. Přehled projektů, studentů, 212 organizací a mentorů je k dispozici na stránkách GSoC.
Oracle vydal verzi 1.0 univerzálního virtuálního stroje GraalVM, který umožňuje běh programů napsaných v jazycích založených na JVM, JavaScript, LLVM bitcode a experimentálně Ruby, R a Python.
Julia Evans pomocí svých kreslených obrázků proniká do Linuxu a informačních technologií. Vedle ucelených zinů publikuje také jednotlivé kreslené obrázky (RSS).
Jordi Sanfeliu vydal verzi 1.0.0 svého unixového jádra Fiwix (Wikipedie) určeného také pro výuku operačních systémů. Dle článku na OSNews na něm začal pracovat již před více než dvaceti lety. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT. Stáhnout a vyzkoušet lze živou disketu nebo CD s GNU/Fiwixem.
Byla vydána nová verze 10.7 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab (Wikipedie). Představení nových vlastností v příspěvku na blogu. Vývojáři GitLabu zdůrazňují Web IDE (YouTube) a SAST (Static Application Security Testing) pro Go a C/C++.
David Revoy, autor open source webového komiksu Pepper&Carrot nebo portrétu GNU/Linuxu, zveřejnil na svém blogu recenzi notebooku Librem 13 od společnosti Purism. Používá jej již sedm měsíců a s ním i jako umělec spokojen. Potřebu francouzské AZERTY klávesnice vyřešil přelepkami. Na displej se podíval kalibrační sondou, barvy vyladil pomocí open source softwaru DisplayCAL, v aplikaci Inkscape nastavil zvětšování na 170 % aby 1 cm v Inkscapu byl 1 cm v reálu. Webovou kameru, mikrofon, Wi-Fi a Bluetooth lze na Librem 13 hardwarově vypnout.
Několik posledních verzí GNOME Shellu obsahuje chybu způsobující memory leak (únik paměti). Viz například videozáznamy verzí 3.26 nebo 3.28. Nalezení chyby #64 a její opravě se věnuje Georges Basile Stavracas Neto v příspěvku na svém blogu [reddit].
V pondělí měl na YouTube online premiéru otevřený krátký 2D film Hero vytvořený v 3D softwaru Blender. Cílem stejnojmenného projektu Hero je vylepšit nástroj Grease Pencil (tužka) v Blenderu 2.8.
Byla vydána verze 4.0 kolekce svobodného softwaru umožňujícího nahrávání, konverzi a streamovaní digitálního zvuku a obrazu FFmpeg (Wikipedie). Přehled novinek v Changelogu (GitHub).
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?
gpg -e -r klíč1 -r klíč2 -r klíč3
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ý.
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ů?
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).
Tedy 2^30 (1048576x výkon Bitcoinu
To by bylo 2^20. 2^30 je něco přes miliardu.
BTW: smazat plaintext muzu i bez toho aniz bych ho sifroval ;)No ale já ho pak budu asi někdy v budoucnu potřebovat
No ale já ho pak budu asi někdy v budoucnu potřebovatTo 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..
Ř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.
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.
Tiskni
Sdílej: