Какая прога быстро зашифрует раздел?

"Надёжно" и "быстро" не бывает, выбирайте одно из двух. Если шифрование не вызывает снижения производительности, то либо 1) используется сверхбыстрый, но малонадёжный алгоритм (скажем, RC4 или вообще доморощенная поделка), либо 2) шифруется только таблица размещения файлов (метаданные), но не данные, либо 3) никакого шифрования не используется, а Вам просто пудрят мозги.

Нужно просто спрятать проги от "внезапно нагрянувших, говорящих о лицензиях там каких то".

Если Вы будете шифровать только метаданные, а "проверяющие" решат изъять ПК, найдут там много интересного, даже не имея доступа к именам файлов. Вы знаете, что данные с диска можно прочитать в raw-режиме? Можете надеяться, что проверяющие этого не знают, только это какая-то страусиная позиция.

Ясно... Вы меня прям мордой об асфальт)))) спасибо!
Блиннн... ну, уж очень не хочеться терять половину всей производительности дисковой системы...

А какие проги поддерживают RC4?

Ясно... Вы меня прям мордой об асфальт)))) спасибо!

Пожалуйста. Горькая правда лучше, чем сладкая ложь. :-)

А какие проги поддерживают RC4?

Я таких не знаю. Просто в качестве примера назвал. В старых версиях TrueCrypt (до версии 4.3) были быстрые шифры с 64-битовым блоком, в частности, Blowfish. Использовать такие алгоритмы на больших объёмах данных не совсем безопасно, но для Вашего случая этого, пожалуй, хватит. Попробуйте.

А какие проги поддерживают RC4

Не будем грузить гостя теорией. Но, тем не менее, RC4 – поточный шифр, для шифрования секторов диска его пришлось бы перевести в режим блочного шифрования. Я бы не стал доверять таким нестандартным решениям.

Наверное, таких программ нет. А если есть, то лучше их не использовать.

SATtva

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

В OpenBSD используется исключительно 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-битового ядра ОС.

Что характерно, в ходе тестов суммарная нагрузка обоих ядер не превышает 53% (при этом балансировка на обоих ядрах довольно симметрична).

Он однопоточный. Это одно ядро работает на 100% (и еще система что-то делает). Зачем Винда гоняет задачу межу ядрами? В одной железячной конференции сказали "Чтобы им было не скучно." У меня нагрузка делится примерно 80%/20%

Может ли пропускная способность ОЗУ выступать ограничивающим фактором?

Судя по отсутстствию какой либо зависимости от размера буфера (от 5 Кб до 100 Мб) – вряд ли.

из-за ограничений на скорость чтения/записи самого накопителя

Из любопытства погонял ISO образ на 800 Мб. Межу партициями 50 Мб/с (один физ. RAID0), запись в криптоконтейнер 35 Мб/с (35% загрузка одного ядра), между криптоконтейнерами 32 Мб/с. В последнем случае оба ядра грузятся на 35%.

сколь велики отличия для 64-битового ядра ОС

Должно быть процентов на 10 медленнее. Ни один из этих шифров под 64 бита не оптимизирован, только большую адресную информацию процессору гонять.

Это одно ядро работает на 100% (и еще система что-то делает). Зачем Винда гоняет задачу межу ядрами?

Как правило, один поток одно ядро и занимает (то есть на 100%, тогда как другое – 0%, давая в итоге искомые 50%). Здесь же нагрузка около 45% на первом и 55% на втором, что нетипично.

SATtva:
При случае проверю в Linux, интересно, сколь велики отличия для 64-битового ядра ОС.

cooshoo:
Должно быть процентов на 10 медленнее. Ни один из этих шифров под 64 бита не оптимизирован, только большую адресную информацию процессору гонять.

Получилось вот что:

• 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), получаем следующую картину:

• Twofish – 34,78
• AES – 31,85
• Serpert – 26,33

При большом условии, что поправка на время записи сколь-нибудь точна, в сухом остатке имеем 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 в качестве криптопровайдера.