Вообще говоря, информации о шифровании там и не должно быть, она по идее должна лежать в ключе, но раз это просто файлик с последовательностью, то никак не убрать (либо алгоритм фиксирован, либо информация о нем хранится в открытом виде).
То, что разница в скорости незаметна, означает лишь то, что процессор успевает обрабатывать считываемый поток. Ради интереса можно сравнить максимальную скорость чтения и нагрузку на процессор на обычном диске и на зашифрованном. Думаю, что разница должна быть заметная. А если зашифрованный диск будет на шустром рейде, то разница в скоростях и нагрузке будет существенная.
P.S. Информацию я не шифрую, т.к. не вижу в этом никакого особого смысла.
Пусть сам алгоритм и не такой простой, как xor, но, обладая информацией о части зашифрованного содержимого, можно если не полностью восстановить ключ, то по крайней мере существенно сократить диапазон для перебора.
Я уже привёл пример того, как защититься от подбора ключа знанием части им зашифрованного.
Размер ключа тут не очень важен, его длина больше влияет на скорость работы с зашифрованным диском.
По-моему, как раз-таки очень важен.
Вот представьте, что Вам известен 1Кб идущих подряд данных в зашифрованном (путь xor'ом) хранилище. Так вот мы можем рас'xor'ить ключ размером до килобайта этими известными данными.
А если ключ 2 Мб, то нам надо найти известный кусок идущих подряд данных.
Единственное, что может действительно усложнить расшифровку — это сохранение информации о алгоритме шифрования вместе с ключом, а сам алгоритм, естественно, тоже должен быть какой-то случайной последовательностью случайной длины более простых (типовых) алгоритмов, причем ключи для стыковки между ними тоже должны быть случайными.
Это по сути шифрование зашифрованного по второму разу. А ключ здесь — это комбинация алгоритмов шифрования и их длин. Т.е. не длинный ключ. Однако, само по себе двойное шифрование — это хорошо. Да и ключи переменной длинны тоже.
Но быстро это работать точно не будет :)
Вот это, кстати, не факт. Я вот не заметил разницы в работе зашифрованного раздела и незашифрованного. Соответственно, если замечу разницу с зашифрованным два (три, пять) раза, то очень маленькую.
А вообще, если Вы знаете, как убрать из зашифрованного тома инфу об алгоритме шифрования и длине ключа, было бы очень интересно.
Конечно не тупой xor :) Там в статье по ссылке написано:
Ciper name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Т.е. при попытке расшифровки алгоритм либо полностью известен, либо выбирается из очень ограниченного списка типовых. Пусть сам алгоритм и не такой простой, как xor, но, обладая информацией о части зашифрованного содержимого, можно если не полностью восстановить ключ, то по крайней мере существенно сократить диапазон для перебора. Размер ключа тут не очень важен, его длина больше влияет на скорость работы с зашифрованным диском.
Единственное, что может действительно усложнить расшифровку — это сохранение информации о алгоритме шифрования вместе с ключом, а сам алгоритм, естественно, тоже должен быть какой-то случайной последовательностью случайной длины более простых (типовых) алгоритмов, причем ключи для стыковки между ними тоже должны быть случайными. Но быстро это работать точно не будет :)
Программы класса «Hello world» существуют для того, чтобы продемонстрировать минимальный функционал языка, а не размер исходного бинарника. Когда речь заходит о серьезных приложениях, размер дистрибутива программы как-то отходит на последний план.
Ну, во-первых, я специально шифрую не всю систему от корня, а только /home, а там известно гораздо меньше.
А во-вторых, да, согласен. Вот если бы можно было использовать ключ длиной метра два, было бы гораздо сложнее использовать расшифровку по известным сигнатурам файлов, да и просто частотным анализом. Против этого наверняка существует защита. Например, если тупо заархивировать контент, то часто встречающиеся комбинации файлов будут включены в словарь архива, который будет зашифрован тоже.
А ещё может быть, что в используемом алгоритме шифрование не просто тупой xor, и м.б. там есть защита от таких методов декриптования.
Хочу прокомментировать не в критику поста, а на счет шифрования дисков вообще.
Смысл шифрования и его стойкости в том, что НЕИЗВЕСТНО что именно зашифровано, в этом случае поможет только брутфорс. В случае шифрования диска задача нахождения ключа (пусть и длиной 256 символов) очень сильно упрощается, т.к. содержимое огромного количества файлов в фаловой системе известно (сама операционка), плюс точно известны сайфер и хэш-функция.
Получается отпугивалка для детей, а не реальная защита данных.
Не могу с уверенностью сказать, насколько этот дистрибутив отвечает вашим критериям, но мне он нравится. Я говорю про Мандриву. Именно она, при первом моем знакомстве с linux-системами, встала так красиво, что не пришлось морочиться. И я ей доверяю что-ли…
Ну а если говорить про извращения, то забыли самое незабываемое — Gentoo :-)))
Пока сидел в окнах пользовался авастом в общем случае около 2.5 лет, проблем с продлеванием ключа на одно и тоже мыло небыло ниразу. Доктор, я умираю?)
Статистика по браузер-на-ОС, за последний месяц (у нас недавно был всплеск посещений, так что тоже интересно):
1. Firefox / Windows — 40%
2. Internet Explorer / Windows — 17%
3. Firefox / Linux — 12.5%
4. Opera / Windows — 8.7%
5. Chrome / Windows — 8.3%
6. Safari / MacOS — 2.7%
7. Chrome / Linux — 2.4%
8. Firefox / MacOS — 1.7%
9. Mozilla / Linux — 1.4%
10. Opera / Linux — 1.1%
Linux очень даже впечатляющие смотрится, 17% всех посещений, обгоняя даже распространенный в штатах МакОС. И опять-таки замечу, что фаерфокс просто прёт, ИЕ вынесен с первого места во всех номинациях.
То, что разница в скорости незаметна, означает лишь то, что процессор успевает обрабатывать считываемый поток. Ради интереса можно сравнить максимальную скорость чтения и нагрузку на процессор на обычном диске и на зашифрованном. Думаю, что разница должна быть заметная. А если зашифрованный диск будет на шустром рейде, то разница в скоростях и нагрузке будет существенная.
P.S. Информацию я не шифрую, т.к. не вижу в этом никакого особого смысла.
Я уже привёл пример того, как защититься от подбора ключа знанием части им зашифрованного.
По-моему, как раз-таки очень важен.
Вот представьте, что Вам известен 1Кб идущих подряд данных в зашифрованном (путь xor'ом) хранилище. Так вот мы можем рас'xor'ить ключ размером до килобайта этими известными данными.
А если ключ 2 Мб, то нам надо найти известный кусок идущих подряд данных.
Это по сути шифрование зашифрованного по второму разу. А ключ здесь — это комбинация алгоритмов шифрования и их длин. Т.е. не длинный ключ. Однако, само по себе двойное шифрование — это хорошо. Да и ключи переменной длинны тоже.
Вот это, кстати, не факт. Я вот не заметил разницы в работе зашифрованного раздела и незашифрованного. Соответственно, если замечу разницу с зашифрованным два (три, пять) раза, то очень маленькую.
А вообще, если Вы знаете, как убрать из зашифрованного тома инфу об алгоритме шифрования и длине ключа, было бы очень интересно.
Вы, кстати, шифруете свою информацию?
Ciper name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Т.е. при попытке расшифровки алгоритм либо полностью известен, либо выбирается из очень ограниченного списка типовых. Пусть сам алгоритм и не такой простой, как xor, но, обладая информацией о части зашифрованного содержимого, можно если не полностью восстановить ключ, то по крайней мере существенно сократить диапазон для перебора. Размер ключа тут не очень важен, его длина больше влияет на скорость работы с зашифрованным диском.
Единственное, что может действительно усложнить расшифровку — это сохранение информации о алгоритме шифрования вместе с ключом, а сам алгоритм, естественно, тоже должен быть какой-то случайной последовательностью случайной длины более простых (типовых) алгоритмов, причем ключи для стыковки между ними тоже должны быть случайными. Но быстро это работать точно не будет :)
А во-вторых, да, согласен. Вот если бы можно было использовать ключ длиной метра два, было бы гораздо сложнее использовать расшифровку по известным сигнатурам файлов, да и просто частотным анализом. Против этого наверняка существует защита. Например, если тупо заархивировать контент, то часто встречающиеся комбинации файлов будут включены в словарь архива, который будет зашифрован тоже.
А ещё может быть, что в используемом алгоритме шифрование не просто тупой xor, и м.б. там есть защита от таких методов декриптования.
Я, правда, не эксперт в криптографии, если что =)
Смысл шифрования и его стойкости в том, что НЕИЗВЕСТНО что именно зашифровано, в этом случае поможет только брутфорс. В случае шифрования диска задача нахождения ключа (пусть и длиной 256 символов) очень сильно упрощается, т.к. содержимое огромного количества файлов в фаловой системе известно (сама операционка), плюс точно известны сайфер и хэш-функция.
Получается отпугивалка для детей, а не реальная защита данных.
тогда hackable1 вообще не тормозит:)
Ну а если говорить про извращения, то забыли самое незабываемое — Gentoo :-)))
1. Firefox / Windows — 40%
2. Internet Explorer / Windows — 17%
3. Firefox / Linux — 12.5%
4. Opera / Windows — 8.7%
5. Chrome / Windows — 8.3%
6. Safari / MacOS — 2.7%
7. Chrome / Linux — 2.4%
8. Firefox / MacOS — 1.7%
9. Mozilla / Linux — 1.4%
10. Opera / Linux — 1.1%
Linux очень даже впечатляющие смотрится, 17% всех посещений, обгоняя даже распространенный в штатах МакОС. И опять-таки замечу, что фаерфокс просто прёт, ИЕ вынесен с первого места во всех номинациях.