Comments 16
Для оживляжа нужны диаграммы и графики вместо таблиц.
И ещё один вариант: заливаем 2 gb файл из пробелов, а потом читаем напрямую с диска, без шифрования. Получится набор байтов, из которого делаем красивую картинку. Чтоб видно было: система работает, все пробелы зашифрованы, враг не догадается.
И ещё один вариант: заливаем 2 gb файл из пробелов, а потом читаем напрямую с диска, без шифрования. Получится набор байтов, из которого делаем красивую картинку. Чтоб видно было: система работает, все пробелы зашифрованы, враг не догадается.
UFO just landed and posted this here
ну я особых проблем с покушением на содержимое не вижу. одни и теже алгоритмы шифрования, разные только методы их использования. Инфо по уязвимостям алгоритмов есть в сети.
А как насчет ошибок? Возможно есть простой способ подобрать пароль из за ошибки программиста?
Поддерживаю двумя руками.
Как раз неделю назад на Васме приводился кусок кода, где (скорее всего по незнанию) программист реализовал ГОСТ 28147 так, что инициализировал синхропосылку XOR-енными между собой байтами ключа шифрования
(и естественно передавал это в открытом виде в начале сеанса).
Какой способ, кроме независимого и тщательного просмотра исходного кода, даст гарантию отсутствия таких же ляпов в приведенных выше продуктах?
Как раз неделю назад на Васме приводился кусок кода, где (скорее всего по незнанию) программист реализовал ГОСТ 28147 так, что инициализировал синхропосылку XOR-енными между собой байтами ключа шифрования
(и естественно передавал это в открытом виде в начале сеанса).
Какой способ, кроме независимого и тщательного просмотра исходного кода, даст гарантию отсутствия таких же ляпов в приведенных выше продуктах?
Я сказал бы более категорично:
если шифросистема А работает в 2 раза быстрее, чем система B,
но при этом вероятность наличия ошибок в ней хотя бы на 1% выше, то
я всё равно выберу систему B
если шифросистема А работает в 2 раза быстрее, чем система B,
но при этом вероятность наличия ошибок в ней хотя бы на 1% выше, то
я всё равно выберу систему B
> dd if=/dev/random
не лучший вариант для оценки скорости именно _шифрования_ — генерация рандома сама по себе довольно затратная операция.
На расположение контейнеров по скорости это конечно не влияет, а вот на величины вроде «Как видно из тестов скорость записи упала почти в 2 раза» — очень даже.
Впрочем, возможно вы это сделали умышленно и мой каммент не в тему, но для меня «скорость записи» это скорость самой записи, без учёта скорости генерации данных.
не лучший вариант для оценки скорости именно _шифрования_ — генерация рандома сама по себе довольно затратная операция.
На расположение контейнеров по скорости это конечно не влияет, а вот на величины вроде «Как видно из тестов скорость записи упала почти в 2 раза» — очень даже.
Впрочем, возможно вы это сделали умышленно и мой каммент не в тему, но для меня «скорость записи» это скорость самой записи, без учёта скорости генерации данных.
на самом деле момент спорный. использование /dev/zero для создания шифрованного контейнера по моему неверно. ибо шифрование происходит поблочно и отделение шифрованного блока от нешифрованного на носителе не составит особого труда. С точки зрения реального использования /dev/random и /dev/zero, то я сильно сомневаюсь, что у вас на файловой системе будут файлы с нулевым содержимым. /dev/random использовался на одной и той же машине, на одних и тех же ресурсах, поэтому использованием /dev/random или /dev/zero я думаю можно пренебречь. Если бы использовались и zero и random, то понятное дело о результатах можно было бы поспорить.
Если есть сомнения, то могу сделать тесты на /dev/zero и выложить. особой разницы вы не увидите.
Если есть сомнения, то могу сделать тесты на /dev/zero и выложить. особой разницы вы не увидите.
Конечно на результат сравнения это никак не повлияет. Быстрые останутся быстрыми, а медленные медленными. Но всё же когда написано «Как видно из тестов скорость записи упала почти в 2 раза» без учёта генерации /dev/random падение окажется намного больше чем в 2 раза. Просто думаю важнее именно падение относительно максимальной скорости харда. А судя по
151.82 real .00 user 132.96 sys
в оценке скорости линейной записи на нешифрованный носитель она (скорость) упёрлась именно в процессор, а никак не в хард
> Если есть сомнения, то могу сделать тесты на /dev/zero и выложить. особой разницы вы не увидите.
Да нет что вы, сомнений в относительных результатах нет никаких. Тем более что дальше идут тесты bonnie
151.82 real .00 user 132.96 sys
в оценке скорости линейной записи на нешифрованный носитель она (скорость) упёрлась именно в процессор, а никак не в хард
> Если есть сомнения, то могу сделать тесты на /dev/zero и выложить. особой разницы вы не увидите.
Да нет что вы, сомнений в относительных результатах нет никаких. Тем более что дальше идут тесты bonnie
ну вот сейчас ради эксперимента сделал следующее.
проверил /dev/zero и /dev/random с включенно/выключенными softupdates.
zero+su_off = 36539247 bytes/sec
121.40 real 0.02 user 15.72 sys
zero+su_on = 36379845 bytes/sec
118.06 real 0.02 user 16.58 sys
random+su_off = 28802712 bytes/sec
149.11 real 0.02 user 133.52 sys
random+su_on = 26710585 bytes/sec
160.81 real 0.02 user 134.81 sys
при использовании /dev/random наблюдается нелинейная кривая которая таки в итоге упирается в 100% загрузку одного из камней. Тут Вы правы, признаю.
проверил /dev/zero и /dev/random с включенно/выключенными softupdates.
zero+su_off = 36539247 bytes/sec
121.40 real 0.02 user 15.72 sys
zero+su_on = 36379845 bytes/sec
118.06 real 0.02 user 16.58 sys
random+su_off = 28802712 bytes/sec
149.11 real 0.02 user 133.52 sys
random+su_on = 26710585 bytes/sec
160.81 real 0.02 user 134.81 sys
при использовании /dev/random наблюдается нелинейная кривая которая таки в итоге упирается в 100% загрузку одного из камней. Тут Вы правы, признаю.
Опечатка:
Правильно:
… партиция(da0s1a), слайс(da0s1)
Это может быть физический накопитель(da0), партиция(da0s1), слайс(da0s1a)
Правильно:
… партиция(da0s1a), слайс(da0s1)
Жаль в таблице нет скорости работы без шифрования. Я сейчас думаю стать криптоманьяком и включить шифрование /home в новой Ubuntu с помощью encfs :). Резонный вопрос, как это скажется на скорость.
Sign up to leave a comment.
Сравнительное тестирование криптоконтейнеров и шифрованных файловых систем