TrueCrypt 6.0a – obsÅ‚uga wielu rdzeni (aktualizacja)
- Dodano: 7 lipca 2008
- Wprowadził: mortoss
- Komentarze: 62
Wreszcie ukazaÅ‚a siÄ™ nowa wersja „multiplatformowego” oprogramowania do szyfrowania plików – TrueCrypt.
Ważniejsze ze zmian to:
- obsługa maszyn wielordzeniowych, umożliwiające wreszcie uzyskanie niemal proporcjonalnego (do liczby rdzeni/procesorów) wzrostu wydajności szyfrowania/odszyfrowywania danych.
- używanie natywnych serwisów kryptograficznych jądra Linuksa (bez potrzeby używania FUSE) dla woluminów XTS.
- wiele innych usprawnień dotyczących zarówno Windowsa, jak i MacOS-a oraz Linuksa.
aktualizacja: UkazaÅ‚a się już pierwsza poprawka 6.0a rozwiÄ…zujÄ…ca niektóre problemy z szyfrowaniem partycji systemowej i nie tylko…
Więcej informacji: http://www.truecrypt.org/docs/?s=version-history
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
62 komentarzy
Wszystkie autorskie niusy w serwisie publikowane sÄ… na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
Zapierdziela aż miÅ‚o – w benchmarkach rzeczywiÅ›cie 2 krotny wzrost w porównaniu do poprzedniej wersji, szkoda że niewiele programów wykorzystuje w peÅ‚ni 2 rdzenie :/
Tak jak niewiele programów wykorzystuje 64-bity dostÄ™pne w nowszych procesorach. Nie mówiÄ…c już o tym, że wiele programów po prostu nie jest dostÄ™pnych pod amd64 (nie wspomnÄ™ tu w ogóle o flashu).
Obecne programy niestety nie są w stanie wykorzystać w pełni nowoczesnego sprzętu.
programy opensourcowe wystarczy skompilowac pod swoja maszynkÄ™ i 64 bity juz sa uzywane
gorzej niestety z rdzeniami :/ bez przepisania przynajmniej czÄ™sci kodu sie nie da…
IMHO peÅ‚na obsÅ‚uga 64-bitów również wymaga zmian w kodzie. Gdyby tak nie byÅ‚o, to Adobe od razu skompilowaÅ‚by swojego plugina pod 64 bity. JakoÅ› nie wierzÄ™, że nie robiÄ… tego, bo im siÄ™ nie chce – widać wymaga to jakichÅ› wiÄ™kszych nakÅ‚adów pracy.
Jeśli kod jest poprawnie napisany (tj. np. bez założeń, że sizeof(size_t) == 4) to wystarczy przekompilować. A jak ma się kod spartolony no to potrzeba więcej pracy.
@Kicer: Guzik prawda. Przekompiluj sobie tak plugin Javy albo OOo. (Chociaz nie wiem, moze OOo dorobilo sie juz mozliwosci pracy w trybie 64bit?)
@bies: no super. program zamiast części rejestrów 32b bÄ™dzie używaÅ‚ 64b. Widzisz tu gdzieÅ› jakÄ…Å› szansÄ™ na poprawÄ™? Czegokolwiek? Nie o to chodzi w 64b…
Tak, widzÄ™. Otóż domyÅ›lne profile kompilatorów na x86_64 używajÄ… SSE (przynajmniej SSE2) do arytmetyki zmiennoprzecinkowej. Na x86 używajÄ… FPU. Wynika to wprost z dostÄ™pnych procesorów x86_64. I o to też chodzi w x64.
Poza tym nie pisałem o zaletach i wadach. Pisałem o trudności portowania spartolonego kodu.
Hmmm… SSE i SSE2 sÄ… dostÄ™pne również dla kodu 32-bitowego. To czy jest używane FPU czy SSE/SSE2 jest wiÄ™c dla mnie jakby ortogonalne wzglÄ™dem 64-bitowoÅ›ci. Dlaczego wiÄ™c kompilatory na x86_64 miaÅ‚yby używać SSE/SSE2, a kompilatory 32-bitowe nie?
Chyba, że masz na myśli konkretne kompilatory i ich obecny stan. Proszę o rozwinięcie tematu
GCC na platformie x86_64 ma wlaczony domyslnie -mfpmath=sse, natomiast na platformie x86 ma -mfpmath=387. Dlatego ze nie wszystkie procesory x86 maja SSE.
Oczywiscie przelacznik mozna dodac do linii polecen i w ten sposob uzywac sse w x86, chociaz bez zoptymalizowanego kodu to raczej niewiele daje…
Co do 64bitowosci – tak dlugo jak nie pracujecie czesto na plikach wiekszych jak 2GB lub ilosci pamieci wiekszej niz 2GB to czy 32bit czy 64bit to nie bedzie w wiekszosci roznicy (chyba, ze program dokonuje operacji na jakis zbiorach o ilosci elementow wiekszych niz 2^32 – wowczas bedzie szybciej jezeli poprawnie sie to zaprogramuje (jeden licznik zamiast dwoch…).
@vampire: Ok, teraz rozumiem co miałeś na myśli, dzięki
Ja niedÅ‚ugo zamierzam kupić laptopa, który bÄ™dzie miaÅ‚ 4 GB RAM-u. MiÅ‚o byÅ‚oby zatem, gdyby architektura x86_64 byÅ‚a bardziej wspierana, a nie traktowana wciąż po macoszemu. W koÅ„cu mamy XXI wiek, a niektórzy producenci oprogramowania wciąż zdajÄ… siÄ™ bardzo zacofani przewidujÄ…c tylko i386.
Czajnik: ja nie pisalem tej pierwszej wiadomosci. Po prostu wyjasnilem o co chodzilo dla bies'a.
diablownik: 32 bitowe jadro linuksa adresuje bez problemow wiecej niz 4GB RAM. Dzieki PSE adresuje 2^36 bitow pamieci, jednak (uwaga!) pojedyncza aplikacja nadal nie moze przekroczyc 4GB (2GB lub 3GB przy domyslnym podziale pamieci w jadrze).
> a niektórzy producenci oprogramowania wciąż zdajÄ… siÄ™ bardzo zacofani przewidujÄ…c tylko i386.
Jakby nie było to x86(_64) jest już od dawna przestarzałą architekturą a nowsze np PowerPC są wydajniejsze i bardziej energooszczędne.
Jak ktoÅ› ma w mieszkaniu ogrzewanie elektryczne to chyba nie bÄ™dzie różnicy czy ogrzewać bÄ™dzie piec powiedzmy 3kW czy komp który pobiera 2kW z zasilacza (przyjmujÄ…c że sprawność zasilacza[y] to 66.(6)%).
Zawsze tak byÅ‚o – kiedyÅ› najszybszym prockiem byÅ‚a Motorola 68000 (1979rok) i też dÅ‚ugo żaden program jej nie wykorzystywaÅ‚.
Nie do konca rozumiem, co probujesz powiedziec. Programy chodzace na mc68000 nie do konca wykorzystywaly ten procesor? To na co byly pisane, skoro nie byl kompatybilny z zadnym wczesniejszym procesorem?
Szkoda, że linuksowe gry nie wykorzystujÄ… 2 rdzeni…..
Na Windowsie też zdaje się jest niewiele lepiej w tym względzie
Windows ma ten plus, że producenci sprzÄ™tów oferujÄ… wiÄ™cej sterowników na ten system. Na Linuksa sÄ… one najczęściej oferowane raz na ruski rok, jeÅ›li w ogóle (nie mówiÄ™ tu o otwartych sterownikach pisanych przez spoÅ‚ecznoÅ›ci, ale tych oficjalnych).
zainstalowałęm wraz z easycrypt i nie wiem jak się teog używa 0.o
Easycrypt to GUI do Truecrypta?? JeÅ›li tak to jest niepotrzebne – od wersji 5 TC ma wbudowane GUI dla Linuksa, prawie identyczne jak w Windows. Tu masz jakiÅ› poradnik:
http://www.jarzebski.pl/read/nowy-truecrypt-5.so
Zrobiłem u siebie testy kopiowania z dysku zaszyfrowanego na inny zaszyfrowany: było 6MB/s (z przestojami po kilka sekund 0MB/s) po zmianie na wersję 6.0 jest 12MB/s bez przerw!!! ( testy na laptopie acer core duo T2350 / Ubuntu HH) Gratuluję załodze TC!!!
Core Duo T2400, dysk 5.4k rpm, dm_crypt 256bits
Zapis:
$ dd if=/dev/zero of=test-crypt bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 104.139 s, 41.2 MB/s
Odczyt:
# dd if=/dev/mapper/home of=/dev/null bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 94.6666 s, 45.4 MB/s
na jednym rdzeniu, bo dm_crypt nie jest zrownoleglony.
Daleka droga przed dm_crypt…
Algorytm: AES-CBC-256.
Nie wiem, jaki masz sprzęt, ale u mnie na Windows potrafi popierdzielać 20 MB/s. A w wersji Linuksowej zawsze zdarzają się "przestoje"; wydajność też nie jest imponująca.
20MB/s to nie jest jakos wyjatkowo duzo. Skoro dm_crypt potrafi wyciagnac bez problemow 40MB/s a tez nie jest demonem predkosci….
Z tego co piszecie wynika, ze TrueCrypt jest koszmarnie powolny…
u mnie na C2D 1,87 GHz wyciga 135 MB/s
To powiedz, jaki dysk tyle wyrobi…
Tja… To chyba prÄ™dkość szyfrowania pamiÄ™ci.
Niestety pod Linuksem są duże problemy; wydajność nawet kilka razy mniejsza niż pod Windows.
MZ: powyzej masz test zapisu zrobiony przy uzyciu dd. Zapis z pamieci na dysk, po czym odczyt z dysku (z innego obszaru co by w cache nie bylo).
M-Z: co do wydajnosci dysku i wypowiedzi uzytkownika jan to widzialem juz macierze RAID o predkosci zapisu i odczytu ~400MB/s…
Tak, tylko kto ma w domu macierz…
Ja przy zwykÅ‚ym kopiowaniu nie mam wiÄ™cej jak 35 MB/s (i to przy kopiowaniu na zewnÄ™trzny dysk USB). WiÄ™c za cholerÄ™ nie wierzÄ™ w te 400 (czy tylko 135 MB/s) – cedek w 5 sekund?
To że kopiujesz na USB nie oznacza że bÄ™dzie szybciej – tutaj może ograniczać kontroler USB. Z CiekawoÅ›ci sprawdziÅ‚em dysk HD Tune – pokazuje 110 MB/s i to wcale nie jakiÅ› najnowszy sprzÄ™t.
A Poza tym to przecież nadchodzą dyski SSD
Moje doÅ›wiadczenie podpowiada mi, że nie chodzi o przepustowość USB. Wystarczy powiedzieć, że prÄ™dkość kopiowania miÄ™dzy różnymi partycjami tego samego dysku stabilizuje siÄ™ w okolicach 20-23 MB/s.
Nie wiem, co to HD Tune, ale mnie interesują rzeczywiste osiągi, a nie to co sobie jakiś program wyliczy teoretycznie. Zapuść kopiowanie 10 GB kontenera z jednej lokalizacji do drugiej, zmierz czas i będziesz miał użyteczne dane. W 110 MB/s realnej szybkości absolutnie nie wierzę.
Prędkość kopiowania na partycjach tego samego dysku to jedno a kopiowanie między 2 dyskami w komputerze to drugie. 110 z partycji na partycje to raczej ciężko
Well, wydaje mi siÄ™, że również miedzy dyskami może być ciężko. Ale może to dlatego, że mam doÅ›wiadczenie z dyskami laptopowymi…
Co za problem w 140-150MB/s przy 4-5 dyskach w raid0. Żaden, nawet przy kopiowaniu sporych ilości danych prędkość będzie utrzymana. Nie ma co się podniecać niezdrowo prędkościami, bo to żadne cuda.
Ale zauważyÅ‚eÅ›, że nie mówimy tu o RAIDach?
Mówimy o różnicach miÄ™dzy wersjÄ… WindowsowÄ… i LinuksowÄ… na sprzÄ™cie dostÄ™pnym dla zwykÅ‚ego użytkownika – tam 110 MB/s nie uÅ›wiadczysz.
90MB/s surowego transferu z początku dysku (hdparm -t /dev/sda) dla Seagate 500GB (wersja NS). Za miesiąc będę miał 1TB w tej samej wersji i 6x1TB w RAID 5 to powiem ile wyciąga surowego transferu.
Kwant!
Nie wiem z czym siÄ™ spotkaÅ‚eÅ›, ale to dość popularne kupowanie 2 dysków choćby na raid1. No chyba że kogoÅ› stać na stratÄ™ danych które ma na takim dysku. Poza tym jeżeli ktoÅ› kupuje komputer z 2-3k PLN to nie wierze, że nie stać takiej osoby na 2-3 dyski po 150zÅ‚, żeby mieć odpowiedni transfer z nich.
ZresztÄ… goÅ‚y ST3250410AS daje przy hdparm -t – 77.06 MB/sec, wiÄ™c przy dwóch powinno być okoÅ‚o 100MB/s ciÄ…gÅ‚ego transferu.
A teraz narzut na szyfrowanie. Przy 4 rdzeniowym procesorze mam zbliżonÄ… wydajność do pracy bez szyfrowania – Å›rednio okoÅ‚o 20MB/s mniej niż normalnie. Co dalej daje okoÅ‚o 100MB/s przy raid0 na 2 dyskach. Przy raid0 i 3 dyskach + dm_crypt poniżej 150MB/s nie schodzi prÄ™dkość.
M-Z niedowiarku: kopiowanie z dysku na dysk – rzeczywisty transfer:
22232064000 bytes (22 GB) copied, 404.939 seconds, 54.9 MB/s
Dwa tanie dyski WDC 250GB, kopiowanie z jednego na drugi, ext3 jako system plikow. Na macierzach RAID 300MB/s nie jest problemem:
8589934592 bytes (8.6 GB) copied, 27.3729 s, 314 MB/s
Na notebooku udowodnilem Ci powyzej transfer 45MB/s na i z zaszyfrowanej partycji (dm_crypt) (pamiec -> dysk, dysk -> pamiec).
TrueCrypt jest powolny skoro daje Wam zaledwie kilka MB/s….
Ale problem truecrypta nie jest jego powolne dziaÅ‚anie w ogóle, tylko pod Linuksem. Dlatego niespecjalnie wierzÄ™ w te dziesiÄ…tki megabajtów. OsiÄ…gi, które przedstawia na poczÄ…tku tej dyskusji mortoss wydajÄ… mi siÄ™ bardziej prawdopodobne.
Z truecryptem, czy nie? Bo w zupełności wierzę, że między 2 fizycznymi dyskami 3.5 cala może tak być (sam mam 35MB/s
z dysku 2.5 na USB 3.5 cala).
No to sporo siÄ™ rozjaÅ›niÅ‚o – Ty nie mówisz o truecrypcie.
Problem z Twoim dm_cryptem jest jego przywiÄ…zanie do Linuksa; ja potrzebujÄ™ rozwiÄ…zania cross-platform.
tak. od poczatku mowie od dm_crypt ze jest szybszy niz TrueCrypt (przynajmniej na linuksie).
Ponoc partycje zaszyfrowane dm_crypt sa obslugiwane przez to: http://www.freeotfe.org/
Ale to tylko tyle co ze strony dm'a wyczytalem. Nigdy nie uzywalem wiec nie wiem na ile to fajne i stabilne jest.
przez "fajne" rozumiem "bezpieczne" w tym przypadku.
I to oznacza, że truecrypt ma jakÄ…Å› "architektonicznÄ…" wadÄ™, gdyż nie widać powodu, by różnice byÅ‚y znaczÄ…ce (zarówno różnice miÄ™dzy Windows a Linuksem, jak i truecryptem i dm_cryptem). Wykres gkrellm "wykorzystania" dysku przy zwykÅ‚ym kopiowaniu i kopiowaniu na szyfrowany kontener powinny mieć zbliżony ksztaÅ‚t (nawet jeÅ›li wystÄ™puje pewien ubytek wydajnoÅ›ci).
Hmm cieszy mnie obsÅ‚uga dwóch rdzeni, chyba nadszedÅ‚ czas na zaszyfrowanie partycji
Ja na razie na starym kompie nie mogę sobie na to pozwolić, bo za słaby sprzęcik, żeby działało to w miarę porządnie.
Ale na nowym planujÄ™ już również szyfrowanie partycji, tym bardziej że to bÄ™dzie laptop
Na moim eeePC (celek 630-900MHz) truecrypt Å›miga i to z szyfrowaniem kaskadowym… Wymagania TC nie sÄ… zbyt wygórowane…
w benchmarkach rzeczywiście x2 dla dual core 2
Żeby jeszcze tak dysk zapisywał 2x szybciej
Wspaniała robota
a język polski jak w truecrypt zrobić pod ubuntu, może ktoś wie?
Przecież nie ma lokalizacji. Zresztą, żeby wpisać hasło to chyba nie potrzeba tłumaczenia.
A czy nowy truecrypt dalej potrafi zawiesić system przy kopiowaniu sporych ilości danych ? Wersja 5.x miała przykrą właściwość wieszania systemu przy dużych obciążeniach.
Nie wiesza siÄ™… poza tym byÅ‚a to wina buga w kernelu… a nie TC…
Masz może jakiegoś linka do tego ? Bo bug był faktycznie jak dobrze pamiętam rozwiązaniem było dodanie 'sync' przy mountowaniu, ale to zasadniczo dalej nie rozwiązywało problemu do końca. Osobiście sprawdzałem kernele od 2.6.18 do 2.6.25.x i na każdym przy dużych obciążeniach kończyło się to zwisem.
http://linuxnews.pl/truecrypt-51/
U mnie problem wystÄ™powaÅ‚ tylko z kernelem 2.6.22 i starszym. Nie wiem kiedy bÅ‚Ä…d poprawiono, ale na żadnej z moich konfiguracji po aktualizacji do K/Ubuntu 8.04 zawieszenie systemu nigdy nie wystÄ…piÅ‚o.. A kopiowaÅ‚em już conajmniej 300 GB.. Może Twój problem powoduje usterka sprzÄ™tu?
Przetestuje, zobaczymy.
Generalnie problem z pisaniem aplikacji na wiele procesorow jest taki ze trzeba dzielic rzeczy na watki "recznie" i czasami nie jest to mozliwe. W gcc 4.2 pojawilo sie OpenMP ktore jest calkiem fajne niestety soft wymaga gcc 4.2 i trzeba to pod OpenMP napisac, albo czekac na np C++ x0 gdzie bedzie natywne wsparcie dla watkow.
OpenMP jest znane od lat. Porzadne kompilatory wspieraja to juz od dawna. Ale to nie zmienia faktu, czesto wcale nie jest tak latwo zrobic program wydajnym i stabilnym uzywajac OpenMP.
Bardzo łatwo, proste dodanie kilku makr do pętli potrafi przyspieszyć program o 40% (rzeczywista sytuacja).
jezeli program jest tak prosty, ze dodanie poprawnienie kilku petli go przyspiesza o 40% to chyba nie mamy o czym dyskutowac.
Numeryka zazwyczaj tak ma. Co wiÄ™cej, tak naprawdÄ™ mówiÅ‚em o jednej pÄ™tli.
Tez zajmuje sie szeroko pojetymi obliczeniami numerycznymi i polecenie "wc -l *.cpp" wydane w glownym katalogu ze zrodlami daje wynik "40560 total"
Mozesz mi wierzyc, ze spedzilem duzo czasu zrownoleglajac ten kod i jak na razie niewiekie sukcesy ;>
Nie, nie trzeba. Co wiÄ™cej to nie jest wskazane. Należy skoncentrować siÄ™ na używaniu równolegÅ‚ych algorytmów (np. paraller STL) i struktur danych (Intel TBB). Automaty takie jak OpenMP mogÄ… pomóc. Ogólnie, rÄ™czne grzebanie w wÄ…tkach aby skorzystać z wydajnoÅ›ci kilku rdzeni to kiepski pomysÅ‚. Herb Sutter na Å‚amach Dr. Dobb's publikuje bardzo ciekawÄ… seriÄ™: ,,Effective Concurrency'' — polecam.
A poza tym czekanie z wÄ…tkami na C++0x jest bez sensu — od lat stosuje siÄ™ w C++ wÄ…tki (Win32 Threads, pthreads czy jakieÅ› biblioteki wyższego poziomu: ACE, Boost.Threads).