Diit.cz - Novinky a informace o hardware, software a internetu

Diskuse k Oracle představil 32jádrové procesory SPARC M7 s 256 vlákny

Len drobnosti.

8xHT? Jedná sa o Oracle a tam by sa patrilo hovoriť o SMP (keďže to nieje Intel). Btw. Oracle (Sun) prvý krát použil SMT8 už asi pred desiatimi rokmi ;)

A na obrázku je SMP32 ale v článku "len" SMP16. Ktoré z tých čísiel je správne?

+1
-5
-1
Je komentář přínosný?

Hardwarovou podporu DES těžce nechápu. DES je už dávno za zenitem, je snadno prolomitelný a oproti AES děsivě pomalý. Hardwarově se dá naimplementovat přímo 3DES (stačí jen drobně modifikovat DES), který je pořád strašně pomalý, ale v současné době je alespoň bezpečný.

Ale stejně to nechápu, proč by dnes někdo sakra používal DES. Kvůli zpětné kompatibilitě? To asi těžko, AES tu je od roku 2002.

Také nechápu, proč se chlubí podporou SHA, které je také prolomitelné. Ve výsledku půjde použít pouze jako kontrola integrity dat, ale nikoli na zabezpečení.

Daleko zajímavější je, co chybí - a to sice zmínka o podpoře HW optimalizace RSA a DSA, což SPARC minulé generace měly.

+1
-10
-1
Je komentář přínosný?

Vycuc z datasheetu:

Thirty-two on-chip encryption instruction accelerators with direct nonprivileged support for 15
industry-standard cryptographic algorithms: AES, Camellia, CRC32c, DES, 3DES, DH, DSA, ECC,
MD5, RSA, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 (one per core)

+1
0
-1
Je komentář přínosný?

No, nejsem teda žádny kryptolog, ale 3DES je podle mě 3xDES, takže pokud něco akceleruje DES, tak 3DES k tomu má automaticky zdarma. Co se týká SHA, tak IMHO (moc to nesleduju) jsou problémy jenom s SHA-1, která ale používá stejné algoritmy, jako SHA-2, která se ale zdá být zatím v pořádku - pokud se teda něco takového dá říct o funkci z dílny NSA.

Jinak ještě taková poznámka - samotné oslabení SHA-1 ještě neznamená, že je obecně nebezpečné ji použít, záleží na kontextu. Jako příklad uvedu generování hesel programem passwd, který - i přes perfektní práci Vlastimila Klímy na oslabení MD5 - stále zůstává stejně bezpečný kvůli tomu, jakým způsobem je MD5 využita. Takže "rozbitá" šifrovací nebo hashovací funkce s námi může být klidně další desetiletí a tudíž má stále smysl ji v procesoru implemetovat.

+1
+2
-1
Je komentář přínosný?

Ano, v podstatě to je 3x DES, ale to, že do procesu šifrování bude sahat software (tzn. říkat zašifruj, výstup rozšifruj jiým klíčem a zašifruj dalším klíčem) vede ke zpomalení. Rozlousknutí DES je otázkou několika dní a využití strojového času za pár tisíc $. Tedy nic nedosažitelného.

SHA1 využívá jiné algoritmy než SHA2. O zranitelnosti SHA1 se ví minimálně 10, až tento rok byla vyčíslena cena útoku na $ 100 000, tedy dosažitelná cena. SHA1 je pro bezpečností funkce již nevhodná. Její použití je vhodné maximálně na kontrolu integrity dat.

O jakém passwd se to bavíme? Ten unixový používá SHA512.

A poslední omyl, který musím vyvrátit, SHA není z dílny NSA. Standardizoval NIST, NSA pouze dodala jednu úpravu, která vedla ke zvýšení bezpečnosti.

Obecně všechny teorie o tom, jak je AES a SHA prolezlé backdoory NSA je úsměvné. Vždyť samotná vláda USA používá pro přísně tajné dokumenty AES.

+1
+2
-1
Je komentář přínosný?

Passwd může používat kde co, nastavuje se to v konfiguraci. Technicky vzato se používá funkce crypt, u které současný stav MD5 nevadí.

+1
+6
-1
Je komentář přínosný?

Ne, default je SHA512.

+1
-8
-1
Je komentář přínosný?

edit: odpoved mala byt na komentar hore od "jsem Zpet" :

1) v mnohych enterprise systemoch sa 2002 povazuje za "nedavno". Cudovali by ste sa kolko bankovych systemov este stale bezi na programoch napisanych v COBOLe.
2) Dalsi dovod moze byt to, ze DES pouziva rovnake matematicke funkcie ako ine sifry, takze takmer zadarmo mozu pridat dalsiu polozku do zoznamu podporovanych sifier.

+1
+1
-1
Je komentář přínosný?

1) O tom, že je DES prolomená se ví ještě déle. Děsí mě, že těch "mnoho" enterprise systémů ještě DES používá.
3) Právě že ne, DES je na fundementální instrukce více náročná. Proto je složitější ji Hardwarově akcelerovat.

+1
+1
-1
Je komentář přínosný?

DES není ani tak moc prolomená, jako spíš moc jednoduchá. (V praxi není zjednodušený útok proveditelný, protože klíče se zpravidla při komunikaci nějakým dalším kanálem periodicky mění.)

+1
+13
-1
Je komentář přínosný?

>DES není ani tak moc prolomená, jako spíš moc jednoduchá.

No a právě proto je prolomitelný. Kromě té jednoduchosti, která spočívá v použití pouze 56 bit klíčů má algoritmus i jiné slabiny, díky čemuž má útok složitost o hodně nižší než teoretických 2^56.

>V praxi není zjednodušený útok proveditelný, protože klíče se zpravidla při komunikaci nějakým dalším >kanálem periodicky mění.

Ne, je prolomitelný velmi lehce, akorát budu muset luštit každou zprávu zvlášť. Ve svém původním odhadu jsem se spletl, na lousknutí DES není potřeba několik dnů, ale pouze jeden jediný (to platilo v roce 2008), takže dnes to budou maximálně hodiny.

Dnes už prostě není důvod, proč šifrovat pomocí DES. Buď použiju 3DES a nebo ještě lépe AES.
Pro používání DES není důvod. Buď chci aby byla data tajná a nebo mi to je jedno.

+1
+13
-1
Je komentář přínosný?

Bezpečnost šifry může být dostatečná i v případě, kdy na prolomení potřebuješ hodinu. Pro určité aplikace stačí, aby přežila třeba jen 5min.

+1
-6
-1
Je komentář přínosný?

A vy snad víte, jak dlouho trvá prolomení DES? Běžný člověk si to může zaplatit pár tisíci $ a bude to v řádu hodin. Jak dlouho to bude trvat NSA, která už zcela jisté má několikátou generaci hardwarového DES crackeru?

Proč by se někdo choval tak nezodpovědně, že by spoléhal, že šifra nebude prolomena určitou krátkou dobu. Může použít silnější šifru, kterou bude možné prolomit až za několik desítek/stovek/tisíců/milionu/miliard let. Dalo by se to pochopit, pokud by DES přinášela výhody v jednoduchosti a nebo rychlosti. DES je pomalá a z hlediska fundamentálních operací složitá.
Zpětná kompatibilita je také pěkný kec. DES je 40 let starý algoritmus. Minimálně 20 let se ví, že jde relativně jednoduše prolomit.
Asi jenom naprostý diletant by ji dnes, v roce 2015 použil.

Mimochodem zajímal by mě příklad konkrétní aplikace, kdy stačí, aby šifra přežila 5 minut.

+1
-7
-1
Je komentář přínosný?

Například pro příkaz zařízení, které něco udělá. Za 5 minut je to už irelevantní, protože dokonáno jest.

+1
-2
-1
Je komentář přínosný?

Jenže z 5ti minut se během krátké doby díky nasazení efektivnějšího crackovacího zařízení může stát pouhá sekunda, což v případě útočníků typu NSA znamená, že jsou schopni dešifrovat provoz v reálném čase a nebo ho dokonce měnit bez toho, aby si toho kdokoliv všimnul.

Přestože je DES 40 let starý, není tento algoritmus, prolomený, data není možné jednoduše dešifrovat bez vyzkoušení všech možných klíčů. Problém DESu spočívá pouze v tom, že jeho klíč je příliš krátký, takže počet všech možných klíčů je na dnešní dobu poměrně malý (2^56). 3DES už tento problém nemá, z kryptografického hlediska je stejně bezpečný jako AES.

+1
+7
-1
Je komentář přínosný?

@Jack FX

Prolomený (=rozbitý) šifrovací algoritmus je takový, který umožňuje provedení útoku mnohem větší rychlostí než brutal force. Brutalforce na DES má složitost 2^56. Složitost lze pomocí pokročilé kryptoanalýzy snížit na 2^40 a při znalosti plaintextu a nebo při možnosti chosen plaintex attack se dostáváme podle implementace DES v krajním případě až na 2^30. Také dost závisí na síle klíčů.

Ostatně i některé implementace AES jsou rozbité (slabé klíče a implementace s méně jak 14 iteracemi). Složitost pokročilých kryptoanalytických útoků vůči AES je téměř stejná jako brutal force.

>Problém DESu spočívá pouze v tom, že jeho klíč je příliš krátký
Ne, to není zdaleka jediný problém DES.

>3DES už tento problém nemá, z kryptografického hlediska je stejně bezpečný jako AES.
To ani náhodou. 3DES, v nejběžněji používané variantě s 112 bit klíčem není ani zdaleka tak bezpečný jako AES.

+1
+13
-1
Je komentář přínosný?

Jistě, ale pak nesplňuje podmínku odolnosti 5 minut a je potřeba volit něco jiného. Nicméně ani to nemusí být nutně problém.

Prolomení je jedna věc, pochopení obsahu je druhá a zfalšování třetí. Ta dešifrovaná zpráva nemusí mít žádný relevantní obsah mimo toto např. 5 minutové časové okno. Dalším faktorem je fakt, že ani NSA nemůže sledovat vše.

Jinak souhlas.

+1
-11
-1
Je komentář přínosný?

Zkusím to vysvětlit jinak - louskání DES spočívá v tom, že si jistými matematickými anelytickými postupy vyberu skupinu možných klíčů, které pak všechny, jednoho podruhém budu zkoušet, dokud se mi zpráva nepodaří rozšifrovat. Jednak zjistím obsah šifrované zprávy, ale také zjistím klíč.

Konkrétně, já pošlu například unixovému stroji zašifrovaně například "reboot". Unixový stroj to rozšifruje klíčem, který jsem mu nastavil (stejný klíč, kterým jsem příkaz šifroval) a pokud dává příkaz po rozšifrování smysl, provedeho. To je hodně blbá forma autentizace, která je reálně nepoužitelná, ale pro příklad můžeme použit. Reálně by to bylo trošku jinak, ale princip napadení DES je pořád stejný.

NSA po pár hodinách zjistí, že jsem poslal "sudo reboot" a že shoda byla nalezena pro klíč například 0x6865736c6f3031. NSA vezme klíč, zašifruje s ním příkaz "install nsa_rootkit", odešle na stroj a stroj ho provede, protože po rozšifrování je příkaz syntakticky správně.

Tady nejde o NSA. To je pouze příklad. Může to být kdokoli. Pointa je v tom, že když něco potřebuju šifrovat, tak to dělám pořádně. K použití DES není jediný důvod. Je to nebezpečná, pomalá a složitá šifra.

+1
+3
-1
Je komentář přínosný?

To je hodně naivní.

Zaprvé je problém s tím, že všechny klíče fungují, takže pokud pošlu "sudo reboot", tak při zvolení náhodného klíče může vyjít i "jsem jelito" (délka zprávy je stejná) a pro útočníka není jasné, jestli jsem poslal zprávu "sudo reboot" nebo "jsem jelito".

Zadruhé pro oslabení DESu je potřeba mít tuším 2^47 zpráv, což blbost - každý správný protokol by měl měnit klíč, takže takové množství zpráv pro jeden klíč nikdy nezískám a i kdybych lousknul kus komunikace, tak mám jenom ten jeden historický kus a nemůžu do komunikce vložit "install nsa_rootkit", protože servery už mají dávno domluvený jiný klíč.

Poznámka o těch pěti minutách tady platí perfektně - pokud je mým cílem, aby nikdo nemohl efektivně pozměnit mou komunikaci se serverem, ale je mi v podstatě šumák, jestli si to někdo přečte, tak je DES úplně OK.

+1
-9
-1
Je komentář přínosný?

To se mu snažím marně vysvětlit.

Když si to pak přečtou tak dostanou např. toto:

01011111011001000111+crc

Tato informace je bezcenná, protože tam pak přijede technik a po opravě změní klíč. Samozřejmě IP, které hádají jsou následně blokovány.

+1
-13
-1
Je komentář přínosný?

>To se mu snažím marně vysvětlit.
Snažíte se, ale nejda vám to. Čím dál více se zamotáváte.

>Tato informace je bezcenná, protože tam pak přijede technik a po opravě změní klíč.
Ano, techniku bude běhat každou hodinu a měnit klíče. To je velmi účinné, flexibilní a hospodárné.

Váš přístup by byl zcela špatný i v případě, že by použití DES bylo bezpečné.

Pokud se jedná o situace, kdy stačí jednou poslat příkaz, jehož obsah není tajný nebo nelze pochopit jeho význam, pak je šifrování zbytečné.
Pokud je třeba zajistit autentizaci (primitivně) a integritu zprávy, použije se MAC.
A pokud je třeba zajistit integritu a utajení, tak by se komunikující strany neměly autentizovat pouze schopností číst šifrovaná data, jelikož to je nesmysl a potencionálně nebezpečná věc.

+1
-10
-1
Je komentář přínosný?

Vy jste prostě marný.

+1
+5
-1
Je komentář přínosný?

Došly argumenty?

+1
+4
-1
Je komentář přínosný?

Já ho chápu a obdivuju svou trpělivost, že pořád ještě píšu k věci. :-)

+1
-9
-1
Je komentář přínosný?

No zatím to vypadá tak, že jsem panu naithovi vyvrátil všechny jeho mylné argumenty a on pořád jenom kličkuje.

+1
+2
-1
Je komentář přínosný?

>Zaprvé je problém s tím, že všechny klíče fungují, takže pokud pošlu "sudo reboot", tak při zvolení >náhodného klíče může vyjít i "jsem jelito" (délka zprávy je stejná) a pro útočníka není jasné, jestli jsem >poslal zprávu "sudo reboot" nebo "jsem jelito".

Ehm, pane kolego, mýlíte se. Můžete si to sám vyzkoušet. Najděte si kryptografickou knihovnu s DES, aby to mělo smysl, tak použijte čistou implementaci kryptografické funkce, takovou, která vezme plaintext a na základě klíče ho zašifruje (žádné přidávání hlaviček do zašifrovaného textu). Pozná te to tak, že plaintext, který má menší velikost, než je velikost bloku šifry (v případě AES to je například 16B) bude mít jako zašifrovaný text velikost jednoho bloku (zmíněných 16B v případě AES).
Zkuste si zašifrovat text a poté ho rozšifrovat chybným klíčem. Zkuste a uvidíte...

>Zadruhé pro oslabení DESu
Opět se pletete. DES je rozbitý, jelikož existují útoky mnohem efektivnější než brutal force. Jde hlavně o to, že DES generuje slabé podklíče.

>protože servery už mají dávno domluvený jiný klíč.
A ten si domluví jak?

>aby nikdo nemohl efektivně pozměnit mou komunikaci se serverem, ale je mi v podstatě šumák, jestli >si to někdo přečte, tak je DES úplně OK.

Není to OK, protože používáte symetrickou šifru na něco, na co je blbost ji používat. Pokud nepotřebuji komunikaci tajit, ale chci zajistit integritu a autentizaci, tak použiju MAC.
To je jako zatloukat hřebíky šroubovákem.

+1
-5
-1
Je komentář přínosný?

Své znalosti zakládám víceméně na okraovém sledování těchto témat a kontrole na Wikipedii, ale mám za to (a Wikipedia to potvrzuje), že pro DES dnes neexistuje žádný použitelný útok, který by měl lepší složitost, než brute force, tedy 2^56.

Jsou posány jenom útoky, u kterých musím mít k dispozici 2^43 (v nejjednodušším případě) zpráv v otevřené a zároveň zašifrované formě, z čehož umím efektivně získat ten 56bit klíč, ale toto je v praxi většinou víceméně k ničemu. Ne úplně - možná umím nějak donutit některou stranu, aby odvysílala takové obrovské množství zpráv, jejichž nezašifrovaný obsah já - jako útočník - znám. Můžu například mít čistě teoreticky něco jako SMTP server (nebo file server), do kterého láduju horem spodem mail / soubor (jehož obsah tím pádem znám), on jej šifruje a odesílá na jiný server a já si umím odychtit tu komunikaci a mám tudíž nezašifrované i zašifrované zprávy a ten klíč potom získám.

V praxi je ale i tato vlastnost úplně k ničemu, protože (jak se píše jinde tady v diskusi) se v normálních protokolech normálně klíč pro symetrickou šifru vygeneruje na začátku spojení (je pro každé spojení unikátní) a v tom daném spojení se časem mění, takže takový počet zpráv stejně nikdy nezískám a i kdybych získal (jakože opravdu nezískám :-), je mi klíč většinou k ničemu, protože jiná spojení toho daného serveru použijí jiné klíče.

Můžou být výjimky, například OpenVPN s Pre-shared klíči (od nichž manuál z tohoto důvodu varuje) může být teoreticky takto napadnutená, tam se klíč nemění.

Jinak s tím zašifrováním, co si mám zkusit - zkusil jsem to, zašifroval si něco, rozšifroval to špatným klíčem, vypadl mi binární binec. Nějak nevím, co by na tom mělo být překvapivého - možná to, že ta šifra opravdu funguje jenom se správným klíčem a pokud zadám špatný, tak mi vypadnou "náhodná" data. Jestli to mělo být o tom, že data musí mít velikost bloku - ano, musí, velikost rozšifrovaných dat je taky zaokrouhlená nahoru na velikost bloku, ten text se v naivním případě doplní do velikosti bloku ještě před zašifrováním nulami, v praxi pak spíš náhodným šumem.

+1
-6
-1
Je komentář přínosný?

Existuhje spousta systémů, které žádné FS nemají a dohoda na klíči pro symetrickou šifru se provádí pomocí zašifrování náhodně zvoleného řetězce veřejným klíčem serveru. To jenom tak na okraj.

Řeč byla ovšem o malých jednoduchých zařízeních, které nejspíš nebudou mít dynamicke měněné klíče.

Prostě a jednoduše, neexistuje rozumný důvod, proč používat DES.

>Jinak s tím zašifrováním, co si mám zkusit - zkusil jsem to, zašifroval si něco, rozšifroval to špatným >klíčem, vypadl mi binární binec.

Mohl byste mi popsat metodiku? Ideálně příkazy, kterými jste to dělal. Mě teda openssl odmítala špatné klíče a běh skončil chybou.
A je to tak logické.

+1
+5
-1
Je komentář přínosný?

Které konkrétní protokoly nemají dynamicky měněné klíče pro symetrické šifry? (Vyjma OpenVPN v režimu PSK.)

Dešifrovací funkce jenom provede předepsané operace s bity klíče a zprávy a vyjde jí z toho jiná zpráva. Jak by poznala, že daný klíč pro symetrickou šifru není ten, který byl použit pro zašifrování, když neví, co z toho má vypadnout?

+1
-8
-1
Je komentář přínosný?

No všechny, které nemají neumí FS. Třeba HTTPS přes TLS-PSK, TLS-RSA, TLA-DSA, TLS-ECDSA... Čili zkráceně, ty které nepoužívají pro key-agreement DHE/ECDHE a nebo eRSA (což je docela rarita).

Světe div se, ale čtvrtina HTTPS serverů nepodporuje key agreemnet klíčů DH.

>Dešifrovací funkce jenom provede předepsané operace s bity klíče a zprávy a vyjde jí z toho jiná >zpráva.

Takhle to nefunguje, milý kolego. Z klíče, který zadáte se derivují IV, které se pak XORují, nebo jdou jako vstup do šifrovací funkce a po zašifrování se XORují s plaintextem, to závisí na zvoleném módu šifry.
Z chybného klíče se logicky vygenerují chybné iv a chybný podklíč. Během operace dešifrování pak nastane problém.

Pokud nevíte, jak AES funguje, tak na to jděte selským rozumem. Proč OpenSSL při dešifrování chybným klíčem skončí s chybou? Podotýkám, že žádný kontrolní součet ani žádná hlavička v zašifrovaném souboru není.
K čemu by byl DES cracker? Vždyť by pro krátkou zprávu vrátil stovky, tisíce nebo desetitisíce chybných, ale po jazykové stránce validních plaintextů.

Tak co, hodíte sem ty příkazy, kterými jste testoval nebo ne?

+1
-9
-1
Je komentář přínosný?

#!/usr/bin/perl

use Crypt::DES;

my $key = pack("H16", "0123456789ABCDEF");
my $cipher = new Crypt::DES $key;
my $ciphertext = $cipher->encrypt("plaintex");
print "Zasifrovano: ", unpack("H16", $ciphertext), "\n";

my $decrypted = $cipher->decrypt($ciphertext);
print "Rozsifrovano spravnym klicem: ", $decrypted, "\n";

my $badkey = pack("H16", "1123456789ABCDEF");
my $badcipher = new Crypt::DES $badkey;
my $baddecrypted = $badcipher->decrypt($ciphertext);
my $badanswer = unpack("H16", $baddecrypted);
print "Rozsifrovano spatnym klicem: ", $badanswer, "\n";

Dává:
Zasifrovano: 6bd28fe34923ee94
Rozsifrovano spravnym klicem: plaintex
Rozsifrovano spatnym klicem: c3ffb6430aeb997f

Přece bych byl úplně blbý, kdybych dal útočníkovi ten luxus, abych mu umožnil zjistit, že použil správný klíč, ne?

Jinak v předchozím příspěvku pletete dohromady symetrické a asymetrické šifry. Asymetrické společný klíč nemají, já se ptal speciálně, kde se používají symetrické (!) s pevným klíčem. Z uvedených odpovědí uznávám jenom TLS-PSK, nicméně - vy jste to už někdy takto použil? Znáte někoho, kdo používá v HTTPS PSK? Já teda ne. Ty ostatní - TLS-RSA / DSA / ECDSA jsou právěže přesně opačné příklady protokolů, které slouží pro vygenerování a předání klíčů.

BTW DES cracker funguje tak, že se mu předá ta stejná zpráva zašifrovaná a rozšifrovaná a on z toho spočítá klíč. Pokud nemám zašifrovanou a rozšifrovanou zprávu, tak je mi DES cracker k ničemu.

Že neumíte vyzkoušet u OpenSSL špatný klíč vám nemám důvod nevěřit. :-)

+1
+6
-1
Je komentář přínosný?

http://search.cpan.org/~dparis/Crypt-DES-2.07/DES.pm

Tak už vím, v čem je problém. Nepochopil jste výsledek testu. Bohužel pro vás Crypt se nechová úplně korektně. Pokud nastane neočekávaný stav, tak prostě skončí tam, kde je, něco vyplivne, ale neobtěžuje se vás o chybě oznámit.
Už jen letmým pohledem lze zjistit, že klíč byl špatný.

To vám nebylo divné, že rozšifrovaný text špatným klíčem má stejnou délku jako zašifrovaný text? Schválně si zkuste zašifrovat 8 B něčeho pomocí DES. Velikost ciphertextu bude 16 B. On si tam DES (ale třeba i AES a další) potřebuje ještě přilepit nějaké věci. To je divné, že ze zašifrované zprávy najednou dostanete plaintext, který se tam nemohl vejít.
Opět stačilo použít zdravý rozum a ušetřil byste si ztrapnění.

Abych vám udělal radost a vy ste nemohl říct, že to je náhoda, tak jsem udělal velký test. Přes noc jsem trápil svoji VPS. Zkoušel jsem 1M náhodných špatných klíčů na zašifrovaný soubor a světe div se, žádný nefungoval.

>Jinak v předchozím příspěvku pletete dohromady symetrické a asymetrické šifry.
Ano pletu, protože spolu souvisí. Pokud probíhá výměna klíču přes RSA/DSA/ECDSA, pak zůstává symetrický klíč relace pořád stejný, nemění se během spojení (client rengotiation se totiž kvůli ochraně před DoS vypíná).

>BTW DES cracker funguje tak, že se mu předá ta stejná zpráva zašifrovaná a rozšifrovaná a on z toho >spočítá klíč. Pokud nemám zašifrovanou a rozšifrovanou zprávu, tak je mi DES cracker k ničemu.
Opět se mýlíte, pane kolego. DES cracker zkouší hrubou silou klíče.

>Že neumíte vyzkoušet u OpenSSL špatný klíč vám nemám důvod nevěřit. :-)
To skutečně neumím, máte pravdu. Vy snad ano? Můžete mi poslat příkazy, kterým lze zařídit, aby OpenSSL dešifrovala chybným klíčem.
A přemýšlejte o tom, co děláte, ať to neskončí fiaskem, jako když jste se pokoušel dešifrovat DES.

>Přece bych byl úplně blbý, kdybych dal útočníkovi ten luxus, abych mu umožnil zjistit, že použil správný >klíč, ne?
Ale ono to jinak nejde, pane kolego.

+1
+3
-1
Je komentář přínosný?

Ty kokos, to už je fakt moc. Teoreticky nejde zašifrovat jiná velikost dat, než velikosti bloku. Pokud chci něco jiného, volím mód operace (a popřípadě inicializační vekto), pak můžu šifrovat typicky násobky velikosti bloku. Proto, abychom mohli zašifrovat ještě i jiné velikosti vstupu, doplní se poslední blok nulami (naivně), nebo tam protokol vyšší vrstvy nacpe náhodný šum (lépe). Po tomto doplnění bude velikost takto doplněné zdrojové zprávy stejná, jako velikost zašifrované zprávy (opravdu si tam šifra nic nepřidává) a taky bude stejná, jako následně rozšifrovaná zpráva (kterýmkoli klíčem). Protokol vyšší vrstvy si ten konec "uřízne", popřípadě - pokud jsme tam nechali naivně nacpat nuly - je dostaneme zpět. Toto celkem hezky koreluje s tím, co dostaneme v mém příkladě - velikost zdrojové, zašifrované, správně rozšifrované a špatně rozšifrované zprávy je přesně 1 blok = 64bitů = 8bytů. Protože šifruji jeden blok, nevolím mód operace.

Nemusí to tak být vždy, šifra může mít i nějakou vlastnost komprese, ale minimálně pro obvyklé mainstreamové šifry to platí. Pokud to chcete zpochybnit, uveďte konkrétní protipříklad pro DES.

Dovedu si představit, že si šifrovací nebo dešifrovací funkce bude stěžovat, že není vstup zarovnaný na velikost bloku, v té chvíli může i skončit chybou, ale toto je jediný požadavek, který má. V implemetacích, které jsem teď prošel, si při zašifrování doplní nuly do konce bloku a nic nepíše.

Teď otázka: Jak poznáte, že vám klíč nefunguje? Uděláme to teď naopak - pošlete kód nebo např. příkazy pro OpenSSL a já vám to opravím nebo vysvětlím.

DES cracker zkouší hrubou silou klíče (sohlas) a pro každý kontroluje, jestli se rozšifrovaný text shoduje se zadaným vzorem (musím mít oba!). Klíč, u kterého toto nastane, se hodí na výstup. Tímto klíčem jde pak rozšifrovat zbytek spojení. Stejně fungoval i projekt deschall - u kterého můžete (a doporučuji) RTFS! Zadání je přímo v programu.

Opravdu mi pro pokračování diskuse nějak ukažte, jak dokazujete, že klíč "nefunguje". Já tvrdím, že fungují vždycky všechny klíče, vy tvrdíte, že poznáte ten správný. Já jsem vám ukázal, že umím použít více klíčů na rozšifrování a nevím, který je správný.

Abych vám ještě trochu pomohl, můžu nagenerovat 8 bytů binárního šumu, deset náhodných klíčů, zašifrovat ten vstupní text jedním z těch klíčů (náhodně vyberu) a pak sem hodím ten zašifrovaný výsledek a všech 10 klíčů. Podle vaší teorie pak nastane to, že 9 klíčů nebude fungovat a jeden, který bude fungovat, nějak poznáte, identifikujete mi jej a pošlete mi zdrojovou jím rozšifrovanou zprávu. Můžem?

+1
-11
-1
Je komentář přínosný?

A co jsem asi říkal?

Jenomže problém je v tom, že nemůžete brát velikost surového plaintextu. Například šifrování (AES)16 B plaintextu vás donutí použít 2 bloky. 15 B surového plaintextu se vejde do 1 bloku. Vyzkoušejte si. 1B je nutné použít jako identifikátor, kde končí užitečná data a kde začíná nějaký binární hnůj, kterým se zarovnává velikost bloku.

Není vám divné, že rozšifrování vám vrátilo řetězec o délce, která se do jednoho bloku nemohla fyzicky vejít?
Vy nechápete, co vám vlastně ta funkce vrátila. Ona nevrátila plaintext, ale nějakým způsobem rozpracovaný blok, protože dál pokračovat nešlo. Já nemůžu za to, že funkce korektně, jak by měla, neohlásila, že neuspěla.

>Nemusí to tak být vždy, šifra může mít i nějakou vlastnost komprese
Což je nebezpečné. ;)

>Uděláme to teď naopak - pošlete kód nebo např. příkazy pro OpenSSL a já vám to opravím nebo >vysvětlím.
Vy nejste schopen cokoli vysvětlit, natož opravit.

>Já jsem vám ukázal, že umím použít více klíčů na rozšifrování a nevím, který je správný.
Až na to, že jste výsledek testu špatně vyhodnotil a v důsledku vlastně potvrdil, to co jsem říkal.

+1
+10
-1
Je komentář přínosný?

Blbost - jeden blok plaintextu bude jeden blok zašifrovaný, dva bloky budou dva bloky atd. Počet bitů před a po šifrování je stejný.

Který text se mi nevejde do jednoho bloku? Všechny moje texty (zašifrované i rozšifrované) mají přesně jeden blok = 8 byte, což je očekávaná velikost. Chápete ten pack / unpack?

Pořád čekám na příklad, kdy poznáte, že daný klíč je špatný.

Jinak k mé nabídce:

Tady je zašifrovaný blok DESem: 79ea07089b668537

Tady máte deset klíčů:

8979c0bbb37c15ff
22e8e71bdd9e2a35
50df64eda3547765
2678aade90b99ab8
9f93966838cc0385
25b17cc27661cda2
4d122cc1c38ed36d
cf44cb03a96ec419
61e978d6f9667c6b
62b8a0dfd4791b63

Jeden z těchto klíčů byl použit pro zašifrování daného bloku. Který to byl? Jak vypadá původní plaintext?

+1
+8
-1
Je komentář přínosný?

No a teď mi vysvětlete, jak pozná dešifrovací funkce, co jsou užitečná data, a co je výplň? Aha.

+1
-10
-1
Je komentář přínosný?

Žádná výplň tam není, všechno jsou užitečná data.

+1
+6
-1
Je komentář přínosný?

Pro ty pomalejší, ještě jednou.

Když chci zašifrovat text "ahoj", se nejdřív musí text zarovnat na velikost bloku. Vy říkáte, že se vyplní nulami (to se ale v praxi nedělá, protože to je nebezpečné a dokonce to odporuje vaši logice, jelikož samé nuly na konci bloku by znamenaly, že půjde poznat který klíč je správný (tedy pokud by šlo dešifrovat špatným klíčem) - sám si protiřečíte a nevíte, která bije)

Ale fajn, budeme předpokládat, že vstup do jádra šifrovací funkce musí být zarovnán nulami. Budu chtít zašifrovat text ahoj0 Pak bych šifroval ahoj0000 (v případě DES). Pokud bych chtěl text rozšifrovat, co dostanu?
ahoj, ahoj0 ahoj00, ahoj000?

+1
-10
-1
Je komentář přínosný?

Pletete hex a plaintext. "ahoj" je 61686f6a, zarovnám na 8 byte - 61686f6a00000000, zašifruji, dostanu právě jeden blok, rozšifruji zpět na 61686f6a00000000.

Jinak jak pokračuje vyřazování těch deseti klíčů? Už se některý ukázal jako nefunkční? Chcete stejný příklad pro AES, nebo vám stačí DES?

+1
+5
-1
Je komentář přínosný?

.

+1
-8
-1
Je komentář přínosný?

@Naith

No tohle jste zrovna moc nedomyslel...

Zašifruji příkaz pomocí DES, odešlu ho, stroj ho přijme, rozšifruje a provede. NSA celou komunikaci zachytila, zprávu a KLÍČ, KTERÝM BYLO ŠIFROVÁNO rozlouskla, a pak už si může vesele dál posílat příkazy sama.
Ano, je to tak, při louskání zjistili nejen obsah zprávy, ale i klíč!

To by se musel klíč měnit každou hodinu bezpečným kanálem a to je v celkovém kontextu nesmysl.

Nehledě na to, že šifrování nenahrazuje autentizaci.

No vidím, že jste kryptografií a bezpečností zcela nepolíbený, takže se asi nemáme o čem bavit. Ale jenom tak pro zajímavost, uveďte prosím jiný systém, kde stačí, aby nebyla šifrovaná zpráva rozluštěna do 5 minut?

+1
-10
-1
Je komentář přínosný?

Proč?

V další iteraci užití stroje může být změněn nejen klíč, ale i formát zprávy. Dokonce může být užití stroje pouze jednorázové.

Například bezpečnostní pojistka. Systém zastavení, nebo naopak spuštění. Po aktivaci je pouze odesláno potvrzení a další komunikace je bezvýznamná.

+1
-12
-1
Je komentář přínosný?

>V další iteraci užití stroje může být změněn nejen klíč, ale i formát zprávy.
To by oddálilo prolomení pouze o pár zpráv, než by NSA našla vzor, podle kterého se to dělá.
A vůbec, proč to dělat jednoduše s AES, když to jde i složitě.

>Dokonce může být užití stroje pouze jednorázové.
Pak ale není potřeba aby byla komunikace šifrovaná, ne? Stačí domluvit něco jako kódovou knihu a komunikovat plaintextem.
A nebo když to musí být šifrované, ale může to být jednorázové, pak lze použít Vermannovu šifru, která je mimochodem neprolomitelná.

Pořád marně přemýšlým, jaký reálný systém by takto pracoval.

+1
-7
-1
Je komentář přínosný?

Pokud si to neumíš představit, tak ti bude muset stačit, že takové zařízení jsou. Jsou to malý krabičky, které jsou součástí zabezpečovacích systémů. Sám jsem pár vyvíjel.

Šifrovat se to musí, aby to například "jsemZpět" nespustil, protože formát zpráv musel být veřejně znám.

Sám jsem DES nepoužil, ale shodou okolností Vernamovu šifru, neboli obyčejný XOR s unikátním klíčem o stejné délce, jako je sama zpráva.

Co se týče Vernamovy šifry, tak je sice neprolomitelná (a nepomůže ani kvantový počítač), respektive vede ke všem možným zprávám, které lze sestavit, ale jen za předpokladu, že klíč je opravdu náhodný (jako zdroj klíče je zvolen například normalizovaný termický šum), je stejně dlouhý jako zpráva a musí být použit jen jednou.

+1
+3
-1
Je komentář přínosný?

>Pokud si to neumíš představit, tak ti bude muset stačit, že takové zařízení jsou.
V tom případě bych prosil oznaćení konkrétního modelu.

>Sám jsem pár vyvíjel.
Jsem zděšen, že lidé, kteří nemají pořádné základy bezpečnosti a kryptografie se podílí na vývoji.

Mimochodem, ten poslední odstavec má sloužit k čemu? Abyste ukázal své rozsáhlé znalosti? Proto odbíháte od tématu?

+1
+3
-1
Je komentář přínosný?

Označení modelu ... ach jo. :( Ty zařízení nemají číslo modelu. Je to zakázková technologie. Váš aplikační rozhled je omezen pouze na jednu oblast a diskuze s vámi je tak zbytečná.

+1
+2
-1
Je komentář přínosný?

Omlouvám se za neznalost něčeho, o čem jsem ani netvrdil, že znám.

No hlavně že vy si pořád myslíte, že použití DES je bezpečné.

K používání DES u takových zařízení prosté ani není důvod. Integrovaný obvod, co zvládá AES se dá koupit za pár šlupek a navíc je jednodušší než DES.

Vaše narážka o malém rozhledu je dost úsměvná v kontrastu s řešením, co jste navrhoval. Aby technik po prolomení šifry přišel k zařízení a změnil heslo. To je opravdu praktické.

+1
-9
-1
Je komentář přínosný?

Hele, moc bych radši neřešil, kdo je tady čím (ne)políbený.

Vem si třeba SSH. Klíč se mění použitím asymetrické šifry a děje se tak buď po určitém čase (tuším hodina) nebo po určitém množství dat. Nový klíč je generovaný náhodně, takže žádný vzor NSA nepomůže.

Každý protokol, který by toto nedělal, bych považoval za nebezpečný.

Pokud se používá kryptografie k autentizaci, tak je to prakticky vždy pro navázání spojení a výmenu klíče asymetrická šifra, pak mají obě strany stejný klíč a šifruje se symetricky.

+1
+12
-1
Je komentář přínosný?

>Vem si třeba SSH. Klíč se mění použitím asymetrické šifry a děje se tak buď po určitém čase (tuším >hodina) nebo po určitém množství dat.

To je sice nezávazné doporučení, ale fajn.

>Nový klíč je generovaný náhodně, takže žádný vzor NSA nepomůže.
No většinou se negeneruje, ale dohodnou se na něm obě protistrany (DH). Bavili jsme se o stand-alone použití DES. A tady nemáte šanci dát nějak zabezpečeně vědět o novém klíči.
Nový klíč se tedy nemůže generovat náhodně, ale obě dvě strany ho musí nějak počítat. To sice jde, ale pro utajení vzoru je třeba použit nějakou hashovací funkci. Navíc je třeba řešit synchronizaci klíčů (co se stane při výpadku spojení, jaké klíče se mají použít).
A tím se dostáváme od blbého řešení s AES k šílené fantasmagorii, která je parodií na bezpečnost.

+1
+6
-1
Je komentář přínosný?

Ne, nebavíme se o stand-alone použití. Právě naopak se od začátku bavíme o takovém použití, které se reálně používá a diskutujeme o tom, že různé druhy útoků jsou kvůli tomu, jak se to reálně používá, buď nerealizovatelné, nebo pořád stejně složité - k některým útokům v praxi nedostanu dostatek zpráv (např. kvůli výměně klíčů u ssh), nebo neznám původní zprávu, nebo je to útok, který se míjí s konkrétním použitím funkce - např. u MD5 je jednoduché (jednodušší) najít nějakou libovolnou kolizi, ale je pořád stejně složité najít kolizi k předem danému hashi, což by bylo nutné pro útok na uložené hashe hesel.

+1
-8
-1
Je komentář přínosný?

Moje tvrzení je, že použití DES je nesmyslné, protože je buď podle implementace nebezpečné a nebo příliš složité.
Stand-alone použití DES je nebezpečné a použití spolu s CRAM/SCRAM je zase komplikované a šifrování tam ani nemá žádný efekt. Výpočet hesla podle předem definovaného algoritmu je také zbytečně komplikované.
Není přece jenom praktičtější použít AES, jednou nastavit heslo a pak se už o to nestarat? Zajistím si tím utajení zpráv a alespoň jednoduchou (i když dost pofidérní) autentizaci.

No tak původně jsme se bavili o jednoduchých malých zařízeních. Pochybuji, že tam půjde nasadit bezpečnostní mechanizmy, co navrhujete. Připlácnout za čip nějaký další šváb, cu bude podle PSK šifrovat to, co do něl leze není složité. Ale implementovat tam dynamickou změnu hesla už docela složité je a zařízení to prodraží.

S tím, že zašifrovanou zprávu nelze rozšifrovat špatným klíčem jste se nevyjádřil, takže předpokládám, že jste uznal svůj omyl, je to tak?

+1
+5
-1
Je komentář přínosný?

Odkud berete, že se bavíme o jednoduchých zařízeních? Tato diskuse je pod zprávou o SPARC M7. Jinak rozšifrovat zprávu špatným klíčem lze, konkrétní případ třeba tady:

http://www.emvlab.org/descalc/?key=012A456789ABCDEF&iv=0000000000000000&...

Opravte si klíč a získáte správnou zprávu. Nebo ne? Jak víte, že klíč je špatně? Nebyla náhdou původní zpráva "27E4B87D64D7D5BE" a klíč je dobře?

+1
-8
-1
Je komentář přínosný?

>Odkud berete, že se bavíme o jednoduchých zařízeních?

naith to zmínil

Ovšem použití DES u velkého stroje je ještě větší blbost.

+1
-5
-1
Je komentář přínosný?

No zatím jste mi nerozluštil ani ten DES, i když máte vybrat jenom jeden z deseti klíčů a ne z 2^56. :-)

+1
-8
-1
Je komentář přínosný?

Muze to bejt paradni, ale ja jak slysim Oracle, vzpomenu na jejich deravou Javu, vzpomenu na vecne zabugovanej VirtualBox a oklepu se - eeeeeeee.

+1
-3
-1
Je komentář přínosný?

Toto je vo svete x86 celkom bežný názor :D

+1
+10
-1
Je komentář přínosný?

Ale je fakt, že image Oracle to hodně ubližuje.

+1
0
-1
Je komentář přínosný?

Image te firmy je presne takovej, jaky si zaslouzi... a tomu panovi predtim - ze x86 je kopa <beep>, to vi vsichni. Problem je spis v tom, ze Oralek sro si mysli, ze jejich sr**ky nesmrdi, a tudiz si muzou uctovat absurdni ceny... pricemz samozrejme smrdi uplne stejne. Takze se nedivte ze lidi maji nazor, jaky maji...

+1
-8
-1
Je komentář přínosný?

Děravou Javu má na svědomi firma Sun, která zbankrotovala a Oracle jí odkoupil. Pro mně je Oracle synonymem velmi dobré databáze.

+1
+9
-1
Je komentář přínosný?

veľmi dobrej pre koho okrem oracle? ich licenčné podmienky sa za posledných 10 rokov zmenili tak, že oracle databáza je momentálne dobrá akurát tak pre oracle. žiaden oracle DBA by Oracle databázu nepoužil na svoj vlastný projekt.

okrem akademických inštitúcií (za špeciálne ceny) a vlád (za špeciálne ceny) si ju nikto, kto si môže vybrať, nevyberie. aplikácie postavené pred 10 a viac rokmi väčšinou nemajú možnosť prejsť inde a to je 90 percent ich užívateľov. môj bývalý zamestnávateľ prešiel za obrovskú cenu na EnterpriseDB pred 10 rokmi ale v retrospektíve ušetril neuveriteľné množstvo peňazí.

oracle express je vynikajúci marketingový ťah. ako perníková chalúpka. kto na tom postaví aplikáciu, toho už "vendor lock-in" nepustí.

+1
-12
-1
Je komentář přínosný?

Moc sem z Vašeho příspěvku nepochopil, jak je to s tím "vendor lock-in" em. Pokud aplikace je schopná běžet i nad jinou databází, stačí prostě zmigrovat data, upravit konfiguraci a když vše bude fungovat správně, oracle odinstalovat. V dnešní době se snad už nepíšou aplikace na míru dané databázi, většinou se používá nějaká vrstva, která skryje rozdíly mezi jednotlivými databázemi.

Licenční podmínky Oracle neřeším, nejsem obchodník, nýbrž developer. Ale nedávno sem četl něco o tom, že Oracle může požadovat po zákaznících, aby proskenovali co a jak mají nainstalováno, výsledek odeslali do Oracle a pokud to nebude souhlasit s tím, co mají koupeno, může jim Oracle vyměřit mastnou pokutu. :-)

+1
+12
-1
Je komentář přínosný?

"V dnešní době se snad už nepíšou aplikace na míru dané databázi"
Zvlastni, dal pisete ze jste developer, cekal bych, ze z techle pohadek uz jste vyrostl...

"Licenční podmínky Oracle neřeším, nejsem obchodník, nýbrž developer"
Ano, tady nekde je jaksi zacatek toho problemu... Licencni podminky lze pochopit snadno, staci si predstavit zhavej pohrabac v p... zadni casti tela. Presneji pohrabac ktery se ne uplne snadno vytahuje z te casti tela...

+1
-9
-1
Je komentář přínosný?

inline sql je síce často nebezpečná vec, ale bohužiaľ VŽDY prítomná v staršom kóde. ani dnes nemá každý čas na ORM, stored procedures, atď. navyše, sú situácie, keď je rýchlosť aplikácie jediné kritérium. treba mať na pamäti, že nie všetci píšu v RoR, Django, atď. keď chcete využiť všetky vymoženosti svojej databázy, abstrakčná vrstva je prekážkou.

+1
+10
-1
Je komentář přínosný?

"Děravou Javu má na svědomi firma Sun"

Joooo.. Oracle ji koupil kdy ? 2009-10 tj asi 5 let zpatky. Odvtedy vysli dve nove major verze jazyka, 7 a 8. Ty tuny der v nich ma asi taky na svedomi Sun, ze ? Za pet let to nestihli opravit, chudacci... jeste tu o karkulce pls....

+1
-5
-1
Je komentář přínosný?

Pro psaní komentářů se, prosím, přihlaste nebo registrujte.