Комментарии 20
Мне кажется, что чем больше пользы от дельта-синхронизации, тем меньше пользы от применения крипто-контейнера (и наоборот). Ведь смысл применения криптографии не только в том, чтобы скрыть содержимое файлов, но также и само наличие файлов, а также производимые с ними действия. Иначе ваши данные будут уязвимы для криптоанализа.
Поддерживаю. Плюс возникает вопрос — если дельта-синхронизация работает с шифрованным файлом и передаёт всего 1 мегабайт, то какая часть контейнера на самом деле шифруется? Или контейнетр разбивает данные на равные(?) блоки и их шифрует отдельно?
Насколько я понимаю, тут используется режим XTS. Шифруется весь контейнер целиком (то есть, не пофайлово). Контейнер разбивается на блоки размером в 16 байт (= размер блока AES). При изменении этого блока меняется только он.
Судя по описанию контейнера в статье, используется блочный шифр AES, размер блока в котором равен 128 битам(16 байт).
Но судя по тому, что у них дельта синхронизация может отличать измененные данные, то используют они его не правильно.
По определению любое малейшее изменение должно менять все зашифрованные данные так, чтобы новые шифроданные были полиноминально не отличимы от старых. Там либо яндекс диск доказал на практике P=NP, либо все же aes там используется не безопасным образом. Для того чтобы блочный шифр был безопасным нужно хотя бы использовать безопасные режимы шифрования. Например с рандомным вектором инициализации (IV).
Но судя по тому, что у них дельта синхронизация может отличать измененные данные, то используют они его не правильно.
По определению любое малейшее изменение должно менять все зашифрованные данные так, чтобы новые шифроданные были полиноминально не отличимы от старых. Там либо яндекс диск доказал на практике P=NP, либо все же aes там используется не безопасным образом. Для того чтобы блочный шифр был безопасным нужно хотя бы использовать безопасные режимы шифрования. Например с рандомным вектором инициализации (IV).
Но судя по тому, что у них дельта синхронизация может отличать измененные данные, то используют они его не правильно.
С чего это не правильно? Вы что предлагаете каждый раз при изменении одного байта перешифровывать весь контейнер? TrueCrypt и аналоги используют режим шифрования заточенный и рекомендованный для блочных устройств хранения данных, а именно — XTS. Так как там своя специфика, одно дело шифровать строку или файл, другое дело блочное устройство с произвольным доступом в реальном времени.
Есть гораздо более удобный способ — использование encfs. Там не создаётся контейнер,
а каждый файл шифруется отдельно. То есть остаётся видна структура каталогов (вместе
с размерами файлов и временем создания), шифруются только имена и содержимое.
Зато есть большое преимущество — можно смонтировать одновременно на нескольких
устройствах, занимаемое место равно суммарному размеру файлов, передаются только
изменённые данные.
а каждый файл шифруется отдельно. То есть остаётся видна структура каталогов (вместе
с размерами файлов и временем создания), шифруются только имена и содержимое.
Зато есть большое преимущество — можно смонтировать одновременно на нескольких
устройствах, занимаемое место равно суммарному размеру файлов, передаются только
изменённые данные.
Ну-ну… А для самой популярной ОС в мире encfs существует?
encfs может работать везде, где есть fuse. В не самой популярной ОС есть по
умолчанию, а чтобы запустить самой популярной — понадобится бубен:
https://github.com/dokan-dev/dokany/blob/master/README.md
Есть даже готовые сборки, правда с несколько устаревшими версиями:
http://members.ferrara.linux.it/freddy77/encfs.html
умолчанию, а чтобы запустить самой популярной — понадобится бубен:
https://github.com/dokan-dev/dokany/blob/master/README.md
Есть даже готовые сборки, правда с несколько устаревшими версиями:
http://members.ferrara.linux.it/freddy77/encfs.html
http://members.ferrara.linux.it/freddy77/encfs.html
http://encfsmp.sourceforge.net/
http://www.getsafe.org/about
Это только бесплатные с открытым кодом
http://encfsmp.sourceforge.net/
http://www.getsafe.org/about
Это только бесплатные с открытым кодом
Насколько я знаю, идеальное шифрование должно быть как хеш функция — малейшее изменение оригинальных данных сильнейшим образом меняет все байты зашифрованных данных.
Шифрование — это инструмент. В некоторых ситуациях дельта-кодирование вполне оправдано.
Ага, добавил запятую в тестовом файле, и пошел пить чай пока контейнер в пару терабайт перекодируется. Вы же не сравнивайте рекомендации по шифрованию для небольших текстовых файлов или строк, и требования к шифрованию блочных устройств. Грубо говоря представьте, что контейнер это просто куча файлов одинаковой длины (равной длине блока устройства или файловой системы). Так что если у вас изменятся данные в одном блоке, то это как будто изменились данные в одном этом файле.
P.S. На самом деле данных в контейнере меняется меньше чем мегабайт, просто это уже такой размер блока задан в программке считающей дельты. Просто чем больше блок тем меньше данных нужно для хранения хэшей блоков, тут нужно искать оптимальное соотношение (возможно оно также зависит от размера или типа файла).
P.S. На самом деле данных в контейнере меняется меньше чем мегабайт, просто это уже такой размер блока задан в программке считающей дельты. Просто чем больше блок тем меньше данных нужно для хранения хэшей блоков, тут нужно искать оптимальное соотношение (возможно оно также зависит от размера или типа файла).
Это у вас не совсем дельта-кодирование получается. Если хотя бы один байт в начало файла, то перезапишется файл целиком и дельта-кодирование работать не будет.
Совсем не обязательно, это зависит от кривизны рук писавших поиск повторяющихся блоков, и насколько они хотели заморочиться, есть тот же Кольцевой хеш, и более простые варианты типа поиска по началу/концу блока.
Но с криптоконтейнерами даже проще, так как там всё пишется блоками, и по сути без разницы в начало или конец файла вы добавите символ. Так как всё равно в таком случае изменится один блок файловой системы и он полностью зашифруется по-новому заменит соответствующий блок в криптоконтейнере. А основной гемор появляется тогда когда блоки могут менять размеры.
Но с криптоконтейнерами даже проще, так как там всё пишется блоками, и по сути без разницы в начало или конец файла вы добавите символ. Так как всё равно в таком случае изменится один блок файловой системы и он полностью зашифруется по-новому заменит соответствующий блок в криптоконтейнере. А основной гемор появляется тогда когда блоки могут менять размеры.
Кольцевой хеш тут использовать не получится по ряду причин. Основная причина — вычислять кольцевой хеш нужно до шифрования, потому что после шифрования в режиме XTS при добавлении байта в начало блоки сдвинутся, шифротекст блоков поменяется и кольцевой хеш не совпадёт.
С криптоконтейнерами, кстати, наоборот сложнее, так как при добавлении символа в начало файла внутри контейнера перезапишутся все блоки изменяемого файла, так как для добавления байта в начало файла, файл нужно перезаписать полностью (по определению).
Вообще, задача с дельта-кодированием, шифрованием и добавлением байта в начало файла — очень интересная. Мне приходилось решать её недавно, скорее всего, скоро напишу статью на хабре.
С криптоконтейнерами, кстати, наоборот сложнее, так как при добавлении символа в начало файла внутри контейнера перезапишутся все блоки изменяемого файла, так как для добавления байта в начало файла, файл нужно перезаписать полностью (по определению).
Вообще, задача с дельта-кодированием, шифрованием и добавлением байта в начало файла — очень интересная. Мне приходилось решать её недавно, скорее всего, скоро напишу статью на хабре.
Ничего не сдвинется, размеры блоков в криптоконтейнерах одинаковые, так же как и в файловой системе, вы просто не сможете добавить байт в начало файла, ну разве что в тупую открыть криптоконтейнер в каком-нибудь hex-редакторе и вручную добавить, но вряд ли он после этого сохранит работоспособность. Тут основная особенность жесткая привязка к размеру блока, и то что блоки в файловой системе без лишней необходимости не "тасуются" и могут быть не последовательными. А если попытаться добавить новый блок, то драйвер записывает его туда где свободное место, а не в начало контейнера сдвигая все остальные блоки.
Потому кольцевой хэш и будет нормально работать, собственно почему будет, он работает, тот же rsync работает с truecrypt контейнерами.
Просто, чтобы быть максимально быстрыми криптоконтейнеры не должны шифровать больше, чем количество измененных блоков, иначе никакой прозрачной работы не получится, а следовательно раз меняется только блок данных (всегда одинаковой длины, так как зависит от начального форматирования), то и найти это не такая уж и проблема.
А вы рассуждаете о шифровании на уровне файлов. Вот можете почитать особенности шифрования дисков.
Потому кольцевой хэш и будет нормально работать, собственно почему будет, он работает, тот же rsync работает с truecrypt контейнерами.
Просто, чтобы быть максимально быстрыми криптоконтейнеры не должны шифровать больше, чем количество измененных блоков, иначе никакой прозрачной работы не получится, а следовательно раз меняется только блок данных (всегда одинаковой длины, так как зависит от начального форматирования), то и найти это не такая уж и проблема.
А вы рассуждаете о шифровании на уровне файлов. Вот можете почитать особенности шифрования дисков.
Я не знаю способа добавить байт в начало файла без перезаписывания всего файла. В любой файловой системе добавление байта в начало файла будет перезаписывать файл целиком.
Попробуйте записать в контейнер файл размером в 2Гб, передать на другой узел, приписать 1 байт в начало 2Гб-файла и запустить rsync. Будете приятно удивлены тем, что rsync исправно передаст около 2Гб. Всё из-за того, что все блоки файла будут перезаписаны, у данных изменится смещение (а смещение является параметром шифрования в режиме XTS). Шифротекст блоков изменится. Кольцевой хеш (weak-хеш, в терминологии rsync) тоже полностью изменится. Все блоки изменённого файла будут переданы заново. Из-за одного байта, да.
Блоки контейнера, на которых лежат другие файлы переданы не будут (данные не изменятся, их смещение не изменится, а значит, шифротекст тоже не изменится)
тот же rsync работает с truecrypt контейнерами.
Попробуйте записать в контейнер файл размером в 2Гб, передать на другой узел, приписать 1 байт в начало 2Гб-файла и запустить rsync. Будете приятно удивлены тем, что rsync исправно передаст около 2Гб. Всё из-за того, что все блоки файла будут перезаписаны, у данных изменится смещение (а смещение является параметром шифрования в режиме XTS). Шифротекст блоков изменится. Кольцевой хеш (weak-хеш, в терминологии rsync) тоже полностью изменится. Все блоки изменённого файла будут переданы заново. Из-за одного байта, да.
Блоки контейнера, на которых лежат другие файлы переданы не будут (данные не изменятся, их смещение не изменится, а значит, шифротекст тоже не изменится)
В общем понял вы рассуждаете о дельте на уровне исходных данных, а я говорю о дельте на уровне криптоконтейнера.
Просто неоднозначная фраза
На уровне контейнера будет, о чем я и говорил, хотя конечно не покажет, что изменился конкретный байт, но как бы для криптоконтейнера этого и не нужно.
Просто неоднозначная фраза
Если хотя бы один байт в начало файла, то перезапишется файл целиком и дельта-кодирование работать не будет.
На уровне контейнера будет, о чем я и говорил, хотя конечно не покажет, что изменился конкретный байт, но как бы для криптоконтейнера этого и не нужно.
Т.е. в статье мы увидели, что небольшое изменение содержимое крипто-контейнера вызвало передачу небольшого объем данных и быструю синхронизацию. Мы говорим здесь о встроенной в облачные клиенту дельта-синхронизации, не о чем-то специальном: клиенты не знают, что это за большой такой файл на 500 Мб, и передают только изменения в нем.
Честно говоря, я бы больше хотел бы видеть возможность монтировать контейнера из облака (с промежуточным хранением на машине, но тоже в зашифрованном виде). Иначе странно: пока я контейнер не размонтирую, синхронизатор не может его закинуть. Т.е. весь рабочий день синхронизация не может состояться, и, если за это время к нам приходят маски-шоу (ой, о чем я, просто любопытные друзья), то свежие изменения в облаке не отражаются.
Так что, да, encfs, или что-то подобное бы…
Честно говоря, я бы больше хотел бы видеть возможность монтировать контейнера из облака (с промежуточным хранением на машине, но тоже в зашифрованном виде). Иначе странно: пока я контейнер не размонтирую, синхронизатор не может его закинуть. Т.е. весь рабочий день синхронизация не может состояться, и, если за это время к нам приходят маски-шоу (ой, о чем я, просто любопытные друзья), то свежие изменения в облаке не отражаются.
Так что, да, encfs, или что-то подобное бы…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дельта-синхронизация крипто-дисков