Дельта-синхронизация крипто-дисков

Существуют разные способы зашифровать «облако». Один из них — поместить в облако крипто-диск. В предыдущей статье мы писали, почему это не всегда удобно. В этой же статье мы рассмотрим тему крипто-диска в облаке с другой стороны.



Могут ли сосуществовать крипто-диск и облако?


Чтобы сэкономить вам один клик мышки, напомним, с чего начиналась предыдущая статья. В ней мы говорили, что самый простой способ — поместить файлы в криптоконтейнер, а файл самого контейнера поместить на Google Диск. Затем, чтобы работать с файлами на другом устройстве, нужно было загрузить контейнер, открыть его, просмотреть/изменить файлы и скопировать контейнер обратно в облако. Но при такой схеме возникает проблема перерасхода трафика. Что если размер крипто-диска составляет несколько гигабайтов, а вам нужно изменить файл, размером всего несколько килобайт? Да, все эти несколько гигабайтов будут загружены в облако повторно.
Все это верно только для облачных хранилищ, не поддерживающих дельта-синхронизацию, то есть для того же Google Диск. Однако некоторые другие облачные хранилища, такие как Яндекс.Диск и Dropbox поддерживают дельта-обновления, а это означает, что крипто-диск может спокойно «жить» в облаке.

Принцип дельта-синхронизации


Принцип дельта-синхронизации (дельта-обновлений) очень прост: в облако копируется не весь файл, а только то, что изменилось. Другими словами, пусть у вас есть большой файл размером, скажем 1 Гб. В нем вы изменили какую-то часть. Именно эта часть и будет отправлена в облако. Аналогично, эта же часть будет из облака загружена на все остальные устройства, использующие эту же учетную запись. В результате снижается, как время синхронизации, так и нагрузка на сеть.
Изначально дельта-синхронизацию поддерживал только Dropbox. Позже к нему присоединился и Яндекс.Диск. Насколько нам известно, пока дельта-обновления поддерживают только эти два хранилища. Облачный диск OneDrive поддерживает дельта-синхронизацию только для файлов MS Office.
Отсюда можно сделать выводы, что хранилища Яндекс.Диск и Dropbox можно использовать не только для хранения крипто-дисков, но и любых других больших файлов, над которыми вы работаете. Правда, есть и исключения. Если формат файла подразумевает упаковку, например, видео, музыка и подобные форматы, то дельта-синхронизация не работает и придется перезаписывать весь файл заново.
Об эффективности дельта-обновлений идут споры в сети, некоторые блоггеры утверждают, что от нее нет толку. Что ж, давайте посмотрим вместе.
Далее будет показано, как работает дельта-синхронизация на примере приложения CyberSafe Disk (его совершенно бесплатно можно скачать с сайта разработчика). Приведенный принцип вы можете использовать с любым другим крипто-диском, например, с контейнерами того же трукрипта.

Дельта-синхронизация в действии


Первым делом нужно установить Яндекс.Диск и указать свои учетные данные (рис. 1). Чтобы никакие другие файлы не мешали синхронизации, мы используем новый аккаунт, созданный специально для написания статьи (рис. 2).


Рис. 1. Вход в Яндекс.Диск


Рис. 2. Содержимое папки YandexDisk по умолчанию

Далее запускаем CyberSafe Disk (или трукрипт — на вкус и цвет все фломастеры разные), переходим в раздел Виртуальный сейф и нажимаем кнопку Создать. В качестве пути сохранения крипто-диска выбираем папку YandexDisk, указываем реальный размер — 500 Мб (по умолчанию — 100 Мб), вводим имя файла, пароль и нажимаем кнопку Принять. На момент создания крипто-диска лучше выключить синхронизацию Яндекс.Диск — чтобы не сбивать с толку приложение и получить реальное время синхронизации.


Рис. 3. Создание крипто-диска


Рис. 4. Синхронизация выключена

Ждем, пока крипто-диск будет создан, затем выбираем его в программе и нажимаем кнопку Монтировать (рис. 5). Далее как обычно — вводим пароль и начинаем работу с ним.


Рис. 5. Программа CyberSafe Disk

На крипто-диск я поместил один относительно большой файл — фильм размером 270 Мб и один небольшой текстовый, что и показано на рис 6.


Рис. 6. Крипто-диск смонтирован как H, на него помещены файлы

По окончанию работы с крипто-диском мы его размонтируем (кнопка Демонтировать в программе), включаем синхронизацию и засекаем время начала и окончания синхронизации. Размонтирование диска необходимо, чтобы клиент облачного диска смог получить доступ к файлу — ведь CyberSafe Disk использует эксклюзивный доступ и ни одна другая программа не сможет прочитать файл, пока он подмонтирован. На практике синхронизацию можно и не выключать, просто она начнется после того, как Яндекс.Диск сможет получить доступ к файлу.
Если у вас Windows 10, можно также посмотреть использование сети приложением Яндекс.Диск. До синхронизации крипто-диска на тестовой машине использование сети Яндекс.Диском составляло 83,5 Мб, что и показано на рис. 7.


Рис. 7. Использование сети до полной синхронизации крипто-диска

Итак, сейчас 9:19. Посмотрим, сколько времени займет полная синхронизация созданного крипто-диска. Со скоростью 1.2 Мб/с на синхронизацию крипто-диска размером 500 Мб понадобилось около 8 минут (рис. 9). Время окончания синхронизации — 9:27.


Рис. 8. Идет синхронизация крипто-диска


Рис. 9. Полная синхронизация завершена

А теперь посмотрим, сколько трафика использовало приложение Яндекс.Диск. После синхронизации использование трафика приложением составило 618 Мб. То есть приложение израсходовало 534,5 Мб трафика.


Рис. 10. Использование трафика после полной синхронизации (до дельта-синхронизации)

Отключаем синхронизацию. Монтируем снова крипто-диск и вносим изменения в текстовый файл. Я просто добавил еще одну строку (рис. 11).


Рис. 11. На этот раз диск подмонтирован как J

Далее размонтируем диск, смотрим на время и запускаем синхронизацию. Сейчас 9:35 (рис. 12). Нужно отметить, что при дельта-синхронизации нужно чуть больше времени на начало самой синхронизации. Приложение должно понять, какую часть файла отправить в облако.


Рис. 12. Время начала дельта-синхронизации

В нашем случае на все про все ушла минута, может быть чуть больше, с точностью до секунды никто не засекал, но в 9:36 приложение сообщило, что крипто-диск (test.vdf) был синхронизирован.


Рис. 13. Дельта-синхронизация завершена. Время 9:36

Посмотрим, сколько трафика израсходовало приложение (рис. 14). Всего 1 Мб.


Рис. 14. Использование трафика после дельта-синхронизации

Проведем такой же эксперимент с OneDrive. Поместим наш крипто-диск в папку OneDrive и запустим синхронизацию. Использование трафика до первой синхронизации составляет 45,3 Мб (см. рис. 14). На рис. 15 показано время начала синхронизации (9:57), использование трафика до синхронизации и то что OneDrive отправляет именно наш файл в облако — это видно по размеру.


Рис. 15. Первая синхронизация крипто-диска с помощью OneDrive

Время окончания первой синхронизации показано на рис. 16 — 10 часов и 7 минут. На первую синхронизацию было потрачено 10 минут, кстати, на 2 минуты больше, чем в случае с Яндекс.Диск. Использование трафика изображено на рис. 17. Было 45,3 Мб, стало 582 Мб, то есть в облако было загружено 536,7 Мб.


Рис. 16. Время окончания первой синхронизации OneDrive


Рис. 17. Трафик после первой синхронизации OneDrive

Далее тот же алгоритм: отключаем синхронизацию, монтируем диск, вносим изменения (я традиционно добавляю еще одну строку в файл), размонтируем, включаем синхронизацию. На рис. 18 показан путь к крипто-диску — обратите внимание подмонтирован крипто-диск именно из папки OneDrive.


Рис. 18. Вносим изменения в крипто-диск

Запуск второй синхронизации OneDrive произошел в 10:16. А что дальше? А дальше OneDrive мегабайт за мегабайтом начинает передавать файл в облако заново (рис. 20).


Рис. 19. Запуск второй синхронизации OneDrive


Рис. 20. Дельта-синхронизация явно не поддерживается…

Вторая синхронизация была завершена в 10:27, то есть заняла примерно те же 10 минут, см. рис. 21. Использование трафика подтверждает то, что дельта обновления не поддерживаются и OneDrive вырывается в лидеры по потреблению трафика (рис. 22).


Рис. 21. Время завершения второй синхронизации


Рис. 22. Использование трафика OneDrive после второй синхронизации

Думаю, комментарии тут излишни — и так все видно. Использование дельта-синхронизации позволяет экономить время и трафик, а также использовать синхронизацию крипто-дисков на мобильных устройствах. Начальную синхронизацию можно выполнить по Wi-Fi, а дельта-обновления занимают совсем немного трафика и вполне уместны в 3G-сетях.
КиберСофт 43,08
Компания
Поделиться публикацией
Похожие публикации
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 20
  • 0
    Мне кажется, что чем больше пользы от дельта-синхронизации, тем меньше пользы от применения крипто-контейнера (и наоборот). Ведь смысл применения криптографии не только в том, чтобы скрыть содержимое файлов, но также и само наличие файлов, а также производимые с ними действия. Иначе ваши данные будут уязвимы для криптоанализа.
    • 0
      Поддерживаю. Плюс возникает вопрос — если дельта-синхронизация работает с шифрованным файлом и передаёт всего 1 мегабайт, то какая часть контейнера на самом деле шифруется? Или контейнетр разбивает данные на равные(?) блоки и их шифрует отдельно?
      • 0
        Насколько я понимаю, тут используется режим XTS. Шифруется весь контейнер целиком (то есть, не пофайлово). Контейнер разбивается на блоки размером в 16 байт (= размер блока AES). При изменении этого блока меняется только он.
        • –2
          Судя по описанию контейнера в статье, используется блочный шифр AES, размер блока в котором равен 128 битам(16 байт).
          Но судя по тому, что у них дельта синхронизация может отличать измененные данные, то используют они его не правильно.
          По определению любое малейшее изменение должно менять все зашифрованные данные так, чтобы новые шифроданные были полиноминально не отличимы от старых. Там либо яндекс диск доказал на практике P=NP, либо все же aes там используется не безопасным образом. Для того чтобы блочный шифр был безопасным нужно хотя бы использовать безопасные режимы шифрования. Например с рандомным вектором инициализации (IV).
          • 0
            Но судя по тому, что у них дельта синхронизация может отличать измененные данные, то используют они его не правильно.

            С чего это не правильно? Вы что предлагаете каждый раз при изменении одного байта перешифровывать весь контейнер? TrueCrypt и аналоги используют режим шифрования заточенный и рекомендованный для блочных устройств хранения данных, а именно — XTS. Так как там своя специфика, одно дело шифровать строку или файл, другое дело блочное устройство с произвольным доступом в реальном времени.
      • 0
        Есть гораздо более удобный способ — использование encfs. Там не создаётся контейнер,
        а каждый файл шифруется отдельно. То есть остаётся видна структура каталогов (вместе
        с размерами файлов и временем создания), шифруются только имена и содержимое.
        Зато есть большое преимущество — можно смонтировать одновременно на нескольких
        устройствах, занимаемое место равно суммарному размеру файлов, передаются только
        изменённые данные.
      • 0
        Насколько я знаю, идеальное шифрование должно быть как хеш функция — малейшее изменение оригинальных данных сильнейшим образом меняет все байты зашифрованных данных.
        • 0
          Шифрование — это инструмент. В некоторых ситуациях дельта-кодирование вполне оправдано.
          • 0
            Ага, добавил запятую в тестовом файле, и пошел пить чай пока контейнер в пару терабайт перекодируется. Вы же не сравнивайте рекомендации по шифрованию для небольших текстовых файлов или строк, и требования к шифрованию блочных устройств. Грубо говоря представьте, что контейнер это просто куча файлов одинаковой длины (равной длине блока устройства или файловой системы). Так что если у вас изменятся данные в одном блоке, то это как будто изменились данные в одном этом файле.
            P.S. На самом деле данных в контейнере меняется меньше чем мегабайт, просто это уже такой размер блока задан в программке считающей дельты. Просто чем больше блок тем меньше данных нужно для хранения хэшей блоков, тут нужно искать оптимальное соотношение (возможно оно также зависит от размера или типа файла).
          • 0
            Это у вас не совсем дельта-кодирование получается. Если хотя бы один байт в начало файла, то перезапишется файл целиком и дельта-кодирование работать не будет.
            • +1
              Совсем не обязательно, это зависит от кривизны рук писавших поиск повторяющихся блоков, и насколько они хотели заморочиться, есть тот же Кольцевой хеш, и более простые варианты типа поиска по началу/концу блока.
              Но с криптоконтейнерами даже проще, так как там всё пишется блоками, и по сути без разницы в начало или конец файла вы добавите символ. Так как всё равно в таком случае изменится один блок файловой системы и он полностью зашифруется по-новому заменит соответствующий блок в криптоконтейнере. А основной гемор появляется тогда когда блоки могут менять размеры.
              • 0
                Кольцевой хеш тут использовать не получится по ряду причин. Основная причина — вычислять кольцевой хеш нужно до шифрования, потому что после шифрования в режиме XTS при добавлении байта в начало блоки сдвинутся, шифротекст блоков поменяется и кольцевой хеш не совпадёт.
                С криптоконтейнерами, кстати, наоборот сложнее, так как при добавлении символа в начало файла внутри контейнера перезапишутся все блоки изменяемого файла, так как для добавления байта в начало файла, файл нужно перезаписать полностью (по определению).
                Вообще, задача с дельта-кодированием, шифрованием и добавлением байта в начало файла — очень интересная. Мне приходилось решать её недавно, скорее всего, скоро напишу статью на хабре.
                • 0
                  Ничего не сдвинется, размеры блоков в криптоконтейнерах одинаковые, так же как и в файловой системе, вы просто не сможете добавить байт в начало файла, ну разве что в тупую открыть криптоконтейнер в каком-нибудь hex-редакторе и вручную добавить, но вряд ли он после этого сохранит работоспособность. Тут основная особенность жесткая привязка к размеру блока, и то что блоки в файловой системе без лишней необходимости не "тасуются" и могут быть не последовательными. А если попытаться добавить новый блок, то драйвер записывает его туда где свободное место, а не в начало контейнера сдвигая все остальные блоки.
                  Потому кольцевой хэш и будет нормально работать, собственно почему будет, он работает, тот же rsync работает с truecrypt контейнерами.
                  Просто, чтобы быть максимально быстрыми криптоконтейнеры не должны шифровать больше, чем количество измененных блоков, иначе никакой прозрачной работы не получится, а следовательно раз меняется только блок данных (всегда одинаковой длины, так как зависит от начального форматирования), то и найти это не такая уж и проблема.
                  А вы рассуждаете о шифровании на уровне файлов. Вот можете почитать особенности шифрования дисков.
                  • –1
                    Я не знаю способа добавить байт в начало файла без перезаписывания всего файла. В любой файловой системе добавление байта в начало файла будет перезаписывать файл целиком.
                    тот же rsync работает с truecrypt контейнерами.

                    Попробуйте записать в контейнер файл размером в 2Гб, передать на другой узел, приписать 1 байт в начало 2Гб-файла и запустить rsync. Будете приятно удивлены тем, что rsync исправно передаст около 2Гб. Всё из-за того, что все блоки файла будут перезаписаны, у данных изменится смещение (а смещение является параметром шифрования в режиме XTS). Шифротекст блоков изменится. Кольцевой хеш (weak-хеш, в терминологии rsync) тоже полностью изменится. Все блоки изменённого файла будут переданы заново. Из-за одного байта, да.
                    Блоки контейнера, на которых лежат другие файлы переданы не будут (данные не изменятся, их смещение не изменится, а значит, шифротекст тоже не изменится)
                    • –2
                      В общем понял вы рассуждаете о дельте на уровне исходных данных, а я говорю о дельте на уровне криптоконтейнера.
                      Просто неоднозначная фраза
                      Если хотя бы один байт в начало файла, то перезапишется файл целиком и дельта-кодирование работать не будет.

                      На уровне контейнера будет, о чем я и говорил, хотя конечно не покажет, что изменился конкретный байт, но как бы для криптоконтейнера этого и не нужно.
            • 0
              Т.е. в статье мы увидели, что небольшое изменение содержимое крипто-контейнера вызвало передачу небольшого объем данных и быструю синхронизацию. Мы говорим здесь о встроенной в облачные клиенту дельта-синхронизации, не о чем-то специальном: клиенты не знают, что это за большой такой файл на 500 Мб, и передают только изменения в нем.

              Честно говоря, я бы больше хотел бы видеть возможность монтировать контейнера из облака (с промежуточным хранением на машине, но тоже в зашифрованном виде). Иначе странно: пока я контейнер не размонтирую, синхронизатор не может его закинуть. Т.е. весь рабочий день синхронизация не может состояться, и, если за это время к нам приходят маски-шоу (ой, о чем я, просто любопытные друзья), то свежие изменения в облаке не отражаются.

              Так что, да, encfs, или что-то подобное бы…

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое