LINUX.ORG.RU

LUKS или TrueCrypt, что быстрее?

 , ,


0

1

Пользуюсь тем и другим уже много лет, проблем с надежностью/стабильностью не было. Сейчас обнулил внешний жесткий диск 1 ТБ на котором был LUKS на весь раздел, вот думаю что делать, опять LUKS или TrueCrypt? Возможности тестировать уже нет, раздел шифруется очень долго чтобы ставить эксперименты. Что будет работать быстрее и отжирать меньше ресурсов при чтении/записи, LUKS или TrueCrypt? Условия шифрования все по дефолту.



Последнее исправление: sako (всего исправлений: 1)

Условия шифрования все по дефолту.

Ты смотри, в новых ядрах что-то допилили, и serpent теперь всех рвёт.

anonymous
()

По-моему, даже на не очень новых процессорах без AES-NI всё упирается в скорость чтения/записи, а нагрузка на процессор от шифрования в районе единиц процентов на одно ядро.

А учитывая полупроприетарную историю трукрипта, я б не стал связываться.

vasilenko ★★
()
Ответ на: комментарий от vasily_pupkin

проясните это, пожалуйста. Фанатично использую cryptsetup. Но из-за того, что в универе приходится подключаться к виндовым компам, приходится часть данных переносить на открытый ntfs, т.к. не хочу весь большой винт шифровать truecrypt'ом, т.к. по опытам прошлых лет (2-3- года назад) сложилось впечатление о нем, как о наиболее медленном средстве. Это не так?

Deleted
()
Ответ на: комментарий от vasilenko

без AES-NI всё упирается в скорость чтения/записи
нагрузка на процессор от шифрования в районе единиц процентов на одно ядро.

Нууууу, не совсем так, 4х летний штеуд тянет ~40мб/сек при 20-30%.

Про однораундовый AES-NI можно забывать сразу.

Umberto ★☆
()
Последнее исправление: Umberto (всего исправлений: 1)

Можешь просто подобрать размер ключа.

cryptsetup --verbose --cipher "aes-cbc-essiv:sha256" --key-size=128 --hash=sha256 --iter-time=40000 --verify-passphrase luksFormat /dev/диск

Umberto ★☆
()

TrueCrypt, пришедшая в Linux из мира Windows-систем, медленнее LUKS/dm-crypt, но, в отличие от последней, предоставляет по-настоящему кроссплатформенное решение (тома TrueCrypt могут быть прочитаны в Mac OS X), обладает встроенным графическим интерфейсом и позволяет создавать так называемые скрытые тома (невидимые зашифрованные тома внутри зашифрованных томов).

Deathstalker ★★★★★
()
Ответ на: комментарий от record

Лицензия tryecrypt содержит кучу взаимопротиворечивых параграфов, фактически делающих её недействительной. А старые версии ещё и явно запрещали коммерческое распространение бинарников софта, основанных на коде truecrypt. Даже GPL этого не запрещает. По этой и нескольким другим причинам редхат в своё время не пустил truecrypt в федору.

http://lists.freedesktop.org/archives/distributions/2008-October/000276.html

https://fedoraproject.org/wiki/ForbiddenItems#TrueCrypt

В последней версии лицензии запрет на коммерческое распространение бинарников убрали, но основные проблемы остались, и к ним добавились новые. Вот, например, разбор:

https://bugs.gentoo.org/show_bug.cgi?id=241650#c27

Вообще, лицензия на 50% состоит из лазеек, позволяющих компании в любой момент подать в суд на любого пользователя. И это не очередные анимированные обои для ведройда, а софт для шифрования дисков. Пользоваться им станет лишь недалёкий, неумный человек.

vasilenko ★★
()
Ответ на: комментарий от vasilenko

Лицензия, если вы прочтёте её, даёт вам практически полное право на использование, модификацию и дистрибуцию как truecrypt'a, так и его производных. Основные ограничения - это нельзя свои производные называть оригинальным именем, и нельзя использовать чужие торговые марки, и необходимо по возможности указывать ссылку на оригинальный truecrypt в производных от него. Всё. Разумные требования для программ шифрования, чтоб не делали бэкдор'ов и хани пот'ов.

Ничего из этого не делает truecrypt проприетарным.

Весь шум из-за лицензии начался после того, как - внезапно - увидели, что она была плохо сформулирована, точнее, содержала разные несовместные виды лицензий, включая ссылку на GPL. Такая лицензия не могла быть включена в US-based дистрибутивы. В том числе и потому что были анонимные девелоперы, и была безучетная система разработки.

Вывод. Это юридическая перестраховка, но не суть программы. По сути она свободна.

record ★★★★★
()
Последнее исправление: record (всего исправлений: 5)
Ответ на: комментарий от vasilenko

гентушники опять бред генерируют
дженту никогда не был полностью свободным дистрибутивом и никогда к этому не стремился с всей этой кучей бинарников
«а теперь давайте теперь выкинем программу потомучто мне кажется что лицензия выглядит подозрительно несвободной»

anonymous
()
Ответ на: комментарий от anonymous

Анонимы опять лужи газифицируют.
truecrypt убрали из всех крупных дистрибутивов, чтоб не иметь никаких проблем из-за лицензионных неоднозначностей, важных для западных юристов.

record ★★★★★
()
Последнее исправление: record (всего исправлений: 3)
Ответ на: комментарий от Umberto

Что вы так упираетесь в AES? BlowFish порезвее будет. Я как-то выбирал алгоритм для openvpn так BF оказался самым резвым.

По стойкости вообще пофиг. Организация, могущая вскрыть даже обычный DES за разумное время - может привлечь и спецов по терморектальному криптоанализу

kombrig ★★★
()
Последнее исправление: kombrig (всего исправлений: 1)

Кстати, про cryptkeeper есть истории неуспеха?

minakov ★★★★★
()
Ответ на: комментарий от neocrust

да, и генту - это не совсем дистрибитив, это метадистрибутив.

record ★★★★★
()
Последнее исправление: record (всего исправлений: 2)

Провел тестирование. Входные данные:

  • Внешний жесткий диск WD Book 3,5" USB 2.0 1ТБ
  • Процессор Intel(R) Core(TM)2 Quad CPU Q8300 @ 2.50GHz
  • Шифрование LUKS (cryptsetup 1.1.3) и TrueCrypt 7.1a
  • Файловая система на шифрованных разделах ext4
  • Ядро Linux 2.6.32-5-686-bigmem
  • Дистрибитив Debian GNU/Linux 6.0.7 (Squeeze)

Что было сделано при тестировании:
1. Копирование одного файла (фильм) размером 10,8 ГБ (11325740 КБ) на шифрованный раздел
2. Копирование 1633 файлов (локальная папка из репозитория Debian /var/ftp/pub/debian/pool/main/p) размером 5,0 ГБ (5319592 КБ) на шифрованный раздел
3. По секундомеру подсчет времени копирования файлов
4. С помощью утилиты top наблюдение за ресурсами, в частности % использования процессора

Певым был протестирован LUKS. Его параметры (дефолт):

root@soprano:~# cryptsetup luksDump /dev/sde1
LUKS header information for /dev/sde1
Version:       	1
Cipher name:   	aes
Cipher mode:   	cbc-essiv:sha256
Hash spec:     	sha1
Payload offset:	2056
MK bits:       	256

Скорость копирования:
1 файл 11325740 КБ / 398 сек = 28524 КБ/сек
1633 файла 5319592 КБ / 225 сек = 23643 КБ/сек
Ресурсы:
При копировании процесс kcryptd - 36% процессора из 400% (4 ядра по 100%) или в общем от CPU 11%

Вторым был протестирован TrueCrypt. Его параметры (дефолт):

Encryption algorithm: AES
Hash algorithm: RIPEMD-160

Скорость копирования:
1 файл 11325740 КБ / 396 сек = 28600 КБ/сек
1633 файла 5319592 КБ / 212 сек = 25092 КБ/сек
Ресурсы:
При копировании процесс kcryptd - 36% процессора из 400% (4 ядра по 100%) или в общем от CPU 11%
Итог:
Как видим, я уперся в скорость передачи данных по шнурку в устройство. Для тестов нужно копировать минимум с SATA на SATA. Ресурсы потребляют одинаково.

sako
() автор топика
Ответ на: комментарий от kombrig

да ну. про aes-ni забыл или расскажешь как хорошо жить со тарыми печами?

parrto
()
Ответ на: комментарий от KillTheCat

такой же тест на и5 делал (+еще что-то в настройках tc ставил) и тест под виндой показал примерно 7-10 процентов лучше резульатат. Win7x64 и Убунта 12.10 x64

windofchange
()
Ответ на: комментарий от windofchange

win7sp1x64, kubuntu 64 13.10 стандартное 3.11.0-12-generic, i7-4770k@4 GHz

По тестам из инета под виндой все ок, а тесты под линукс я не нашел. Еще он плавает сильно под линуксом, но ниже 5 аес я не видел - вот AES 6.1 GB/s

KillTheCat ★★★★★
()
Ответ на: комментарий от KillTheCat

нормальная видеокарта всё равно быстрее...

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.