| 1.1, aa (?), 21:10, 03/03/2008 [ответить]
| +/– |
автору следует узнать что есть разные режимы шифрования. интересным тут было бы увидеть сравнение xts-lrw-cbc. и подумать на тему что ключи тоже бывают разной длины
| | |
| |
| 2.6, chip (ok), 09:37, 04/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
 >автору следует узнать что есть разные режимы шифрования. интересным тут было бы
>увидеть сравнение xts-lrw-cbc. и подумать на тему что ключи тоже бывают
>разной длины
оратору предстоит провести исследование самостоятельно. Если нет возможности сделать это самостоятельно можно подумать о проведении эксперимента за умеренную плату.
| | |
|
| 1.3, unisol (?), 22:40, 03/03/2008 [ответить]
| +/– |
>Доступны (http://blog.unixstyle.ru/index.php?/archives/23-cryptoloop-losetup,-dm-crypt-cryptsetup,-dm-crypt-LUKS-cryptsetup;-AES-vs-blowfish.html) результаты оценки производительности представленных в Linux ядре 2.6.x систем шифрования
>блочных устройств: cryptoloop, dm-crypt и dm-crypt с расширением LUKS. В итоге,
>dm-crypt с расширением LUKS продемонстрировала хорошие показатели, максимально приблизившись к
>показателям разделов без шифрования, для случая записи, и отстала от последних,
>для случая чтения, всего лишь на четверть (25%).
Результат годится только для одного случая - "мы решили залить на шифрованный диск толстый [rt]ar-архив с помощью dd". То есть, "шоб никто не догадался, чё мы туда записали".
Вообще-то большинство операций ввода-вывода - это 512-16384 байт. В итоге, если шифрование происходит бОльшими блоками - для операции надо считать целый блок, его расшифровать, достать из него кусочек и выбросить (или закешировать) остальное.
А с записью - ещё интересней. Не веселее, чем в raid5.
| | |
| |
| 2.7, chip (ok), 09:40, 04/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>>Доступны (http://blog.unixstyle.ru/index.php?/archives/23-cryptoloop-losetup,-dm-crypt-cryptsetup,-dm-crypt-LUKS-cryptsetup;-AES-vs-blowfish.html) результаты оценки производительности представленных в Linux ядре 2.6.x систем шифрования
>>блочных устройств: cryptoloop, dm-crypt и dm-crypt с расширением LUKS. В итоге,
>>dm-crypt с расширением LUKS продемонстрировала хорошие показатели, максимально приблизившись к
>>показателям разделов без шифрования, для случая записи, и отстала от последних,
>>для случая чтения, всего лишь на четверть (25%).
>
>Результат годится только для одного случая - "мы решили залить на шифрованный
>диск толстый [rt]ar-архив с помощью dd". То есть, "шоб никто не
>догадался, чё мы туда записали".
Достаточно недальновидное заключение. Действительно, в зарисовке не представлены результаты bonnie++, относящиеся к созданию мелких файлов. Однако результаты не сильно разнятся с представленными на диаграммах. Общую тенденцию можно проследить.
| | |
|
| 1.4, FK (?), 23:57, 03/03/2008 [ответить]
| +/– |
порадовала фраза про отсутствие сравнительных тестов AES vs Blowfish
Во-первых, поставьте Трукрипт, там встроен бенчмарк по всем алгоритмам, причем с возможностью выбора размера тестового куска. Правда, шифрование производится в памяти, но производительность позволяет оценить.
Во-вторых, блоуфиш признан потенциально небезопасным...
| | |
| |
| 2.8, chip (ok), 09:44, 04/03/2008 [^] [^^] [^^^] [ответить]
| +/– |
>порадовала фраза про отсутствие сравнительных тестов AES vs Blowfish
>Во-первых, поставьте Трукрипт, там встроен бенчмарк по всем алгоритмам, причем с возможностью
Сапоги не почистить? man openssl
>Во-вторых, блоуфиш признан потенциально небезопасным...
Улыбнуло.
| | |
|
| 1.5, exn (??), 04:47, 04/03/2008 [ответить]
| +/– |
Все это конечно круто, а как бы реализовать такую вичу как в zfs - сжатие ? .. фузя уж больно камушек грузить.
| | |
| 1.10, cobain (??), 03:09, 03/07/2008 [ответить]
| +/– | |
Говорят truecrypt медленнее lunks (http://movingparts.net/2007/10/26/truecrypt-versus-luks-speed-test/).
А насчёт шифров, скажу что в AES не верю. Факты говорят что, АНБ знало алгоритм взлома (дифференциальный криптоанализ) DES ещё когда помогала его разроботке в IBM. Да ещё у них по законадательству запрещено экспортировать криптостойкие шифры. Такая же ситуация наверняка и с AES. Его же для промышлнного/комерческого использования рекомендуют с подозрительно огромной настойчивостью. А главный пиар лозунг, что если вруг его кто-то взломает, то админ не виноват не будет, это ж государство его одобрило :-)
А "проектировщики Serpen шифра считали, что 16 раундов достаточно, чтобы противостоять известным видам криптоанализа, но увеличили число раундов до 32, чтобы алгоритм мог лучше противостоять ещё не известным методам криптоанализа" видно фишку секут и историю в школе хороше изучали :-)
SHA256 тож в топку, пока китайцы снова нас не обрадывали новыми математическими изысканиями, как с было SHA1. Лучше из хеш фукций использовать что-то вроде RIPEMD-160.
| | |
|
