https://opennet.ru/openforum/vsluhforumID3/40468.html Доступны (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%).<br><br>URL: http://blog.unixstyle.ru/index.php?/archives/23-cryptoloop-losetup,-dm-crypt-cryptsetup,-dm-crypt-LUKS-cryptsetup;-AES-vs-blowfish.html<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=14529<br> https://opennet.ru/openforum/vsluhforumID3/40468.html#10 Wed, 02 Jul 2008 23:09:14 GMT Говорят truecrypt медленнее lunks (http://movingparts.net/2007/10/26/truecrypt-versus-luks-speed-test/).<br><br>А насчёт шифров, скажу что в AES не верю. Факты говорят что, АНБ знало алгоритм взлома (дифференциальный криптоанализ) DES ещё когда помогала его разроботке в IBM. Да ещё у них по законадательству запрещено экспортировать криптостойкие шифры. Такая же ситуация наверняка и с AES. Его же для промышлнного/комерческого использования рекомендуют с подозрительно огромной настойчивостью. А главный пиар лозунг, что если вруг его кто-то взломает, то админ не виноват не будет, это ж государство его одобрило :-)<br><br>А "проектировщики Serpen шифра считали, что 16 раундов достаточно, чтобы противостоять известным видам криптоанализа, но увеличили число раундов до 32, чтобы алгоритм мог лучше противостоять ещё не известным методам криптоанализа" видно фишку секут и историю в школе хороше изучали :-)<br><br>SHA256 тож в топку, пока китайцы снова нас не обрадывали новыми математическими изысканиями, как с было SHA1. Лучше https://opennet.ru/openforum/vsluhforumID3/40468.html#9 Tue, 04 Mar 2008 09:33:13 GMT &gt;Во-вторых, блоуфиш признан потенциально небезопасным... <br><br>ССылку в студию?<br><br> https://opennet.ru/openforum/vsluhforumID3/40468.html#8 Tue, 04 Mar 2008 06:44:35 GMT &gt;порадовала фраза про отсутствие сравнительных тестов AES vs Blowfish <br>&gt;Во-первых, поставьте Трукрипт, там встроен бенчмарк по всем алгоритмам, причем с возможностью <br><br>Сапоги не почистить? man openssl<br><br>&gt;Во-вторых, блоуфиш признан потенциально небезопасным... <br><br>Улыбнуло. <br> https://opennet.ru/openforum/vsluhforumID3/40468.html#7 Tue, 04 Mar 2008 06:40:56 GMT &gt;&gt;Доступны (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 систем шифрования <br>&gt;&gt;блочных устройств: cryptoloop, dm-crypt и dm-crypt с расширением LUKS. В итоге, <br>&gt;&gt;dm-crypt с расширением LUKS продемонстрировала хорошие показатели, максимально приблизившись к <br>&gt;&gt;показателям разделов без шифрования, для случая записи, и отстала от последних, <br>&gt;&gt;для случая чтения, всего лишь на четверть (25%). <br>&gt;<br>&gt;Результат годится только для одного случая - "мы решили залить на шифрованный <br>&gt;диск толстый [rt]ar-архив с помощью dd". То есть, "шоб никто не <br>&gt;догадался, чё мы туда записали". <br><br>Достаточно недальновидное заключение. Действительно, в зарисовке не представлены результаты bonnie++, относящиеся к созданию мелких файлов. Однако результаты не сильно разнятся с представленными на диаграммах. Общую тенденцию можно проследить.<br><br> https://opennet.ru/openforum/vsluhforumID3/40468.html#6 Tue, 04 Mar 2008 06:37:17 GMT &gt;автору следует узнать что есть разные режимы шифрования. интересным тут было бы <br>&gt;увидеть сравнение xts-lrw-cbc. и подумать на тему что ключи тоже бывают <br>&gt;разной длины <br><br>оратору предстоит провести исследование самостоятельно. Если нет возможности сделать это самостоятельно можно подумать о проведении эксперимента за умеренную плату.<br> https://opennet.ru/openforum/vsluhforumID3/40468.html#5 Tue, 04 Mar 2008 01:47:48 GMT Все это конечно круто, а как бы реализовать такую вичу как в zfs - сжатие ? .. фузя уж больно камушек грузить.<br> https://opennet.ru/openforum/vsluhforumID3/40468.html#4 Mon, 03 Mar 2008 20:57:31 GMT порадовала фраза про отсутствие сравнительных тестов AES vs Blowfish<br>Во-первых, поставьте Трукрипт, там встроен бенчмарк по всем алгоритмам, причем с возможностью выбора размера тестового куска. Правда, шифрование производится в памяти, но производительность позволяет оценить.<br>Во-вторых, блоуфиш признан потенциально небезопасным...<br> https://opennet.ru/openforum/vsluhforumID3/40468.html#3 Mon, 03 Mar 2008 19:40:12 GMT &gt;Доступны (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 систем шифрования <br>&gt;блочных устройств: cryptoloop, dm-crypt и dm-crypt с расширением LUKS. В итоге, <br>&gt;dm-crypt с расширением LUKS продемонстрировала хорошие показатели, максимально приблизившись к <br>&gt;показателям разделов без шифрования, для случая записи, и отстала от последних, <br>&gt;для случая чтения, всего лишь на четверть (25%). <br><br>Результат годится только для одного случая - "мы решили залить на шифрованный диск толстый [rt]ar-архив с помощью dd". То есть, "шоб никто не догадался, чё мы туда записали".<br><br>Вообще-то большинство операций ввода-вывода - это 512-16384 байт. В итоге, если шифрование происходит бОльшими блоками - для операции надо считать целый блок, его расшифровать, достать из него кусочек и выбросить (или закешировать) остальное.<br><br>А с записью - ещё интересней. Не веселее, ч https://opennet.ru/openforum/vsluhforumID3/40468.html#2 Mon, 03 Mar 2008 19:34:26 GMT Да зачем ему это? И так сойдет ...<br>