Truecrypt без переустановки системы

возможно, уважаемые форумчане подскажут что-то получше?

LUKS

Из мануалов я понял, что мне необходимо отформатировать диск, т.е. переустановить систему. Можно ли этого избежать?

Не обязательно переустанавливать. Сделай бэкап и перенеси на новый зашифрованный раздел.

P.S. Можно также откусить часть винта, зашифровать, перенести туда систему, забить случайными данными оставшуюся незашифрованную часть и расширить зашифрованный том на всё оставшееся место. Но это просто более утомительно, и на винте нужно место хотя бы под размер твоего рута.

В новых версиях cryptsetup добавили cryptsetup-reencypt, которая позволяет создать LUKS-контейнер из незашифрованного раздела (после предварительного уменьшения файловой системы на нём).

Если не пользоваться LUKS (делать plain-контейнер), у зашифрованного раздела не будет заголовка. Тогда перешифровка ещё проще (cryptsetup cryptsetup open --type plain /dev/sdXY mycrypt && cat /dev/sdXY > /dev/mapper/mycrypt).

Естественно, перешифровка должна производиться на размонтированном разделе (с livecd, например), шифрованный раздел должен быть описан в /etc/crypttab, а initrd - пересобран.

Подробнее см. https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions

Забей, он же гарантировано под управлением АНБ.

Можешь luks попробовать. Он по надежнее будет я думаю.

зашифровать раздел, на котором установлена Linux Gentoo
Truecrypt

Оно FUSE использует, я бы не стал так делать низачто.

возможно, уважаемые форумчане подскажут что-то получше

LUKS ака cryptsetup.

Забей, он же гарантировано под управлением АНБ.

Можешь luks попробовать. Он по надежнее будет я думаю.

Тогда ещё aes лучше стороной обойти...

Да, две рыбы лучше юзать я полагаю.

Прошу прощения, не могли бы Вы разъяснить термин «две рыбы»?

twofish

Twofish. Только оно не ускоряется на современных процессорах, в отличие от AES.

LUKS

Без поддержки скрытых томов, не, спасибо.

У тебя устаревшие данные.

CONFIG_CRYPTO_TWOFISH_X86_64_3WAY
CONFIG_CRYPTO_TWOFISH_AVX_X86_64

ТС не упоминал скрытые тома.

Ускоряется. Нет специального сопроцессора, то да. Однако скорость будь здоров, всяко упрёшься в IO.

Тогда было бы хорошо уточнить в каком именно контексте оно «лучше».

Я вот симпатизирую LUKS, но при всем желании пользоваться им не могу, т.к. без поддержки скрытых томов это все аки жесткая порнография.

Это только часть. Ассемблерные реализации в модулях существуют очень давно.

Скорость в разы ниже AES.

#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   481.8 MiB/s  1697.5 MiB/s
 serpent-cbc   128b    74.3 MiB/s   275.0 MiB/s
 twofish-cbc   128b   165.9 MiB/s   214.4 MiB/s
     aes-cbc   256b   367.4 MiB/s  1413.5 MiB/s
 serpent-cbc   256b    78.2 MiB/s   275.5 MiB/s
 twofish-cbc   256b   168.2 MiB/s   213.9 MiB/s
     aes-xts   256b  1308.0 MiB/s  1341.7 MiB/s
 serpent-xts   256b   264.0 MiB/s   268.5 MiB/s
 twofish-xts   256b   206.8 MiB/s   210.0 MiB/s
     aes-xts   512b  1102.7 MiB/s  1111.1 MiB/s
 serpent-xts   512b   267.5 MiB/s   270.3 MiB/s
 twofish-xts   512b   207.9 MiB/s   210.2 MiB/s

Ну да.

aes-cbc       256b   175,0 MiB/s   191,3 MiB/s
twofish-cbc   256b   212,5 MiB/s   260,2 MiB/s

Однако не на всех процах есть сопроцессор aes. Упираться сабж таки будет в любом случае в IO, польза от сабжа не так уж высока. А вот рассчитывать ну хоть на какую-то надёжность рассово пиндосского аппаратного шифрования (тем более анбшного) я бы не стал... Какой смысл шифровать алгоритмом который наверняка имеет закладки, да ещё его реализацией точно сделанной с ними. ИМХО с такими вводными двурыба даже более шустрая.

Упираться сабж таки будет в любом случае в IO, польза от сабжа не так уж высока.

Есть разница между загрузкой процессора в 100 и 20 процентов при равном потоке данных.

А вот рассчитывать ну хоть на какую-то надёжность рассово пиндосского аппаратного шифрования (тем более анбшного) я бы не стал...

Достаточно не использовать RNG из процессора (а он и не используется нигде).

который наверняка имеет закладки

Хотелось бы увидеть чуть более обоснованные аргументы.

реализацией точно сделанной с ними

Вот здесь нужен пруф или хотя бы мнение, основанное на некотором владении основами криптографии.

Есть разница между загрузкой процессора в 100 и 20 процентов при равном потоке данных.

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

Достаточно не использовать RNG из процессора (а он и не используется нигде).

Это не так. Почитай на просторах этих ваших инетов о том как ни хреново ослаблено всё шифрование в GSM сетях. И это при использовании изначально надёжных алгоритмов, просто реализация специально ослаблена.

Хотелось бы увидеть чуть более обоснованные аргументы.

Те же GSM сети, выкладки того же господина снежка...

Вот здесь нужен пруф или хотя бы мнение, основанное на некотором владении основами криптографии.

Опять же зная о том как заломали GSM американцы при разработке, зная о их тотальной слежке за всем миром, зная что AES изначально стандартизирован их АНБ, будешь уверен наверняка что расово пиндоская фирма делая сопроцессор заложила в алгоритм всё, что им повелели спецслужбы. Сильно удивлюсь если через лет цать когда математики осилят провести путёвый криптоанализ не обнаружат закладок, как это было с GSM. История это наука. Историю забывать нельзя.

Это не мнение, это — наука. А наука — бессердечная стерва с 14—дюймовым страпоном. (копирайт за Масукой из сериала Декстер)

ЗЫ я не спец по криптографии... Но полноценный криптоанализ AES поверь появится на публике ох как не скоро, сейчас это и для спецов заоблочно. А вот история штука доступная для понимания любого и она говорит что пиндосы кладут закладки в криптоалгоритмы, этого более чем достаточно чтоб им не доверять и даже более, что заведомо считать их обманьщиками.

Это не так. Почитай на просторах этих ваших инетов о том как ни хреново ослаблено всё шифрование в GSM сетях.

Апельсины в сравнении с яблоками.

поверь

Мы тут не религию обсуждаем.

Апельсины в сравнении с яблоками.

Американская технология с шифрованием сравнивается с американской технологией с шифрованием, более чем корректно.

Мы тут не религию обсуждаем.

Мы тут видимо вырывания по слову из контекста и жирные школовбросы собрались обсуждать? Нет спасибо, я как-то сегодня обойдусь.

Американская технология с шифрованием сравнивается с американской технологией с шифрованием, более чем корректно.

Ясно. Давай ещё посравниваем ГОСТ с RC4 или блочные алгоритмы с поточными? Так, JFL.

Тогда было бы хорошо уточнить в каком именно контексте оно «лучше».

LUKS умеет использует «AF stripes» [ключь хранится надёжно для эксренного удаления или смены] , а ещё LUKS позволяет иметь надёжный пароль размером во много раз менее чем 24 символов :-) [потомучто динамический подбор количества итераций для BPKDF2]

и всё это — поимолчанию. а не какие-то спец-настройки.

другими словами — LUKS является болеменее безопасным, поумолчанию. а TrueCrypt вместо этого хвастатеся лишь своей кросплатформенностью (и никому не нужным скрытым томом: используете ли вы «скрытый том» в TrueCrypt? и делаете ли это правильно? ).

Ясно. Давай ещё посравниваем ГОСТ с RC4 или блочные алгоритмы с поточными? Так, JFL.

Тебе про Фому, ты про Ерему...

и никому не нужным скрытым томом

Прошу добавить к протоколу, что dm-crypt в принципе тоже может в отрицаемое шифрование, хоть и ценой потери всех плюшек LUKS.

а cryptsetup\luks — умеет использовать twofish в режиме xts-plain (xts-plain64 ? xts-plainXXX ?) ?

или как twofish надо там устанавливать?

@ deterok @ Gotf

Да.

Да, ты просто указываешь тип шифрования и все.

Прошу добавить к протоколу, что dm-crypt в принципе тоже может в отрицаемое шифрование, хоть и ценой потери всех плюшек LUKS.

Можно вынести хэдер LUKS на отдельный носитель, например, на USB-флешку. Это позволит сохранить плюшки LUKS и сделать отрицаемое шифрование винчестера.

Да, две рыбы лучше юзать я полагаю.

А змейки где-нибудь сейчас используются?

TrueCrypt вместо этого хвастатеся лишь своей кросплатформенностью

Вроде же была новость про то что он уже ничем не хвастается и не рекомендуется к использованию самими разработчиками?

на моём ноутбуке twofish (512 байт) — работает быстрее чем aes (256 байт, или любое другое число байт).

этот факт соблазняет меня поменять aes на twofish(512b)

не рекомендуется к использованию самими разработчиками

но ведь фанаты-truecrypt не верят в эти заявляения..

мол "это заговор ЭфБиАй, ... и вообще(!) ты (разработчик) не разбираешься в своей программе, я лучше знаю безопасна она или нет!"

:-)

Еще бы знать чем эти алкоритмы отличаются...

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

Тогда и только тогда имеет смысл играться ими не только из-за скорости...

Это же вроде они на латыне написали шифрограмму, что мол за ними вышло АНБ?

на латыне

хорошо ещё что на латыне, а не на языке аннунаков с планеты Нибиру :-)

Все это не имеет абсолютно никакого смысла, если вас могут вежливо попросить показать содержимое ваших криптоконтейнеров.

вас могут вежливо попросить показать содержимое ваших криптоконтейнеров.

а ни чего страшного что на этих криптоконтейнерах (помимо всех остальных безобидных файлов) — могут находиться видеозаписи о том как я бегаю голышом по своей квартире..

(или частную жизнь уже отменили?)

в этом случае я бы на конституции лучше бы поклялся, что того что хотят найти — на моём жёстком диске нет. и что я ни к чему плохому не причастен.

# P.S.: и вообще — где гарантия что я всё ещё помню пароль(?), быть может я пароль забыл от испуга? или быть может — "я пароль на бумашку записал и положил бумажку в тумбочку.. но по какой-то причине после обыска теперь этой бумашки с паролем я не нахожу"? или быть может — "мой пароль это слово Футбол.. но почему-то программа теперь пишет что этот пароль не верный — я не знаю! вы мня спросили пароль(?), я вам пароль сказал.. теперь разбиратесь сами..."?

Почитал немного про LUKS и решил делать как советовал товарищ Chaser_Andrey:

Можно также откусить часть винта, зашифровать, перенести туда систему, забить случайными данными оставшуюся незашифрованную часть и расширить зашифрованный том на всё оставшееся место. Но это просто более утомительно, и на винте нужно место хотя бы под размер твоего рута.

У меня как раз есть пустой раздел на половину винта. Пытаюсь сделать следующее:

$ cryptsetup luksFormat /dev/sda1 -h=sha256 -c=twofish-xts -s=256

WARNING!
========
This will overwrite data on /dev/sda1 irrevocably.

Are you sure? (Type uppercase yes): YES    
Enter passphrase: 
Verify passphrase: 
device-mapper: reload ioctl on  failed: Недопустимый аргумент
Failed to setup dm-crypt key mapping for device /dev/sda1.
Check that kernel supports twofish-xts cipher (check syslog for more info).

$ cat .config | grep TWOFISH
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
CONFIG_CRYPTO_TWOFISH_X86_64=m
# CONFIG_CRYPTO_TWOFISH_X86_64_3WAY is not set
# CONFIG_CRYPTO_TWOFISH_AVX_X86_64 is not set

$ lsmod | grep twofish
twofish_generic         5609  0 
twofish_x86_64          5213  0 
twofish_common         12681  2 twofish_generic,twofish_x86_64

попробовал повторить:

[regular-user@localhost ~]$ cd ~/Desktop/
[regular-user@localhost Desktop]$ truncate -s 1200M disk.img
[regular-user@localhost Desktop]$ sudo losetup -f ./disk.img 
[sudo] password for regular-user: 
[regular-user@localhost Desktop]$ sudo losetup 
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE
/dev/loop0         0      0         0  0 /home/regular-user/Desktop/disk.img
[regular-user@localhost Desktop]$ lsblk | grep -Fi loop
loop0                                           7:0    0   1.2G  0 loop  
[regular-user@localhost Desktop]$ sudo cryptsetup luksFormat /dev/loop0 -h=sha256 -c=twofish-xts -s=256

WARNING!
========
This will overwrite data on /dev/loop0 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase: 
Verify passphrase: 
[regular-user@localhost Desktop]$ sudo cryptsetup luksDump /dev/loop0
LUKS header information for /dev/loop0

Version:       	1
Cipher name:   	twofish
Cipher mode:   	xts
Hash spec:     	sha256
Payload offset:	4096
MK bits:       	256
MK digest:     	8d ee bc c1 39 e6 d0 cd f8 98 79 72 87 81 57 4a 6c e0 41 5a 
MK salt:       	a7 96 0a 1e b8 6f 84 b7 01 a9 08 d7 45 1c 9f 9a 
               	51 03 92 1b 6e c6 1d 71 8d 3d d3 61 a7 4f f9 f3 
MK iterations: 	45875
UUID:          	3325592b-d050-4cb3-b2da-955ddbc15888

Key Slot 0: ENABLED
	Iterations:         	184437
	Salt:               	24 49 02 97 df fa c3 5d ff 0a d1 b2 a5 07 a9 74 
	                      	1d b5 d6 45 3d 02 7c c7 5b ef 08 1f b5 14 6e 17 
	Key material offset:	8
	AF stripes:            	4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
[regular-user@localhost Desktop]$ 

### дополнение: ###

[regular-user@localhost Desktop]$ lsmod | grep twofish
twofish_generic        16569  0 
twofish_avx_x86_64     50220  0 
twofish_x86_64_3way    25483  1 twofish_avx_x86_64
twofish_x86_64         12541  2 twofish_avx_x86_64,twofish_x86_64_3way
twofish_common         20585  4 twofish_generic,twofish_avx_x86_64,twofish_x86_64_3way,twofish_x86_64
lrw                    12757  4 serpent_sse2_x86_64,serpent_avx_x86_64,twofish_avx_x86_64,twofish_x86_64_3way
glue_helper            12649  4 serpent_sse2_x86_64,serpent_avx_x86_64,twofish_avx_x86_64,twofish_x86_64_3way
ablk_helper            12572  3 serpent_sse2_x86_64,serpent_avx_x86_64,twofish_avx_x86_64
xts                    12679  4 serpent_sse2_x86_64,twofish_x86_64_3way
[regular-user@localhost Desktop]$ 

быть может я пароль забыл от испуга?

Разогревающийся на столе паяльник быстро вернет тебе память :)

(или частную жизнь уже отменили?)

Это вы не мне будете рассказывать, а тем кто будет вежливо просить показать содержимое криптоконтейнера. Вы как-то очень недооцениваете эффективность рализных заочных способов криптоанализа.

Так же отказ продемонстрировать содержимое своих криптоконтейнеров может трактоваться судом как косвенное признание своей вины.

Так шта все перечисленное можешь смело умножить на 0.

Если указать просто

cryptsetup luksFormat /dev/sda1

PS: если указываю -c=aes-xts, то такая же ошибка.

а если указываешь -c=twofish-xts-plain64 ?

Да, вот так получилось. Не могли бы Вы пояснить в чем разница и почему без plain64 не получалось?

есть три варианта (на самом деле вариантов больше, но рассмотрим только три:)):

• НазваниеШифра-xts
• НазваниеШифра-xts-plain
• НазваниеШифра-xts-plain64

и в интернетах есть чуть-чуть инфы на тему того чем отличается режимы -xts-plain от -xts-plain64 ..

однако я так не смог нагуглить — чем отличаются -xts от -xts-plainXX..

(поидее в этом случае я должен уже начать изучать исходники, чтобы выявить различия, но пока-что не дошёл до этой стадии.. и не факт что смогу разобраться).

было бы действительно полезно, если тут кто-то раскажет в чём разница в этих трёх вариантах. :-)

Подумал, что создавать новую тему нету смысла ради такого вопроса, потому решил запостить его здесь. Получилось перенести систему на зашифрованный раздел и настроить загрузку с флешки. Однако, при переносе системы «побились» все права. Теперь у меня такая картина: на /dev/sda3 у меня клон системы с «нормальными» правами, на зашифрованном /dev/sda1 рабочая система, но с очень ограниченными правами (только root имеет права на чтение/запись). Есть ли способ как-нибудь «скопировать» права?

cp -p

Оказалось, мне нужен был параметр --attributes-only. Сейчас все работает, спасибо всем.