Сквозное шифрование дневника

Как это сделать в GrowScope

1. При первом открытии приложения после этого релиза (новая регистрация или существующий аккаунт) автоматически запускается полноэкранный шаг настройки — нажимать кнопку для его начала не нужно.
2. Фраза восстановления из 12 слов (мнемоника BIP-39, 128 бит энтропии) генерируется локально, на устройстве, и показывается один раз.
3. Пользователь должен подтвердить два случайно выбранных слова из фразы, прежде чем продолжить — этот шаг нельзя пропустить или закрыть, потому что это единственная проверка того, что фраза действительно была записана.
4. После подтверждения дневник шифруется и переносится одним PUT-запросом текущего снимка данных; каждая последующая запись автоматически проходит через шифрование на весь срок жизни аккаунта.
5. На втором устройстве или после очистки хранилища браузера приложение вместо этого запрашивает ту же фразу из 12 слов для разблокировки дневника — для устройства, на котором она уже кэширована локально, она больше не запрашивается.

Шифрование дневника (grow_data)

Категория

Приватность и безопасность

Назначение

Шифровать всё содержимое гроу-дневника на стороне клиента так, чтобы сервер всегда хранил только шифротекст.

Ввод

От пользователя ничего, кроме одноразового подтверждения фразы восстановления — само шифрование автоматическое при каждом сохранении

Расположение

Работает прозрачно при каждом сохранении/загрузке дневника; единственный видимый шаг — экран фразы восстановления (обязателен при первом шифровании и снова, если устройству нужно разблокироваться)

Действие пользователя

1. Подтвердить два слова из сгенерированной фразы восстановления из 12 слов (только при первой настройке)
2. Повторно ввести полную фразу из 12 слов для разблокировки на новом устройстве или после очистки хранилища браузера

Результат

Дневник хранится на сервере как непрозрачные зашифрованные байты (`grow_data.ciphertext` + `grow_data.nonce` + номер версии ключа) вместо читаемого JSON-блока. Также хранится обёрнутый ключ шифрования конкретного аккаунта и его соль (`users.wrapped_mek`, `wrapped_mek_nonce`, `kek_salt`), но они криптографически бесполезны без фразы восстановления пользователя.

Используется в

Каждое чтение/запись дневника — растения, журналы, заметки, сохранённый текст истории AI

Связанные функции

Нет

Примечания

• Иерархия ключей, точно: энтропия фразы восстановления из 12 слов растягивается в ключ шифрования ключа (KEK) через Argon2id (на стороне клиента, ~64 МиБ затрат памяти) со случайной солью для каждого аккаунта. Этот KEK оборачивает (шифрует через AES-256-GCM) отдельно сгенерированный 256-битный главный ключ шифрования (MEK) — именно обёрнутый MEK, а не саму фразу, загружают на сервер. Отдельные записи шифруются ключами, выведенными из MEK через HKDF-SHA256 со строкой контекста, специфичной для записи (например, дневник использует фиксированную строку контекста «grow_data», поскольку на аккаунт приходится один дневник), поэтому скомпрометированный производный ключ не раскрывает MEK или любую другую запись. Собственно шифрование содержимого использует AES-256-GCM (аутентифицированное шифрование — изменённый шифротекст не расшифровывается, а не молча выдаёт мусор).
• Фраза восстановления генерируется один раз, локально, и никогда не передаётся на сервер и не хранится им в пригодном для использования виде — только обёрнутый через AES-GCM MEK и публичная соль KDF. Это значит, что фраза — единственная точка восстановления: потеря её вместе с потерей всех устройств, на которых ключ уже кэширован, означает, что данные этого дневника не сможет восстановить никто, включая GrowScope. Это осознанная цена того, что дизайн действительно zero-knowledge, а не просто «зашифрован» — вариант восстановления на стороне сервера потребовал бы, чтобы сервер хранил нечто, способное восстановить ключ, а именно этого дизайн и избегает.
• Единственное раскрытое исключение из «сервер никогда не видит открытый текст», сформулированное точно: этот дизайн zero-knowledge для хранения и синхронизации — всегда; он намеренно НЕ zero-knowledge для AI-функций, и никогда не описывается как таковой. Каждая функция, использующая AI-кредиты, работает одинаково — AI-анализ растения (оценки здоровья/развития/кроны), Трихомный трекер, AI-скаутинг вредителей, консультант по удобрениям, текстовый анализ оптимизатора размещения оборудования (AI), AI-анализ различий в Сравнении растений, еженедельные отчёты Grow Coach и AI-генерация арта карточек. В каждом из них триггер — это нажатие кнопки действия: ваше устройство расшифровывает только те конкретные данные, которые нужны этому действию (например, выбранные вами фото или недавние записи растения — никогда весь дневник целиком), отправляет их один раз на сервер GrowScope, который пересылает их стороннему провайдеру модели (Anthropic Claude или, через OpenRouter, Google Gemini — выбирается автоматически по задаче, пользователь его не выбирает) для генерации этого одного ответа, и возвращает его. После этого ничего из этого запроса не записывается в таблицу базы данных или в лог на стороне GrowScope.
• Почему это не сделано на устройстве вместо этого: более раннее техническое задание требовало полностью локальную модель на устройстве (через WebLLM/MLC-LLM, квантованную модель на 1–3 млрд параметров, работающую в браузере) как единственный способ сделать AI-функции тоже zero-knowledge. Это было отклонено для GrowScope в его нынешнем виде: оптимизация дозы удобрений, анализ фото трихом/вредителей и разрешение сущностей нескольких растений — это как раз те задачи, в которых маленькие модели на устройстве слабее всего, а это платные функции с расходом кредитов (например, консультант по удобрениям стоит 45 кредитов за вызов), оценённые по цене качества уровня Claude/Gemini. Молча понизить их качество под лозунгом «zero-knowledge» было бы худшим исходом для пользователей, которые полагаются на это качество. Этот компромисс сделан осознанно и изложен здесь прямо, а не скрыт: для того единственного действия, которое вы явно запрашиваете, сторонний провайдер обрабатывает относящийся к нему открытый текст.
• Существующие (до релиза) аккаунты мигрируют лениво: шаг настройки запускается при следующем реальном открытии приложения владельцем этого аккаунта, а не через фоновую/пакетную задачу. Аккаунт, который больше никогда не открывают после этого релиза, просто остаётся в старом, незашифрованном формате хранения бессрочно — это принятый компромисс требования показать фразу восстановления реальному, присутствующему пользователю, а не сгенерировать её без присмотра.

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