| RSS



Меню

Bookmark and Share


Статистика
Ваш IP: 18.210.12.229
Вы используете: v





Сейчас на сайте:

Тех поддержка ->

Облако тэгов
ОС видио Tor Обратная сторона антенна 4.6 PHP Эксплоит Windows Server 2008 qip Virtual chroot kernel proc sysctl tune FreeBSD bridge Boot Disk Bluetooth GEO game directx Emulator Python Shell DDoS червь Conficker вирус троян Лаборатория Касперского пиратство apple iPhone ИТ-отрасль Щеголев Microsoft экономический кризис Twitter социальная сеть анонимность Лицензия Open Source ASP.NET MVC уязвимость MySQL база данных файлообмен закон франция пират Skype мобильный Deutsche Telekom Хакер киберпреступник Trend Micro кибератака Германия робот утечка данных персональные данные ноутбук интернет Китай цензура ядро Linux Торвальдс Windows Vista Acer Linux патент браузер Firefox Internet Explorer Opera Net Applications Safari Intel Linux Foundation Moblin Oracle патч банкомат кардер HSM IBM X-Force Cofee сша кибервойна Эстония Dell ИТ-специалист хакерские атаки Pirate Bay контроль кибербезопасность язык программирования The Pirate Bay Пиратская партия утечка информации приговор Mozilla Chrome безопасность Госдума СМИ Windows 8 Баллмер взлом Пентагон ботнет Украина Facebook Cisco cloud Windows XP нетбук торрент музыка биометрический nokia ФБР IP-адрес CIPAV Comcast sms RSA java Google CAPTCHA Symantec спам конфиденциальная информация инсайдер Perimetrix антивирус тест Anti-Malware Windows 7 операционная система Windows провайдер авторское право RapidShare UNIX свиной грипп шантаж дети EFF BluWiki копирайт экстремизм Panda Security cloud computing McAfee Cybercrime Response Unit Bottle Domains HTTPS ICANN студент шпионское ПО Норвегия школьник New York Times XSS YouTube Warner Music кибершпионаж КНДР Ubuntu свободное ПО AMD ATI касперский Россия РФ сервер хостинг фальшивый антивирус Comodo CA Wi-Fi D-Link суд пароль блог фишинг Одноклассники медведев контрафакт мошенник штраф Sony GPS по Gumblar JAVASCRIPT хакеры вредоносное ПО Yahoo ФАС компьютер Софт MPAA кибероружие PandaLabs Red Hat Минкомсвязи сбой ASUSTeK Computer мошенничество Доктор Веб ВКонтакте Cyber-Arc исходный код PCI DSS МВД фильтр порнография BREIN свобода слова Казахстан GEMA Autodesk сисадмин Gmail кредитная карта кибермошенник LiveJournal шифрование криптография Deep Purple банк нанотехнологии Wikipedia zero-day ColdFusion выборы кража данных DNS BIND Android BASIC атака Black Hat Mac OS X Click Forensics Clampi домен фсб Прокуратура Уголовное дело icq Barrelfish киберпреступность Sophos AT&T ошибка Electa Gamma Knife OpenBSD DARPA военные Сайт Visual Studio 2010 .NET Framework 4 Chrome OS электронная почта турция конференция спамер FTC полиция российская ОС Koobface Великобритания БЕЛОРУССИЯ грузия BSA Bittorrent облачные вычисления Azure Европа Dr.Web Билл Гейтс спецслужбы Cryzip Живой Журнал Royal Bank of Scotland смартфон Canonical Pwn2Own F-Secure Symbian Hotmail фильм

Главная » Статьи » Общие Статьи

Сравнительное тестирование криптоконтейнеров и шифрованных файловых систем
Основные задачи:
— Возможность бекапирования данных в любом виде для аварийного восстановления.
— Исключение доступа к этим данным неавторизованных лиц.
— Невозможность доступа к файлам при аварийном выключении сервера и загрузке с внешнего носителя.
— Прозрачная работа пользователей с файлами и любым содержимым находящемся на сервере.
— 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
ad0: 38166MB <Seagate ST340014A 3.06> at ata0-master UDMA100
# mount | grep var
/dev/ad0s1g on /var (ufs, local, soft-updates)

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

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

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

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

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

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

При прочих равных условиях 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
testcrypt# /usr/bin/time geli init -s 4096 -K my.key /dev/md0
Enter new passphrase:
Reenter new passphrase:
       13.34 real 9.61 user .00 sys

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

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

Как мы видим, скорость упала до 14.5 мегабайт/сек. Я пропущу блок разметки и тестирования скорости связки ggate+geli, так как он идентичен блоку geli+md. Так как мы не можем оценивать скорость работы только по циклу записи, мы запускаем bonnie для дополнительного анализа.
Сводные результаты работы bonnie на всех связках будут приведены в конце статьи.
testcrypt# bonnie -s 1024
File './Bonnie.1145', size: 1073741824
  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
testcrypt# gbde init /dev/md0 -i -K my.key -L /var/tmp/md0.lock -P testcrypt
testcrypt# ll /var/tmp/md*
md0.lock
testcrypt# gbde attach /dev/md0 -l /var/tmp/md0.lock -k my.key -p testcrypt
testcrypt# ll /dev/md*
crw-r----- 1 root operator , 98 Apr 21 13:25 /dev/md0
crw-r----- 1 root operator , 100 Apr 21 10:15 /dev/md0.bde
crw------- 1 root wheel , 78 Apr 21 10:15 /dev/mdctl

gbde при создании устройства использует файл блокировки в котором находятся текущие ключи для инициализации криптоконтейнера. Система инициализации криптоконтейнера не имеет реверсивной процедуры восстановления данных, поэтому если вы забыли пароль или потеряли файл блокировки, то вы потеряли все данные которые находились в криптоконтейнере. После инициализации криптоконтейнера gbde создаёт устройство с суффиксом .bde с которым можно обращаться так же как и c .eli.
Подробное руководство по использованию обоих систем можно найти тут. Запускаем bonnie для тестирования связки gbde+md и gbde+ggate.
testcrypt# bonnie -s 1024
File './Bonnie.1145', size: 1073741824
  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
gmake NOGUI=1 WXSTATIC=1 PKCS11_INC=/usr/local/include/pkcs11/

TrueCrypt запустился весело сообщив:
testcrypt# truecrypt
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
Volume type:
 1) Normal
 2) Hidden
Select [1]:
 
Enter volume size (sizeK/size[M]/sizeG): 4G
 
Encryption algorithm:
 1) AES
 2) Serpent
 3) Twofish
 4) AES-Twofish
 5) AES-Twofish-Serpent
 6) Serpent-AES
 7) Serpent-Twofish-AES
 8) Twofish-Serpent
Select [1]:
 
Hash algorithm:
 1) RIPEMD-160
 2) SHA-512
 3) Whirlpool
Select [1]:
 
Filesystem:
 1) FAT
 2) None
Select [1]:
 
Enter password:
WARNING: Short passwords are easy to crack using brute force techniques!
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
Re-enter password:
Done: 100,000% Speed: 31 MB/s Left: s
The TrueCrypt volume has been successfully created.
      139,42 real 204,75 user 13,80 sys

Созданный раздел без проблем смонтировался.
testcrypt# truecrypt -k /var/test/my.key --mount /var/test/truecrypt.dump /mnt
Enter password for /var/test/truecrypt.dump:
Protect hidden volume? (y=Yes/n=No) [No]:
 
testcrypt# mount
...
/dev/fuse0 on /var/tmp/.truecrypt_aux_mnt1 (fusefs, local, synchronous)
/dev/md0 on /mnt (msdosfs, local)
 
testcrypt# mdconfig -l -v
md0 vnode 4.0G /var/tmp/.truecrypt_aux_mnt1/volume
testcrypt# ll /var/tmp/.truecrypt_aux_mnt1/
total
-rw------- 1 root wheel 1522 21 апр 15:51 control
-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/
Enter password:
testcrypt# mount_fusefs /dev/fuse0 /mnt
testcrypt# df -h | grep mnt
Filesystem Size Used Avail Capacity Mounted on
/dev/fuse0 18G 5.1G 12G 30% /mnt

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

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

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

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

23:44
Обновить


Пользователи
aka_kludge
qwerty
LeadyTOR
aka_Atlantis
AdHErENt
mAss
Sissutr
hiss
DrBio
tHick

Поиск


Copyright tHR - TeAM 2021 г. admin: aka_kludge (ICQ:334449009) Moderator's: LeadyTOR, ... Яндекс.Метрика