что jimichi не защищает

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

mailbox: два клиента переписываются под сквозным слоем, поэтому mailbox на выходе хранит только записи постоянного размера, которые не может прочитать. но он видит обе цепочки разговора и связывает их через очереди: время каждого put и забора, исход put, вид и номер записи. вместе с наблюдателем каналов обоих входов он может связать двух клиентов; насколько это удаётся, не измерено. у клиента без сквозного слоя сообщения по-прежнему читает выход.
украденный ключ клиента: у хэш-ратчета нет шага диффи-хеллмана, поэтому восстановления после компрометации нет: тот, кто взял текущий ключ цепочки направления, читает его следующие записи до нового рукопожатия. прошлые записи остаются закрытыми. держатель закрытого ключа личности клиента может проводить рукопожатия от его имени и подделать первую запись рукопожатия как запись его собеседника; это сбрасывает только сессию, которой нет, неподтверждённую или устаревшую, и не открывает ни одной прошлой записи.
глобальный наблюдатель: модель не покрывает нарушителя, который видит все каналы сразу.
скомпрометированное устройство: если ваш работающий телефон или компьютер захвачен, jimichi не поможет. файл контейнера в покое, изъятый или скопированный, входит в модель. атаки по сторонним каналам на реализацию примитивов тоже вне модели.
root на машине с узлом: от выгрузки в swap заблокированы только буферы ключей, а от привилегированного чтения блокировка не защищает. против root на машине с узлом меры уровня процесса не работают.
кооперативное представление памяти: ключевой эксперимент наблюдает только три выбранных ключа ячеек клиента как точные байты в добровольно экспортированных данных объектов. защищённые первичные буферы вне представления даже при жизни. отсутствие совпадений не доказывает ни стирания, ни стойкости к привилегированному чтению.
моменты соединений: каждая цепочка открывает и закрывает свои tcp-соединения по всей цепочке. эти моменты совпадают и видны глобальному наблюдателю; атака в работе их пока не измеряет.
активная временная метка: измеренный стенд временной метки не устанавливает стойкость к произвольным активным атакам или порог периода узлов. основная метрика требует верного указания цели и отзывчивой исходной цепочки. закрытие всех шести цепочек при 75 мс означает потерю доступности; неверные активные указания и указания sham остаются в отчёте.
отказ в обслуживании: узел даёт одному адресу не больше его доли каналов, рукопожатий и установок и ограничивает время жизни цепочек. нагрузка с числа адресов, достаточного для общих пределов, заполнение кэша меток установки со временем, один адрес, который держит занятыми несколько пар узлов и так влияет на то, какие цепочки выживут, и остановка узла не предотвращаются и не измеряются. любой узел любой из двух цепочек или mailbox останавливает разговор, пока продолжает.
принуждение: контейнер клиента даёт легенду, а не иммунитет: у любого контейнера две области, поэтому принуждающий, который знает программу, потребует второй пароль. выданный пароль вместе с файлом отдаёт ключ личности, право забора и карточку контакта этого тома на всё время жизни контейнера.

где кончаются результаты.

стенд

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

измерения

базовая атака пассивна: наблюдатель считает кадры по окнам на входном канале и на последнем канале между узлами и коррелирует эти числа, только в прямом направлении. auc около 0.5 означает, что не сработала эта атака, а не что не сработает более сильная.
историческая серия временной метки c25519 f0f1885 задерживает один зашифрованный поток клиент-вход и оценивает завершённые кадры вперёд к последнему узлу, включая заполнение. известны эпоха и общие часы loopback, фиксированы кандидаты и поиск кода/сдвига. основная метрика объединяет верную атрибуцию с открытой исходной цепочкой и эхом отдельной пробы. неверные активные указания и указания sham сохранены; при 75 мс все шесть исходных цепочек закрылись в каждом запуске. независимая единица: блок повтора. общий хост, обратное давление и закрытия влияют на признаки; калибровка без метки не ограничивает ошибочную атрибуцию с меткой. нагрузка наблюдалась без исключений после просмотра данных, её эффект отдельно не выделен. ноль наблюдённых основных исходов не означает нулевую вероятность или безопасный порог периода.
неудачные попытки, закрытые и пустые кандидаты остаются в учёте. цепочка отзывчива, только если остаётся открытой и отдельная проба получает эхо до границы захвата. успешный возврат отправки сам по себе не доказывает доставку. опубликованные пассивные таблицы не содержат частоты обнаружения для активного эксперимента. порог стойкости не установлен.
моменты соединений и обучаемый коррелятор пока не измерены. опубликованная таблица связывания потоков использует пассивную атаку; выбор цепочек измерен, а из цены только круговая задержка, множитель полосы и бенчмарки примитивов. кооперативная серия ключей ячейки клиента завершена, с отдельным ограниченным представлением данных объектов. внешнее получение памяти, диск/swap/история, другие секреты и расшифрование записанного трафика остаются неизмеренными за v0.4.0. оставшиеся полные наблюдения узлов обязательны для v0.4.0, проектируются и не реализованы; измерения контейнера клиента остаются в плане.
серии корреляции идут на эхо-топологии: последний узел возвращает каждое сообщение обратно. разговор двух клиентов через mailbox в числа не входит, а измерение этой топологии, двух входов и mailbox, в плане.
подделка разговора в лаборатории показывает офлайн-отрицаемость на конкретных ключах и ничего не измеряет. отрицаемость отправки не измерена: различитель полезных и фоновых ячеек есть, но он меряет узлы, которые пересылают сразу, а не настройку, при которой свойство заявлено. отсутствие того, что можно выдать после сессии, пока не измерено.

сообщения и доставка

сообщение должно помещаться в одну ячейку: не больше 444 байт на трёх хопах. более длинное отклоняется с ошибкой и не отправляется; фрагментации и классов размера нет. длина на проводе ничего не говорит о сообщении только потому, что сообщение не занимает больше одной ячейки. между двумя клиентами тело записи не больше 368 байт, текст сообщения стенда не больше 363.
доставка не гарантируется. при постоянной скорости клиент без сквозного слоя держит в очереди не больше 256 сообщений и новое при полной очереди отбрасывает без ошибки; сообщение в очереди или в пути теряется, когда его цепочка закрывается. подтверждений и повторной отправки нет.
клиент -peer надёжной доставки тоже не даёт. отказ put только задерживает сообщение, но запись, которую mailbox сохранил, снова не кладётся, поэтому сообщение теряется вместе с ней, если истёк её срок в mailbox, её очередь вытеснена или она потерялась в ответе на забор. тело с неизвестным исходом put отправляется снова, поэтому возможен дубликат, а порядок сообщений при отказах не сохраняется.
изоляции по контактам нет. у клиента -peer один контакт на процесс, одна цепочка и одна очередь; второму контакту нужен второй процесс. цепочки и очереди на каждый контакт в плане. групп и нескольких устройств нет.

разговор через mailbox

mailbox видит обе цепочки разговора и связывает их через очереди: по каждой цепочке право забора в открытом виде, очередь put, время каждой заявки, исход put, вид записи, её номер и копии одной записи. вместе со входами он получает граф пары, а вместе с наблюдателем каналов обоих входов может связать двух клиентов атакой корреляции. насколько это удаётся, не измерено. очереди без постоянного идентификатора и цепочки на контакт в плане.
выход клиента -peer закреплён на mailbox: подставной mailbox есть в каждом разговоре своих клиентов, а вместе с подставным входом держит оба конца цепочки, на стенде с вероятностью 1/4. что такой mailbox, следуя протоколу, знает о маршруте, выведено из протокола: на стороне клиента -peer он называет только середину. что он видит и связывает, не измерено.
до сессии put несут только записи рукопожатия, поэтому mailbox видит момент рукопожатия. с покрывающими put, а они включены по умолчанию, клиент кладёт запись на каждом тике, пустую, если сообщения нет, и mailbox не отличает настоящую запись от пустой. без них он видит ещё момент и число настоящих сообщений. отказ put показывает собеседнику и mailbox, что другая сторона не забирает.
с покрывающими put каждая сторона на каждом тике кладёт одну запись и забирает одну, поэтому накопившийся хвост ничто не разбирает: каждый тик, на котором сторона не забирает, во время пересборки её цепочки или паузы её процесса, оставляет в её очереди ещё одну запись собеседника, и каждая следующая его запись ждёт на столько же тиков дольше. хвост ограничен глубиной очереди, по умолчанию 16 записей: сверх неё put получает отказ и собеседник отправляет снова, возможно не по порядку, так что запись ждёт не больше чем на 16 тиков дольше, 3.2 с при скорости 200 мс.
mailbox снимает запись при выдаче, а запись снова не кладётся, если одна её копия уже сохранена: запись, все сохранённые копии которой потерялись в ответах на забор вместе с цепочкой получателя, пропала. настоящее сообщение тогда теряется; потеря записи рукопожатия стоит 60 с ожидания и нового рукопожатия; после потери первой записи инициатора после рукопожатия ответчик не отправляет настоящих сообщений, пока не откроется следующая запись инициатора, без покрывающих put до 30 с. у ответчика нет способа попросить эту запись.
когда узел, остановивший разговор, прекращает, разговор восстанавливается пересборкой и новым рукопожатием примерно за 5 мин. три отказа ответа за 10 мин или 10 мин без цепочки завершают клиента.
очереди mailbox можно исчерпать: n очередей, которые нельзя вытеснить, стоят около n/2 установок коротких цепочек за срок жизни очереди или n открытых цепочек по одной заявке за срок, до 24 ч, и такие очереди мешают новым парам. квоты в плане.
личность и закреплённый контакт клиента -peer живут только в памяти процесса: перезапуск любого клиента даёт новую личность и требует нового знакомства. контейнер клиента реализован, а клиент -peer, у которого личность в нём переживает перезапуск, в плане.
знакомство на стенде доверяет api кластера: тот, кто может читать журналы подов клиентов и пробрасывать их порты, может закрепить любую карточку контакта до первого закрепления или после перезапуска клиента. хэши карточек сравнивает скрипт, а не люди. клиент, которому после закрепления предлагают другую карточку, отвергает её и останавливается, пока оператор его не перезапустит.
журналы клиентов стенда попадают на диск узла кластера: строка на каждое сообщение и строка счётчиков раз в минуту дают время и число сообщений, а хэш закреплённой карточки связывает журналы двух клиентов пары.

криптография и память

реализация гост не является сертифицированным скзи. алгоритмы те же и проверены контрольными примерами из стандартов, но класс защиты не заявляется.
библиотека гост взята с зеркала модуля её автора и закреплена по версии. совпадает ли её код с релизом автора, по независимому источнику пока не проверено.
два набора не смешиваются: узел работает на одном наборе, а клиент отвергает якорь и дескриптор другого, поэтому пользователи гост и c25519 образуют отдельные сети. оба сообщения рукопожатия имеют одинаковый размер на обоих наборах; дескрипторы по открытому http по-прежнему называют набор.
каждый выводимый ключ привязан к транскрипту своего обмена, набору и версии схемы, но правильность состава транскрипта держат только тесты wire и link: интерфейс гарантирует, что ключ нельзя вывести без транскрипта, но не то, что в транскрипт вошло всё нужное. формальной модели установки и рукопожатия канала нет; модель установки в плане.
каналы используют симметричные переходы noise и общий автомат токенов с совместимым сквозным профилем. стандартные векторы noise проверяют производственные переходы канала с заменой только шифра и заданных эфемерных входов. рабочие наборы используют собственные сочетания xchacha или гост; совместимость с готовым noise на проводе и доказанность этих сочетаний не заявляются.
согласования версий схемы ключей и канала нет: несовместимые стороны не проходят рукопожатие, fallback отсутствует. узлы и клиенты обновляются вместе. при включённой аутентификации личность соседа привязана к обмену; сторона, привязавшая другие байты личности, выводит другие ключи.
библиотеки держат свои копии ключей на куче go. рабочий ключ aead живёт там всю жизнь цепочки или канала и не зануляется: он остаётся, пока эту память не займут снова. secmem защищает только собственные буферы.
кооперативный ключевой эксперимент ищет только точные непрерывные байты трёх ключей ячеек клиента внутри разобранных данных объектов одного добровольного экспорта go 1.27.3. стеки, глобальные данные, области среды выполнения и системы и данные mmap вне представления, включая защищённые первичные буферы при жизни. полный разбор не означает полного охвата кучи или процесса, а среда выполнения может молча пропустить данные.
none и all меняют несколько мер памяти вместе. меньше совпадений может означать выход буферов за пределы представления; эксперимент не выделяет вклад отдельной меры или усиления защиты процесса. дополнительные совпадения не отличают копии библиотек от копий компилятора или среды выполнения, вызванных экспортом; преобразованное состояние ключей не ищется. отсутствие совпадений не доказывает ни стирания, ни срока стирания.
каждая точка использует новый процесс и ключи: во время цепочки, сразу после успешной очистки или не раньше чем через монотонную секунду. независимые снимки не прослеживают жизнь ключа; естественный gc и фактические задержки относятся к этому расписанию. неудачные, неподдерживаемые и недоступные наблюдения исключаются, а не становятся нулём. оценены все 360 заданных наблюдений. точные байты c25519 наблюдались под all после close; нули гост после close не доказывают стирания и не исключают преобразованные состояния. cpu хоста: 30 отсчётов серии, 3-33%, медиана 11.5%, среднее 12.4%, они включают проверку, посторонняя нагрузка не выделяется; исключений по нагрузке и выводов о производительности нет. секреты узла, канала, установки, сквозного слоя, ратчета и контейнера не измерены.
от выгрузки в swap заблокированы только буферы secmem. копии на куче лежат на обычных страницах и могут попасть в swap; блокировка всей памяти процесса в плане.
открытый текст сообщений нигде не зануляется. клиент не стирает ни своих сообщений, ни ответов, а выходной узел не стирает открытый им текст: всё это остаётся в памяти процесса, пока её не займут снова. это не ключевой материал, и меры защиты памяти ключей его не касаются.
сквозной слой построен в форме рукопожатия noise, но это не экземпляр noise. формальной модели рукопожатия kk над криптографическим интерфейсом нет, а композиция на гост проверена обвязкой, сверенной на c25519.
клиент -peer держит ключ личности, право забора и текущие цепочки ратчета в заблокированной памяти до конца процесса и ничего из этого на диск не пишет. выданный ключ личности открывает только будущие рукопожатия, а текущая цепочка только следующие записи своего направления.
на наборе гост каждая подпись оставляет на куче копии скаляра ключа подписи и одноразового числа. при выдаче сертификатов с хоста windows ключ уц на время выпуска остаётся в незаблокированной памяти процесса без запрета дампов.
прямая секретность слоёв цепочки простирается настолько, насколько живёт онион-ключ узла. узел меняет этот ключ по таймеру и освобождает заменённый, когда истекли все дескрипторы, в которых он был назван: служебная ячейка установки, сохранённая соседом, открывается не дольше периода ротации плюс срок дескриптора и допуск часов после первой публикации её ключа. самое короткое окно, которое можно задать узлу, 36 минут. память узла, снятая после освобождения, ячейку не открывает, а запись с провода без эфемерных ключей каналов не читается.
ротация не покрывает ключи хопа цепочек, живых в момент снятия памяти, ключ канала, который живёт столько же, сколько процесс, и копии освобождённых ключей и секретов установки, оставленные библиотеками на куче. окно выполняется, только пока ротации удаются и узел может действовать: спящий хост или замороженный процесс хранят свою память, пока не заработают снова.
ротацию делает сам узел, и клиент проверить её не может: дескриптор показывает, что опубликованный ключ сменился, а не что заменённый освобождён. база измерений работает без ротации, и там слои узла после кражи его ключа раскрываются за всё время его работы.
ключи кадров канала и ключи хопа не меняются, пока живут канал и цепочка: число ячеек под ключом хопа ограничено только пределом counter, число кадров под ключом кадров только номером кадра. ротация внутри канала и цепочки в плане.
формат ячейки даёт постоянный размер и защиту от повтора, но это не полный sphinx: позицию узла в цепочке больше ничто не скрывает.
ключ из пароля в наборе гост подобрать перебором офлайн дешевле, чем в c25519: набор гост растягивает пароль pbkdf2 с hmac-стрибог-512, которой не нужна память, потому что функции с затратой памяти в рекомендациях тк26 нет, а c25519 берёт argon2id с 64 миб. число итераций уравнивает процессорное время с argon2id только для стрибога стенда в linux-контейнерах; с оптимизированным стрибогом, на gpu и на специализированном железе догадка стоит дешевле, во сколько раз, не измерено. этот ключ берёт контейнер клиента.

аутентификация узлов

клиент берёт ключи узлов только из комплекта, проверенного по якорю доверия, то есть по открытому ключу уц, и проверяет каждый комплект отдельно: комплект узла списка, не прошедший проверку, считается узлом, которого вход не включил, а комплект самого входа должен пройти проверку, иначе клиент отказывается строить цепочку. кто может изменить якорь в конфигурации клиента, тот решает, каким узлам верит клиент.
ключ уц существует только на время выпуска сертификатов. его владелец, то есть оператор или тот, кто украл ключ за время выпуска, может сертифицировать свою личность на любые имя и адрес и, имея позицию в сети, подменить узлы. узел с сертификатом чужого уц не попадает ни в одну цепочку, пока у клиента якорь стенда и включена проверка узлов, это проверяет тест lab с настоящими узлами; клиент, вытянувший такой узел входом, всё же просит у него зеркало, прежде чем отказаться, поэтому этот узел видит адрес клиента и момент его запуска. как часто случайно выбранная цепочка встречает узлы владельца ключа, посчитано и проверено выборкой; что каждый из них знает о маршруте, выведено из протокола, а что они видят и связывают, не измерено. прошлые цепочки подмена не раскрывает.
выдача сертификатов на стенде держится на доступе оператора к кластеру. тот, кто управляет хостом или его сетью docker, может во время выдачи подменить то, что идёт между уц и узлом, и выдать себя за этот узел.
отзыва нет, кроме истечения сертификата и перезапуска узла с новой выдачей под новым уц. ключ подписи, извлечённый из памяти живого узла, позволяет выдавать себя за этот узел до того из двух моментов, что наступит раньше.
процесс узла принимает один сертификат и один ростер, а ключи узла живут только в памяти процесса, поэтому каждый перезапуск требует новой выдачи, а выдача требует свежих процессов всех узлов; до неё клиенты отвергают узел, и цепочек он не продолжает. тот, у кого есть доступ оператора к свежему процессу узла, может успеть выдать ему сертификат своего уц: клиенты с якорем оператора такой узел отвергают, и до перезапуска он выведен из строя.
тот же доступ позволяет отправить узлу ростер раньше оператора. список узлов в ростере не аутентифицирован: такой ростер должен назвать якорь, которым сертифицирован узел, и даёт ему в соседи только узлы, чьи дескрипторы проверяются по этому якорю, поэтому он может убрать узлы, но не добавить.
дескрипторы узлы публикуют сами, каталога нет, поэтому узел мог бы показывать разные ключи разным узлам ростера, а значит, и клиентам разных входов. с -consistency, включённым по умолчанию, узлы раз в минуту читают зеркала друг друга и держат каждый дескриптор, который узел подписал: два его дескриптора, нарушающие правило, например два онион-ключа одной эпохи, это доказательство, которое каждый узел и каждый клиент проверяет по своему якорю, и узел получает отказ у всех. остаётся окно: до 201 с на стенде после того, как ротация впервые дошла до честного зеркала, два честных зеркала могут нести соседние эпохи, не чаще двух раз за 16 мин, и ключ, открывший служебную ячейку установки, говорит узлу, к какой из двух групп зеркал относится вход: один бит на цепочку, построенную внутри окна. узел с отказом ещё укорачивает список каждого клиента на один.
при включённой аутентификации установка и каналы привязаны к личности узла, заверенной якорем доверия. канал kk привязывает обе личности и адрес инициирующего узла для выбора проверенной записи ростера. адрес только выбирает запись; первый аутентифицированный кадр данных подтверждает владение инициатора конечными ключами. хэша сертификата в транскрипте нет. при выдаче сравниваются адреса, ключи подписи и онион-ключи ростера, но не ключи канала.
у сертификатов и дескрипторов есть сроки действия, поэтому часы узлов и клиентов должны расходиться не больше допуска.

каналы между узлами

при включённой аутентификации канал клиент-вход использует nk и аутентифицирует вход. каналы между узлами используют kk и аутентифицируют обе стороны по проверенным дескрипторам ростера. узел с аутентификацией отвергает nn и неизвестного или просроченного соседа kk без fallback. клиент остаётся неаутентифицированным для входа; его канал nk не заявляет членство в ростере.
ответчик подтверждает конечные ключи инициатора только при открытии первого кадра данных и до него не отправляет прикладных данных. первое сообщение kk повторяемо и подделывается при раскрытии статического ключа ответчика; установки цепочки в нём нет. версия, роль и адрес выбора записи kk остаются видны. оба сообщения рукопожатия и кадры данных имеют один постоянный размер.
базовая линия без аутентификации узлов продолжает цепочку на любой адрес из служебной ячейки установки, и её каналы между узлами не аутентифицированы: они скрывают заголовки только от пассивного наблюдателя. её клиент берёт непроверенные ключи каждого хопа только у входа. ни один блок экспериментов не сравнивает её с конфигурацией с аутентификацией; серии корреляции тоже идут без сертификатов.
каждый узел держит зеркало проверенных комплектов тех узлов ростера, которые у него есть, а клиент обращается только ко входу и просит комплекты всех узлов своего списка, поэтому запрос не показывает цепочку. изменить комплект вход не может: изменённый комплект не проходит проверку и считается отсутствующим. но вход может не отдать зеркало: тогда клиент завершается и при следующем запуске выбирает другой вход; клиент -peer делает так только до первой цепочки, а при пересборке снова спрашивает тот же вход, пока через 10 мин не завершится. ещё он видит, когда клиент готовит цепочку: запрос дескрипторов идёт перед установкой.
узел включает комплект соседа в зеркало только с его начала по часам узла и до момента за 2 мин 6 с до его истечения, чтобы клиент, чьи часы расходятся с часами узла в пределах допуска, ещё считал его действительным; вне этого окна сосед считается узлом, которого вход не включил. сам дескриптор узел держит, и цепочки к соседу продолжает, до его истечения. после перезапуска соседа зеркало отдаёт его прежний комплект до конца срока дескриптора, а цепочки через этого соседа не устанавливаются: у нового процесса другой ключ канала, и рукопожатие канала он не проходит.
тот, кто устанавливает ростер, выбирает, какие хосты узел опрашивает на информационном порту: узел запрашивает дескриптор у каждого адреса ростера, когда запись пора обновить, и продолжает спрашивать с паузой 5 с между проходами, пока соседа нет в кэше или запись всё ещё пора обновить, в том числе когда сосед отдаёт дескриптор, ещё не подписанный заново. ни один адрес ростера не опрашивается о дескрипторе чаще раза в 5 с; с -consistency узел ещё раз в минуту читает зеркала четырёх случайно выбранных узлов ростера по отдельному пути. ростер называет каждый хост один раз, поэтому граница действует и на хост, но только на одно написание: хост, доступный под несколькими именами или под именем и ip-адресом, получает по запросу на каждый такой адрес за проход. соседа, чья запись закончилась вместе с его сертификатом, после этого спрашивают раз в минуту, пока узел не перезапустят. адреса это только ip-адреса и имена dns, а ответ считается, только если проверяется по якорю ростера.

выбор цепочки

список узлов клиента статический: обнаружения узлов нет, как нет и каталога, подписанного несколькими сторонами, который закрепил бы состав узлов. служебная ячейка установки ограничивает цепочку четырьмя хопами на c25519 и тремя на гост.
вход может не включить в зеркало ограниченное число узлов списка, по умолчанию один, а комплект, не прошедший проверку, идёт в счёт того же предела; цепочка выбирается среди оставшихся. подставной вход, исключивший честный узел, повышает вероятность того, что и выход окажется подставным.
узел, не отдающий свой дескриптор остальным, выбывает из их зеркал, и цепочку к нему они не продлевают. когда так поступает больше узлов, чем допускает клиент, его устраивают только зеркала молчащих узлов: при двух таких узлах из пяти и допуске в один узел каждая установленная цепочка входит через один из этих двух и кончается честным узлом. этот случай посчитан и проверен выборкой. больший допуск даёт подставному входу больше простора для выбора.
узел, который отказывает неугодным ему цепочкам или рвёт их, решает, какие цепочки выживут: клиент без сквозного слоя после сбоя завершается, при следующем запуске выбирает новую цепочку и сбоев не учитывает. этот выборочный отказ в обслуживании не предотвращается и не измеряется.
клиент -peer при конце цепочки не завершается, а пересобирает её через тот же вход: сначала ту же цепочку, а новые середины выбирает, только когда её установить нельзя, и не больше 2 раз за процесс. поэтому подставной вход, который закрывает каждую цепочку с честной серединой, добивается не больше 3 выборов середины. на стенде, при честном mailbox и двух подставных узлах среди остальных четырёх, середина-сообщник выходит с вероятностью 7/8 при подставном входе, который не включает в зеркало один честный узел, против 1/2 при одном выборе, а вместе с серединой вход узнаёт, каким mailbox пользуется клиент.
повторные выборы может вызывать и дальняя сторона: подставной mailbox, который оставляет без ответа каждую заявку через честную середину, получает середину-сообщника с вероятностью 19/27 при честном входе вместо 1/3, а середина видит вход, поэтому mailbox узнаёт вход своего клиента. оба значения проверены перебором всех исходов выбора.
граница действует на процесс. клиент, который 10 мин не может построить цепочку, завершается, и новый процесс выбирает новый вход с новым запасом и новую личность, которую надо знакомить заново. какие процессы выживают, решает тот же неизмеренный выборочный отказ в обслуживании.
сторожевых узлов нет: клиент без сквозного слоя выбирает вход заново для каждой цепочки, клиент -peer для каждого процесса, поэтому вероятность того, что хотя бы у одной цепочки и вход, и выход были подставными, растёт с каждым перезапуском клиента.
счётчики узла это точные суммы без идентификаторов цепочек, но при малом числе цепочек сумма описывает отдельные: на стенде с двумя клиентами число ячеек растёт именно у узлов их цепочек, а по счётчикам видны ещё входы и mailbox. это узнаёт всякий, кто читает вывод узла.

повтор и порядок ячеек

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

ограничения узла

соединение принимается или отклоняется до любого согласования ключей, и один адрес получает не больше своей доли каналов, рукопожатий и установок. при исчерпанном общем пределе узел отказывает в новых соединениях. это отказ в обслуживании; каждое место занято не дольше, чем до истечения его срока, времени простоя или срока жизни цепочки.
узел не отличает другой узел от клиента, потому что ответчик канала не аутентифицирует инициатора, а входом может быть любой узел, поэтому каждый узел держит ограничения на один адрес. на среднем и выходном узле каждая цепочка, прошедшая через один узел, приходит с одного адреса этого узла, и такие цепочки делят запас одного адреса: один клиент может израсходовать его за всех остальных клиентов, чьи цепочки проходят те же два узла в том же порядке.
один адрес может держать занятыми сразу несколько таких упорядоченных пар узлов. его запас считается на каждом узле отдельно, а его собственная цепочка проходит до трёх пар на c25519 и до двух на гост: в сети без других клиентов это через n входов до 3n упорядоченных пар на c25519 и до 2n на гост, 15 и 10 из 20 при пяти узлах. цепочка, проходящая занятую пару, срывается на установке: клиент без сквозного слоя завершается и выбирает другую, а у клиента -peer две такие цепочки подряд дают один из двух его повторных выборов, поэтому такой адрес влияет на то, какие цепочки выживут. владелец ключа уц, чьи подставные узлы есть в ростере, может держать занятыми пары между честными узлами и оставлять свободными пары через свои узлы. во что это обходится и насколько поднимает долю выживших цепочек, которые держат его узлы, не измерено; измерение в плане.
на стенде порт ячеек принимает соединения только от подов клиента и узлов, если сетевой плагин кластера применяет сетевые политики. на стенде два клиента по одной цепочке, поэтому общий запас там не исчерпывается.

тайминг

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

отрицаемость

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

контейнер клиента

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

границы применимости модель угроз