Шифрование данных паролем: тест VeraCrypt и Cryptomator

Реальная разница между инструментами возникает на уровне архитектуры: что именно шифруется, как устроен контейнер, какие метаданные остаются видимыми, сколько операций приходится на один файл и как система переживает синхронизацию.

VeraCrypt и Cryptomator решают разные задачи, хотя в интерфейсе оба выглядят как программы, которые защищают данные паролем. VeraCrypt строит монолитный зашифрованный том или шифрует диск целиком. Cryptomator создает файловое хранилище, где каждый объект обрабатывается отдельно и подготовлен к работе поверх Dropbox, Google Drive, OneDrive или Nextcloud.

Поэтому вопрос «что безопаснее — VeraCrypt или Cryptomator» поставлен неполно. Корректная формулировка другая: нужна ли вам непрозрачная зашифрованная область, или вы хотите хранить отдельные файлы в облаке так, чтобы провайдер не видел их содержимое?

Архитектурные различия: контейнер против файлового хранилища

VeraCrypt работает на уровне тома. Пользователь создает контейнер фиксированного размера либо включает шифрование раздела или диска. После монтирования операционная система видит обычную файловую систему внутри зашифрованной области. Для приложений это стандартный диск: файлы открываются, изменяются и удаляются без отдельной логики шифрования на уровне каждой операции.

Такая модель дает VeraCrypt важное свойство: внутри контейнера скрывается не только содержимое, но и структура данных. Внешний наблюдатель не получает нормального списка файлов, не видит иерархию каталогов и не может напрямую определить размеры отдельных объектов. Снаружи есть контейнер, его размер и служебные признаки. Внутри — данные, доступные после монтирования и ввода пароля.

Cryptomator устроен иначе. Он создает виртуальный сейф, но физически хранит набор зашифрованных файлов и каталогов. Содержимое каждого файла шифруется отдельно. Имена объектов преобразуются в зашифрованные значения, а сама структура хранилища остается совместимой с файловой системой и облачной синхронизацией.

Это не косметическая разница интерфейса. Она определяет поведение системы при изменении одного файла.

Если документ на 20 МБ изменился внутри контейнера VeraCrypt, облачный клиент без поддержки блочной синхронизации может рассматривать весь контейнер как измененный объект. Тогда на сервер отправляется весь файл-контейнер. Cryptomator в аналогичной ситуации меняет конкретный зашифрованный объект, и синхронизатор передает только его.

Для облака это принципиально. Монолитный контейнер плохо сочетается с обычной файловой синхронизацией: система видит большой бинарный файл, а не набор независимых объектов. Cryptomator изначально рассчитан на противоположный сценарий.

В практическом сравнении VeraCrypt против Cryptomator нельзя подменять понятия «скрывает содержимое» и «скрывает метаданные». Оба инструмента защищают данные от чтения без ключа. Но только контейнерная модель VeraCrypt последовательно скрывает внутреннюю структуру как единое целое.

VeraCrypt шифрует пространство. Cryptomator шифрует объекты. От этого зависит не только безопасность, но и вся эксплуатационная модель.

Криптография: AES-256 одинаково надежен, но протоколы разные

Фраза «зашифровано AES-256» почти бесполезна без уточнения режима работы, схемы аутентификации и функции деривации ключа. Пароль не используется напрямую как ключ AES. Сначала из него получают криптографический ключ с помощью KDF — функции, специально рассчитанной на то, чтобы сделать перебор дорогим.

У Cryptomator содержимое файлов шифруется с использованием AES-256-GCM. Это authenticated encryption: схема одновременно обеспечивает конфиденциальность и проверку целостности. Если зашифрованный объект был изменен, подделан или поврежден, проверка тега аутентификации должна обнаружить проблему.

Имена файлов и каталогов обрабатываются отдельно. Для детерминированного шифрования имен используется AES-SIV. Здесь детерминированность нужна не для удобства чтения, а для сохранения возможности сопоставлять структуру каталогов и выполнять файловые операции поверх зашифрованного хранилища. Одинаковые входные значения в соответствующем контексте дают предсказуемый результат, что является частью архитектурного компромисса.

Мастер-ключ Cryptomator защищается через scrypt. Это память-емкая функция деривации ключа. Ее назначение — увеличить стоимость массового перебора пароля, особенно на GPU, где простые быстрые KDF масштабируются слишком хорошо для атакующего.

VeraCrypt предлагает другой набор криптографических вариантов. В конфигурациях могут использоваться AES-256 в режиме XTS, а также Serpent, Twofish, Camellia и Kuznyechik. Для получения ключевого материала поддерживаются PBKDF2 с различными хэш-функциями, включая HMAC-SHA-512, SHA-256 и Whirlpool. Для несистемных томов в версии 1.26.29 была добавлена поддержка Argon2id.

Здесь нельзя делать примитивный вывод, будто Argon2id автоматически делает VeraCrypt безопаснее Cryptomator или наоборот. Криптографическая стойкость системы определяется связкой:

• качеством пароля;
• параметрами KDF;
• режимом шифрования;
• защитой целостности;
• реализацией монтирования и работы с ключами;
• моделью угроз;
• тем, какие метаданные остаются на диске или в облаке.

Слабый пароль не становится сильным из-за того, что выбран AES-256. И наоборот, использование scrypt или Argon2id не компенсирует утечку мастер-ключа, зараженную систему или ошибку в операционной среде.

KDF и перебор пароля

Для локального злоумышленника, получившего копию контейнера или файла masterkey.cryptomator, KDF определяет стоимость офлайн-перебора. В этом сценарии атакующий может запускать большое количество проверок без ограничений интерфейса. Никакой капчи. Никакого rate limit. Только вычислительная стоимость одной попытки и качество самого пароля.

scrypt и Argon2id проектировались с учетом памяти. Это усложняет эффективное распараллеливание на GPU и специализированных устройствах. PBKDF2 в первую очередь увеличивает число вычислительных итераций и остается широко используемым стандартом, но его характеристики против современных аппаратных атак нужно оценивать по конкретным параметрам.

Название алгоритма без параметров ничего не говорит о реальной защите. У scrypt есть параметры памяти, времени и параллелизма. У Argon2id — параметры памяти, числа итераций и потоков. У PBKDF2 — число итераций и хэш-функция. Сравнивать только слова «scrypt против Argon2id» — это маркетинговая бухгалтерия, а не аудит.

Практический вывод для пользователя простой: пароль должен быть устойчивым к офлайн-перебору, а выбранный инструмент — использовать актуальные параметры KDF по умолчанию и позволять их корректно применять. Но даже сильная KDF не скрывает факт существования самого контейнера и не защищает данные после разблокировки тома на скомпрометированной машине.

Производительность и оверхед: почему контейнер быстрее на больших потоках

У VeraCrypt преимущество появляется там, где данные читаются и записываются крупными последовательными потоками. После монтирования операционная система взаимодействует с томом как с блочным устройством. Криптографический слой может эффективно использовать AES-NI, а операции не требуют отдельной упаковки и обработки каждого файла.

В бенчмарках для VeraCrypt с аппаратным ускорением AES-NI скорость AES-256 в оперативной памяти достигает примерно 560–1033 МБ/с. Это не универсальная гарантия для любой системы. Результат зависит от процессора, режима шифрования, файловой системы, диска, размера блока и характера нагрузки. Но диапазон хорошо показывает архитектурный потолок: при крупных последовательных операциях оверхед шифрования может быть относительно небольшим.

Cryptomator платит за файловую гранулярность. Каждый объект нужно открыть, обработать, зашифровать, снабдить служебными данными и передать файловому слою. Для каталогов с большим количеством мелких объектов это особенно заметно: стоимость системных вызовов, операций с метаданными и синхронизации становится сопоставимой с самой криптографией.

Для локальной записи на SSD в сценариях Cryptomator указывают порядок 80–200 МБ/с. Это не означает, что AES-GCM «медленный». Причина в другом: пофайловое шифрование добавляет накладные расходы на каждый объект. При работе с большим архивом одного крупного файла разница будет одной; при каталоге из десятков тысяч мелких документов — другой.

Нужно различать три типа нагрузки:

1. Большие последовательные файлы.

Видеоархив, образы дисков, большие резервные копии. Здесь VeraCrypt обычно лучше раскрывает возможности локального SSD и AES-NI.

2. Много мелких файлов.

Исходный код, документы, конфигурации, фотографии с сопутствующими файлами. В Cryptomator оверхед на объект заметнее, но зато синхронизация отдельных изменений становится рациональнее.

3. Смешанная облачная работа.

Пользователь редактирует несколько документов, а остальные данные не должны повторно передаваться в сеть. Cryptomator выигрывает не абсолютной скоростью шифрования, а объемом данных, который приходится синхронизировать.

У VeraCrypt можно получить высокий локальный throughput и одновременно проиграть на канале передачи. Контейнер на 200 ГБ, внутри которого изменился один файл, остается контейнером на 200 ГБ для файлового синхронизатора. Если клиент не умеет блочную дедупликацию и дельта-синхронизацию, сетевой оверхед будет несоразмерен изменению.

У Cryptomator обратная сторона: локальная файловая операция сложнее, а структура хранилища более многословна. Криптографическая защита каждого объекта удобна для синхронизации, но не бесплатна по CPU, I/O и метаданным.

В бенчмарке локального диска побеждает не всегда лучший инструмент. Иногда побеждает неправильный тест.

Приватность метаданных: содержимое — не вся информация

Шифрование данных паролем часто оценивают по одному вопросу: сможет ли атакующий открыть файл? Для серьезной модели угроз этого мало. Метаданные сами по себе могут раскрывать рабочий контекст: сколько объектов хранится, как организованы каталоги, какие файлы изменялись и насколько они велики.

VeraCrypt здесь работает жестче. Монолитный контейнер скрывает содержимое внутренней файловой системы, количество файлов и их размеры. Снаружи наблюдаем в основном сам контейнер и его общий размер. При корректном использовании это значительно сокращает объем информации, доступной без пароля.

Дополнительный механизм VeraCrypt — скрытые тома. Он предназначен для сценариев правдоподобного отрицания наличия определенных данных. Это не универсальная защита от анализа системы и не магический режим невидимости. Но в архитектуре VeraCrypt такая функция присутствует и напрямую связана с контейнерной моделью.

Cryptomator не обещает такого уровня сокрытия. Он шифрует содержимое и имена файлов, но облачный провайдер или другой наблюдатель может частично видеть структуру хранилища, количество файлов, иерархию и примерные размеры объектов. Даже если сами названия заменены шифротекстом, профиль активности остается частично наблюдаемым.

Это типичная граница между конфиденциальностью содержимого и конфиденциальностью паттернов использования. Представим хранилище, где нельзя прочитать ни один файл, но можно заметить:

• что в каталоге постоянно появляются объекты примерно одинакового размера;
• что один набор файлов изменяется по будням;
• что архив содержит много крупных объектов;
• что структура каталогов стала глубже;
• что после определенного события объем данных резко вырос.

Для обычного облачного бэкапа такая утечка может быть приемлемой. Для корпоративного расследования, журналистского архива или защищенного набора исследовательских данных — уже нет. Здесь VeraCrypt предоставляет более сильную модель приватности метаданных, если контейнер хранится и передается как единый объект.

Но у этой защиты есть эксплуатационная цена. Облачный сервис не понимает внутреннюю структуру контейнера и не может эффективно синхронизировать отдельные изменения. Повышение приватности метаданных оплачивается сетевым оверхедом и худшей совместной работой.

Безопасность в реальной эксплуатации

Криптографический алгоритм редко является главным источником уязвимости. На практике проблемы появляются в месте, где зашифрованное хранилище пересекается с операционной системой, резервным копированием и пользовательскими привычками.

VeraCrypt после монтирования предоставляет обычный доступ к расшифрованным файлам. В этот момент вредоносный процесс с правами текущего пользователя может читать открытые документы, перехватывать данные из памяти, извлекать временные копии или использовать приложения, которым разрешен доступ к тому. Зашифрованный контейнер защищает данные в состоянии покоя. Он не превращает уже разблокированную систему в изолированный аппаратный модуль.

Cryptomator работает по той же базовой логике: пока сейф открыт, приложения получают доступ к расшифрованному содержимому через виртуальную файловую систему. Профиль риска меняется, но фундаментальное ограничение остается. Шифрование at rest не равно защите от malware на endpoint.

Есть и другие точки отказа:

• пароль может попасть в менеджер буфера обмена или журнал утилиты;
• незашифрованные временные файлы могут остаться в каталоге приложения;
• резервная копия может включать расшифрованную рабочую папку;
• ключи восстановления и конфигурационные файлы могут храниться рядом с контейнером;
• при аварийном завершении программы открытые данные могут остаться в кэше;
• синхронизация может передать старые версии объектов в историю облачного сервиса.

Последний пункт особенно важен для Cryptomator. Пофайловая синхронизация уменьшает объем передачи, но облачный провайдер может хранить версии измененных зашифрованных файлов. Это не раскрывает их содержимое без ключа, однако увеличивает объем доступного для анализа шифротекста и сохраняет историю изменений на стороне сервиса.

У VeraCrypt иная проблема: повреждение контейнера потенциально затрагивает структуру тома, а не один независимый объект. Поведение зависит от файловой системы, резервного копирования и характера повреждения. Монолитность — это одновременно сильная сторона для сокрытия метаданных и единая область риска для хранения.

Надежное шифрование папки паролем не отменяет резервное копирование. Если контейнер VeraCrypt или набор файлов Cryptomator существует в единственном экземпляре, пользователь защищает данные от чтения, но не от потери. Резервные копии тоже должны оставаться зашифрованными. Иначе безопасность исходного хранилища обнуляется копией, которую забыли защитить.

Сценарии использования: где какой инструмент рациональнее

Локальный защищенный рабочий том

Если требуется зашифрованная область на ноутбуке или внешнем диске, VeraCrypt выглядит логичнее. Он дает привычную файловую систему, скрывает внутреннюю структуру и подходит для крупных последовательных операций. Для рабочего набора, который постоянно монтируется и используется локально, это более прямой путь.

Особенно уместен VeraCrypt, если нужно шифровать не отдельную папку, а раздел или весь диск. Здесь Cryptomator не является конкурентом: он предназначен для файлового шифрования сейфов, а не для системного FDE.

Облачный архив документов

Если данные должны храниться в Dropbox, Google Drive, OneDrive или Nextcloud, Cryptomator обычно практичнее. Изменение одного файла не требует повторной передачи всего контейнера. Облачный клиент видит набор объектов и может синхронизировать только те, которые изменились.

Это не делает Cryptomator полностью прозрачным для провайдера. Структура и размеры частично наблюдаемы. Но для сценария «защитить содержимое перед загрузкой в облако» компромисс разумный: меньше сетевой оверхед, проще выборочная синхронизация, удобнее работа с несколькими каталогами.

Большие резервные копии

Для образов дисков, больших архивов и других крупных последовательных наборов VeraCrypt обеспечивает более чистую модель. Контейнер можно обрабатывать как единый объект, а AES-NI позволяет получить высокий throughput на подходящем CPU.

Однако такой архив нужно правильно копировать. При изменении небольшой части монолитного контейнера обычный облачный синхронизатор не обязан передавать только изменившийся участок. Для этого требуется поддержка блочной синхронизации на стороне инструмента или инфраструктуры.

Часто изменяющиеся документы

Для набора офисных файлов, проектов и каталогов, которые регулярно редактируются, Cryptomator экономит передачу данных. Его файловая модель соответствует характеру изменений: изменился объект — изменился его зашифрованный объект в хранилище.

Цена — больший локальный оверхед и частичная утечка метаданных. Если эти свойства приемлемы, архитектура подходит лучше контейнера.

Требование скрыть саму структуру данных

Когда критичны не только байты файлов, но и факт их организации, VeraCrypt предпочтительнее. Скрытые тома и монолитное представление дают инструменты, которых у Cryptomator нет.

Но подобный сценарий требует дисциплины. Если рядом лежат незашифрованные индексы, названия резервных копий или история синхронизации, теоретическая приватность контейнера быстро превращается в формальность.

Что выбрать для шифрования данных паролем

Сводный выбор можно свести к нескольким техническим условиям:

• Нужна защита локального диска или раздела. VeraCrypt.
• Нужно работать с большим локальным томом. VeraCrypt.
• Нужно хранить отдельные файлы в облаке. Cryptomator.
• Нужно минимизировать объем повторной синхронизации. Cryptomator.
• Нужно скрыть количество файлов и их размеры внутри хранилища. VeraCrypt.
• Нужен скрытый том и правдоподобное отрицание. VeraCrypt.
• Нужно шифровать только выбранные каталоги перед загрузкой в облако. Cryptomator.
• Нужно шифровать системный диск. VeraCrypt, не Cryptomator.

При выборе программ для шифрования файлов паролем не стоит начинать с рейтинга алгоритмов. Сначала фиксируется модель угроз. От кого защищаемся: от случайного доступа к ноутбуку, от провайдера облачного хранения, от кражи внешнего диска, от анализа метаданных или от компрометации рабочей станции? Один и тот же инструмент не может одинаково хорошо закрывать все эти сценарии.

ВераCrypt сильнее там, где требуется непрозрачный контейнер и высокая локальная производительность. Cryptomator сильнее там, где нужна файловая гранулярность и предсказуемая облачная синхронизация. Ни один из них не решает проблему слабого пароля, зараженной ОС или незащищенных резервных копий.

Итоговый вердикт

VeraCrypt — не «более безопасная версия» Cryptomator. Это другой слой абстракции. Его архитектура минимизирует утечку метаданных и дает полноценный зашифрованный том, но плохо сочетается с обычной облачной синхронизацией. Cryptomator жертвует частью приватности структуры ради пофайловой обработки, меньшего сетевого оверхеда и удобства облачного сценария.

Для локальной защиты диска, внешнего накопителя и больших архивов выбор рационально смещается к VeraCrypt. Для клиентского шифрования файлов перед отправкой в облако — к Cryptomator. AES-256 в обоих случаях не является решающим аргументом. Решают архитектура, KDF, модель метаданных и стоимость эксплуатации.

Технический вердикт жесткий: выбирать между VeraCrypt и Cryptomator по формулировке «какая программа лучше шифрует» — ошибка постановки задачи. VeraCrypt лучше скрывает пространство. Cryptomator лучше управляет изменениями файлов. Если перепутать эти сценарии, уязвимость появится не в AES, а в самой архитектуре хранения.