TrueCrypt 6.0a – obsługa wielu rdzeni (aktualizacja)

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…

żadnych reklam, sama wiedza.

Zarejestruj się na BEZPŁATNY NEWSLETTER i raz w tygodniu otrzymuj najważniejsze wiadmości
ze świata IT, nowych technologii i kryptowalut.

Bez reklam.

  1. Awatar jan
    jan

    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 :/

    1. Awatar diablownik
      diablownik

      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.

      1. Awatar Kicer
        Kicer

        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…

        1. Awatar diablownik
          diablownik

          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.

        2. Awatar bies
          bies

          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.

        3. Awatar trasz
          trasz

          @Kicer: Guzik prawda. Przekompiluj sobie tak plugin Javy albo OOo. (Chociaz nie wiem, moze OOo dorobilo sie juz mozliwosci pracy w trybie 64bit?)

        4. Awatar jabaca
          jabaca

          @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…

        5. Awatar bies
          bies

          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.

        6. Awatar Czajnik
          Czajnik

          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 🙂

        7. Awatar vampire
          vampire

          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…).

        8. Awatar Czajnik
          Czajnik

          @vampire: Ok, teraz rozumiem co miałeś na myśli, dzięki 🙂

        9. Awatar diablownik
          diablownik

          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.

        10. Awatar vampire
          vampire

          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).

        11. Awatar norbert_ramzes
          norbert_ramzes

          > 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)%).

      2. Awatar Mieszko Kaczmarczyk
        Mieszko Kaczmarczyk

        Obecne programy niestety nie są w stanie wykorzystać w pełni nowoczesnego sprzętu.

        Zawsze tak było – kiedyś najszybszym prockiem była Motorola 68000 (1979rok) i też długo żaden program jej nie wykorzystywał.

        1. Awatar trasz
          trasz

          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?

    2. Awatar Mieszko Kaczmarczyk
      Mieszko Kaczmarczyk

      Szkoda, że linuksowe gry nie wykorzystują 2 rdzeni….. 🙁

      1. Awatar diablownik
        diablownik

        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).

  2. Awatar soda2
    soda2

    zainstalowałęm wraz z easycrypt i nie wiem jak się teog używa 0.o

    1. Awatar jan
      jan

      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

  3. Awatar mortoss
    mortoss

    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!!!

    1. Awatar vampire
      vampire

      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…

      1. Awatar vampire
        vampire

        Algorytm: AES-CBC-256.

    2. Awatar M-Z
      M-Z

      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.

      1. Awatar vampire
        vampire

        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…

        1. Awatar jan
          jan

          u mnie na C2D 1,87 GHz wyciga 135 MB/s

        2. Awatar M-Z
          M-Z

          u mnie na C2D 1,87 GHz wyciga 135 MB/s

          To powiedz, jaki dysk tyle wyrobi…

        3. Awatar M-Z
          M-Z

          20MB/s to nie jest jakos wyjatkowo duzo. Skoro dm_crypt potrafi wyciagnac bez problemow 40MB/s a tez nie jest demonem predkosci….

          Tja… To chyba prędkość szyfrowania pamięci. 🙂

          Z tego co piszecie wynika, ze TrueCrypt jest koszmarnie powolny…

          Niestety pod Linuksem są duże problemy; wydajność nawet kilka razy mniejsza niż pod Windows.

        4. Awatar vampire
          vampire

          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).

        5. Awatar vampire
          vampire

          M-Z: co do wydajnosci dysku i wypowiedzi uzytkownika jan to widzialem juz macierze RAID o predkosci zapisu i odczytu ~400MB/s…

        6. Awatar M-Z
          M-Z

          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?

        7. Awatar jan
          jan

          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 🙂

        8. Awatar M-Z
          M-Z

          To że kopiujesz na USB nie oznacza że będzie szybciej – tutaj może ograniczać kontroler USB.

          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.

          Z Ciekawości sprawdziłem dysk HD Tune – pokazuje 110 MB/s i to wcale nie jakiś najnowszy sprzęt.

          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ę.

        9. Awatar jan
          jan

          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 🙂

        10. Awatar M-Z
          M-Z

          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…

        11. Awatar LCF
          LCF

          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.

        12. Awatar M-Z
          M-Z

          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.

        13. Awatar kwant
          kwant

          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!

        14. Awatar LCF
          LCF

          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.

          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ść.

        15. Awatar vampire
          vampire

          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….

        16. Awatar M-Z
          M-Z

          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.

          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.

          M-Z niedowiarku: kopiowanie z dysku na dysk – rzeczywisty transfer:

          22232064000 bytes (22 GB) copied, 404.939 seconds, 54.9 MB/s

          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).

          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….

          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.

        17. Awatar vampire
          vampire

          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.

        18. Awatar vampire
          vampire

          przez "fajne" rozumiem "bezpieczne" w tym przypadku.

        19. Awatar M-Z
          M-Z

          tak. od poczatku mowie od dm_crypt ze jest szybszy niz TrueCrypt (przynajmniej na linuksie).

          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).

  4. Awatar Plichu
    Plichu

    Hmm cieszy mnie obsługa dwóch rdzeni, chyba nadszedł czas na zaszyfrowanie partycji 🙂

    1. Awatar diablownik
      diablownik

      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 😉

      1. Awatar mortoss
        mortoss

        Na moim eeePC (celek 630-900MHz) truecrypt śmiga i to z szyfrowaniem kaskadowym… Wymagania TC nie są zbyt wygórowane…

  5. Awatar Mariusz
    Mariusz

    w benchmarkach rzeczywiście x2 dla dual core 2 🙂

    Żeby jeszcze tak dysk zapisywał 2x szybciej 🙂

    Wspaniała robota 😀

  6. Awatar ergo
    ergo

    a język polski jak w truecrypt zrobić pod ubuntu, może ktoś wie?

    1. Awatar LCF
      LCF

      Przecież nie ma lokalizacji. Zresztą, żeby wpisać hasło to chyba nie potrzeba tłumaczenia.

  7. Awatar LCF
    LCF

    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.

    1. Awatar mortoss
      mortoss

      Nie wiesza się… poza tym była to wina buga w kernelu… a nie TC…

      1. Awatar LCF
        LCF

        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.

        1. Awatar mortoss
          mortoss

          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?

        2. Awatar LCF
          LCF

          Przetestuje, zobaczymy.

  8. Awatar Winter
    Winter

    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.

    1. Awatar vampire
      vampire

      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.

      1. Awatar bies
        bies

        Bardzo łatwo, proste dodanie kilku makr do pętli potrafi przyspieszyć program o 40% (rzeczywista sytuacja).

        1. Awatar vampire
          vampire

          jezeli program jest tak prosty, ze dodanie poprawnienie kilku petli go przyspiesza o 40% to chyba nie mamy o czym dyskutowac.

        2. Awatar bies
          bies

          Numeryka zazwyczaj tak ma. Co więcej, tak naprawdę mówiłem o jednej pętli. 😉

        3. Awatar vampire
          vampire

          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 ;>

    2. Awatar bies
      bies

      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).

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *