Společnost AMD na veletrhu Computex 2024 představila (YouTube) mimo jiné nové série procesorů pro desktopy AMD Ryzen 9000 a notebooky AMD Ryzen AI 300.
OpenCV (Open Source Computer Vision, Wikipedie), tj. open source multiplatformní knihovna pro zpracování obrazu a počítačové vidění, byla vydána ve verzi 4.10.0 . Přehled novinek v ChangeLogu. Vypíchnout lze Wayland backend pro Linux.
Národní superpočítačové centrum IT4Innovations s partnery projektu EVEREST vydalo sadu open source vývojových nástrojů EVEREST SDK pro jednodušší nasazení aplikací na heterogenních vysoce výkonných cloudových infrastrukturách, zejména pro prostředí nabízející akceleraci pomocí FPGA.
Společnost Valve aktualizovala přehled o hardwarovém a softwarovém vybavení uživatelů služby Steam. Podíl uživatelů Linuxu aktuálně činí 2,32 %. Nejčastěji používané linuxové distribuce jsou Arch Linux, Ubuntu, Linux Mint a Manjaro Linux. Při výběru jenom Linuxu vede SteamOS Holo s 45,34 %. Procesor AMD používá 75,04 % hráčů na Linuxu.
Blíží se léto, chladiče topí, tranzistory se přehřívají, novinářům pomalu docházejí témata a nastává klasická okurková sezóna. Je tomu tak i mezi bastlíři? Na to se podíváme na Virtuální Bastlírně! Tentokrát se strahováci podívají na zoubek velmi slibně vypadajícímu open-source EDM projektu - ne, nejde o taneční hudbu, ale o elektroobrábění. Ukáží taky, jak vypadá starší cykloradar zevnitř nebo jak se testuje odolnost iPhonů.
… více »Společnosti Ticketmaster byla odcizena databáze s osobními údaji (jméno, adresa, telefonní číslo a část platebních údajů) 560 miliónů zákazníku. Za odcizením stojí skupina ShinyHunters a za nezveřejnění této databáze požaduje 500 tisíc dolarů [BBC].
Byla vydána nová stabilní verze 24.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Uakari. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Byla vydána nová verze 1.48.0 sady nástrojů pro správu síťových připojení NetworkManager. Novinkám se v příspěvku na blogu NetworkManageru věnuje Fernando F. Mancera. Mimo jiné se v nastavení místo mac-address-blacklist nově používá mac-address-denylist.
Před 25 lety, 31. května 1999, započal vývoj grafického editoru Krita (Wikipedie). Tenkrát ještě pod názvem KImageShop a později pod názvem Krayon.
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 . 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…
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.
Ř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: