Niedawno ukazało się nowe jajko w wersji 2.6.24 (aktualnie już 2.6.24.1) w którym dodano nowy algorytm szyfrujący aes-xts-plain, jest to dobra wiadomość bo dm-crypt dostał nową możliwość, a raczej sposób wiązania zaszyfrowanych bloków jakim jest XTS.

XTS jest już dostępne pod linux-em za pomocą TrueCrypt 5.0 który używa XTS jako domyślnego sposobu.

Jednak nie mam zamiaru rozczulać się tu na temat czym się różni starsza metoda LRW od XTS, tylko przetestuje wydajność.

Do tego celu wybrałem maszynę zaopatrzoną w Athlon-a64 taktowanego 1.6GHz na płycie Gigabyte K8Triton Server z 4GB ramu i zainstalowanym Slackware-em 12.0 (aktualizowanym do current) z jajkiem 2.6.24

Podczas testów używam klucza o długości 384bitów algorytmu haszującego sha512 test powtarzałem 10 razy a wyniki uśredniłem.

Pierwszy test to rozpakowywanie kernel-a 2.6.24 na 1GB partycji (na początku dysku) umieszczonej na dysku Samsung SP 250GB SATA2 pod kontrolą systemu plików XFS (sync).

wniosek: realny czas rozpakowania jądra spadł średnio o 15% !

Drugi test to kasowanie wcześniej rozpakowanego źródła

wniosek: podobnie jak w przypadku rozpakowywania prędkość kasowania wzrosła o 8%

Próbowałem jeszcze robić kilka testów np. kasowanie pliku o wielkości 10Mb za pomocą bcwipe metodą Gutmann-a ale rezultaty są podobne i zbliżają się do około 10% różnicy na korzyść XTS.

Co ciekawe gdy użyjemy długości klucza 512bit dla XTS rezultaty spadają bardzo nieznacznie w porównaniu do 384bitów.

Rozpakowywanie kernela:
512/384bit (XTS)

Kasowanie:
512/384bit (XTS)

Wniosek: różnica wydajności żadna, a wzrost mocy szyfrowania bardzo znaczący.

Podobny test przeprowadzałem dla LRW ale różnica też była nieznaczna.

Wniosek końcowy:
Z racji że LRW oraz XTS w kernelu są oznaczone jako eksperymentalne trzeba by było pozostać przy starym CBC jednak wielu użytkowników używa z powodzeniem LRW w tym ja, bez jakichkolwiek kłopotów.

Ja zalecam pozostanie przy LRW do czasu aż XTS się troszkę rozwinie, ponieważ na razie nie budzi zaufania, np. dlatego że w help-ie jądra pisze:
„This implementation currently can’t handle a sectorsize which is not a multiple of 16 bytes.”
Wiem że to teoretycznie nic nie znaczy jednak mi się wydaje że autor chciał tu powiedzieć:
„To jest nieskończona wersja, pracuje nad tym”

KONIEC

W najbliższym czasie przeprowadzę podobny test którego celem będzie sprawdzenie wydajności dm-crypt aes-xts-plain vs. TrueCrypt 5.0 aes-xts , który jak zawsze umieszczę tu 🙂

Po naciskach ze strony czytelników stwierdziłem, że muszę wykonać jeszcze test porównawczy dm-crypt aes-xts vs. TrueCrypt 5.0 aes-xts vs. brak szyfrowania, aby ukazać jak spada wydajność gdy używamy szyfrowania.

Dodatkowe informacje można odszukać na poniższych stronach:
Bardzo bogata dokumentacja TrueCrypt: http://www.truecrypt.org/docs/
Trochę o dm-crypt: http://pl.wikipedia.org/wiki/DM-Crypt
Dokumentacja Cryptsetup+LUKS: http://www.saout.de/tikiw…x.php?page=LUKS
Polska wiki „mode of operation”: http://pl.wikipedia.org/wiki/CBC
Znacznie bogatsza angielska wersja wiki „block cipher mode of operation”: http://en.wikipedia.org/w…es_of_operation
Teoria szyfrowania dysków: http://en.wikipedia.org/w…cryption_theory

Tagged with:
 


Portal Bezpieczna Sieć - Forum komputerowe, Informatyka śledcza, bezpieczeństwo, backtrack, kali - Kali Linux Polska Edycja - Polska Edycja Backtrack - Poradnik dla gracza - Praca oparta na wiedzy i edukacji - Seriws Laptopów Katowice - Sklep Komputerowy Katowice - Odzyskiwanie Danych Katowice - Parking BETA przy lotnisku Pyrzowice - miejsce Run w sieci - Prawda od promocjach ,Informatyka, promocje, ceny, ekonomia, ekologia, filozofia - Prawda na tematy informatyki, ekonomii, ekologii - Wróżka, Poezja - eMono-cykl, SegWay, AirWheel, SoloWheel

stat4u