Po velkém úspěchu prvního MobileLinux Hackdaye se vracíme do Českých Budějovic s druhým ročníkem. V pátek 30. října 2026 od 10:00 se v prostorách Jihočeské univerzity uskuteční Embedded & MobileLinux Hackday #2. Těšit se můžete na témata jako Immutable Linux na telefonech (BengalOS), U-Boot a upstream vývoj, AI optimalizace pro embedded systémy nebo otevřený hardware. Nebude chybět praktické hackování, sdílení zkušeností a možnost … více »
Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »Francouzský výrobce kabelů Nexans upozornil na napjaté dodávky elektrických kabelů. Výstavba nové výrobní linky pro některé typy kabelů může trvat přibližně tři roky. Datacentra potřebují rozsáhlé nízkonapěťové a středněnapěťové rozvody. Poptávka roste současně s modernizací elektrických sítí. Někteří odběratelé proto uzavírají výrazně delší dodavatelské smlouvy [Reuters].
Představena byla (𝕏) virtuální platforma FLYBENCH FPV, která nováčky provede zapojením a konstrukcí dronů.
Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
V implementaci Broadcom 802.11 byla zjištěna chyba ve zpracování WPS/EAP, týká se to SDK od roku 2010. Broadcom podle výzkumníka Quentina Kaisera odmítl CVE přidělit. Modemy Huawei a Technicolor jsou používány i v ČR, v LTE routerech, běžných domácích routerech a firemních přístupových bodech, jejich současný počet a zranitelnost konkrétních verzí však zatím neznáme. Více detailů a demo. GitHub / Broadcom 802.11 SDK Detection Toolkit.
.
Ekvivalentní řešení č. 2, jehož popis je kratší: Alice použije PhoneBook, pod heslem H1 zašifruje zprávu Bobovi, pod heslem H2 zašifruje dílo a přidá nějaký náhodný balast. Výsledek nasdílí. Heslo H2 je velmi krátké.
Došlo k porušení AZ. Jak dokázat úmysl? Pravděpodobností. Je tak strašlivě nepravděpodobné, že po zadání nějakého kratičkého hesla vyleze úplnou náhodou nějaké autorsky chráněné dílo, že to můžeme zanedbat (stejně, jako můžeme zanedbat možnost, že se kvantovými fluktuacemi vakua náhodou zhmotnila kulka a prošla panem Novákem, který šel zrovna na policii nahlásit únos).
jak mi muze nekdo dokazat, ze sem vedel, ze v tom souboru je schovanyho neco zavadnyhoJako že máš v počítači virus, který do fotek, které si stahuješ z digitálního foťáku, automaticky vkládá kousky hudby z CD, které máš v mechanice? Ale to pak taky můžeš říct, že ti tam ten virus vytvořil tu 50GB složku
WAREZ a nasdílel ji přes torrent. Záleží na soudci, jestli tomu uvěří.
Co kdybyste si ten komentář konečně přečetl?To už jsem udělal dávno. Bohužel, ten komentář je naprosto mimo.
Takže Alice zveřejní 700MB soubor, který se dá snadno rozšifrovat na nějaké video, pak zveřejní druhý 700MB soubor, o kterém bude tvrdit, že je heslem k výstupuStále mimo. Alice zveřejní jen jeden 700MB soubor a krátké heslo, přinejhorším podobně dlouhé, jako ona textová zpráva. To krátké heslo je vygenerováno jen porovnáním zprávy a stejně dlouhé (čili krátké) části díla. Co toto heslo udělá se zbytkem těch dat je naprosto irelevantní. Už chápeš?
Obecně pro šifru, kde můžete zaměnit vstup a heslo...což není požadavkem. Ne mým požadavkem.
Pokud použijete krátké heslo, je to důkaz, že ve výstupu je balast.Ne, to teda není. Maximálně to je důkaz, že ta šifra není moc dobrá (jedno heslo použito výcekrát), ale to je tak všechno a ničemu to nevadí. Klidně by mohl zbytek být smysluplný.
Tedy Alice by tím rovnou přiznala, že celé tohleto šifrování je nesmysl, a důležitý byl jen vstupní soubor.Jaký vstupní soubor? Vstupem byla zpráva + sůl.
...což není požadavkem. Ne mým požadavkem.Je to vaším požadavek – nechcete přece heslo hádat hrubou silou.
Ne, to teda není. Maximálně to je důkaz, že ta šifra není moc dobrá (jedno heslo použito výcekrát), ale to je tak všechno a ničemu to nevadí.Pokud použijete šifru, pro kterou platí, že délka vstupu, hesla i výstupu je stejná, a použijete ve skutečnosti různě dlouhá data, je zřejmé, že délka užitečných dat je rovna nejkratší z těch délek, zbytek je pouhý balast.
Klidně by mohl zbytek být smysluplný.To byste ale musel mít heslo stejně dlouhé, jako je vstup a výstup.
Jaký vstupní soubor? Vstupem byla zpráva + sůl.Jaká „sůl“? Nepletete si šifrování s hashováním? To by jako Alice tvrdila, že ke vstupu jen tak úplně zbytečně přidala 699,9 MB náhodných dat, která (spolu s původní zprávou) po rozšifrování „náhodou“ tvoří nějaký film?
Je to vaším požadavek – nechcete přece heslo hádat hrubou silou. Pokud použijete šifru, pro kterou platí, že délka vstupu, hesla i výstupu je stejná, a použijete ve skutečnosti různě dlouhá data, je zřejmé, že délka užitečných dat je rovna nejkratší z těch délek, zbytek je pouhý balast.Ne, to teda zřejmé není. Viděl jsem takové případy použité v praxi. Bijektivní funkce o definičním oboru velikosti 128 bajtů a bylo tím zašifrováno ~20MB užitečných dat. Bylo to v jedné mmorpg hře. Šifra to bezpečná rozhodně není (taky jsem jim to tehdá cracknul
), ale neplyne z toho, že tam je balast a ne data.
To byste ale musel mít heslo stejně dlouhé, jako je vstup a výstup.To by platilo jen v případě, kdybych chtěl z nějakého většího množství náhodných/šifrovaných dat, podobně jako v tomto případě, udělat data nějak smysluplná.
Jaká „sůl“? Nepletete si šifrování s hashováním? To by jako Alice tvrdila, že ke vstupu jen tak úplně zbytečně přidala 699,9 MB náhodných dat, která (spolu s původní zprávou) po rozšifrování „náhodou“ tvoří nějaký film?Zaprvé, po rozšifrování Aliciným heslem z toho film rozhodně nevyleze, nýbrž vyleze z toho zpráva a zbytek je balast nesmyslných čísel, ne film.
Ne, to teda zřejmé není. Viděl jsem takové případy použité v praxi. Bijektivní funkce o definičním oboru velikosti 128 bajtů a bylo tím zašifrováno ~20MB užitečných dat. Bylo to v jedné mmorpg hře. Šifra to bezpečná rozhodně není (taky jsem jim to tehdá cracknulTakže když to otočíte (to je váš požadavek, heslo nechcete hledat hrubou silou, ale spočítat), dostanete ze 128 zašifrovaných bajtů 20 MB užitečných dat. Tomu neříkejte šifra, ale geniální kompresní algortimus, a nechte si to patentovat.), ale neplyne z toho, že tam je balast a ne data.
Zadruhé, ano, Alice k tomu přidala náhodný balast, aby zmátla nepřítele, který by to chtěl rozlousknout.Alice zvolila nějakou primitivní šifru, a pak pro zmatení nepřítele přidala „náhodný balast“, který jakousi zvláštní shodou okolností je filmem zašifrovaným jednoduchým heslem. To si Alice může všechnu tu práci s šifrováním zprávy Bobovi rovnou odpustit a vystavit to zaheslované video rovnou a tvrdit o tom, že je to výstup jejího
/dev/urandom, který ji z nějakého důvodu přišel zajímavý a chce se o něj podělit s ostatními.
Takže když to otočíte (to je váš požadavek, heslo nechcete hledat hrubou silou, ale spočítat)Ne, to není můj požadavek. Pouze tvůj nepravdivý výrok je, že to je můj požadavek.
/dev/urandom
, které označim X. Pak mám text T, který má 20 bajtů. Hledám heslo/bijekci, které mi z dat X vyplivne text T a 80 bajtů balastu. Takové heslo/bijekci jdenoduše spočítám porovnáním 20 bajtů z X s textem T. Že při dalším aplikování z těch 80 bajtů vyleze jakýchsi jiných 80 bajtů mě nezajímá...
Všechno je to v tom zápisku popsaný, ale ty se stejně furt dokola ptáš.Já se neptám. Já jenom upozorňuju, že v tom zápisku jsou některé předpoklady, které jsou při současném stavu techniky nerealizovatelné – a nebo jsou to tak nesmyslné operace, že bude hned jasné, že to byl naivní pokus o zastírací manévr.
V zápisku Odporuje to autorskému právu? jsem se v diskusi dověděl, že je v zásadě jedno, kdo a jakým způsobem ilegálně rozšíří autorské dílo, důležité je, že je možné prokázat, že to udělal se záměrem autorské dílo svévolně šířit.No konecne
Pravo v tomto pripade neni dulezite. Dulezita je anonymita. A poznamka k "Poznámka k realitě" jedine co by s tim mohl kdokoliv udelat je postavit mimo zakon sifrovani.
Tiskni
Sdílej: