новости

ключи привязаны к транскрипту, набору и версии схемы

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

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

каждый ключ зависит от всего обмена

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

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

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

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

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

провод тот же, версии не смешиваются

привязка не занимает ни байта: ячейка по-прежнему 512 байт, служебная ячейка установки по-прежнему вмещает четыре хопа на c25519 и три на гост, а в приветствии, ответе и кадрах канала для неё нет полей.

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

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

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

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

чего это не исправляет

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

дальше в плане по-прежнему клиент-получатель со сквозным слоем и отрицаемая аутентификация между клиентами.

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