Какая прога быстро зашифрует раздел?
Извиняюсь, за может быть ламерский вопрос... но ситуация следующая...Хочется все проги имеющиеся на компе запускать с отдельного защифрованного диска...
Но использование программ таких как TrueCrypt, Bat PrivateDisk и т.д. существенно снижает скорость работы с диском... Соответственно программулины начинают ощутимо претормаживать...
Тестировал программкой Drive Speed... на 50%, а то и на 70%.
Хотелось бы узнать а есть ли решения которые позволяют шифрануть без тормозов... например крипованием только области на винте, где находиться инфа о файлах... Пока видел только Drive Encryption... она как раз криптует весь раздел без тормозов. Не знаю насколько она эффективна?
P.S.: Сразу говорю я не кул хацкер... Нужно просто спрятать проги от "внезапно нагрянувших, говорящих о лицензиях там каких то"... Все проги портабельные в самой винде не светятся никак...
"Надёжно" и "быстро" не бывает, выбирайте одно из двух. Если шифрование не вызывает снижения производительности, то либо 1) используется сверхбыстрый, но малонадёжный алгоритм (скажем, RC4 или вообще доморощенная поделка), либо 2) шифруется только таблица размещения файлов (метаданные), но не данные, либо 3) никакого шифрования не используется, а Вам просто пудрят мозги.
Если Вы будете шифровать только метаданные, а "проверяющие" решат изъять ПК, найдут там много интересного, даже не имея доступа к именам файлов. Вы знаете, что данные с диска можно прочитать в raw-режиме? Можете надеяться, что проверяющие этого не знают, только это какая-то страусиная позиция.
Ясно... Вы меня прям мордой об асфальт)))) спасибо!
Блиннн... ну, уж очень не хочеться терять половину всей производительности дисковой системы...
А какие проги поддерживают RC4?
Пожалуйста. Горькая правда лучше, чем сладкая ложь. :-)
Я таких не знаю. Просто в качестве примера назвал. В старых версиях TrueCrypt (до версии 4.3) были быстрые шифры с 64-битовым блоком, в частности, Blowfish. Использовать такие алгоритмы на больших объёмах данных не совсем безопасно, но для Вашего случая этого, пожалуй, хватит. Попробуйте.
Не будем грузить гостя теорией. Но, тем не менее, RC4 – поточный шифр, для шифрования секторов диска его пришлось бы перевести в режим блочного шифрования. Я бы не стал доверять таким нестандартным решениям.
Наверное, таких программ нет. А если есть, то лучше их не использовать.
SATtva
В OpenBSD[link1] используется исключительно Blowfish для шифрования дискового пространства (типа, всё должно быть быстро). Это не то ли что нужно гостю?
Возможно сюда.
Поигрался тут с бенчмарками шифров (TrueCrypt 4.3a). Удивился насколько зависит от платформы – если на Р4 шифрование Twofish вдвое медленнее AES 25.6 против 48.9 Мб/с (при одинаковой скорости расшифрования 33.6), то на Conro шифрование Twofish уже быстрее, чем AES (66.5 и 66.0). Также удивился разнице в скорости шифрования и расшифрования – и Twofish и AES могут использовать одну и ту же процедуру – подключи (и таблица замен для AES) расчитываются однократно.
Результаты для двуядерного AMD-64 под Win32 (среднее):
- Twofish – 36,0
- Serpent – 28,8
- AES – 28,6
Что характерно, в ходе тестов суммарная нагрузка обоих ядер не превышает 53% (при этом балансировка на обоих ядрах довольно симметрична). Может ли пропускная способность ОЗУ выступать ограничивающим фактором? (Конечно, это синтетические цифры, и при работе с реальным жёстким диском таких показателей без SCSI не добиться уже из-за ограничений на скорость чтения/записи самого накопителя.) При случае проверю в Linux, интересно, сколь велики отличия для 64-битового ядра ОС.Он однопоточный. Это одно ядро работает на 100% (и еще система что-то делает). Зачем Винда гоняет задачу межу ядрами? В одной железячной конференции сказали "Чтобы им было не скучно." У меня нагрузка делится примерно 80%/20% Судя по отсутстствию какой либо зависимости от размера буфера (от 5 Кб до 100 Мб) – вряд ли. Из любопытства погонял ISO образ на 800 Мб. Межу партициями 50 Мб/с (один физ. RAID0), запись в криптоконтейнер 35 Мб/с (35% загрузка одного ядра), между криптоконтейнерами 32 Мб/с. В последнем случае оба ядра грузятся на 35%. Должно быть процентов на 10 медленнее. Ни один из этих шифров под 64 бита не оптимизирован, только большую адресную информацию процессору гонять.
Как правило, один поток одно ядро и занимает (то есть на 100%, тогда как другое – 0%, давая в итоге искомые 50%). Здесь же нагрузка около 45% на первом и 55% на втором, что нетипично.
Получилось вот что:
- 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 режиме можно будет прочитать такие диски наверное тогда мучиться и заказывать их не стоит, я так понимаю.
Средства аппаратного шифрования непроверяемы, и поэтому я очень не рекомендую их использовать. Используйте ТОЛЬКО программные решения, либо аппаратные решения с открытой, поддающейся проверке архитектурой (к сожалению не знаю таких). Иначе никто не гарантирует, что вместо 3DES в том девайсе не окажется 3XOR :)
Из программных решений могу посоветовать http://freed0m.org/?index=dcrypt
Это наиболее быстрое из всех существующих открытых решений (в 1.5-6 раз быстрее TrueCrypt в зависимости от условий работы), но программа пока находиться в beta версии, поэтому ОБЯЗАТЕЛЬНО делайте резервные копии данных перед шифрованием.
Если вы решили использовать коммерческое решение, то используйте ТОЛЬКО PGP WDE, потому что все другие аналоги закрыты и вызывают вопросы аналогичные проприетарным железкам.
Кроме того, указанные длины ключей не соответствуют указанным криптоалгоритмам.
Единственный тип аппаратных решений, которые я могу посоветовать, — это криптоускорители типа VIA Padlock. Они берут на себя все криптографические вычисления (которые выполняют очень эффективно, ибо специализированная схема), разгружая тем самым процессор; сами примитивы остаются реализованы чисто программно. К сожалению, это не универсальное решение. Тот же Padlock поддерживает OpenSSL, но ни одна программа дискового шифрования не использует OpenSSL в качестве криптопровайдера.
sentaus, если речь об этом
то всё "нормально": они просто накинули лишние 8 битов чётности на каждый ключ, которые совершенно не влияют на стойкость. Формально материал ключа DES на самом деле составляет 64 бита, но в научной литературе принято говорить только об эффективной длине — 56 битов.
Кстати, для темы Юмор[link2] может быть интересно вот это[link3]:
Или ребята не понимают, о чём говорят, или намеренно вводят в заблуждение. (Если быть педантичным, можно сказать, что программное шифрование в сравнении с аппаратным легче обойти, учитывая дырявость большинства софта и операционных систем, но это не то, о чём они пишут.)
...Вообще довольно забавно, что стоимость жёсткого диска у них зависит от длины ключа. :-)
Скорее всего маркетинг отрабатывает деньги. А диск сам у них там не прилагается. Только кит мобил рэка + ключ определенной длинны.
Если по теме – мне нужно именно аппаратное шифрование, потому как ставиться будет на системный раздел.
Я Вас правильно понял что если производитель не врет и там действительно 3DES шифрование то вещь стоит своих денег?
А чем PGP WDE или DiskCryptor не устраивают? Шифруют диск целиком, включая и системный раздел.
О режиме шифрования они ничего не пишут ("не все режимы-йогурты одинаково полезны"). Не удивлюсь, если там простой CBC или, чего доброго, ECB, учитывая такой маркетинг и тот факт, что они заведомо продают одноключевой DES в век, когда этот шифр не позволит только "младшей сестре прочитать Ваши файлы". (Кстати, многоключевые режимы DES они тоже не называют.)
И чтобы добить: как я понимаю из описания, ключи генерируете не Вы сами, они поставляются "фирмой" вшитыми в брелоки. Если хотите генерировать ключи самостоятельно, придётся обзавестись вот такой фигнёй[link4] за две штуки баксов.
Жаль что VIA PadLock встроен только в малораспостраненные процессоры VIA, а гиганты рынка Intel и AMD не сделали еще своего аналога. Я читал спецификации по PadLock, и даже подумавал встроить его поддержку в DiskCryptor, но меня останавливает отсутствие процессора на руках.
Подобные PadLock аппаратные решения хороши тем, что параноики могут проверить правильность их работы простым сравнением результатов с программной реализацией. Единственное что такой проверке не поддается – это hardware RNG. Но его достаточно просто использовать не в одиночку, а как компонент накопительного софтварного RNG с множетсвом источников энтропии.
Да, у меня та же самая мысль возникла.
Прямо как сертификаты у одной другой конторы :)
Все это за километр пахнет Хаанским бальзамом.
списался с техподдержкой производителя
диалог примерно следующий получился
– what DES mode are u use (ECB, CBC, CFB, OFB)?
ECB mode
– is multikey solutions for DES awailable?
For our TDES chips, we use either TWO (128-bit) or THREE (192-bit) different DES keys
– is it possible to change pregenerated key instead of using programming unit?
Please elaborate the question.
– is ur solution use full hard drive encryption not only file allocaion table?
Full disk encryption applies to all sectors of a drive including MBR and FAT.
– is "192bit TDES" means that it is only one 56(64) key applyed three times?
No. THREE different DES 64-bit keys to make the TDES 192-bit strength. The algorithm follows:
Encrypt with Key#1 --> Decrypt with Key#2 --> Encrypt with Key#3. If
Key#1, Key#2, and Key#3 are all independent, it's TDES 192-bit strength;
Key#1 = Key#3, Key#2 independent, it's TDES 128-bit strength.
упс сорри не освоился с тегами.
ECB это не шифрование. Для примера bmp картинка зашифрованая в ECB режиме сохраняет видимое изображение, только теряя в несколько раз разрешение.
К тому же производитель упорно продолжает считать 56 битные DES ключи 64 битными.
Ну и даже если там действительно окажется 3DES как заявлено, то это не снимает вопрос надежности шифрования, так как нет ни исходного кода ни внятной методики проверки ключей на стойкость. А что, если тот девайс за 2000 баксов генерирует ключи из крайне ограниченого набора? Тогда ваши данные будут полностью вскрываемы за секунды. Про безопасность ключей поставляемых в комплекте речи даже не идет, ибо производителю никто не мешает сделать их копию.
Лично я не верю в честность кого-либо кроме себя, и не стану пользоваться тем, что не могу проверить. Поэтому не советую покупать эти поделки.
Я-то был не слишком серьёзен, предполагая ECB. Молодцы, оправдали мои самые смелые предположения. :-)
Более того, сам производитель пишет, что если вы теряете один дубликат брелока (их в поставке идёт 2 шт.), то другой должны немедленно переслать в фирму для изготовления резервной копии (с помощью того агрегата, напоминающего кассовый аппарат :-).
Ржунимагу :)
P. S.: сорри, не удержался :)
Нужно написть им, что столь надёжного шифрования не требуется. Достаточно слова "CRYPTO" на диске =)
Ответ на вопрос темы тут: https://www.pgpru.com/forum/pr.....j/drivecryptpluspack[link5]
Тормоза почти не ощущаются и составляют примерно 10-20% потери производительности дисков.
DiskCryptor быстрее :)
Возможно, но...
Ограничения:
1. Шифрование системного раздела при использовании динамических дисков невозможно.
2. Для загрузки ОС можно использовать только один раздел (конфигурации, когда ntldr и boot.ini находятся на одном разделе, а сама система на другом, DiskCryptor не поддерживает).
Используйте базовые диски.
А перенести загрузчик на раздел с симтемой очень трудно?
Зато у Drive Crypt Plus pack есть один фатальный недостаток, который перевешивает все мыслимые и немыслимые достоинства – это негарантированая безопасность. Вы можете только верить авторам удтверждающим что "все безопасно" (все так говорят), ну а проверить не получиться.
Для криптографического софта закрытость – это недостаток переводящий программу в разряд "защита для домохозяек", все остальные не будут даже рассматривать такой софт как безопасный.
С одной стороны – я всячески рад вашему творению (наше, наше!) и тому, что оно есть "опенсорс".
С другой – авторитет разработчика упомянутой мной программы весьма высок и (для меня) сравним с авторитетом автора PGP. Чего не скажу об авторе (GoSecure) похожей программы – Secure Disk.
Использую плюс пак на нескольких машинах давно и весьма доволен. Немного подожду развития вашей программы и начну её "щупать на вкус" – есть желание перейти на опенсорс.
Не могу оставить без внимания заявления, что файлы дампов и файл "засыпания" не шифруются другими диск-крипто-програмами. Не верю (применительно к драйв крипт плюс паку). Все мои машины сбрасываются "в сон" и, при следующем запуске, требуют ввода пароля и лишь потом идёт восстановление из файла гибернации. Я не посчитал нужным обсуждать этот вопрос у вас на форуме (и форум, и сайт глазу приятно) – лучше уж тут, на нейтральной территории. Квалификация у меня не ахти, но... не верю.
Исходники PGP открыты (хоть и не свободны), исходники DCPP закрыты. К кому из них может быть больше доверия?
Эта прога вобще ахтунг. Авторы показали себя некомпетентными в криптографии в высказываниях на некоторых форумах.
Последняя версия DCPP (v3.01) которую я смотрел неумела это делать. PGP WDE последних версий вроде умеет.
Спасибо за информацию.