новости

контейнер клиента с одним или двумя томами

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

в основную ветку вошёл контейнер клиента: сам пакет, профиль, который хранит в томе карточку контакта, и две команды, jimichi vault init и jimichi vault show. работающий клиент -peer его пока не использует и по-прежнему держит личность только в памяти. в числа на странице исследования контейнер не входит.

один файл, две области

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

команда jimichi vault init принимает одну или две карточки контакта, сама генерирует пароль каждого тома и печатает пароли один раз. jimichi vault show читает пароль из stdin и печатает собственную карточку, которую выводит этот том, и хэш его карточки контакта, но никогда не число томов и не открывшуюся область.

ключа в файле нет, и чего это не значит

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

карточка, построенная из тома, при допущениях о выводе ключей неотличима от карточки клиента без контейнера, поэтому ни контакт, ни mailbox по ней о контейнере не узнают.

одна запись

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

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

что заявлено

  • файл в одном состоянии и пароль одного тома не выдают, есть ли второй том. это держится на названных допущениях о растяжении пароля, aead с одноразовым ключом и выводе ключей и на рассуждении, а не на формальном доказательстве. верно это только для сгенерированного пароля второго тома, поэтому jimichi vault init создаёт пароли сама; с -stdin пользователь даёт свои, и команда предупреждает, что для них утверждение не заявляется.
  • состояния файла после создания совпадают байт в байт.
  • изменённый том не открывается: каждая область запечатана aead, а номер области и соль входят в ключи, поэтому изменённый бит или переставленные области дают отказ открытия, а файл другого размера отвергается как не контейнер.

что не заявлено

  • пароль, выбранный человеком, ни на одном наборе: такой пароль лежит в пределах перебора. на гост догадка к тому же дешевле, чем на c25519, потому что растяжению не нужна память; во сколько раз, не измерено.
  • напечатанный пароль: jimichi vault init печатает сгенерированный пароль один раз, а история терминала и перенаправленный вывод в утверждение не входят.
  • иммунитет против принуждения. у любого контейнера две области, поэтому принуждающий, который знает программу, потребует второй пароль. второй том это легенда, и легенда правдоподобна, только если ею пользуются: неактивная очередь легенды у mailbox или контакт легенды, который не отвечает, её выдают.
  • выданный пароль. вместе с файлом он отдаёт ключ личности, право забора и карточку контакта этого тома на всё время жизни контейнера, а ротации и отзыва нет.
  • файловая система и диск. временные метки показывают, когда контейнер создан и когда открыт, а сколько следов создания хранят журналы, теневые копии, wear-leveling и trim, не измерено. временный файл, оставшийся от создания, убитого до ссылки, это другой контейнер со своей солью; он удаляется при следующем запуске, но удаление не стирает блоки на диске.
  • активный нарушитель между изъятиями. подмена другой области свежим пустым томом не мешает легенде, а для владельца второго тома выглядит как неверный пароль; контейнер, пересозданный тогда на том же устройстве, при следующем изъятии покажет, что второй том был.
  • работающее устройство: в памяти библиотек остаются копии пароля, его растяжения и ключа личности, и они могут уйти в swap и файл подкачки.
  • неотличимость файла без пароля от случайных байт держится только на допущении, которое для кузнечика-mgm не доказано. при этом изъявший узнаёт, что это контейнер: его выдают командная строка, которая его называет, путь и постоянный размер, а скрытым остаётся, один в нём том или два.

как это проверено

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

дальше

клиент -peer, который хранит личность в контейнере между перезапусками, и измерение свойства: различитель одного и двух томов и трасса состояний файла (#20). у такого клиента будут свои границы: постоянное право забора это постоянная очередь, по которой mailbox свяжет все запуски с этим контейнером. затем топология измерения сквозного пути (#47) и блоки атак: извлечение ключей из дампов памяти (#24), компрометация узлов (#117) и временная метка в потоке (#116).

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