два клиента переписываются через mailbox под сквозным слоем
на стенде теперь два клиента, которые переписываются под сквозным слоем, рукопожатием kk и хэш-ратчетом, через mailbox на последнем узле своих цепочек. mailbox хранит записи, которые не может прочитать, а офлайн-отрицаемость показана подделкой.
до сих пор последний узел цепочки читал сообщение и возвращал его обратно. теперь два клиента переписываются друг с другом, а последний узел хранит только то, что не может прочитать. числа на странице исследования те же, это прежняя предварительная серия: она снята на эхо-топологии, и разговор двух клиентов в неё не входит.
два клиента на стенде
на стенде пять узлов и два клиента, client-a и client-b, в режиме -peer. оба держат свои
очереди в mailbox на relay-5: client-a отправляет сообщение раз в 2 с, client-b отвечает на
каждое. клиент случайно выбирает вход среди остальных четырёх узлов, проверяет комплекты всех узлов
списка и выбирает середину среди проверенных; его цепочка заканчивается на mailbox.
при запуске каждый клиент печатает только хэш своей карточки контакта. сама карточка, то есть набор, адрес mailbox, очередь и статический ключ, отдаётся на админ-порту на loopback. скрипт забирает каждую карточку через port-forward, сверяет её с хэшем в журнале того же контейнера и передаёт другому клиенту, а тот закрепляет её на всё время жизни процесса. клиент, которому после закрепления предлагают другую карточку, отвергает её и останавливается, пока оператор его не перезапустит.
рукопожатие kk и хэш-ратчет
оба клиента знают статические ключи друг друга по карточкам ещё до разговора, поэтому рукопожатие идёт по шаблону kk: две записи, в каждой свежий эфемерный ключ, и каждая подмешивает согласования с ключами собеседника. после него у каждого направления своя цепочка ключей. каждый шаг выводит ключ одной записи и следующий ключ цепочки и стирает предыдущий, поэтому ключ, взятый сейчас, не открывает прошлых записей. каждая операция идёт через тот же криптографический интерфейс, что и вся система, на обоих наборах.
узлы этот слой не открывают: для них запись это часть содержимого ячейки. запись, изменённая mailbox или узлом, не открывается у получателя и отбрасывается, а копия или опоздавшая запись ничего в сессии не меняют.
mailbox
последний узел работает как mailbox. он держит очереди записей только в памяти и отвечает на каждую заявку ответом постоянной длины. на каждом тике клиент шлёт заявку, которая забирает запись из его очереди; с покрывающими put, а они включены по умолчанию, заявка ещё и кладёт запись в очередь собеседника, пустую, если сообщения нет, и mailbox не отличает фиктивную запись от настоящей.
что mailbox всё же узнаёт:
- обе цепочки разговора, связанные через очереди: по каждой цепочке право забора в открытом виде, очередь put, время каждой заявки, исход put, вид и номер записи и копии одной записи.
- момент рукопожатия, потому что до сессии put несут только записи рукопожатия.
- вместе с наблюдателем каналов обоих входов, возможно, кто с кем говорит. насколько это удаётся, пока не измерено.
выход клиента закреплён на его mailbox, поэтому подставной mailbox есть в каждом разговоре своих клиентов.
офлайн-отрицаемость, показанная подделкой
рукопожатие состоит из одних согласований ключей, ключа подписи у клиента нет. получатель уверен в авторе, но может вычислить каждое значение транскрипта своими ключами, поэтому может построить транскрипт с теми же сообщениями, распределённый так же, как настоящий. транскрипт даже вместе с закрытыми ключами получателя не доказывает третьей стороне, что отправитель участвовал.
лаборатория показывает это рабочим кодом сессии. cmd/lab -set deny запускается на обоих наборах
с получателем в обеих ролях: получатель подделывает разговор, а настоящий и поддельный транскрипты
проходят одну проверку и имеют одинаковую структуру. подделка, сделанная со свежим ключом вместо
ключа получателя, не проходит проверку на первой же записи. обёртка над криптопровайдером видит
закрытый ключ отправителя в настоящей сессии и не видит его ни в подделке, ни в проверке. это
демонстрация на конкретных ключах, а не измерение.
утверждение кончается на засвидетельствованном транскрипте: mailbox или наблюдатель канала отправителя в сговоре с получателем хранит независимую запись того, кто отправил шифротексты. онлайн-отрицаемость, против судьи, который во время сессии действует вместе с получателем, и отрицаемость метаданных не заявляются.
ограниченная пересборка
клиент в режиме -peer не завершается, когда кончается его цепочка. он снова устанавливает ту же
цепочку через тот же вход, а новые середины выбирает, только когда её установить нельзя, и не
больше двух раз за процесс. поэтому подставной вход, который закрывает цепочки снова и снова,
добивается не больше трёх выборов середины, первого и двух повторных, а дальше может только
остановить разговор, что ему доступно и так. граница действует на процесс: клиент, который 10 мин
не может построить цепочку, завершается, а новый процесс это новая личность, которую надо знакомить
заново.
как это проверено
- золотые векторы рукопожатия kk на обоих наборах.
- тесты сквозного слоя: изменённая или чужая запись не открывается, копия и опоздавшая запись отбрасываются, и ни одна из них не меняет сессию.
- тесты разговора через узлы с mailbox на выходе и два процесса клиента, переписывающиеся через mailbox.
- на стенде kind: сообщение туда и обратно между
client-aиclient-bчерезrelay-5, а карточка чужого ключа и затем прежняя карточка отвергаются без перезапуска клиента.
что не сделано
- при покрывающих put накопившийся хвост не разбирается: каждый пропущенный стороной тик оставляет в её очереди ещё одну запись собеседника, и каждая следующая запись ждёт дольше, до глубины очереди (#148).
- запись, потерянная в ответе на забор, снова не кладётся. если это первая запись инициатора после рукопожатия, ответчик не отправляет настоящих сообщений, пока не откроется следующая запись инициатора, и попросить потерянную не может (#149).
- восстановления после компрометации нет: у ратчета нет шага диффи-хеллмана (#136).
- mailbox видит вид, номер и копии записи (#137), а формальной модели рукопожатия и утверждения об отрицаемости нет (#138).
- один контакт на процесс, а личность и закрепление живут только в памяти процесса: перезапуск означает новое знакомство. постоянное хранение придёт с контейнером клиента (#20), цепочки и очереди на каждый контакт в плане (#96).
- знакомство на стенде доверяет api кластера (#90).
дальше
контейнер клиента с двумя томами (#20), топология измерения сквозного пути, два входа и mailbox (#47), и блоки атак: извлечение ключей из дампов памяти (#24), компрометация узлов (#117) и активный нарушитель с временной меткой в потоке (#116).
полный список на странице границ и в границах применимости, слой и аргумент об отрицаемости в документе о криптографии, угрозы и меры в модели угроз.