[ Ivan Dimkovic @ 27.07.2013. 18:00 ] @
http://www.tweaktown.com/news/...ew-microcode-update/index.html

Citat:

Apparently, Intel does not like its customers overclocking their new Haswell chips on non-Z87-equipped motherboards. Several of the large motherboard manufacturers have released workarounds that allow their customers to overclock their Haswell processors on motherboards that did not feature a Z87 chipset.

Read more at http://www.tweaktown.com/news/...index.html#11h0RMQASMEHK1ht.99


Ovo je, gospodo, skolski primer kako izgleda de-facto monopol u praksi :(

Kako Intel danas vise nema nikakvu konkurenciju na desktop (a i workstation/server) polju, sada mogu da rade sta god hoce.

- Prvo su totalno parcelisali trziste marketinskim ogranicenjima izmedju desktop i server procesora u Sandy Bridge generaciji
- Sandy Bridge je, takodje, doneo i softverski upgrade nekih procesora (?!) sa "scratch karticama" od $50 (!)
- Ivy Bridge generacija je donela jos ostriju segmentaciju sa jos pogasenih feature-a
- Haswell je doneo jos novih ogranicenja (nema TSX-a sa K modelima, 'alo?)

A sada sa Haswell-om su dostigli nove visine - naime motherboard vendori su nudili overclock mogucnosti sa H i B chipset-ovima i to se Intelu ne dopada. Sta ce Intel da uradi povodom toga? Pa, izbacice microcode update koji ce K procesore promeniti tako da ne mogu da se overclockuju na ne-Z87 cipsetu.

Alal' vera.

Pretpostavljam da ce sa Broadwell-om bukvalno sve stvari biti kontrolisane eFuse-ovima i preko Intel Management Engine-a, i Intel ce nuditi 100 razlicitih modela hardverski identicnih procesora gde ce jedina razlika biti u konfiguraciji fuse-ova.

Ne sumnjam da neko u Intelu razmislja i o ideji rentiranja procesora - ono, ako ne platis godisnju globu Intel ME pogasi sve.

--

A i drugi vendori su videli da se moze - znaci, pre neki dan hocu da ubacim novi microcode u BIOS. E pa nece moci, ASUS je odlucio da potpuno zakljuca flash-ovanje tako da je nemoguce patch-ovati BIOS zbog kriptografske provere. To je, inace, "preporucena konfiguracija" od strane Intela i novi Management Engine (9.x) ne dozvoljava "nesigurni" flash po default-u. Do sada ste mogli da override-ujete to sa FTK-om (Flash Toolkit) medjutim od skora to vise nije moguce.

Drugim recima, maticna ploca koju ste kupili nije skroz vasa.

Ja sam to resio tako sto sam narucio SPI flash programator. Ali ne sumnjam da ce vrlo brzo i to biti zatarabljeno prebacivanjem firmware memorije negde na CPU.
[ EArthquake @ 28.07.2013. 01:08 ] @
Taj ME mi je jako gadna stvar od kad se pojavio
niko ne zna kako funkcionise i sta sve moze da radi , niti da li moze da se iskljuci.
A meni licno ne treba ni malo. Jedino gde sam uspeo nesto malo detalja da iskopam o tome jeste
ovaj talk od Igora Skochinskog , koji mi nimalo ne budi poverenje :)

https://ruxconbreakpoint.com/a...kpoint%202012%20Skochinsky.pdf

[ bigvlada @ 28.07.2013. 06:19 ] @
Ne bi me čudilo da ih EU natera da u Evropi prodaju procesore bez tih ograničenja. Zato je dobro imati pirate u EU parlamentu, da objasne ostalima zašto je ovo loše.
[ xtraya @ 28.07.2013. 11:36 ] @
Kakva nezasitost ... sledece je ME u firmweru vesh masine, naravno sa secret wifi konekcijom/BTooth/NFC itd... pa ce proizvodjaci praska od svog InfoWash provajdera za odredjen fee imati vise informacija o tome kako/koji prasak trosite i koji wesh perete...

Naravno secret webcam (undocumented feature) na wesh masini ce pratiti koliko cm paste za zube stavljate na cetkicu i u slucaju da stavljate manje, servirace Vam personalizovane "adsems" banere / reklame na tv, gde ce Vam "preporuciti" da stavljate vise (bez obzira sto su FI rupe na pasti odavno povecali)

Citat:
dimke: Ovo je, gospodo, skolski primer kako izgleda de-facto monopol u praksi :(


prevedeno na srpski: Zabole nas, moze nam se, pa Vi ubuduce kupujte digitron workstatione/servere....

[ Ivan Dimkovic @ 28.07.2013. 12:20 ] @
Citat:
EArthquake:
Taj ME mi je jako gadna stvar od kad se pojavio
niko ne zna kako funkcionise i sta sve moze da radi , niti da li moze da se iskljuci.
A meni licno ne treba ni malo. Jedino gde sam uspeo nesto malo detalja da iskopam o tome jeste
ovaj talk od Igora Skochinskog , koji mi nimalo ne budi poverenje :)

https://ruxconbreakpoint.com/a...kpoint%202012%20Skochinsky.pdf



Hehe, do Sandy Bridge generacije si generalno mogao da iskljucis ME potpuno bez nekih posledica.

Medjutim, danas sa Haswell generacijom, ME kontrolise kljucne aspekte procesora kao sto su power-management, speed-step, overclocking i sl.. Na nekim "advanced" plocama tipa EVGA SR-X je moguce iskljuciti ME ali se sa tim momentalno gubi gomila funkcija.

Sa Haswell generacijom je ASUS, takodje, odlucio da primeni potpuno Intel-ovu preporuku za 100% lock-ovanje SPI flash-a, tako da je sada moguce uraditi flash samo ako kriptografski potpis odgovara. Do sada je ovo bilo rezervisano samo za ME region flash-a a sada to vazi i za BIOS/UEFI region, samo je GbE region otkljucan.

Takodje, ASUS je ovo pravilo primenio i na svojim X79/C602 plocama (LGA 2011) - vise nije moguce softverski flash-ovati patchovan BIOS.

ME, takodje, u sebi ima gomilu f-ja koje su prilicno zabrinjavajuce sto se sigurnosti tice - ukljucujuci mogucnost kompletne blokade boot-a laptopa i brisanja podataka. Ove funkcije je nemoguce iskljuciti potpuno. Intel ovo naziva unapredjenjem sigurnosti ali je to zapravo potencijalni sigurnosni problem ako neko uspe da provali kako da posalje ME poison-pill neautorizovano. Ovo je i dalje moguce blokirati firewall-om ali opet, ako neko ima lokalni pristup firminoj mrezi (recimo inficiranjem nekog kompjutera) i provali kako da nanese stetu cela stvar moze biti prilicno gadna.

Za PC-jeve postoji jednostavan nacin da se ME "security" zaobidje - koristite odvojenu mreznu karticu koja ne koristi Intel cip. ME dolazi u kombinaciji sa Intel-ovim GbE/WiFi kontolerima i zajedno dele SPI flash prostor i tesno "saradjuju". Tako ME moze da pristupi "out of band" LAN/WiFi saobracaju cak i kada je PC iskljucen (ali i dalje povezan na AC). To se moze osujetiti tako sto koristite LAN/WiFi adapter koji nisu vezani za ME.

Ista prica i za laptopove - USB LAN/WiFi kontroler, bez OpROM-a, ne od Intel-a.

[ Ivan Dimkovic @ 28.07.2013. 12:33 ] @
Citat:
bigvlada:
Ne bi me čudilo da ih EU natera da u Evropi prodaju procesore bez tih ograničenja. Zato je dobro imati pirate u EU parlamentu, da objasne ostalima zašto je ovo loše.


Sumnjam.

Intel je vec uspeo da se izbori da zatvore svoje procesore za 3rd party chipsete jos pre par generacija procesora.

NVIDIA je dobila 1.5 milijarde $ za pretrpljen dusevni bol, i cela stvar je gotova. Vise, jednostavno, nema nikog zainteresovanog na trzistu da pravi cipsetove kompatibilne sa novim Intel-ovim procesorima. Od kada je AMD presao na fabrikaciju sopstvenih arhitektura a ne kloniranje Intel-ovih vise nema zajednickog trzista. Poslednji gram isplativosti je nestao kada je Intel izbacio "northbridge" i njegove funkcije integrisao u sam CPU. Ostao je samo IOH (nekadasnji "southbridge") sa sve manje i manje funkcionalnosti osim kontrole procesora.

A ako Intel proizvodi svoje cipsetove onda imaju pravo da ih segmentiraju kako hoce :( Nije lepo za kupce, ali nije protivzakonito. Intel moze uvek da tvrdi da je overclock osobina "platforme" koju cine odredjeni CPU i odredjeni cipset, i tesko da im se to danas moze osporiti na legalan nacin posto su zaista prebacili gomilu stvari na cipset.

Da postoji neko trziste 3rd-party cipsetova, stvar bi bila drugacija zato sto bi neko mogao da ponudi cipset koji nudi stvari Z87 cipseta od Intela ali po manjoj ceni. Medjutim, nema vise nikog ko se time bavi, zato sto je to danas neisplativ biznis (danasnji cipset ima sve manje i manje funkcionalnosti) i predstavlja otvoren rizik (posto Intel u svakom momentu moze da izbaci cipset kompletno i sve stvari stavi na SoC).

Jedina realna alternativa svemu ovom je da neko uspe da napravi konkurentan CPU.

Medjutim i to je vrlo malo verovatno posto je, prakticno, AMD jedini koji je ostao sa x86 licencom ali, kao sto se vidi, vise nije u stanju da prati Intel R&D. Sto nije za cudjenje uopste posto je samo Intel-ov R&D budzet veci od AMD-a kao firme.

Mozda za nekoliko godina ARM-ovi postanu konkurentni u high-performance polju. Ali i to mi deluje kao SF za sad uzevsi u obzir da ce Intel za mesec-dva izbaciti Xeon sa 10 jezgara i 70W TDP-a sto je 7W po cipu i koji moze da obrise pod sa par stotina ARM-ova verovatno.
[ EArthquake @ 28.07.2013. 18:09 ] @
Citat:
Ivan Dimkovic:

Za PC-jeve postoji jednostavan nacin da se ME "security" zaobidje - koristite odvojenu mreznu karticu koja ne koristi Intel cip. ME dolazi u kombinaciji sa Intel-ovim GbE/WiFi kontolerima i zajedno dele SPI flash prostor i tesno "saradjuju". Tako ME moze da pristupi "out of band" LAN/WiFi saobracaju cak i kada je PC iskljucen (ali i dalje povezan na AC). To se moze osujetiti tako sto koristite LAN/WiFi adapter koji nisu vezani za ME.

Ista prica i za laptopove - USB LAN/WiFi kontroler, bez OpROM-a, ne od Intel-a.


e vidis to mi nije palo na pamet kao opcija ... Good to know.
[ Ivan.Markovic @ 29.07.2013. 08:41 ] @
Jel moze predlog nekih USB LAN/WiFi kartica koje "zaobilaze" ME a opet daju solidne perfomanse preko USB-a? Tnx.
[ bojan_bozovic @ 29.07.2013. 12:25 ] @
Čekaj malo Ivane, deset jezgara, šta, pa kome to na desktopu treba, ako se izuzmu workstation potrebe? I koliko je trenutni softver optimizovan za rad na toliko jezgara (apet ako se izuzmu Maya, Mathematica, MathCAD i sl.)? Čak i novi PS4 i Xbox One imaće AMD A bazirane CPU/GPU sa osam jezgara, tako da je to neki maksimum za koji će se većina softvera optimizovati u narednih nekoliko godina. A ta manjina koja kupuje workstation hardver, to čini zbog posla i malo viša cena neće da smeta.
[ Nedeljko @ 29.07.2013. 16:01 ] @
Citat:
bojan_bozovic: I koliko je trenutni softver optimizovan za rad na toliko jezgara (apet ako se izuzmu Maya, Mathematica, MathCAD i sl.)?

A zar to nisu legitimne aplikacije? Zašto ih izuzimati?
Citat:
bojan_bozovic: Čak i novi PS4 i Xbox One imaće AMD A bazirane CPU/GPU sa osam jezgara, tako da je to neki maksimum za koji će se većina softvera optimizovati u narednih nekoliko godina.

U čemu je razlika u optimizaciji za ovoliko ili onoliko jezgara? Napraviš paralelne algoritme, ispališ odgovarajući broj niti prema broju jezgara na ploči i ako je sve na jednoj ploči, to je to. Svejedno je da li je broj jezgara na ploči 2 ili 256.
[ EArthquake @ 29.07.2013. 16:53 ] @
plus, ne moraju programi da mi budu paralelizovani, dovoljno je da ih imam vise pokrenutih u istom trenutku...
[ Nedeljko @ 29.07.2013. 18:07 ] @
Recimo da imaš 16 jezgara i pokrenuti su neki sitni sistemski procesi, koji ne smeju da guše mašinu. Kojih ćeš to 15 ili 16 programa da pokreneš koji će da rade odjednom (ne da čekaju neki događaj), a da ti to zaista treba?
[ EArthquake @ 29.07.2013. 19:56 ] @
cepidlacis , ali dobro ...

otvoris 10 tabova u chrome-u i eto ti 10 procesa, sa svim silnim javascript/ajax/web2.0 zahebancijama ce retko koji od njih biti idle u bilo kom trenutku
pa imas player za muziku, ssh konekciju, vpn ... ja recimo gotovo non stop imam neki VM ukljucen, sto njemu nebi dao par jezgara ... a imas i gomilu stvarai
koje se ne vide, a nije da su idle , recimo full disk enkripcija ...

u ostalom, sistem uvek ima sta da radi, zasto bi zvrjao u prazno (osim za ustedu energije, ali kad govorim o PCu, to mi nije preterano bitno)

poenta mog posta je bila da ne moraju svi programi da budu ekstra paralelni da bi video benefite multi-core sistema...
radi i sa ova 4 koja imam na laptopu , al mi nebi sokdilo da imam jos koji ...

s druge strane , ne vidim sta ce mi N core-ova na tabletu ... al to je vec druga prica ...
[ Ivan Dimkovic @ 29.07.2013. 19:58 ] @
Citat:
bojan_bozovic:
Čekaj malo Ivane, deset jezgara, šta, pa kome to na desktopu treba, ako se izuzmu workstation potrebe? I koliko je trenutni softver optimizovan za rad na toliko jezgara (apet ako se izuzmu Maya, Mathematica, MathCAD i sl.)? Čak i novi PS4 i Xbox One imaće AMD A bazirane CPU/GPU sa osam jezgara, tako da je to neki maksimum za koji će se većina softvera optimizovati u narednih nekoliko godina. A ta manjina koja kupuje workstation hardver, to čini zbog posla i malo viša cena neće da smeta.


Pomenuo sam "high performance" polje, tj. HPC. To da 10 jezgara nisu potrebni na desktopu je ocigledno - i sam Intel to demonstrira: njihovi mainstream procesori su i dalje limitirani na 4 jezgra. Cak i najskuplja desktop varijanta Intel procesora (tzv. HEDT segment) nudi samo 2 vise, tj. 6 ukupno.

Za koju nedelju izlazi Ivy Bridge E, tj. i7 4960x. Broj jezgara: 6. Iako je sama arhitektura ("IvyTown") u mogucnosti da podrzi do 15 jezgara, sto ce Intel valjati server ekipi kao Xeon E7 8800 v2 (pretpostavljam da ce najskuplja edicija tog procesora biti blizu $5K po komadu)

Jasno je da na cistom desktopu vecina aplikacija nisu optimizovane za vise od 4 jezgra, a ono malo korisnika koji spadaju u "workstation" grupu ce i ovako i onako kupiti workstation Xeon-e koji ce za koju nedelju dobiti 10 jezgara, ili ce kupiti server procesore sa kojima trenutno mogu da imaju 80 jezgara ako im treba, ili 120 jezgara za koji mesec kada Brickland platforma pocne da se prodaje (mada pretpostavljam da kljucni korisnici vec imaju pristup, posto je Ivy Bridge EX upravo usao u QS fazu)

AMD nudi nesto vise na desktopu koliko kapiram, ali to sto oni nude je zapravo dosta sporije od Intel ekvivalenta po broju jezgara, pa nije bas za poredjenje.
[ Nedeljko @ 29.07.2013. 20:43 ] @
Citat:
Ivan Dimkovic: Jasno je da na cistom desktopu vecina aplikacija nisu optimizovane za vise od 4 jezgra.

Izvini, a kako bi se optimizovale za neki ograničeni opseg broja jezgara a da ne budu optimizovane za veći broj jezgara? Ima li neka metoda koja je dobra za broj jezgara ne veći od nekog N, a da nije primenljiva za N faktorijel jezgara? Jedino što mi pada na pamet je

1. Da program obavlja nekoliko vrsta zadataka, pri čemu nijedna od tih vrsta zadataka nije paralelizovana,
2. Iterativni algoritam kod kojeg se sledeća iteracija ne može izračunavati dok se prethodna ne završi, a iteracija se mo\e ograničeno paralelizovati (recimo, numeričko rešavanje sistema jednačina fiksne dimenzije).

Tipični paralelni algoritmi dopuštaju proizvoljan stepen paralelizma nad dovoljno velikim podacima. Ne vidim šta tu ima da se optimizue za neki specifičan broj jezgara.
[ Ivan Dimkovic @ 29.07.2013. 22:16 ] @
Problem je sto je jako malo aplikacija gde je omoguceno koriscenje vise od 4-8 thread-ova.

Veci broj aplikacija imaju nekoliko thread-ova, ali je taj broj mali (tipa 10-20) od cega mozda par niti zaista radi neki zahtevniji posao. Vecina drugih thread-ova su neke sitnice tipa GUI, pomocne stvari i sl... Cak i ako veci broj niti rade neke "teske" stvari cesto su resavani problemi ogromnim kriticnim sekcijama koje zapravo serijalizuju kod i totalno ubijaju performanse kada broj CPU-ova postane veci.

Mali broj aplikacija je napravljen tako da se dobro skaliraju tj. da njihovi glavni algoritmi budu raspisani tako da su paralelni, ali cesto je dobar deo njih testiran na masinama do 6-8 jezgara i nije otkljucana mogucnost koriscenja vise thread-ova.

Konacno, najmanji % programa su zaista dizajnirani da se skaliraju na dvocifren broj jezgara i to zaista omogucavaju.

--

ALI! Cak i ako imas program koji je implementiran tako da moze da se skalira, ne tako retko dizajner algoritma nije vodio racuna o NUMA topologijama pa je koriscenje memorije sub-optimalno (koristis memoriju sa procesora kome ta memorija ne prihvata, sto znaci da zahtev za memorijom mora da putuje preko CPU interconnect-a sto latenciju uvecava drasticno i sl...).

Cak i ako je dizajner vodio racuna o NUMA topologijama, ako je u pitanju, recimo, Windows aplikacija, za koriscenje vise od 64 logicka procesora (32 fizicka moderna Intel procesora) moraju se koristiti novi Windows 7 / Server 2012 API-ji za procesorske grupe, inace ce aplikacija biti "pinovana" na jednu procesorsku grupu od 64 jezgra.

Itd... itd...

Situacija je zapravo jako losa.

AnandTech je testirao 4S sistem baziran na Xeon E5 4650L (32 jezgra, 64 logicka procesora), i dosli su do porazavajuceg zakljucka da gomila aplikacija prestaje da se skalira daleko ispod broja dostupnih jezgara.

A to je tek pocetak - Haswell EX ce, recimo, imati do 18 jezgara i 8S podrsku, dakle 144 fizicka procesora / 288 logickih. To ce tek biti show.

Citat:

Tipični paralelni algoritmi dopuštaju proizvoljan stepen paralelizma nad dovoljno velikim podacima. Ne vidim šta tu ima da se optimizue za neki specifičan broj jezgara.


Na zalost, prakticno, ima tu dosta stvari na koje se mora obratiti paznja ako se zeli postici dobar rezultat sto se performansi tice:

1. Sve moderne 2S/4S/8S (socket) arhitekture (Intel i AMD) su NUMA, sto znaci da aplikacija mora eksplicitno da bude svesna NUMA topologije pri alociranju memorije i koriscenju iste, inace ce patiti od drasticnog pada memorijskih performansi

2. Sinhronizacija koda je kriticna kada pricamo o velikom broju procesora zato sto postaje vrlo skupa - lockless kod je najboljji sto se skaliranja tice, ali je takodje i najtezi za implementaciju zbog toga sto dizajner mora biti izuzetno dobro upoznat sa pristupom podacima i nacinu na koji arhitektura radi pristup memoriji kako bi operacije bile atomske. Ukoliko se cesto pribegava spinlock-ovima / kriticnim sekcijama / mutexima, na dvocifrenom broju niti performanse mogu da totalno degradiraju

3. Ako se radi o vise od 64 logicka procesora, u Windowsu bar aplikacija mora rucno da setuje affinity svojih niti na odredjenu procesorsku grupu. Takodje, i alokacija memorije i koriscenje iste mora biti u skladu sa topologijom i grupama
[ Nedeljko @ 30.07.2013. 14:00 ] @
Evo ti ga fotošop. Filtere može da primenjuje na svako parče slike ponaosob. Možda ponekad to nije tako, ali algoritmi za rad sa grafikom (2D i 3D) su uglavnom takvi da se mogu potpuno paralelizovati. Kriptografski algoritmi su takođe blokovski, tj. obrađuju velike količine podataka u odvojenim blokovima. Igranje šaha se može odlično skalirati.

Što kolega zemljotres (šala, bez ljutnje) reče, otvori 20 tabova u fajerfoksu i radiće u 20 niti. Za to ograničenje Windows-a na grupu od 64 jezgra, osim ako koristiš nove API funkcije nisam znao, ali mi smo daleko od 64 jezgra na tipičnim PC-jevima. Radi se o tome da ako nabudžim 16 jezgara, hoće li imati efekta. Programi koji glavne zadatke paralelizuju će svakako raditi brže.
[ Dexic @ 30.07.2013. 23:57 ] @
Ne mogu svi kriptografski modovi da se paralelizuju. U stvari jedino ECB (koji ima 0 zastitu i samo je osnova za sve ostale) i CTR mogu da se paralelizuju. Sve ostalo nije paralelizacija, vec je samo enkripcija manjih delova kao zasebnih celina, i to nije isto, niti je isti stepen zastite.
Ovo vredi za TrueCrypt recimo, kome to nije bitno, jer ionako mora random blokovima da pristupa/upisuje, pa ne moze XTS da juri prethodne blokove. Ali kada se enkriptuje arhiva CTS/CBC modom, ne moze da se paralelizuje, jer svaki blok zavisi od prethodnog.
[ Nedeljko @ 31.07.2013. 08:48 ] @
Govorio sam o kriptografskim algoritmima, koji rade blok po blok, a ako baš hoćeš mod uz koji imaš paralelizaciju, eto ti ga counter mode, koji si i sam pomenuo.

Tvrditi da ECB nudi 0 stepen zaštite je smešno. Daću ti književno delo na engleskom u ASCII formatu kriptovano AES-om od 256 bita u ECB režimu, pa pogađaj koje je u pitanju delo od svih dela približne dužine. To pije vodu samo ako se u fajlu često ponavljaju delovi koji nisu manji od bloka, a kriptosistem sa malim blokovima znaš kako je inače upotrebljiv.

Osim toga, standardan softver za enkripciju će zbog smanjenja redundanse (koju bi kriptoanalitičari mogli da iskoriste) prvo da komprimuje sadržaj (dobro, to i nije baš paralelno kada se radi o jednom fajlu), pa da vidim kako ćeš onda da tražiš mustre koje je ECB režim ostavio.
[ Dexic @ 31.07.2013. 09:36 ] @
Mani se tih prica, kad budes u neku vladinu ustanovu ili ozbiljnu firmu ubacio softver sa ECB enkripcijom, a da to nije u nekoj banana Srbiji ili slicno, onda mozemo da pricamo o tome da je ECB siguran.
Ja nisam kriptoanaliticar da moj uspeh u dekripciji necega uzimas kao osnov za to da li je nesto sigurno :D


Counter mode se inace ne primenjuje kada se trazi veci stepen zastite, niti se primenjuje ukoliko ne mora (a mora jedino pri random pristupu podacima).
[ EArthquake @ 31.07.2013. 09:56 ] @
mislim da se niste razumeli

mislim da je Nedeljko mislio na paralelizaciju unutar algoritma, znaci na nivou bloka
tu vec ima mesta za paralelizaciju s obzirom na uobicajeni dizajn blok cipher-a
a sto se AES-a tice, hardverska podrska vec jede malu decu
bukvalno mi je 10 puta brza enkripcija/dekripcija sa tim dodatnim instrukcijama.
Jedino sto hard disk ne moze da izvuce 800 megabajta u sekundi kolko procesor moze da dekriptuje :D


inace, i dekripcija kod CBC moda moze da se paralelizuje (just saying)
[ Dexic @ 31.07.2013. 10:02 ] @
Kako ces ECB na blok od 8 ili 16 bajtova da paralelizujes???
[ Nedeljko @ 31.07.2013. 10:22 ] @
Earthquake

Ne, mislio sam na baš paralelizaciju kod koje se veći broj blokova obrađuje paralelno, a ne na paralelizaciju unutar bloka. Kod nekih algoritama može i to donekle (paralelizacija unutar blokova). Brzo množenje se obavlja pomoću FFT, koja se može paralelizovati, ali bi onda blokovi trebali da budu dovoljno veliki da paralelizacija ima smisla. No, nisam mislio na to.


Dexic

Ja nisam rekao da ECB nudi u opštem slučaju isti nivo sigurnosti, ali je problem u ovome:
Citat:
Dexic: ECB (koji ima 0 zastitu i samo je osnova za sve ostale)

Naveo sam i pod kojim uslovima on ima slabosti. Kada se podaci prethodno dobro komprimuju - nema.

Osim toga nastupaš kao neko ko je već radio kriptografiju za neku vladu, vojsku itd. Obzirom da to nije slučaj, mogao bi da se spustiš na zemlju.

Postoji li jedan jedini slučaj u istoriji da je nešto razbijeno, a da je problem bio u tome da je primenjen ECB sa prethodnim komprimovanjem otvorenog teksta najboljim kompresorom tog vremena ili da je problem bio u tome da je primenjen Counter režim? Znači, pretpostavka je da je sve ostalo bilo urađeno kako treba i da je problem bio u tome.
[ Ivan Dimkovic @ 31.07.2013. 11:11 ] @
Citat:
Nedeljko:
Evo ti ga fotošop. Filtere može da primenjuje na svako parče slike ponaosob. Možda ponekad to nije tako, ali algoritmi za rad sa grafikom (2D i 3D) su uglavnom takvi da se mogu potpuno paralelizovati. Kriptografski algoritmi su takođe blokovski, tj. obrađuju velike količine podataka u odvojenim blokovima. Igranje šaha se može odlično skalirati.

Što kolega zemljotres (šala, bez ljutnje) reče, otvori 20 tabova u fajerfoksu i radiće u 20 niti. Za to ograničenje Windows-a na grupu od 64 jezgra, osim ako koristiš nove API funkcije nisam znao, ali mi smo daleko od 64 jezgra na tipičnim PC-jevima. Radi se o tome da ako nabudžim 16 jezgara, hoće li imati efekta. Programi koji glavne zadatke paralelizuju će svakako raditi brže.


Zapravo, ti 2D/3D algoritmi su nesto sto se zove "embarrassingly parallel" klasa problema.

Kada imas takav problem, nije tesko implementirati algoritam koji se skalira lako na N jezgara, medjutim problem je sto vecina problema sa kojima se susreces negde u sebi ima "usko grlo" i ne mogu se svesti na lepe "embarrassingly parallel" blokice.

Primera radi, uzmes neki kodek za sliku, obicno su sve transformacije (DCT, DWT i sl...) lake za paralelizaciju - medjutim, entropy koder obicno nije, ili zahteva vrlo inventivne implementacije koje se ne vidjaju tako cesto.
[ Dexic @ 31.07.2013. 11:14 ] @
Nedeljko, kada budes stavio softver sa ECB modom u neku vladinu ustanovu, onda reci da je ECB dovoljno siguran. Posto znam da to nece biti dozvoljeno, stojim pri stavu da je ECB nesiguran (bio bi dozvoljen da jeste).

U pravi si da pod nekim uslovima moze imati sigurnost, ali ako postoji ishta od poznatih podataka cleartexta ta sigurnost se gubi. Posto se za proveru sigurnosti smatra da je kompresija samo obfuskacija a ne zastita, onda se smatra i da je nacin kompresije poznat, samim tim i output kompresije, pa samim tim i output poznatog cleartexta.

Primera radi, header za WORD dokumenat je prilicno poznat, i znace se kako ce biti kompresovan neki delic. Znamo dakle koji output ce dati. (jos gre ako je obican text u pitanju, gde nema random binary data). Samim tim, kompresija je samo nesto sto dodaje obfuskaciju a ne i zastitu.

Jedini nacin da se predje preko ovoga je razlicit key za razlicite blokove. Sto onda nije ECB vise, jer se koristi IV/salt efektivno, i postaje blizi CBC-u.
[ EArthquake @ 31.07.2013. 12:28 ] @
odosmo u off topic zesci ...
ja hteo da se malo vise prica o Intel ME , a zaglibismo u neku levu pricu

moji poslednji komentar u off topic delu :

Parallel AES Encryption Engines for Many-Core Processor Arrays
http://hgpu.org/?p=6936 , priznajem, nije neko zvunco ime , ali eto moze ...

sto se ECBa tice, generacije programera su ubedjene da je problem kod ECBa to sto mozes da vidis pingvine kroz njega.

Nije samo to problem, problem su ti i replay napadi i integritet podataka (CBC ti pruza integritet, CTR ne , mada postoje prosirrenja koja pruzaju oba, CXT, XST ...)
i jos dosta sitnica ... slazem se da prethodna kompresija nije preveliko resenje. Off the top of my head, nemam konkretan primer, ali
kad bih ga imao, verovatno bi bilo pitanje zloupotrebe poznavanja nekih dodatnih osobina ciphertext-a. Kao sto ste vec rekli , CTR mod ne pati od tog
problema, ali ima druge... Najbolje bi bilo da se sva trojica ostavimo kriptografije ... :)

Ili da uzmemo da resavamo Matasano crypto zadatke: http://www.matasano.com/articles/crypto-challenges/
Jako su dobri, prakticni i zanimljivi.

END OF OFF TOPIC XMISSION
[ Nedeljko @ 31.07.2013. 12:36 ] @
Je li, a koliko si to kripto softvera za vladu ti implementirao? Ovo postaje neozbiljno.

Kompresija nije samo obsfurkacija. lossless kompresija ne menja entropiju, ali smanjuje veličinu. Redundansa podatka se definiše kao broj bitova podatka (teorijski maksimum entropije za podatak date veličine) minus entropija podatka. Redundansa je 0 ako i samo ako je reč o nizu nasumičnih nezavisnih bitova ravnomerne raspodele nula i jedinica. U protivnom je veća od nule. Pošto se lossless kompresijom entropija ne menja, a veličina se smanjuje, redundansa se smanjuje.

Ako redundanse ulaza u kriptoalgoritam nema (tj. jednaka je 0), onda kriptoanaliza nije moguća. Nije samo infeasible (nemoguća u praksi), već je impossible (nemoguća čak i u neograničenom vremenu sa neograničenom memorijom).

Kriptoanaliza se uvek zasniva na redundansi. Što je ona veća, izgledi za uspeh kriptoanalitičara su veći i obrnuto. Stoga se kompresijom postiže ne samo obsfurkacija, već i fundamentalno smanjivanje redundanse.


Ivane,

Znam ja da paralelizam u opštem slučaju ne ide tako lako, ali sam naveo primer masovne upotrebe računara (PS je vrlo popularan program) gde su rezultati odlični.
[ Nedeljko @ 31.07.2013. 12:40 ] @
Taj pingvin se vidi kroz ECB zato što nije komprimovani grafički format u pitanju. To je vrlo namešten školski primer. Prebaci tog pingvina u jpg (ali ne lossless, nego da sačuvaš 90% kvaliteta), pa da vidim kako će da se vidi kada je redundansa ulaza niska.
[ Dexic @ 31.07.2013. 13:36 ] @
Ja ne radim algoritme vec ih samo primenjujem. Na pomen ECB-a umesto CBC-a bi u najboljem slucaju dobio slobodan dan da se nivo buncanja smanji u krvi.

Iskreno osim u tvom postu ja nisam naisao da je iko preporucivao ECB, osim za probni softver bilo kog tipa uospte.
Mozda ne znam samu matematiku, ali nemam razloga da sumnjam u reci ljudi koje se time bave kad kazu "No ECB for security".
[ EArthquake @ 31.07.2013. 13:40 ] @
to je bila sala , odnosno citat, naravno da znam da je ono namesten primer ...
[ Nedeljko @ 31.07.2013. 17:29 ] @
Dexic

Šta ti to primenjuješ? Ajde oladi. Vidi se da nisi stručnjak za kriptografiju i da te za to niko ozbiljan ne bi angažovao jer inače ne bi izvaljivao stvari poput
Citat:
Dexic: ECB (koji ima 0 zastitu i samo je osnova za sve ostale)

Dve gluposti u jednoj rečenici - 0 zaštita i osnova za ostale
Citat:
Dexic: Posto se za proveru sigurnosti smatra da je kompresija samo obfuskacija a ne zastita

Nikad čuo za redundansu.

i onda si još slobodan da mi prišivaš stvari tipa
Citat:
Dexic: Iskreno osim u tvom postu ja nisam naisao da je iko preporucivao ECB, osim za probni softver bilo kog tipa uospte.

Primenjuješ ti, ali ne kriptografske algoritme, već kriptografske aplikacije i biblioteke. Taman da ne treba da znaš ništa više od pojmovnika

1. simetrična kriptografija,
2. asimetrična kriptografija,
3. javni ključ,
4. privatni ključ,
5. digitalni potpis,
6, digotalni sertifikat,
7. kriptografski heš,
8. digitalni timestamp potpis,
9. čip i kartice za digitalno potpisivanje i enkripciju/dekripciju.

Za ostalo te definitivno niko ne bi platio. Na pomen ECB-a bi ti eventualno neko rekao "time se velike čike bave".
[ Dexic @ 01.08.2013. 00:16 ] @
ECB je osnova za ostale modove.
Priznajem da verovatno ne znam matematiku kriptografije koliko ti, ali si prvi koji je predlozio ECB kao siguran mod. Mozda si u pravu, ali zasto onda ne bi bio koriscen u 7Zipu (koji koliko znam koristi CBC) kada je to arhiva bez redudanse?

Nemoj da mislis da ti prkosim, ali mi nigde niko ranije nije predlozio ECB. Cak ni za arhive. Zasto bi onda tvoj stav uzeo kao validan? Jos teorija koja nije primenjena u praksi?
[ Nedeljko @ 01.08.2013. 02:17 ] @
Izvini, gde ja to predlažem ECB kao siguran režim? Ja samo odgovaram na onih tvojih 0 zaštite. Da, postoje uslovi pod kojima je on dovoljno dobar, ali to ne znači da treba ostaviti korisnika na cedilu da razmišlja o tome da li u konkretnoj situaciji sme da upotrebi taj softver ili ne, već mu se nudi opšte rešenje.

Što se 7zip-a tiče, ne postoji algoritam kompresije bez redundanse. 7zip koristi valjda LZMA2 kao najjaču kompresiju (ako je najjača), ali je i ona daleko od 0 redundanse.

Uzmi lepo neki program za računanje prvih sto miliona cifara broja bez ispisivanja razmaka i praznih redova. Smesti ih u ASCII datoteku i podeli dužinu u bajtovima sa . Nijedan kompresor ti neće komprimovati taj niz na manje od toliko, mada postoji način da se on predstavi na sažetiji način - tim programom.

Niz cifara broja pokazuje mnoge statističke osobine niza nezavisnih slučajnih dekadnih cifara sa ravnomernom raspodelom (ista raspodela svih cifara, parova cifara, trojki cifara itd.). Doduše, to za sada nije dokazano teorijski, već je samo provereno statistički za onoliko prvih cifara koliko ih je izračunato do sada (10000000000050 je valjda trenutni rekord). Zbog toga nijedan kompresor ne uspeva da ga uhvati ni za glavu ni za rep, a možeš ga preneti na flešu na mnogo manjem prostoru prenošenjem programa za njegovo generisanje.

Slično tome, probaj da tom LZMA2 kompresijom komprimuješ slike, a probaj da to uradiš nekom lossless kompresijom specijalizovanom za slike. Isto važi i za izvršne fajlove i ostale specifične vrste podataka. Specijalizovani metodi lossless kompresije za njih mogu dati mnogo bolje rezultate od opštih metoda, kao što je LZMA2. Naravno, kompresije koje nisu lossless, mogu još više da komprimuju, ali nije o njima reč.

Pošto redundanse ostaje i to mnooogo, naravno da nije svejedno kako ćeš da šifriraš komprimovane podatke. Eliminacija ponavljanja je dovoljna da syebe slabosti ECB-a.
[ Dexic @ 01.08.2013. 05:18 ] @
Citat:
Nedeljko: Izvini, gde ja to predlažem ECB kao siguran režim? Ja samo odgovaram na onih tvojih 0 zaštite. Da, postoje uslovi pod kojima je on dovoljno dobar, ali to ne znači da treba ostaviti korisnika na cedilu da razmišlja o tome da li u konkretnoj situaciji sme da upotrebi taj softver ili ne, već mu se nudi opšte rešenje.

Aha, pardon! Tu jesi u pravu.

Citat:
Pošto redundanse ostaje i to mnooogo, naravno da nije svejedno kako ćeš da šifriraš komprimovane podatke. Eliminacija ponavljanja je dovoljna da syebe slabosti ECB-a.

A primer eliminacije redunansi i primena ECB-a je gde vidjena i primenjena?
[ Nedeljko @ 01.08.2013. 08:14 ] @
Redundansa != ponavljanje.

Redundansa(X) = broj_bitova(X) - entropija(X).

Primer: u Nizu od milion bitova ima barem pola miliona jedinica ili barem pola miliona nula (jedno od to dvoje). Dakle, neka cifra se ponavlja, ali ako je savršeni random, ima redundansu 0.

Teorema 1: Eliminacija redundanse = savršena kompresija.

Činjenica: Savršena kompresija za sada ne postoji.

Teorema 2: Lossless funkcije ne menjaju entropiju.

Teorema 3: Lossless kompresijom se redundansa smanjuje za onoliko za koliko smanjuje veličinu u bitovima.

Činjenica: LZMA2 ima prozor od npr. 64 megabajta.

Zadatak: Napraviti random fajl od 10 megabajta, pa jedan fajl od 20 megabajta koji sadrži dve kopije ovog od 10 megabajta, pa taj od 20 megabajta komprimovati 7Zip arhiverom LZMA2 kompresijom sa veličinom prozora od 64 megabajta. Uraditi to isto sa random fajlom od 100 megabajta i fajlom od 200 megabajta koji sadrži dve kopije ovog od 100 megabajta. Zatim uporediti stepene kompresije. U prvom slučaju je 50%, a u drugom 0%.

Zaključak: Zbog efikasnosti, LZMA2 metod kompresije ne eliminiše ponavljanja dugih blokova koji se pojavljuju pre više od 64 megabajta, pa neće eliminisati sve nedostatke ECB-a. Slično je sa drugim metodama koje imaju prozor. Huffman ga nema, ali isti blokovi imaju isti komprimovani zapis.

Napomena: u ranijim porukama sam pod eliminacijom ponavljanja mislio na eliminaciju pojavljivanja više od jedanput istog bloka bitova koji po veličeini nije manji od bloka za šifriranje.
[ Dexic @ 02.08.2013. 05:21 ] @
Da li aam dobro razumeo da kazes da onda nije moguce kompresovati tako da nema redudanse i samim tim nema logike koriscenje ECBa?
[ Nedeljko @ 02.08.2013. 10:19 ] @
Nije moguće komprimovati bez redundanse. Međutim, moguće je komprimovati tako da nema poanvljanja blokova za šifriranje. To već eliminiše mane ECB-a u dovoljnoj meri. Međutim, standardni metodi kompresije zbog brzine na dugim fajovima ne rade tako.

Takođe, problem je što egzaktni dokazi kriptografske sigurnosti za sada ne postoje, osim u najjednostavnijim slučajevima (simetrični XOR algoritam sa ključem dužine poruke, koji je savršeni random, kao i delenje tajni su primeri). Razlog je taj što matematika nije dostigla potreban stepen razvoja. Razmotrimo sledeće probleme:

Citat:
1. Određivanje privatnog ključa na osnovu javnog.

Pri dizajnu algoritama se zahteva da normalna upotreba ključeva bude efikasna, a to definitivno znači da mora biti polinomijalna (). Kaže se da to mora da pripada klasi P. U tom slučaju je provera da li je neki niz bitova privatni ključ ako je javni ključ poznat takođe efikasna, tj. pripada klasi P. Primeniš na neki blok bajtova jedan od ta dva ključa, pa onda onaj drugi, vidiš da li si dobio isti blok bajtova i samim tim da li ta dva ključa čine par. Problem je što kada je privatni ključ nepoznat, mogućih nizova bitova za njega ima eksponencijalno mnogo, pa samim tim bi gruba sila zahtevala eksponencijalno vreme za njegovo razbijanje. Međutim, na zamišljenoj mašini sa neograničenim paralelizmom (takozvanoj nedeterminističkoj mašini) se onda taj problem može rešiti u polinomijalnom vremenu, tj. pripada klasi NP.

Dakle, problem određivanja privatnog ključa na osnovu javnog uvek pripada NP klasi problema. To je teorijski maksimum složenosti tog problema. Sama klasa NP ne deluje praktično jer mašine sa neograničenim paralelizmom ne postoje. Međutim, nas zanima da li je problem određivanja privatnog ključa na osnovu javnog rešiv efikasno, tj. da li pripada klasi P. Kada bi neko uspeo da dokaže da to nije slučaj za barem jedan algoritam, on bi dokazao da je P != NP, a P vs NP je jedan od čuvenih nerešenih matematičkih problema. OK, možda nije potrebno da problem određivanja privatnog ključa na osnovu javnog bude vn klase P, možda je dovoljno da ne bude rešiv u polinomijalnom vremenu nekog niskog stepena, ali i tu su rezultati mršavi. Do sada nije dokazano čak ni da postoji NP problem koji nije rešiv u linearnom vremenu. Uz neka ozbiljna memorijska ograničenja dokazano je da postoje NP problemi koji nisu rešivi u vremenu . Dakle, postojeći rezultati su daleko od onoga što je potrebno za dokaz kriptografske sigurnosti. Pritom se sve ovo ne odnosi na kriptografske algoritme, već na ikakav NP problem.

2. Dešifrovanje poruke koja je šifrovana nepoznatim ključem.

Ako bismo isprobavali sve nizove bitova koji su kandidati za ključ (a ima ih eksponencijalno mnogo) i mogli u polinomijalnom vremenu da detektujemo koji kandidat za otvoreni tekst je smislen, onda bismo na osnovu redundanse koja je skoro uvek ogromna mogli da odredimo ključ. Recimo, ako znamo da je tekst u ASCII obliku i pisan na engleskom jeziku, uz pomoć rečnika bismo mogli da detektujemo šta ima smisla. No, pošto kandidata za ključ ima eksponencijalno mnogo, takav pristup bi to rešavao u eksponencijalnom vremenu, ali na zamišljenoj mašini sa neograničenim paralelizmom u polinomijalnom. Dakle, opet je NP teorijski maksimum složenosti razbijanja poruke i važe sve prethodne napomene.


Stoga se bezbednost zasniva na empirijskoj proveri. Niko se do sada nije setio kako praktično da razbije neki kriptografski algoritam i objavio to. Da, pakuju se problemi da budu teški koliko i neki problemi koji se smatraju teški. Međutim, tu postoje sledeći problemi:

1. Obično nije dokazano da je problem razbijanja težak koliko i taj drugi problem. Ima slučajeva kada jeste, ali retko. Polaženje od pretpostavke da neko mora da reši taj problem da bi razbio algoritam (tj. da ne može na neki alternativan način) je pogrešno. Za ovo je potrebno dokazati da može da se napiše efikasan program za rešavanje tog problema koji se smatra teškim u nekom programskom jeziku (nebitno kom) sa zamišljenim proširenjem funkcijom koja efikasno vrši razbijanje. To je u nekim retkim slučajevima dokazano.

2. Nije poznato koliko su ti problemi koji se smatraju teškim zaista teški.

Pošto dokaza bezbednosti za sada nema, primenjuje se više slojeva zaštite što veće ukupne procenjene debljine. Zato se ECB ne preporučuje, a CTR se koristi samo kada postoji opravdanje za njega.
[ Dexic @ 02.08.2013. 10:47 ] @
Da li bi mi, kao laiku, sazeo tu teoriju i rekao prakticno da li je ikada igde javno, orpavdano i u velikoj razmeri (korisnika/primene) koriscen ECB mod i da se to resenje smatra sigurnim?
[ Nedeljko @ 02.08.2013. 13:14 ] @
Ne postoji ni jedan razlog da se ne stave dodatni slojevi zaštite, koje je moguće staviti. Pošto je uvek moguće primeniti barem CTR, za ECB-om ne postoji potreba.

Međutim, poenta je u onom "ECB nudi 0 zaštite". Daleko od toga da nudi 0 zaštite. Može se primeniti tako da nudi dovoljnu zaštitu i bezbednosno najzahtevnijim korisnicima (vojska, vlada), ali

1. Nema dokaza bezbednosti ni za jedan algoritam, pa samim tim ni za režim od koga je slaba vajda ako se vidi kroz algoritam.
2. Ne postoji nikakva potreba za nestavljanjem dodatnih slojeva zaštite jer se uvek mogu staviti.

Zato ga nećeš nigde videti u praksi, a tamo gde se propisuju mere za postizanje najvišeg nivoa bezbednosti se naravno zabranjuje, jer nije u skladu sa tačkom 2.
[ Dexic @ 02.08.2013. 16:58 ] @
Znaci teorija samo. OK.
[ Nedeljko @ 02.08.2013. 22:13 ] @
Pa, sad, ako je paralelizacija bitna, to je sasvim dovoljan razlog da se primeni CTR režim.
[ Dexic @ 03.08.2013. 05:46 ] @
Za enkripciju mnogo bolja primena radi paralelizacije je big-block separation uz primenu CBC/CTS/XTS moda. Npr. blokovi od 1MB ili 64KB se tretiraju kao zasebne celine i samo oni se celi enkriptuju, dok se veci dele na te celine, a ne zavise jedni od sadrzine drugih. Uz naravno dobar salt/IV generator.

Mislim da CTR ima jednu jedinu primenu - byte_random read/write access ili kada je nepoznata velicina ulaza. Nigde drugde ne bi trebao biti primenjen?
[ newtesla @ 03.08.2013. 06:25 ] @
^^Ovo pisanije i dalje ima veze sa temom zaključavanja overkloka ako nemaš taj-i-taj čipset???
[ Burgos @ 03.08.2013. 09:23 ] @
Nema veze, uživam kada se ovde pojavi kvalitetna i interesantna diskusija (svakih godinu dana).
[ Dexic @ 03.08.2013. 09:40 ] @
Nijedna poruka posle 1. nema veze sa temom inace ;)