Příspěvky

316

Odkladiště / Re:Vaše největší přehmaty?

« kdy: 04. 10. 2018, 00:55:46 »

Potřebuju restartovat server. Připojím tedy notebook přes Wi-Fi hotspot a slabý mobilní signál na Internet. Na notebooku jen napíšu „ssh user@server“ a hned potom „sudo reboot“. SSH se začne připojovat na server, „sudo reboot“ zatím zůstává v bufferu, aby se poslalo po připojení. Chvilku tedy čekám, pak slyším bell sound (zřejmě timeout SSH spojení) a vidím, jak se mi restartuje notebook. No, holt „sudo reboot“ se z bufferu vysypalo trošku jinam…

Z jednoho startupu: Jedeme prezentovat, co jsme udělali za poslední sprint. Kolega ve vlaku najde ve zdrojácích nějakou totální blbost, já to opravím a do commit message dám zhruba „fixed some shit“. No, běžně zadavateli neukazujeme zdrojáky (nechtěl si je prohlížet), ale zrovna tehdy někdo otevřel „git log“ na velké obrazovce a můj commit byl samozřejmě nahoře. No, zasmáli jsme se a šlo se dál…

317

Odkladiště / Re:Vaše největší přehmaty?

« kdy: 30. 09. 2018, 21:10:29 »

Nejhorší těžko říct (obvykle se podařilo škody nějak napravit nebo nebyly velké), ale pár veselých historek mám… Některé jsou už poněkud staré (snad všechny ze studentských let) a byly mi zdrojem poučení…

Dělal jsem takový poloautomatický import dat z doc do DB. Data byla celkem pravidelně nastrukturovaná (nic extra složitého), ale občas byla nějaká výjimka, psal to člověk, znáte to… Hledal jsem nějaké špatně importované záznamy. Byl jsem v konzoli. Byl jsem líný napsat dotaz od nuly, tak jsem si řekl, že si to „select * from tabulka where “ vyberu z historie. Učinil jsem tedy tak, dopsal správnou podmínku, stiskl enter, a … a zjistil jsem, že to nebylo „select *“, ale „delete“. Lenoši se nejvíc nadřou…

Otevřel jsem si vedle sebe produkční DB a testovací DB, importoval data (nějaké články apod., nic extrémně citlivého) do testovací DB. V testovací DB jsem pak zkoušel „pocuchat“ jeden článek a zkoumat, jak si s tím DB poradí. V testovacím prostředí se ale nic neměnilo…

V jednom předmětě, který se netýkal bezpečnosti, jsem zkoušel SQL injekci na webovou aplikaci, kterou jsme k tomu měli. Nenapadlo mě nic chytřejšího než zakomentoval zbytek SQL dotazu… jenže to byl UPDATE a já zakomentoval WHERE. Následně jsem se vyučujícím omluvil, popsal problém a prošlo to bez postihu. Od té doby mám ale větší respekt z testování na ostrých datech a ostrých serverech.

Na QubesOS je u některých druhů virtuálních strojů (template-based VMs) potřeba přebindovat některé adresáře (např. /var/lib/mysql) do /rw, jinak data nezůstanou po restartu. Tehdy na to ještě nebyl speciální mechanismus, tak jsem měl nějaký skript spouštěný při bootu, něco ve stylu rm -r /var/lib/mysql && mkdir /var/lib/mysql && mount --bind /rw/mysql /var/lib/mysql && systemctl start mysql. Fungovalo to krásně, ale jednou jsem ten skript upravoval a nenapadlo mě nic lepšího než ho spustit celý znovu… Od té doby se snažím mít podobné skripty pokud možno idempotentní, nebo aspoň ne tak destruktivní v neobvyklých situacích…

318

Vývoj / Re:Riemannova hypoteza

« kdy: 29. 09. 2018, 22:46:51 »

Co jsou ta „ta už získaná“ prvočísla?

Ad času máme dost – OK, zkuste tedy nějak zhruna vyčíslit, kolik času budete potřebovat. Můžete třeba vzít stonásobek výkonu BTC sítě (to je výkon, jaký člověk jen tak nezíská) a spočítat, jestli se toho vůbec dožijete.

Jinak jestli jde o útoky na chybně implementované generování klíčů – tam to smysl mít může. Ale tam asi nebudete potřebovat vědět nic detailnějšího o struktuře prvočísel…

K tomu počtu prvočísel na milionu HDD: Zdálo se mi to nějak málo, tak jsem to překontroloval, a zapomněl jsem to vynásobit tím milionem, výsledek je tedy pro jeden disk. I tak je to „jen“ něco přes 2^57. Pokud bychom zvali návrh od aaa, dostali bychom se tak na 2^60 prvočísel.

V neposlední řadě: I kdybychom čistě teoreticky zvládli uložit všechna potenciálně relevantní prvočísla (takže bychom do jedné elementární částice jich asi museli uložit několik), co s tím dál? Projít to jedno po druhém a všechna vyzkoušet? Good luck, výsledku se nedožijete. (To není výhružka, jen konstatování časové náročnosti.) Ani teď nevím, jestli procházení prvočísel bude efektivnější čtením z HDD, nebo generováním dalších a dalších prvočísel on the fly.

Přínosy seznamu prvočísel jsou totiž hrozně diskutabilní. Šlo by snadno zjistit, kolikáté prvočíslo v seznamu je N (a naopak, kolik je n-té prvočíslo v seznamu je), otázka ovšem je, k čemu by to bylo prakticky. A jinak přínos pro kryptoanalýzu RSA moc nevidím.

319

Vývoj / Re:Riemannova hypoteza

« kdy: 29. 09. 2018, 13:33:06 »

Budu-li mít k dispozici milion disků o 20 TiB, uložím tam něco přes 2^37 prvočísel o délce 1024 bitů, pokud budu počítat, že první a poslední číslice ve dvoujové soustavě je jednička, a tedy by mi stačilo 1022 bitů na prvočíslo. Spočítáno jako log[2](8*20*1024^4/1022). To je dost málo. Mám trochu tušení, že tolik prvočísel bych s dobrou entropií na svém starém počítači prošel v řádu dní, a nepotřebuju úložný prostor. Aspoň tak nějak mi to na starém notebooku vycházelo v Javě přes něco jako BigInteger.probablyPrime se SecureRandom nebo tak něčím, bez speciálních optimalizací.

Ano, nějaká malá prvočísla vyřadíme, myslím, že těch 7/8 je dostatečně pesimistických. O čísel kongruentních s 1 (mod 3) nevím – pokud takováto pravidla znáte, sem s nimi, mohu je započítat. Samotné toto pravidlo by vyřadilo hádám polovinu prvočísel (pokud kongruence s (mod 3) je mezi prvočísly rovnoměrně rozložena mezi 1 a 2). Nemyslím si, že bychom se dostali pod 2^1000 použitelných prvočísel, což je pořád dost.

Pozná…ka o enyropii je dobrá. A hlavně je to další argument, proč spoléhat se na pomalé procházení prvočísel ke rozbité již dnes – útočník při procházení všech možností nepotřebuje generovat dost entropie.

Terminilogický detail: i čísla začínající nulou mohu řadit do 1024-bitových, proto 2^1024. Druhá věc je, že tato čísla nejspíš vyřadím jako příliš malá…

320

Vývoj / Re:Riemannova hypoteza

« kdy: 29. 09. 2018, 10:01:30 »

Tak znovu: u RSA klíčů máme v případě RSA-2048 (dnes decentní volba, doporučení to už ale začínají tlačit k delším klíčům) na výběr řádově 2^1014 prvočísel. I kdybychom třeba 7/8 z různých důvodů (příliš krátká) vyřadili, máme jich pořád asi 2^1010.

Pro srovnání:

* Částic ve viditelné části vesmíru se odhaduje na 10^86 ≈ 2^286. Hodně štěstí s ukládáním všech známých prvočísel.
* AES má podle varianty 2^128 až 2^256 možných klíčů. Nepovažuje se za příliš praktické vygenerovat náhodný AES klíč a zkoušet, jestli nebude někde sedět. Ale asi by to bylo praktičtější než zmíněné kejkle s prvočísly na RSA.
* Pravděpodobnost, že na mě spadne meteor, si můžete dohledat za domácí úkol. Asi bude vyšší než crack AES-128. Tím nechci šířit poplašnou zprávu…
* Pravděpodobnost výhry v loterii taktéž. Tím ale nechci. Nabádat k žádnému sázení…


Pokud se někomu skutečně povede najít nějaké recyklované prvočíslo, bude to tedy nejspíš znamenat nějakou implementační chybu – například příliš zúžený okruh hledání prvočísel (např. ROCA*) nebo malá entropie (např. ~10 let stará kauza sdílených prvočísel u embedded zařízení).

*) V tomto případě došlo k oslabení kryptografie a možnému prolomení, ale nejsem si jist, jestli až tak, že by v praxi docházelo ke znovupoužití prvočísel. V principu ale takové zranitelnosti mohou k tomu vést.

321

Vývoj / Re:Riemannova hypoteza

« kdy: 28. 09. 2018, 22:03:05 »

Kdybychom mohli projít seznam prvočísel rychle (ve smyslu máme vzoreček pro výpočet příštího prvočísla vyčíslitelný za pár taktů CPU), ještě to nic neznamená. Když budu uvažovat RSA-2048, mám 2048b modulus, který je součinem dvou prvočísel o délce cca 1024b. Počet prvočísel zde lze odhadnout na 2^1024/(ln(2^1024)-1), což mi kalkulačka nepobrala, ale dá se to zjednodušit, že cca každé (ln(2^1024)-1)-té číslo v tomto intervalu je prvočíslo. Sice ani ln(2^1024)-1 mi kalkulačka nepobrala, ale když jsem to zjednodušil na 1024*ln(2)-1, dostal jsem, že cca jedno ze 709 čísel je v tomto intervalu prvočíslo. To jsem zaokrouhlil na 1024 a došel jsem k výše uvedenému odhadu 2^(1024-10)=2^1014 prvočísel v tomto intervalu. Řekl bych, že ani dnes není problém v tom, že bychom neuměli dostatečně rychle prvočísla procházet, jako spíš s tím, že je jich prostě moc. Hrubou silou to při jakkoli efektivním způsobu procházení prostě neprojdete. Pro srovnání: AES staví mj. na tom, že neprojdete všech jeho 2^128 až 2^256 (podle varianty) klíčů. To je o poznání méně než počet prvočísel v uvažovaném rozsahu.

Jestli to zefektivní nějaký jiný algoritmus lámání RSA – možná ano, čekal bych ale spíše zlepšení nějakých faktorů, rozhodně ale od toho nečekám polynomiální složitost. Prakticky to znamená, že čekám spíše přinejhorším nutnost používat delší klíče v RSA než kompletní průlom RSA.

A i kdybychom měli průlom RSA, není to dnes nenahraditelný algoritmus… Náhrady se hledají asi spíše z jiných důvodů – rychlost, délka klíče nutná k zajištění dané úrovně bezpečnosti a kvantové počítače.

s: Ale vždyť to používání známých prvočísel vyvracím.

322

Vývoj / Re:Riemannova hypoteza

« kdy: 28. 09. 2018, 19:07:53 »

Poněkud mě překvapila hypotéza, že se pro kryptografii používají známá prvočísla. Předpokládám, že tím bylo myšleno RSA, které je asi nejpopulárnějším kryptoalgoritmem založeným na prvočíslech a kde je případný snadný prvočíselný rozklad problémem. Jenže tam případná znalost jednoho z prvočísel útočníkem je průšvih samo o sobě.

Co si vzpomínám, tak se běžně používají na hledání prvočísel různé triky, takže se nepoužije celý ≈ 2^1014 prostor pro prvočísla k RSA-2048, ale jen nějaký zúžený. Alr i ten zúžený může být pořád dost velký. Konkrétní varianta zjednodušení může mít nějaké zranitelnosti (vzpomeňme si na ROCA), případně nějaké charakteristiky (tým zabývající se ROCA předtím AFAIR dovedl odhadnout, čím byl daný klíč vygenerován).

Jestli případný důkaz pomůže omezit prostor, kde hledat jedno z těch prvočísel – asi moc ne. Velikost toho prostoru těžko bude převapením pro lidi, kteří řeší to hledání prvočísel, ono se to zákonitě musí nějak projevit do statistik, za jak dlouho to prvočíslo najdu. Což má vliv i na výkon.

Jestli případný důkaz přinese něco jiného, co nám zboří RSA nebo jinou část kryptografie – to je tak obecná otázka, že by bylo pošetilé odpovídat jednoznačně „ne“. Ale nějaký velký strach z toho nemám.

323

Vývoj / Re:Staticky typovaný skriptovací jazyk pro rok 2018

« kdy: 28. 09. 2018, 10:48:32 »

Bash jsem zde rozhodně nedoporučoval původními tazateli, jen mi to zrazování od Bashe (implicitně obsažené v „opravdu chces nekomu v zari 2018 doporucovat Bash“) přišlo příliš kategorické. Bash stále má svoje místo a nezatracoval bych ho kategoricky, asi to ale není to, co tazatel hledá.

Popravdě stále moc nevím, co tazatel hledá. Vím, že chce rychlý startup time (zmiňoval jako nevýhodu Javy), statické typování, multiplatformnost a má nějaké požadavky na syntaxi. Kompilace mu zřejmě nevadí (vizte zmínky o Javě v úvodním příspěvku) a není mi úplně jasné, co má být na takovém jazyce „skriptovacího“. Asi chce něco spíše high-level. Jak moc to má být funkcionální/objektové/whatever moc nespecifikoval.

324

Vývoj / Re:Websocket vs. REST

« kdy: 27. 09. 2018, 22:13:42 »

Jsem pro použití RESTu tam, kde máme požadavek/odpověď:

1. REST je na to dělaný, u WS si to musíte implementovat. Proč implementovat něco, co mohu mít „zadarmo“?
2. HTTP má několik mechanismů pro cacheování, které můžete využít. Třeba u historie se nabízí If-Modified-Since. Máte připravené hotové mechanismy i jejich implementaci.

Udělat to přes WebSockety – pro edukativní účely klidně, můžete třeba zkusit implementovat odesílání obrázku – a pak řešit, jak velkým obrázkem na pomalé lince nezablokovat ostatní věci. Do produkce by ale musel být nějaký dostatečně silný speciální důvod to udělat takto.

325

Vývoj / Re:Staticky typovaný skriptovací jazyk pro rok 2018

« kdy: 27. 09. 2018, 21:57:13 »

No, Bash… Je to dost specifický jazyk. Některé věci vněm jdou úžasně jednoduše, jiné pekelně složitě, a u některých je někdy trochu problém to udělat dokonale (např. počítat s mezerama nebo zpracovat chyby). Už jsem v tom dělal i paralelismus, jde to, ale není to ono.

Celkově bych řekl, že se Bash vyplatí znát, ale zároveň znát jeho limity a mít představu, kdy je chodné jej použít a kdy ne. Rozhodně bych ho ale nebral jako univerzální jazyk se širokým záběrem.

326

Vývoj / Re:Staticky typovaný skriptovací jazyk pro rok 2018

« kdy: 23. 09. 2018, 22:00:29 »

Neexistuje type inference, o které by člověk ani nevěděl. Maximálně do doby, kdy píše všechno správně. Jakmile něco napíšu špatně, pak čím silnější inference, tím větší šance na WTF chybové hlášky. Pamatuju si to z Haskellu. Proto jsem spíše zastáncem slabší inference za cenu občasné nutnosti typ uvést explicitně.

327

Vývoj / Re:Staticky typovany skriptovaci jazyk pro rok 2018

« kdy: 23. 09. 2018, 15:26:55 »

Neznám úplně váš scénář použití, ale pokud je jediný problém Javy její startup time, nabízí se použít Javu a vyřešit problém se startup time. Možnosti jsou různé:

a. Použít Nailgun.
b. Použít jinou JVM.
c. Omezeně: použít native-image z GraalVM – toto je zatím dost omezené (např. na Windows s tím zatím nepochodíte a někdy kompilace selže bez vysvětlení), ale je dobré to mít v hledáčku. Časem se snad dnešní problémy vyřeší.

Další možnost je kompilace do nativního kódu u .NETu, ať už pomocí Mono (IMHO celkem hotové již dnes), nebo pomocí .NET Core (kde ale nemám zkušenost, jen vím, že to jde).

328

Odkladiště / Re:Odesílání přílohy v mailu sežere dvojnásobek dat

« kdy: 19. 09. 2018, 08:24:27 »

Původní dotaz nezmiňuje použitý protokol ani e-mailového klienta ani server. Podle dalšího dotazu to vypadá na SMTP+IMAP – to skutečně může znamenat dvojí nahrání. Ale nemusí. Některé servery (např. GMail) ukládají do Sent mail automaticky. Pak je ovšem potřeba tuto funkcionalitu vypnout na klientovi, aby se to neukládalo dvakrát. Takže doporučuju zkontrolovat nastavení klienta a složku Sent. Případně se podívat, jestli klient nezaložil náhodou ještě druhou Sent.

Ze síťového provozu by to mělo jít odhadnout – SMTP a IMAP běží na jiný portech.

Pokud by to ale bylo kombinací SMTP+IMAP, pak je divné, že se to nafoukne *jen* dvakrát – vizte base64 a quoted printable. Ledaže by šlo o tak velký plain text, ale to u ~ 8BM souboru nečekám. I když, GCO nebo STL klidně může…

329

Software / Re:Google chce zabít URL

« kdy: 17. 09. 2018, 20:19:22 »

Diakritika v URL jsopu ve sakutečnosti dvě věci:

1. Dekódování procentové notace v adrese (částečné).
2. IDN

Dekódování procent je IMHO relativně nekontroverzní – není tu moc prostor k IDN homograph útoku. Byly tu v minulosti útoky spojené s RTL, případně někde šlo použít 🔒. Kontroverzní je IDN, která otevírá prostor k homograph attacku, protože se zpracovává na úrovni domén, které fungují jako hlavní identifikátor webu.

330

Server / Re:Jak dokumentujete servery?

« kdy: 30. 08. 2018, 22:29:42 »

Spustitelná dokumentace v Ansible/Salt/Chef/whatever je základ, v jednodušších případech může stačit. Spustitelná dokumentace má tu výhodu, že je mnohem jednodušší zajistit, aby seděla s realitou. Někdy se hodí přidat i nějaké readme nebo wikistránku s textovým popisem. Ten by neměl být extrémně podrobný (pokud každá změna v konfiguraci vyvolá změnu v readme, je něco špatně), spíš poskytnout takový big picture.  Může odpovídat na otázky jako „proč je DB server separátní“, „na kterém serveru hledat komponentu XX a proč”,  „proč používáme komponentu YY a ne ZZ” a spoustu jiných věcí. Kdy je tam toho dost – těžko obecně říct, je to ale možné vyzkoušet: dejte kolegovi (ideálně nově příchozímu) dokumentaci a ověřte si, že se v ní vyzná.

Proč ne podrobné readme? Jednak je zbytečně náročné to udržovat, ale to ve výsledku není to nejhorší. Horší je, že pak dříve nebo později readme přestane odpovídat realitě pak už jsme jen krůček od toho, aby dělalo více škody než užitku. Neaktuální dokumentace je někdy horší než žádná, protože mate lidi.