Системный администратор
0,0
рейтинг
22 апреля 2009 в 16:32

Разработка → Сравнительное тестирование криптоконтейнеров и шифрованных файловых систем

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

Основные задачи:
— Возможность бекапирования данных в любом виде для аварийного восстановления.
— Исключение доступа к этим данным неавторизованных лиц.
— Невозможность доступа к файлам при аварийном выключении сервера и загрузке с внешнего носителя.
— Прозрачная работа пользователей с файлами и любым содержимым находящемся на сервере.
— OS FreeBSD 7.2 и максимальный простор для фантазии в выборе вариантов реализации.
После энного количества времени сложилась следующая тестовая конфигурация:
GELI — GEOM_ELI (встроенная во FreeBSD подсистема шифрования использующая crypto(9) framework(аппаратное и программное шифрование))
GBDE — GEOM_BDE [Geom Based Disk Encryption] (встроенная во FreeBSD подсистема шифрования)
TrueCrypt — Портированная версия TrueCrypt 6.1a (использует fuse)
cryptofs — cryptofs использующая fuse
encfs — encfs использующая fuse

UPD: Таблица сравнения скоростей чистой и шифрованной файловых систем.


Начнем с классификации используемых систем шифрования.
Первые две системы используют любое устройство определяемое через GEOM. Это может быть физический накопитель(da0), партиция(da0s1), слайс(da0s1a), а также любое другое синтетическое устройство созданное скажем через mdconfig или ggatel.
mdconfig — утилита использующая geom_md и формирующая виртуальное устройство из имеющейся у Вас оперативной памяти или файла на диске или любом другом носителе.
ggatel — это утилита которая позволяет перевести любое устройство или файл, которое не может быть отнесено к классу GEOM в этот класс.

TrueCrypt — автономная кроссплатформенная система шифрования криптоконтейнеров.

fuse_cryptofs — подсистема парольного шифрования данных на диске шифрующая имена файлов и их содержимое при помощи алгоритмов заданных в конфигурационном файле.
fuse_encfs — подсистема парольно-ключевого шифрования данных на диске шифрующая имена файлов и их содержимое с контролем изменений в файлах.

Все тесты проводились на системе имеющей следующие характеристики P4 2.8HT/1GB RAM/40GB IDE/.
Для оценки скорости работы использовались dd и bonnie.
Временные файлы криптоконтейнеров и директории с файлами были размещены на разделе /var.
# dmesg | grep ad0<br/>ad0: 38166MB <Seagate ST340014A 3.06> at ata0-master UDMA100<br/># mount | grep var<br/>/dev/ad0s1g on /var (ufs, local, soft-updates) <br/>

Первым делом нужно было оценить какую скорость линейной записи на жёсткий диск мы можем получить в пике.
<br/>testcrypt# /usr/bin/time dd if=/dev/random of=testfile.dump bs=1m count=4096<br/>4096+0 records in<br/>4096+0 records out<br/>4294967296 bytes transferred in 151.801076 secs (28293392 bytes/sec)<br/>      151.82 real 0.00 user 132.96 sys <br/>

Т.е. максимально мы можем рассчитывать примерно на 27 мегабайт/с при потоковой записи.
Для анализа скорости работы GEOM провайдеров был создан файл размером 4GB, который по очереди подключался к mdconfig и ggatel(размер сектора был определен в 4Кб). Далее по тексту я постараюсь максимально исключить лишнюю служебную информацию из вставок кода.
Мы проверили линейную скорость записи через GEOM провайдеров.
testcrypt# mdconfig -a -t vnode -f /var/test/testfile.dump -S 4096 -u 0<br/>testcrypt# /usr/bin/time dd if=/dev/random of=/dev/md0 bs=1m<br/>4294967296 bytes transferred in 306.514082 secs (14012300 bytes/sec)<br/>      306.55 real 0.02 user 120.03 sys<br/>testcrypt# mdconfig -d -u 0<br/> <br/>testcrypt# ggatel create -s 4096 -u 0 /var/test/testfile.dump<br/>testcrypt# /usr/bin/time dd if=/dev/random of=/dev/ggate0 bs=1m<br/>4294967296 bytes transferred in 319.859650 secs (13427662 bytes/sec)<br/>      319.91 real 0.02 user 133.34 sys<br/>testcrypt# ggatel destroy -u 0 <br/>

Как видно из тестов скорость записи упала почти в 2 раза и ggate провайдер оказался немного медленнее чем md, но в принципе это не особо критично, хотя ggate немного больше грузит систему чем md.

Следующий шаг это проверка нагрузочной способности для файловых систем работающих через GEOM провайдеров. Первым тестировался md.

testcrypt# mdconfig -a -t vnode -f /var/test/testfile.dump -S 4096 -u 0<br/>testcrypt# newfs /dev/md0<br/>/dev/md0: 4096.0MB (8388608 sectors) block size 16384, fragment size 4096<br/>        using 13 cylinder groups of 336.98MB, 21567 blks, 21568 inodes.<br/>super-block backups (for fsck -b #) at:<br/> 160, 690304, 1380448, 2070592, 2760736, 3450880, 4141024, 4831168, 5521312,<br/>6211456, 6901600, 7591744, 8281888<br/>testcrypt# mount /dev/md0 /mnt<br/>testcrypt# /usr/bin/time dd if=/dev/random of=/mnt/testfile.dump bs=1m<br/>4220518400 bytes transferred in 235.262614 secs (17939605 bytes/sec)<br/>      235.28 real 0.03 user 136.49 sys<br/>testcrypt# umount /mnt<br/>testcrypt# mdconfig -d -u 0<br/>

Как мы видим скорость работы с файлами возросла и составила 17.1 мегабайт/сек.
Вторым тестировали ggate.
<br/>testcrypt# ggatel create -s 4096 -u 0 /var/test/testfile.dump<br/>testcrypt# newfs /dev/ggate0<br/>/dev/ggate0: 4096.0MB (8388608 sectors) block size 16384, fragment size 4096<br/>        using 13 cylinder groups of 336.98MB, 21567 blks, 21568 inodes.<br/>super-block backups (for fsck -b #) at:<br/> 160, 690304, 1380448, 2070592, 2760736, 3450880, 4141024, 4831168, 5521312, 6211456, 6901600, 7591744, 8281888<br/>testcrypt# mount /dev/ggate0 /mnt<br/>testcrypt# /usr/bin/time dd if=/dev/random of=/mnt/testfile.dump bs=1m<br/>4220518400 bytes transferred in 228.256445 secs (18490249 bytes/sec)<br/>      228.29 real 0.00 user 137.80 sys<br/>testcrypt# umount /mnt<br/>testcrypt# ggatel destroy -u 0<br/>

При прочих равных условиях ggate показал увеличение скорости по сравнению с md — 17.6 мегабайт/сек.
Настало время потестировать связку crypto и geom провайдеров. Для этого создали случайный ключ, который будет использоваться в дальнейших тестах.
testcrypt# dd if=/dev/random of=/var/test/my.key bs=4k count=1 

Инициализируем криптоконтейнер geli
testcrypt# mdconfig -a -t vnode -f /var/test/testfile.dump -S 4096 -u 0<br/>testcrypt# /usr/bin/time geli init -s 4096 -K my.key /dev/md0<br/>Enter new passphrase:<br/>Reenter new passphrase:<br/>       13.34 real 9.61 user 0.00 sys<br/>

Как видно из вывода time, geli init довольно долго просчитывает связку ключа шифрования с паролем и записывает его на диск.
testcrypt# geli list<br/>Geom name: md0.eli<br/>EncryptionAlgorithm: AES-CBC<br/>KeyLength: 128<br/>Crypto: software<br/>UsedKey: 0<br/>Flags: NONE<br/>Providers:<br/>1. Name: md0.eli<br/>   Mediasize: 4294963200 (4.0G)<br/>   Sectorsize: 4096<br/>   Mode: r0w0e0<br/>Consumers:<br/>1. Name: md0<br/>   Mediasize: 4294967296 (4.0G)<br/>   Sectorsize: 4096<br/>   Mode: r1w1e1<br/>

Криптоконтейнер создан и сформировано новое устройство с суффиксом .eli, которое можно использовать как обычное блочное устройство. Размечать его, создавать партиции и файловые системы.
Создаём новую файловую систему на криптоконтейнере и тестируем скорость.
testcrypt# newfs /dev/md0.eli<br/>/dev/md0.eli: 4096.0MB (8388600 sectors) block size 16384, fragment size 4096<br/>        using 13 cylinder groups of 336.98MB, 21567 blks, 21568 inodes.<br/>super-block backups (for fsck -b #) at:<br/> 160, 690304, 1380448, 2070592, 2760736, 3450880, 4141024, 4831168, 5521312, 6211456, 6901600, 7591744, 8281888<br/>testcrypt# /usr/bin/time dd if=/dev/random of=/mnt/testfile.dump bs=1m<br/>4220518400 bytes transferred in 277.940331 secs (15184980 bytes/sec)<br/>      277.96 real 0.03 user 145.50 sys<br/>

Как мы видим, скорость упала до 14.5 мегабайт/сек. Я пропущу блок разметки и тестирования скорости связки ggate+geli, так как он идентичен блоку geli+md. Так как мы не можем оценивать скорость работы только по циклу записи, мы запускаем bonnie для дополнительного анализа.
Сводные результаты работы bonnie на всех связках будут приведены в конце статьи.
testcrypt# bonnie -s 1024<br/>File './Bonnie.1145', size: 1073741824<br/>
  Sequential Output Sequential Input Random
  Per Char Block Rewrite Per Char Block Seeks
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
geli+md 1024 17178 25.7 18324 8.4 5684 2.2 14492 15.1 15185 2.3 139.8 0.7
geli+ggate 1024 13855 20.6 12018 5.2 6388 2.7 19021 21.8 22473 4.2 136.5 0.7

Как мы видим ggate медленнее работает на циклах записи, но намного быстрее работает на циклах чтения. Возможно это связано с буферизацией записи и различных методах сброса буферов в md и ggate. Если попробовать ввести неверный файл ключа или пароль, то geli не создаёт устройство для доступа к файловой системе, а так как файл контейнера внутри напоминает содержимое /dev/random, то расшифровать его просто нереально. Ни пофайлово, ни целиком. Одним из преимуществ geli является возможность использования нескольких ключей шифрования, скажем мастер ключа и ключа пользователей.

Инициализируем контейнер GBDE.
testcrypt# mdconfig -a -t vnode -f /var/test/testfile.dump -S 4096 -u 0<br/>testcrypt# gbde init /dev/md0 -i -K my.key -L /var/tmp/md0.lock -P testcrypt<br/>testcrypt# ll /var/tmp/md*<br/>md0.lock<br/>testcrypt# gbde attach /dev/md0 -l /var/tmp/md0.lock -k my.key -p testcrypt<br/>testcrypt# ll /dev/md*<br/>crw-r----- 1 root operator 0, 98 Apr 21 13:25 /dev/md0<br/>crw-r----- 1 root operator 0, 100 Apr 21 10:15 /dev/md0.bde<br/>crw------- 1 root wheel 0, 78 Apr 21 10:15 /dev/mdctl

gbde при создании устройства использует файл блокировки в котором находятся текущие ключи для инициализации криптоконтейнера. Система инициализации криптоконтейнера не имеет реверсивной процедуры восстановления данных, поэтому если вы забыли пароль или потеряли файл блокировки, то вы потеряли все данные которые находились в криптоконтейнере. После инициализации криптоконтейнера gbde создаёт устройство с суффиксом .bde с которым можно обращаться так же как и c .eli.
Подробное руководство по использованию обоих систем можно найти тут. Запускаем bonnie для тестирования связки gbde+md и gbde+ggate.
testcrypt# bonnie -s 1024<br/>File './Bonnie.1145', size: 1073741824<br/>
  Sequential Output Sequential Input Random
  Per Char Block Rewrite Per Char Block Seeks
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
gbde+md 1024 4436 5.3 4349 1.7 2695 1.2 12920 13.7 17078 2.9 130.1 0.7
gbde+ggate 1024 1971 2.2 1970 0.8 1480 0.6 13812 15.2 17206 3.0 120.3 0.6

Подсистема gbde показала довольно скудные значения быстродействия, хотя как видно из таблицы процессорное время практически не использовалось в отличии от geli. С чем это связано я так до конца и не выяснил.

Найдя в сети неофициальный порт TrueCrypt 6.1a на FreeBSD, было решено испытать его в работе.
TrueCrypt должен работать на FreeBSD через fuse, но на деле всё оказалось не совсем так.
Попытка скомпилить данный порт привела к тому, что в систему были затащены xorg, glib, gtk, gnome, wxWidgets и куча другого барахла. Детальный анализ выявил, что виной всему GUI интерфейс сделанный на wxWidgets. Нам GUI был ненужен и поэтому путём проб и ошибок были найдены магические последовательности для gmake которые таки собрали TrueCrypt на нашей тестовой системе.
gmake NOGUI=1 WX_ROOT=/usr/local/tmp/wx wxbuild<br/>gmake NOGUI=1 WXSTATIC=1 PKCS11_INC=/usr/local/include/pkcs11/<br/>

TrueCrypt запустился весело сообщив:
testcrypt# truecrypt<br/>13:35:34: Error: Cannot convert from the charset 'US-ASCII'!

Ругань относилась к тому, что TrueCrypt не смог конвертнуть help из LANG=C в en_US.UTF-8, который жестко зашит в исходниках.
testcrypt# /usr/bin/time truecrypt -c --filesystem=ufs -k /var/test/my.key --random-source=/dev/random /var/test/truecrypt.dump /mnt<br/>Volume type:<br/> 1) Normal<br/> 2) Hidden<br/>Select [1]:<br/> <br/>Enter volume size (sizeK/size[M]/sizeG): 4G<br/> <br/>Encryption algorithm:<br/> 1) AES<br/> 2) Serpent<br/> 3) Twofish<br/> 4) AES-Twofish<br/> 5) AES-Twofish-Serpent<br/> 6) Serpent-AES<br/> 7) Serpent-Twofish-AES<br/> 8) Twofish-Serpent<br/>Select [1]:<br/> <br/>Hash algorithm:<br/> 1) RIPEMD-160<br/> 2) SHA-512<br/> 3) Whirlpool<br/>Select [1]:<br/> <br/>Filesystem:<br/> 1) FAT<br/> 2) None<br/>Select [1]:<br/> <br/>Enter password:<br/>WARNING: Short passwords are easy to crack using brute force techniques!<br/>We recommend choosing a password consisting of more than 20 characters. Are you sure you want to use a short password? (y=Yes/n=No) [No]: y<br/>Re-enter password:<br/>Done: 100,000% Speed: 31 MB/s Left: 0 s<br/>The TrueCrypt volume has been successfully created.<br/>      139,42 real 204,75 user 13,80 sys

Созданный раздел без проблем смонтировался.
testcrypt# truecrypt -k /var/test/my.key --mount /var/test/truecrypt.dump /mnt<br/>Enter password for /var/test/truecrypt.dump:<br/>Protect hidden volume? (y=Yes/n=No) [No]:<br/> <br/>testcrypt# mount<br/>...<br/>/dev/fuse0 on /var/tmp/.truecrypt_aux_mnt1 (fusefs, local, synchronous)<br/>/dev/md0 on /mnt (msdosfs, local)<br/> <br/>testcrypt# mdconfig -l -v<br/>md0 vnode 4.0G /var/tmp/.truecrypt_aux_mnt1/volume<br/>testcrypt# ll /var/tmp/.truecrypt_aux_mnt1/<br/>total 0<br/>-rw------- 1 root wheel 1522 21 апр 15:51 control<br/>-rw------- 1 root wheel 4294705152 21 апр 15:51 volume

Но нас постигло жестокое разочарование. Вопреки ожидаемому использованию fusefs, TrueCrypt стал использовать трансляцию своего endpoint файла через md. Таким образом мы получили еще один лишний стык в преобразовании криптоконтейнера. Разочарование стало еще большим когда при попытке записи данных на примонтированный TrueCrypt Volume мы получили deadlock после того как исчерпались буфера записи для vfs. Танцы с бубном вокруг TrueCrypt, настроек vfs и многого другого ни к чему не привели и мы забросили идею нормального тестирования TrueCrypt. К сожалению текущая сборка TrueCrypt может создавать только две файловые системы независимо от OS, FAT и NTFS, это жестко запрограммировано в исходных кодах. Создание файловой системы на отмонтированном Volume вполне решает проблему использования msdosfs, но не решает проблему deadlock.

Так как тестируемые криптоконтейнеры у нас закончились, мы попытались реализовать какуюнибудь схему резервного копирования этих контейнеров. В общем тут нас ожидало не менее грустное обстоятельство, чем проблемы с TrueCrypt. Мы попытались сделать snapshot на файловой системе на которой находится подмонтированный криптоконтейнер и выцепив оттуда файл контейнера посмотреть на его содержимое. Но тут же поймали проблему. При активных файловых операциях с криптоконтейнером попытка сделать snapshot приводит к deadlock. Система вроде бы живая, но в тоже время обратиться к примонтированному контейнеру нельзя, а впоследствии умирает доступ ко всем системным разделам :(
При отсутствии операций с криптоконтейнером snapshot происходит нормально, но вероятность последующего deadlock тоже не исключена. Причем с md устройствами проблема проявляется раньше чем с ggate. После deadlock и последующей принудительной dirty(reboot -qn) перезагрузки, криптоконтейнер необходимо сначала проверить через fsck, иначе он не примонтируется. Выдернутый же криптоконтейнер из snapshot на поверку оказывается битым, с отсутствующей файловой системой и без наших данных. Что очень и очень грустно. Ну да ладно, нельзя использовать online бекап, значит 100% можно использовать offline бекап. На этом с криптоконтейнерами и остановимся.

Вторая часть тестирования связана с использованием fusefs.
Для тестирования были выбраны cryptofs и encfs. Разница между системами небольшая и основное отличие заключается в том, что encfs поддерживает параноидальный режим безопасности проверяющий целостность файлов.
testcrypt# cryptofs -r /var/crypto/<br/>Enter password:<br/>testcrypt# mount_fusefs /dev/fuse0 /mnt<br/>testcrypt# df -h | grep mnt<br/>Filesystem Size Used Avail Capacity Mounted on<br/>/dev/fuse0 18G 5.1G 12G 30% /mnt

cryptofs создаёт шлюз который шифрует проходящие через него данные при помощи пароля заданного пользователем, используя обычную файловую систему на машине. Для работы системы требуется поместить в директорию, которая будет домашней, файл с настройками .cryptofs
# See README for details on each parameter<br/> <br/>[CryptoFS]<br/>cipher=AES256<br/>md=MD5<br/>blocksize=2048<br/>salts=256

Настройки — это список алгоритмов шифрования, которые будут использоваться в работе. К сожалению месторасположение файла изменить нельзя :(
testcrypt# cp /etc/defaults/* /mnt<br/>testcrypt# ls /mnt/<br/>bluetooth.device.conf devfs.rules pccard.conf periodic.conf rc.conf<br/>testcrypt# ls /var/crypto/<br/>.cryptofs JuSxlpX8BzEtClI= MuKkkZS2WycuAUc= IO2ylZK9GjApQUWQR697gAD3Valf MOLpk4m8Ew== MuS1mYm2HCdvDE6bVw==

Система очень легка в использовании, но имеет один недостаток. Если Вы случайно ошиблись буквой или цифрой при вводе пароля — система зашифрует данные именно тем паролем который Вы набрали. Велика вероятность того, что Вы заметите это не сразу, а пользователи уже нальют файлов которые будут зашифрованы новым паролем. Файловая система после ввода неверного пароля выглядит примерно вот так.
testcrypt# cryptofs -r /var/crypto<br/>Enter password:<br/>testcrypt# mount_fusefs /dev/fuse0 /mnt<br/>testcrypt# ls /mnt/<br/>i+???F9&??tg? i-???F~&T?} k-???L6 {"???M?1SA?l?????y???   }+????"0W?h<br/> <br/>

encfs данной проблемы лишён, но имеет уже намного более широкие настройки по шифрованию, а также в конфигурационном файле создаёт уникальный ключ. При помощи этого ключа encfs определяет корректность ввода пароля, правильность шифрования файлов, а также определяет какие файлы показывать или не показывать(имеется ввиду — шифрованные именно этим ключом). Если Вы забыли пароль, то можете смело удалять все данные, восстановлению они не подлежат. Процесс работы выглядит следующим образом.
testcrypt# encfs /var/crypto /mnt<br/>Creating new encrypted volume.<br/>Please choose from one of the following options:<br/> enter "x" for expert configuration mode,<br/> enter "p" for pre-configured paranoia mode,<br/> anything else, or an empty line will select standard mode.<br/>?><br/> <br/>Standard configuration selected.<br/> <br/>Configuration finished. The filesystem to be created has<br/>the following properties:<br/>Filesystem cipher: "ssl/aes", version 2:1:1<br/>Filename encoding: "nameio/block", version 3:0:1<br/>Key Size: 192 bits<br/>Block Size: 1024 bytes<br/>Each file contains 8 byte header with unique IV data.<br/>Filenames encoded using IV chaining mode.<br/> <br/>Now you will need to enter a password for your filesystem.<br/>You will need to remember this password, as there is absolutely<br/>no recovery mechanism. However, the password can be changed<br/>later using encfsctl.<br/> <br/>New Encfs Password:<br/>Verify Encfs Password:<br/>testcrypt# mount | grep mnt<br/>/dev/fuse0 on /mnt (fusefs, local, synchronous)<br/>testcrypt# cp /etc/defaults/* /mnt<br/>testcrypt# ls /mnt<br/>bluetooth.device.conf devfs.rules pccard.conf periodic.conf rc.conf<br/> <br/>testcrypt# ls /var/crypto/<br/>.cryptofs Nq2IBppvuCpNNHuYS1k5dn-q wiNUtxqXvJqCLs3s-u1qwJrA<br/>.encfs6.xml gNsHASsB,5N2H1TZlWTJjldR<br/>B7rx58O9WjTGrjeTaiFXjREamAQzW7u3oK3NOK1KuN4Rp- sTZaWdYP4B-oXrW1d1COMMNV


Бекапирование данных можно осуществлять методом обычного снятия снепшотов с раздела, а также прямым копированием файлов в требуемое место, главное сохранить ключи для возможности обратной расшифровки ;)

Выводы: Все исследуемые в данной статье методы шифрования данных на дисках имеют право на использование в повседневной жизни. В зависимости от используемых систем шифрования, Вы можете получить нужный Вам функционал за короткий промежуток времени. Из тестируемых мною систем я бы всё таки остановил свой выбор на geli и encfs. Первая система очень привлекательна с точки зрения использования аппаратных модулей шифрования, при использовании которых не будет затрачиваться процессорное время на шифрование данных, а также возможностью шифрования разделов целиком. Вторая система интересна режимами контроля целостности шифруемых файлов и возможностями изменения множества параметров. При всём уважении к encfs хочется отметить зависимость системы от нескольких внешних библиотек которые придётся таскать с собой. Опять же с geli могут возникнуть проблемы с резервным копированием массивов большого объёма. Ну вот в общем-то и всё. Спасибо за уделённое время на прочтение данного материала.

Сравнительная таблица тестов bonnie по всем системам.
  Sequential Output Sequential Input Random
  Per Char Block Rewrite Per Char Block Seeks
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
geli+md 1024 17178 25.7 18324 8.4 5684 2.2 14492 15.1 15185 2.3 139.8 0.7
geli+ggate 1024 13855 20.6 12018 5.2 6388 2.7 19021 21.8 22473 4.2 136.5 0.7
gbde+md 1024 4436 5.3 4349 1.7 2695 1.2 12920 13.7 17078 2.9 130.1 0.7
gbde+ggate 1024 1971 2.2 1970 0.8 1480 0.6 13812 15.2 17206 3.0 120.3 0.6
fusefs+cryptofs 1024 17207 23.8 21015 10.7 6494 3.5 16202 17.1 16829 3.2 70.1 1.2
fusefs+encfs 1024 19073 25.3 23250 11.4 7676 3.9 16402 18.4 19187 3.5 70.3 1.2


UPD: Таблица сравнения скоростей чистой файловой системы и шифрованной. С включенными и выключенными softupdates.
  Sequential Output Sequential Input Random
  Per Char Block Rewrite Per Char Block Seeks
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
fusefs+cryptofs 1024 17207 23.8 21015 10.7 6494 3.5 16202 17.1 16829 3.2 70.1 1.2
fusefs+encfs 1024 19073 25.3 23250 11.4 7676 3.9 16402 18.4 19187 3.5 70.3 1.2
cleanfs+su_on 4096 33745 33.5 32517 12.8 10681 4.4 34911 35.9 39035 7.7 80.1 0.5
cleanfs+su_off 4096 34918 33.4 35108 12.9 11188 4.5 37268 38.3 39513 7.6 84.6 0.5


(C) Aborche 2009
aborche @aborche
карма
100,2
рейтинг 0,0
Системный администратор
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (16)

  • +2
    Для оживляжа нужны диаграммы и графики вместо таблиц.

    И ещё один вариант: заливаем 2 gb файл из пробелов, а потом читаем напрямую с диска, без шифрования. Получится набор байтов, из которого делаем красивую картинку. Чтоб видно было: система работает, все пробелы зашифрованы, враг не догадается.
    • +4
      видео как deadlock происходит снять? на на ютуб? :)
    • +1
      пробелы — это фигня. ты попробуй залить монохромный bmp файл, а затем посмотреть на зашифрованный отпечаток.
      • 0
        сделать?
        ради прикола :)
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      ну я особых проблем с покушением на содержимое не вижу. одни и теже алгоритмы шифрования, разные только методы их использования. Инфо по уязвимостям алгоритмов есть в сети.
      • 0
        А как насчет ошибок? Возможно есть простой способ подобрать пароль из за ошибки программиста?
        • 0
          Поддерживаю двумя руками.

          Как раз неделю назад на Васме приводился кусок кода, где (скорее всего по незнанию) программист реализовал ГОСТ 28147 так, что инициализировал синхропосылку XOR-енными между собой байтами ключа шифрования
          (и естественно передавал это в открытом виде в начале сеанса).

          Какой способ, кроме независимого и тщательного просмотра исходного кода, даст гарантию отсутствия таких же ляпов в приведенных выше продуктах?
    • 0
      Я сказал бы более категорично:

      если шифросистема А работает в 2 раза быстрее, чем система B,
      но при этом вероятность наличия ошибок в ней хотя бы на 1% выше, то
      я всё равно выберу систему B
  • 0
    > dd if=/dev/random
    не лучший вариант для оценки скорости именно _шифрования_ — генерация рандома сама по себе довольно затратная операция.
    На расположение контейнеров по скорости это конечно не влияет, а вот на величины вроде «Как видно из тестов скорость записи упала почти в 2 раза» — очень даже.

    Впрочем, возможно вы это сделали умышленно и мой каммент не в тему, но для меня «скорость записи» это скорость самой записи, без учёта скорости генерации данных.
    • 0
      на самом деле момент спорный. использование /dev/zero для создания шифрованного контейнера по моему неверно. ибо шифрование происходит поблочно и отделение шифрованного блока от нешифрованного на носителе не составит особого труда. С точки зрения реального использования /dev/random и /dev/zero, то я сильно сомневаюсь, что у вас на файловой системе будут файлы с нулевым содержимым. /dev/random использовался на одной и той же машине, на одних и тех же ресурсах, поэтому использованием /dev/random или /dev/zero я думаю можно пренебречь. Если бы использовались и zero и random, то понятное дело о результатах можно было бы поспорить.
      Если есть сомнения, то могу сделать тесты на /dev/zero и выложить. особой разницы вы не увидите.
      • 0
        Конечно на результат сравнения это никак не повлияет. Быстрые останутся быстрыми, а медленные медленными. Но всё же когда написано «Как видно из тестов скорость записи упала почти в 2 раза» без учёта генерации /dev/random падение окажется намного больше чем в 2 раза. Просто думаю важнее именно падение относительно максимальной скорости харда. А судя по
        151.82 real .00 user 132.96 sys
        в оценке скорости линейной записи на нешифрованный носитель она (скорость) упёрлась именно в процессор, а никак не в хард

        > Если есть сомнения, то могу сделать тесты на /dev/zero и выложить. особой разницы вы не увидите.
        Да нет что вы, сомнений в относительных результатах нет никаких. Тем более что дальше идут тесты bonnie
        • 0
          ну вот сейчас ради эксперимента сделал следующее.
          проверил /dev/zero и /dev/random с включенно/выключенными softupdates.

          zero+su_off = 36539247 bytes/sec
          121.40 real 0.02 user 15.72 sys

          zero+su_on = 36379845 bytes/sec
          118.06 real 0.02 user 16.58 sys

          random+su_off = 28802712 bytes/sec
          149.11 real 0.02 user 133.52 sys

          random+su_on = 26710585 bytes/sec
          160.81 real 0.02 user 134.81 sys

          при использовании /dev/random наблюдается нелинейная кривая которая таки в итоге упирается в 100% загрузку одного из камней. Тут Вы правы, признаю.
  • 0
    Опечатка:
    Это может быть физический накопитель(da0), партиция(da0s1), слайс(da0s1a)

    Правильно:
    … партиция(da0s1a), слайс(da0s1)
  • 0
    Жаль в таблице нет скорости работы без шифрования. Я сейчас думаю стать криптоманьяком и включить шифрование /home в новой Ubuntu с помощью encfs :). Резонный вопрос, как это скажется на скорость.
    • 0
      Добавил сравнительную таблицу. Смотрите в конце статьи

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