В статье "Encrypting /home and swap over RAID with dm-crypt (http://www.shimari.com/dm-crypt-on-raid/)" показано как под Fedora Core 5 использовать модуль для шифрования дисковых разделов dm-crypt совместно с программным RAID.URL: http://www.shimari.com/dm-crypt-on-raid/
Новость: http://www.opennet.me/opennews/art.shtml?num=7582
1. Это тормоз для системы.
2. Толку криптовать, если доступ к информации осуществляется как к обычной FS.
3. Криптовать, тем что валяется в Интернете, от спецслужб бесполезно.
4. Поможет только при Вашем раздолбайстве, когда любая секретарша
сможет зайти и вынуть из массива диск.
5. Криптовать бэкапы при транспортировки.
Да неужели? А где аргументы? Взять тоже ванильное ядро: предположим, что я зашифровал том с использованием AES или serpent 256 бит CBC и покажите нам пожалуйста, как можно(хотя бы теоритически) поиметь информацию за приемлемое время. Всякие сливы, типа терморектального анализа можете сразу оставить пионерам.
Газифицируйте лужи в другом месте. Ничего личного ;)
> Криптовать, тем что валяется в Интернете,
> от спецслужб бесполезно???Криптовать полезно ТОЛЬКО тем, что валяется в Интернете.
А вот криптовать "сертифицированным ФАПСИ" тулзом это реально опасно.
Помимо того, что абсолютно бесполезно.Не наводите тень на плетень.
Извеняюсь, добавлю... под "валяется в интернете" я имел ввиду не утилиты,
или криптопрограммы или криптокомплексы, а просто сами алгоритмы.Из свободных алогоритмов хорошо стойкие это Blowfish, но только с хорошим
генератором, желательно аппаратным, псевдо-сл. чисел. То что есть в линухе, увы...А про то, что Вы говорили относительно ФАПСИ (царство им небесное), так для
этого обмен информацией только с использованием лецензированных ими продуктов типа "ШИП",
"Верба", продукты фирмы "Криптоком", скажем в межбанковских операциях и с ЦентроБанком,
и придумывался.
Ничего личного, но это гос. тайна, и меня могут в места не столь отдалённые.
Оффтопик можно?Вот увидал последний ChangeLog c kernel.org
--- a/arch/i386/power/cpu.c
+++ b/arch/i386/power/cpu.c
@@ -92,7 +92,7 @@ void __restore_processor_state(struct sa
write_cr4(ctxt->cr4);
write_cr3(ctxt->cr3);
write_cr2(ctxt->cr2);
- write_cr2(ctxt->cr0);
+ write_cr0(ctxt->cr0);
/*
* now restore the descriptor tables to their proper valuesЯ ваще удевляюсь как оно раньше работало.
Ладно ещё ошибка в типах signed/unsigned, long double вместо long long double...,
но функция которая должна писать в регистр CR2 пишет в регистр CR0.
Это примерно тоже самое что, на м.Тверская сесть не до Речного Вокзала,
а до Сходненской, в принципе рядом, можно и на маршрутке доехать.
arch/i386/power/cpu.c
/* X0R был здесь
*/
eax=0;
> Из свободных алогоритмов хорошо стойкие это Blowfish, но только с хорошим генератором, желательно аппаратным, псевдо-сл. чисел.Развелось доморощенных криптоаналитиков, блин!
Каждый неуч мнит себя Шнайером.Во-первых: AES, Twofish, RC6 - ничуть не менее стойкие, чем Blowfish.
Во-вторых: данные алгоритмы не используют случайные числа и, соответственно, их неализация никоим образом не зависит от качестве генератора.
В-третьих: про гостайну а фапси будешь перед девченками понтоваться - если нечего сказать по-существу, то лучше молчи.
В четвертых: сами всё раскажите :)
> данные алгоритмы не используют случайные числаАга, и в образующей функии в сети Фейштеля, будем использовать линейную y=k*x+b ;)
ФАПСИ не занимается криптографической защитой и соответственно и сертификацией. Стыдно товарищи!
Протоколы-то не скрываются, а вот в их реализациях частенько находят ошибки. Обидно... Читайте Шнайера, читайте Фергюсона и не пишите фигню о том, что не знаете.
В основе аппаратных генераторов псевдо-случайных чисел лежат программные алгоритмы!