Da li imas 2 particije Win i OSX ili samo Win na Macbook-u ?

Ako imas dual boot, BitLocker ti vazi samo za Win, predpostavljam..

Imam dual boot (OS X + Windows) ali OS X particiju planiram da takodje FDE-ujem sa FileVault2-jkom. Na OS X-u nemam nista osetljivo doduse vec je FV2 samo tu da masinu ucini potpuno neupotrebljivom bez re-imaginga ako je neko drpi i bilo kakve podatke nedostupnim.

BitLocker vazi samo za Win particiju (bas kao sto i FV2 vazi samo za OSX), zbog toga je TrueCrypt prakticno bolje resenje ako se neke particije dele posto je format podrzan i na OS X i Windows sistemima.

Ah, da, ako koristite BitLocker na Win8/Srv2012 masinama bez TPM-a, obratite paznju na ovu polisu:

http://technet.microsoft.com/en-us/library/jj679890.aspx



Pretpostavljam da su u MSFT-u procenili da je po defaultu ogranicavanje sifre na slova alfabeta (i to bez malih/velikih slova) dobro za "user experience" zbog frustrirajucih problema ako se boot keyboard layout razlikuje ili idiot korisnik nije u stanju da replicira svoju sifru zato sto je nije dobro uneo...

Ali, svejedno, nije lose imati jos malo entropije... naravno, daleko bitnije je da je sifra sto duza i da korisnik moze istu da zapamti od toga da ima alfanumerike ili kombinaciju malih/velikih slova, kao sto je xkcd objasnio:

https://xkcd.com/936/

Hmm ceo zivot sam onda ziveo u zabludi. Znaci 4 reci (pozeljno nepovezane ili bar nestandardne) su bolje od kombinacije od 10+ karaktera ?!
Sto znaci da je onda jos jaca sifra koja se sastoji od 4 reci koje su napisane pomocu znakova i brojeva. Ili je dovoljno i 4 random bez kerefeka ?

Fora je da nasumicni znakovi/brojevi/kerefeke cine da se sifra lako zaboravi sto onda motivise usera da sifru zapise i time totalno eliminise kompletnu poentu "sigurne sifre".

Umesto par "kerefeka" dodaj par najobicnijih nasumicnih reci (nekoliko slova za svaku rec), sve malim slovima i zapravo si povecao sigurnost sifre mnogo vise a nisi povecao bitno opasnost da ces sam da zaboravis sifru.

Tuzno je sto ozbiljne firme koje su same umesane u standarde koji koriste jaku kriptografiju nisu svesne toga.

Ima jedan poveci proizvodjac cipova, da ga ne imenujem, koji ima "jake standarde" za pristup svojim dizajn dokumentima, nesto tipa - sifra mora da ima bar 12 slova sa velikim i malim slovima, brojevima i specijalnim znakom. I to vrlo specificno, inace se sifra odbija kao "laka". I tako svaka 3 meseca, sifra mora da se menja - ponovo sa svim "vrlo sigurnim" kriterijumima.

Totalna budalastina, mogu da se kladim da vecina ljudi kada jednom u 10 puta "ubodu" idiotizam koji sistem smatra "jakom sifrom" tu sifru momentalno zapisuju / snimaju negde posto sansa da svaka 3 meseca memorisu korektno novi skup slucajnih ASCII karaktera nije velika.

Sigurnost - do mojeg.

Ivane, jel' moze neki disk I/O test tog rMBP SSD-a sa i bez BitLockera? (ili barem sa, samo mi potvrdi da li imas model sa PCI-e SSDom)

Mislim da TC neće skoro uvesti podršku za UEFI, tj. nisu duuuuuugo vremena mrdnuli od poslednje verzije i nema nikakvih naznaka kada će da izbace novu. :(

Imam model sa PCIe SSD-om ali mi je sada ceo disk bitlocker-ovan (mada, mogu da probam da uradim test na EFI sistemskoj particiji ako ti to radi posao).

Sta hoces da poteram?



Toga se i pribojavam, posto je poslednji release iz 2012.

Mislim da je jedan od problema to sto TrueCrypt ima neku svoju licencu za kod pa je verovatno slab interes za 3rd party razvojem :( Format je, doduse, javan pa neko moze i da raspise alternativu ali kada je security sw. u pitanju to je upravo ono sto >ne zelis< (da gomila ljudi koji pojma nemaju sa enkripcijom krenu da prckaju i implementiraju kripto sw.).

Takodje, fakat da je format poznat nije neka unikatna prednost TC-a, koliko znam i BitLocker format je poznat i isto tako bi neko mogao da napise nezavisnu implementaciju.

Sto se TC-a tice, dodavanje UEFI podrske je, verovatno, i "lako" i "tesko" u isto vreme.

Lako je, posto nije potrebno pisati nov kripto kod.

Tesko je, posto UEFI zahteva malo kompleksniji chainload-ing. Sa MBR-om je bilo vrlo lako, posto samo upises u MBR da ti ucita neki tvoj bootloader koji onda posle pozive OS bootloader gde se u ranoj fazi inicijalizacije inicijalizuje file-system drajver a do tog momenta OS dobija podatke preko int13h BIOS handlera.

Sa UEFI-jem situacija postaje komplikovanija, posto u momentu zavrsetka UEFI BootServices faze je sistem u 64-bitnom modu i OS loader koristi UEFI firmware za pristup podacima. To znaci da je verovatno neophodno raspisati UEFI drajver koji bi na jako niskom (firmware) nivou "varao" UEFI OS bootloader

BitLocker izbegava ovaj problem na jednostavan nacin: integrisan je u sam Windows UEFI OS loader pa nije potrebno nista "podmetati". TC ili bilo koji drugi FDE nemaju taj luksuz i nekako moraju da nateraju Windows OS loader da pokupi kernel i bazne drajvere sa kriptovanog diska a ne mogu da se oslone na BIOS fore (int 13h)

Cak i ako to rese, sledeci problem su UEFI "secure boot" sistemi gde je u boot procesu, takodje, ukljucena i kriptografska verifikacija loader-a i drugih UEFI komponenti. Mada, cenim da bi TC tim sigurno to mogao da resi sa potpisivanjem svojih komponenti adekvatnim UEFI kljucem.

Dovoljno je samo na enkriptovanoj Windows particiji da pokrenes obican CDM ili sta god ti slicno bude pri ruci.

Ako mozes da "sparujes" jedno 4GB upisa, zgodno bi bilo da pokrenes CDM sa tom opcijom.

sa specijalnim AES-NI instrukcijama u upotrebi , enkripcija/dekripcija leti
na obicnom disku je sam disk tu bottleneck
na SSDu bi taman trebalo da se podudaraju , tako da cak i ako postoji usporenje, bice neznatno
barem ja ne mogu da primetim razliku (samsung 840 PRO i i5ica neka proslogodisnja)
voleo bih da vidim rezultate

inace, malo offtopic, sto se truecrypt-a tice, postoje druge implementacije
"linux"-ov cryptsetup podrzava truecrypt FDE drajvove u potpunosti
(bas su mi pre 2 meseca prihvatili patch )
a postoji i cisto userspace varijanta preko tcplay-a

gomila ljudi nema bas mnogo poverenja u TrueCrypt bas zbog njihovog poprilicno zatvorenog
nacina razvoja open source projekta :)
a i cinjenica da niko ne zna ko je u stvari autor TrueCrypt-a mu ne daje bas mnogo na pouzdanosti
elem, skupili se ljudi i pokrenuli ovo http://istruecryptauditedyet.com/ sto je svakako dobra inicijativa

i jos jedan off , sto se tice rukovanja lozinkama , bacite pogled na YubiKey
https://www.yubico.com/products/yubikey-hardware/yubikey/
odlicna spravica, u najprostijem obliku se ponasa kao "tastatura" pa odkuca
sifru koju treba (mada vidim da Dimkovic nije bas fan dodatnih uredjaja) ali
moze vrlo lako da se koristi za implementaciju dvofaktorske autentifikacije

Teorija i praksa su u teoriji iste, ali u praksi razlicite :)

Sve to naravno zavisi od primene, ali uz ogroman I/O, kada nema vremena da se uradi thread queuing, ni AES-NI nije neprimetan overhead, i moze preko 50% da uspori PCI-e SSD koji inace moze oko 1GB/s da ispuni.

Cek da vidimo sta kaze Ivanov rezultat.

Za TrueCrypt sam video dobro usporenje i na USB2 diskovima, bez AES-NI, ako se prilicno koristi disk.

truecryptov benchmark za AES sa CPU podrskom je dao ~650MB/s , bez CPU podrske za AES ~70MB/s
ali taj benchmark je bez interakcije s diskom pretpostavljam

Smatras da je 650MB/s dovoljno da se ne oseti? Nema sanse, bez offloadinga, sto znaci da samo za asinhroni transfer mozes imati takve "rezultate". Pod navodnicima, jer cim bude ozbiljnog koriscenja, kada ne moze da se postigne offloading, imaces znaci ispod 50% performanse.

I naravno, pod uslovom da se CPU ne koristi ni za sta drugo, ali ako u isto vreme radis render, znaci da offloading nece moci da da iluziju uradjenog zadatka, pa ces osetiti, u ovom slucaju extremno, usporen rad.

Doduse, to su posebne situacije.

jasno , samo dajem brojke koje ja imam
i nudim svoje dosadasnje iskustvo

na hard disku , sa FDU , bez CPU AES podrske , kad sam kopirao fajl od par gigabajta
mogao sam samo da sedim i da cekam da se zavrsi, nista drugo pametno nije moglo da
se radi na racunaru, posto sve ide kroz CPU

na SSD + CPU podrska , ja ne primecujem

@Dexic, odradicu test u ponedeljak posto sam sad u JP pa ne mogu da se posvetim testu dovoljno vremena.

Inace je moj stari Ivy Bridge Vaio Z izvlacio oko 600 MB/s AES NI ako se dobro secam.

Inace, koliko vid BitLocker moze da se konfigurise da koristi AES crypto od samog SSD-a ako isti to podrzava. To bi u teoriji offloadovalo crypto sa CPU-a kompletno.

600MB/s sa jednim threadom, nadam se??
Nesto mi je to premalo, na dual core Sandy Bridge CPU-u ide 1.5GB/s MT.

Koliko se secam, test je bio sa jednim thread-om.

Ali sad nemam vise Z, doduse jos imam stari Retina Macbook Pro sa Ivy Bridge arhitekturom pa cu da probam AES-NI na oba.

Jbt, pa "skoro" si uzimao Z, a vec ga nemas :D

Cek, BitLocker na W7 nije UEFI friendly? Tj. jel u pitanju isti BitLocker?


Pa 'ajde sto zapisuju, vec sto bilo kako da ti kogod provaljuje sifru moze da radi substitution A/4, i/1, a/@,... Ali ni ovo sto xkcd savetuje nije bas potpuno imuno, jer kao sto postoje dictionary, tako ih ima i sa kompletnim recima gde alat pravi kombinacije koje bi ti pravio u svojoj sifri. Najbolje napraviti kombinaciju nekoliko reci od kojih je bar jedna izmisljena/nepostojeca (recimo dimkovicizam*). :D

_{*kuca ti u Nemacku, radis u Japan, zivis za fajt sa Apple-om. :P}

W7 BitLocker bi trebalo da radi sa UEFI-jem podjednako kao i W8 BitLocker, pod uslovom da je Windows instaliran u UEFI modu, naravno.

Da u UEFI, nego posto si eksplicitno naveo W8 i Wserver pomislio sam da W7 nece raditi... a pitam jer kolega hoce da ukljuci BitLocker na W7 na MBP.



Sto se tice jacine sifre, prilicno sam konfuzno napisao sad vidim :D , ali je poenta da ako moze da se radi substitucija karaktera kroz poznate reci kao jedan metod, tako mogu te iste reci iz dictionary-a da se kombinuju cele u niz od tri, cetiri, pet reci - odatle savet za bar jednom izmisljenom reci koje nema u dictionary-ju. :) A primer je naravno sala, sa poznatim referencama u vezi tvoje vecite "borbe" sa Apple-om na neki nacin. :)

Ivane, hoce skoro taj benchmark?:)

Bice veceras, sorry.

10 dana traje benchmark od 4GB, to je los znak za performanse :D

Evo rezultata za Haswell rMBP:

#1 - Kriptovana sistemska particija (BitLocker), 4 GB:



#2 - Nekriptovana particija, morao sam da koristim UEFI sistemsku particiju pa je test fajl samo 100 MB:



U principu, AES enkripcija ne cini neku drasticnu razliku ali nije ni neprimetna tj. definitivno se moze registrovati.

Cisto poredjenja radi, na istom sistemu sam odradio test u OS X-u, kako bi utvrdili da li ima neke bitne razlike u I/O performansama izmedju OS X-a i Windows-a kada se radi o PCIe SSD-u:

Ovo je jedini disk bench koji sam nasao - meri samo sekvencijalni I/O, ali je to IMHO dovoljno da vidimo da li postoji neka razlika:

I..... na kraju si odlicno pokazao da je Apple PCI-e resenje slabije ne samo od Sonyevih, vec i od Samsung840 RAID opcije :)

Hvala - ko je bese ono hvalio rMBP zbog PCI-e SSDa? (ne mislim ne tebe, Ivane)

Inace, primetna je razlika u random 4K - koji je inace i slab. Imam vece performanse sa obicnim SATA3 SSDom u IB laptopu, a na desktopu je tek razlika.
U prevodu, sve, sve, ali ovo PCI-e SSD resenje je daleko od necega sto daje ko zna kakve dobre performanse, i sram bilo onoga ko ga je hvalio :D

Slazem se da je Sony ili RAID 840 bolje resenje, naravno ako imas mogucnosti za RAID na laptop masini.

Cisto poredjenja radi, ovo su moji rezultati na Sony Vaio Z masini iz 2012 (poslednja generacija, IvyBridge):



Ovo samo govori u prilog koliko je Sony bio ispred vremena. Jednostavno, Z je bio remek delo tehnike, mada u poslednjoj generaciji vise nije bio toliko ispred vremena kao verzije koje su i dalje imale integrisan dGPU.

Na zalost, pre neki dan je Sony prodao Vaio biznis, tako da vrlo verovatno mozemo da zaboravimo na bilo kakvu sansu da ce se desiti Z ponovo :(

Vece su sanse da ce neko fokusiran na Japan da napravi novi Z, nego Sony :)

Koliki je CPU usage kad si radio test?

Sumnjam da ce novi vlasnik da se zamlacuje sa takvim biznisom posto zahteva ogromne R&D troskove sa malim brojem potencijalnih kupaca.

Mislim, sa jedne strane imas Intel ultrabook platformu, koja gotovo sasvim sigurno ima referentni dizajn i razne vidove pomoci od strane Intel-a, a sa druge strane mozes da pravis svoju platformu sa komponentama koje ti izaberes. Za to drugo ce ti trebati dosta R&D-a za nesto sto vecina korisnika nece znati da cene.

Platforma kao sto je Z se ne moze napraviti prostim kupljenjem OTS komponenti vec zahteva vrlo jak R&D: od PCB dizajna i metoda fabrikacije, preko bus-eva i konektora pa sve do specijalizovanih minijaturizovanih komponenti. O hladjenju i da ne pricamo. Strpati 4-jezgra u prostor (zapreminu) na kome konkurencija muku muci i sa 2 jezgra je bio prilican poduhvat.

Zbog toga je Sony batalio Z. Koliko god to bila revolucionarna masina, ultrabook-ovi su, jednostavno, "dovoljno dobri" za dobar deo market-a na koji su Z masine ciljale.

Mislim, voleo bih da gresim i bicu medju prvima koji bi kupili novi Z, sve i da je za JP trziste (imao sam ranije JP Sony masine i nisam imao nikakvih problema sa koriscenjem istih).



10-12% za sekvencijalne testove. Do 100% za 4K random testove.

LOL, bre!

Evo sad sam odradio isti test na particiji koja nije enkriptovana.

CPU load je ~3% za sekvencijalne testove i ~10% za 4K random

Dakle, BitLocker AES-NI enkripcija dodaje:

- 7-9% CPU ciklusa za sekvencijalne testove
- 90% CPU ciklusa za 4K I/O (!)

E, sad, postavlja se pitanje zasto li je toliko veliki overhead za 4K I/O u CDM-u i da li je taj overhead prisutan i u drugim aplikacijama koje koriste 4K I/O.

Mislim da bi ovo zasluzilo malo dublju analizu koja bi zahtevala znanje o tome kako operise BitLocker-ov I/O drajver. tj. koji je granularitet blokova, posto mi ovo lici na neki clusterfuck tj. debeo mismatch izmedju velicine bloka koji BitLocker koristi i CDM access pattern-a tako da 4K upisi zahtevaju vise operacija na BitLocker nivou rezultujuci u ogromnom skoku CPU zauzetosti.

Takodje, pretpostavljam da je BL oportunisticki nastrojen u ovom slucaju tj. da ce "pojesti" 100% CPU-a ako moze, sto znaci da u nekim realnijim scenarijima gde je CPU u upotrebi doslo do veceg pada 4K I/O performansi zato sto BL filter ne bi mogao da iservisira puno zahteva.

Dakle, ako su vam random I/O performanse kriticne, bar BitLocker nije idealno resenje (za TC nisam siguran posto ga nemam ovde) i mozete ocekivati ili vidan pad performansi ili dostupnost CPU ciklusa.

Isprobao sam upravo TC particiju, 4GB, 4K u CDM-u.
<20% CPU usage je bio max. Oko 20% su i manje read performanse, a prilican je pad write performansi (55-75MB/s bez TC, 35MB/s sa)

Cak i uz obicnu (bez AES-NI), BL bi postigao 200MB/s barem, a verovatno i vise kod tebe. Ne verujem da je bilo kakva potrebna kalkulacija u pitanju!


Ali ne bih to koristio za production mashinu, kad bi toliko usporio.

Btw, upravo sam saznao preko foruma da samo 1 TB PCIe diskovi koriste 4 PCIe kanala, dok 512 GB verzija (koju ja imam) koristi 2 PCIe kanala sto je u saglasnosti sa ciframa koje vidim.

@edit, znaci TC je verovatno vise optimizovan od BitLocker-a - to mi je malo cudno posto da me ubijes ne znam zasto MSFT programeri ne bi bili u stanju da implementiraju visoko optimizovan AES crypto, ali ko zna i cudnije stvari su se desavale :)

Zar rMBP ne koristi PCI-e v3? To bi znacilo oko 2GB/s teoretski, sto ce reci, nema sanse da je overhead 1300-1400MB/s ;)
I da je v2, to je 1GB/s za 2 lane-a, a overhead nije 300-400MB/s.


Ma ko zna sta oni rade :D
Ako u seq. mogu da urade 600-700MB/s sa low CPU usage, nema sanse da je sama kriptografija ono sto trosi CPU.

Ne, trenutni PCIe diskovi koje pravi Samsung su PCIe 2.0.

Sa 2 PCIe lane-a imas oko 800 MB/s protoka zato sto PCIe ima 20% overhead u transportu podataka.



Jasno - kriptografija ne moze biti odgovorna posto TC ne trosi vise od 20% CPU-a, ja tipujem na neku neoptimalnu velicinu blokova sa kojima BitLocker operise.

Ne vidim kako bi povecali CPU usage.
Disk I/O da, ali ne CPU usage jedno 10-20x. (ti imas 8x brzi CPU od mog)