Какая прога быстро зашифрует раздел?
Извиняюсь, за может быть ламерский вопрос... но ситуация следующая...
Хочется все проги имеющиеся на компе запускать с отдельного защифрованного диска...
Но использование программ таких как TrueCrypt, Bat PrivateDisk и т.д. существенно снижает скорость работы с диском... Соответственно программулины начинают ощутимо претормаживать...
Тестировал программкой Drive Speed... на 50%, а то и на 70%.
Хотелось бы узнать а есть ли решения которые позволяют шифрануть без тормозов... например крипованием только области на винте, где находиться инфа о файлах... Пока видел только Drive Encryption... она как раз криптует весь раздел без тормозов. Не знаю насколько она эффективна?
P. S.: Сразу говорю я не кул хацкер... Нужно просто спрятать проги от "внезапно нагрянувших, говорящих о лицензиях там каких то"... Все проги портабельные в самой винде не светятся никак...
комментариев: 11558 документов: 1036 редакций: 4118
Если Вы будете шифровать только метаданные, а "проверяющие" решат изъять ПК, найдут там много интересного, даже не имея доступа к именам файлов. Вы знаете, что данные с диска можно прочитать в raw-режиме? Можете надеяться, что проверяющие этого не знают, только это какая-то страусиная позиция.
Блиннн... ну, уж очень не хочеться терять половину всей производительности дисковой системы...
комментариев: 11558 документов: 1036 редакций: 4118
Пожалуйста. Горькая правда лучше, чем сладкая ложь. :-)
Я таких не знаю. Просто в качестве примера назвал. В старых версиях TrueCrypt (до версии 4.3) были быстрые шифры с 64-битовым блоком, в частности, Blowfish. Использовать такие алгоритмы на больших объёмах данных не совсем безопасно, но для Вашего случая этого, пожалуй, хватит. Попробуйте.
комментариев: 9796 документов: 488 редакций: 5664
Не будем грузить гостя теорией. Но, тем не менее, RC4 – поточный шифр, для шифрования секторов диска его пришлось бы перевести в режим блочного шифрования. Я бы не стал доверять таким нестандартным решениям.
Наверное, таких программ нет. А если есть, то лучше их не использовать.
комментариев: 1515 документов: 44 редакций: 5786
В OpenBSD используется исключительно Blowfish для шифрования дискового пространства (типа, всё должно быть быстро). Это не то ли что нужно гостю?
комментариев: 83 документов: 4 редакций: 4
Поигрался тут с бенчмарками шифров (TrueCrypt 4.3a). Удивился насколько зависит от платформы – если на Р4 шифрование Twofish вдвое медленнее AES 25.6 против 48.9 Мб/с (при одинаковой скорости расшифрования 33.6), то на Conro шифрование Twofish уже быстрее, чем AES (66.5 и 66.0). Также удивился разнице в скорости шифрования и расшифрования – и Twofish и AES могут использовать одну и ту же процедуру – подключи (и таблица замен для AES) расчитываются однократно.
комментариев: 11558 документов: 1036 редакций: 4118
- Twofish – 36,0
- Serpent – 28,8
- AES – 28,6
Что характерно, в ходе тестов суммарная нагрузка обоих ядер не превышает 53% (при этом балансировка на обоих ядрах довольно симметрична). Может ли пропускная способность ОЗУ выступать ограничивающим фактором? (Конечно, это синтетические цифры, и при работе с реальным жёстким диском таких показателей без SCSI не добиться уже из-за ограничений на скорость чтения/записи самого накопителя.) При случае проверю в Linux, интересно, сколь велики отличия для 64-битового ядра ОС.комментариев: 83 документов: 4 редакций: 4
комментариев: 11558 документов: 1036 редакций: 4118
Как правило, один поток одно ядро и занимает (то есть на 100%, тогда как другое – 0%, давая в итоге искомые 50%). Здесь же нагрузка около 45% на первом и 55% на втором, что нетипично.
комментариев: 11558 документов: 1036 редакций: 4118
Получилось вот что:
- Twofish – 32 (-10%)
- AES – 29,5 (+4%)
- Serpent – 24,7 (-13%)
Оценка выполнялась только для зашифрования на том же AMD Turion 64 2x 1600MHz, что и в Windows, но на сей раз в Gentoo Linux 2.6.22 (сборка с оптимизацией под x86-64), TrueCrypt 4.3 (аналогично).Поскольку в Linux-версии TrueCrypt отсутствует встроенный бенчмарк, телеметрия была получена так: time truecrypt --encryption <algo> --filesystem none --hash SHA-1 --keyfile "" --random-source /dev/urandom --type normal --disable-progress --size 500M --create ~/temp.tc.
Каждый алгоритм тестировался четыре раза, а итоговые Мб/с рассчитывались как 524 / ((CPU_kernel + CPU_userspace) / 4). Результат похож на предсказанный (за исключением AES), однако, здесь, в отличие от синтетического теста в Windows, данные реально писались на диск. Если аналогичным образом (time cp test.tc test1.tc) замерить время процессора для чтения-записи данных, получается порядка 0,005 сек. на Мб. Если разделить это значение надвое (грубо получая только время записи) и применить как поправку к изначальным результатам (компенсировав время записи и приведя показатели к синтетическим результатам Windows), получаем следующую картину:
При большом условии, что поправка на время записи сколь-нибудь точна, в сухом остатке имеем AES с примерно 15-процентным ускорением относительно 32-битовой ОС, и Twofish и Serpent с замедлением на 5-7%. Расчёты выполнялись вручную (лень писать скрипт, чтобы перемножить-поделить дюжину цифр) с округлениями и приближениями, но, надеюсь, слишком сильно я цифры не переврал.
Есть средства аппаратного шифрования, вроде http://addonics.com/products/Saturn/aesmr.asp
Насколько надежно подобное решение? Если в raw режиме можно будет прочитать такие диски наверное тогда мучиться и заказывать их не стоит, я так понимаю.
комментариев: 371 документов: 19 редакций: 20
Из программных решений могу посоветовать http://freed0m.org/?index=dcrypt
Это наиболее быстрое из всех существующих открытых решений (в 1.5-6 раз быстрее TrueCrypt в зависимости от условий работы), но программа пока находиться в beta версии, поэтому ОБЯЗАТЕЛЬНО делайте резервные копии данных перед шифрованием.
Если вы решили использовать коммерческое решение, то используйте ТОЛЬКО PGP WDE, потому что все другие аналоги закрыты и вызывают вопросы аналогичные проприетарным железкам.
комментариев: 1060 документов: 16 редакций: 32
комментариев: 11558 документов: 1036 редакций: 4118