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

Пакет сертификатов, выгрузка сотрудников, конфиг с закрытым ключом — в итоге файл оказывается на личном Яндекс Диске, в Облаке Mail.ru или в общей папке компании. Страница загрузки пишет «шифрование при передаче», «шифрование при хранении», «сейф». Эти слова описывают диски и канал самого сервиса, а не «кроме вас никто не откроет». В другой заметке уже разобрали, как во вкладке «Сеть» проверить, что открытый текст не ушёл: слоган ничего не доказывает. Здесь сценарий уже, файл вот-вот покинет этот компьютер и ляжет на чужое хранилище. Сначала разделите, кто сможет прочитать открытый текст. Потом решите, каким каналом вести пароль.

Это не обзор «онлайн-шифрования файлов» и не сравнение, какой диск выбрать. Вопросов три. До выхода наружу открытый текст уже стал шифротекстом? После загрузки провайдер или следующий, кто скачает, всё ещё открывает содержимое как есть? Пароль уехал в том же письме, что и .lock или .enc? Страница шифрования файлов MyPassGen работает на этой границе: AES-256-GCM заканчивается в браузере, затем вы скачиваете результат. Файл и пароль не уходят в теле рабочего запроса. Аккаунт не нужен. Таблицу и шаги ниже можно проверить на месте.

«Зашифровано» часто про слой провайдера

HTTPS закрывает только тех, кто слушает канал. Когда файл доехал до Яндекс Диска, Google Диска или OneDrive, сервис всё ещё может положить его открытым текстом или шифротекстом, который сам же умеет развернуть. Многие продукты как раз такое шифрование «на стороне сервиса» подписывают фразой «ваши файлы зашифрованы». Для эксплуатации это помогает, если диск вынесли из дата-центра. Для «сторона хранения не должна открыть скан паспорта» этого мало.

Сначала зашифровать на клиенте, потом загрузить — другой слой. Браузер или локальная программа выводит ключ из пароля, который держите вы. В облаке остаётся шифротекст. Сюда относятся Rclone Crypt, Cryptomator, часть клиентов синхронизации и Web Crypto во вкладке. Они отвечают на вопрос «хранилище не получит пригодный открытый текст». Они не отвечают на слабый пароль, пароль в том же сообщении, что и файл, или имя, которое уже выдаёт содержимое.

Статья 3 152-ФЗ называет персональными данными любую информацию, относящуюся к прямо или косвенно определённому человеку. Скан паспорта в личном Диске — как раз такой случай. Статья 10 отдельно держит специальные категории: здоровье, биометрия, политические и религиозные взгляды. Незашифрованный скан, который потом переслали в групповой Telegram, передаёт и саму возможность опознать человека. Шифрование до загрузки сужает круг тех, кто откроет байты. Это не обезличивание и не замена вопроса, должен ли файл вообще покинуть машину.

Кто получит открытый текст

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

Только третий класс отвечает на «сторона хранения не должна видеть содержимое». Шифрование должно закончиться до загрузки, и ключ нельзя отдавать той же машине хранения. Предыдущая заметка уже фиксирует: Web Crypto API гарантирует, что считать можно на этом устройстве. Она не запрещает странице сначала загрузить файл, а потом «зашифровать» на сервере. «Сначала локально» проверяют трафиком, не слоганом.

Что на этом шаге делает AES-256-GCM

Первая версия MyPassGen использует только AES-256-GCM. NIST SP 800-38D задаёт GCM как аутентифицированное шифрование: если шифротекст поменяли, расшифровка должна отказать. Вы не получаете кашу, которую ещё можно принять за документ. RFC 5116 AEAD_AES_256_GCM берёт ключ 32 байта, nonce 12 байт и тег 16 байт. В MDN у AesGcmParams тот же совет: IV 96 бит, и под одним ключом каждый раз новый IV. Сам IV — не секрет. Его можно класть рядом с шифротекстом.

Пароль не подставляют как ключ AES. Страница шифрования файлов считает PBKDF2: 100 000 итераций, SHA-256, соль 16 байт, затем ключ 256 бит. Соль лежит в заголовке, чтобы при расшифровке получить тот же ключ. RFC 8018 ссылается на NIST SP 800-132: число итераций берут как можно выше при приемлемом ожидании. Актуальная рекомендация OWASP для хешей паролей на сервере — PBKDF2-HMAC-SHA256 не ниже 600 000 итераций. Это другая задача. Первая линия для пароля файла — длинная случайная строка. Итерации замедляют офлайн-перебор. Они не спасают 123456 в комментарии к файлу на Диске.

Пароль не передавать вместе с шифротекстом

Обычный провал — не «не тот алгоритм». Это backup.lock и фраза «пароль — лето плюс табельный» в одном чате Telegram, в одном письме или в readme.txt той же папки на Диске. Тогда сторона хранения или любой в этом канале держит обе половины. Локальное шифрование ничего не сделало.

Надёжнее разрезать так: шифротекст — через Диск или вложением в почту; пароль — другим каналом: лично, по телефону или одноразовой ссылкой (ключ стоит после # в URL; страница чтения без аккаунта). Не кладите пароль в имя файла, в комментарий архива и не в «заметку только для себя» под тем же облачным аккаунтом.

Пароль лучше собрать на этой машине в генераторе. Случайный режим — от 6 до 128 символов, по умолчанию 16. Короче 8 считайте слабым. Забытый пароль не восстановить: серверной копии открытого текста нет, контрольных вопросов тоже. Это цена того, что хранилище не видит содержимое. Это не «недоделанная функция».

Что всё ещё видно в .lock

Шифротекст — это не «весь файл превратился в нечитаемый шум». Открытый заголовок контейнера часто несёт метаданные. MyPassGen по умолчанию пишет .lock и умеет .enc — один формат, разные расширения, чтобы совпасть с привычкой других инструментов. Заголовок начинается с четырёх байт CSLK, затем версия, соль 16 байт, размер блока и исходное имя файла и MIME-тип открытым текстом. Содержимое режется примерно по 1 МБ и шифруется AES-GCM. У каждого блока свой IV 12 байт и тег 16 байт.

Поэтому если зашифровать паспорт_скан.pdf в паспорт_скан.pdf.lock и загрузить это, список Диска и заголовок файла по-прежнему скажут «это документ, удостоверяющий личность». Шифрование закрывает байты содержимого, не имя. Если имя чувствительное, переименуйте исходник во что-то бессмысленное до шифрования. Загруженному .lock тоже не давайте читаемое название.

Один файл — до 5 ГБ. Шифрование режет через Blob.slice примерно по 1 МБ и отдаёт кусок в crypto.subtle.encrypt. У Web Crypto encrypt() за раз принимает один BufferSource. Скормить весь файл одним вызовом на большом объёме забьёт память вкладки. Нарезка как раз избегает «отдать весь открытый текст API разом». Сборку результата страница делает на этом устройстве, затем отдаёт скачивание. Расшифровка сейчас сначала читает весь .lock, поэтому очень большой файл ест больше памяти — это видно в диспетчере задач, не в слогане.

Проверка на месте

Шаги ниже не опираются на обещание бренда. Возьмите одноразовый маленький текстовый файл. Не тренируйтесь на настоящем скане паспорта.

1. Создайте probe.txt на несколько десятков байт и напишите тестовую фразу, которую знаете только вы, например orange-lake-7. Не используйте настоящий пароль и не номер документа.
2. Откройте инструменты разработчика, вкладку «Сеть», включите «Сохранять журнал». Откройте страницу шифрования файлов, выберите этот файл, задайте пароль и запустите шифрование.
3. Пройдите каждый Fetch / XHR: в строке запроса и в теле не должно быть orange-lake-7 и только что введённого пароля. Аналитика тоже не должна унести исходник. Скрипты, стили и статистика без тела файла допустимы.
4. Скачайте .lock или .enc. В шестнадцатеричном просмотрщике первые четыре байта заголовка должны быть 43 53 4C 4B (ASCII CSLK). Дальше ещё видно исходное имя probe.txt открытым текстом — не саму тестовую фразу.
5. Перетащите этот шифротекст обратно на ту же страницу. Верный пароль должен вернуть тестовую фразу. Смените один символ пароля — расшифровка должна отказать. Каши вместо документа быть не должно.
6. Только после этого загрузите .lock на Яндекс Диск или в Облако Mail.ru. Пароль отправьте другим сообщением. Откройте предпросмотр в облаке: без пароля исходник не должен открыться.

Шифрование файлов MyPassGen работает на этой границе: AES-256-GCM, PBKDF2 100 000 итераций, один файл до 5 ГБ, на выходе .lock / .enc. Счёт заканчивается в текущей вкладке. Аккаунт не создаёте. Доверять всё равно «Сети» и заголовку файла, а не пяти словам «мы ничего не загружаем».

Короткий секрет — не целый файл

Ключ API, код восстановления или пароль базы не нужно сначала превращать в файл. Целый файл уместен для пакета сертификатов, выгрузки таблиц и кусков образа диска. Короткий текст лучше отдать одноразовой ссылкой: открытый текст до 32 КБ, на сервере только шифротекст, ключ после #, число чтений и TTL можно задать. Создать и прочитать можно без входа.

Исходящие пояснения — другая работа. URL с utm_source разбирает заметка какие параметры снимать. Телефон и паспорт в тикете — какие поля маскировать. Шифрование файла отвечает на «сторона хранения не откроет содержимое». Оно не отвечает на «в этом обсуждении не должно быть полного номера».

Частые ошибки

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

«HTTPS уже защищает весь путь.» HTTPS заканчивается на входе провайдера. После посадки файла граница защиты меняет хозяина. Сокращаете вы открытый текст в копии, которая лежит на диске сервиса.

«Переименовал в .lock — уже шифрование.» Файл, который не прошёл аутентифицированное шифрование, в блокноте по-прежнему ищется как открытый текст. В заголовке должно быть условленное магическое число, содержимое не должно открываться. Одна смена суффикса ничего не делает.

«Пароль забыл, поддержка сбросит.» При хранении без знания серверной копии пароля нет. В подвале сайта нет и ящика поддержки «сбросить пароль шифрования». Пароль живёт в вашем менеджере паролей или в другом канале, который контролируете вы.

С чего начать

Начните с того файла, который нужно загрузить сегодня. Прогоните шесть шагов выше на одноразовом маленьком файле. Убедитесь: во вкладке «Сеть» нет исходника, заголовок CSLK, неверный пароль не открывает. Затем шифруйте настоящий файл. Если имя чувствительное — сначала переименуйте.

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

Частые вопросы

Чем сейф провайдера отличается от «сначала локально»?

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

Если пароль забыл, можно ли ещё расшифровать?

Нет. Серверной копии открытого текста или пароля нет. Берите длинный случайный пароль и держите его в своём менеджере паролей. Это оборотная сторона фразы «сторона хранения не видит содержимое».

Чем .lock отличается от .enc?

На этом сайте это один контейнер с разными расширениями. Расшифровка принимает оба суффикса. Не считайте, что чужой .enc использует тот же заголовок.

Нужен ли аккаунт, чтобы шифровать? Уходит ли файл на сервер?

Аккаунт не нужен. Риск журнала начинается, когда исходник отдаёте сайту, который шифрует «за вас». Локальная обработка держит файл и пароль в текущей вкладке. Проверяйте, ушло ли во вкладке «Сеть» тело файла или пароль и ищется ли в .lock тестовая фраза.