Comments 11
созданная офицером безопасности FreeBSD Колином Персивалем
Товарищи офицеры!
Что если сервер или клиент проигнорирует требование a>0 / b>0? Как второй может это распознать и предотвратить?
И что-то до меня не доходит смысл шага 7. Вообще обмен 6+7 разве не должен идти уже используя общий вычисленный S ?
Если b = 0, то Алиса получит от боба точку О(нейтральный элемент группы). В разных реализациях О может фигурировать как (X:Z) = (1:0) или (0:1:0) — в зависимости от выбранного представления (в проектных координатах).
В этом случае Алисе не стоит посылать бобу точку А, ибо она и будет ключом сессии S, передаваемым в открытом виде.
Если a = 0 то Алиса пошлет Бобу точку A = [0x]G+[x]B = O + [x]B = [xb]G. Боб вычтет [b]V = [bx]G из точки Алисы и получит О.
И ключом сессии будет точка О. Что не есть хорошо.
Помимо этого, обоим стоит выбирать a и b большими (например, 128 бит). Для маленьких a и b решение задачи дискретного логарифма решается тупо подбором. Хотя Алиса умножает a на 128-битный x...
В п. 7 (на самом деле это 3 пакет сетевого взаимодействия) Алиса доказывает Бобу, что она выработала такой же ключ сессии, что и Боб. Это калька с оригинального протокола.
И далее Алиса доказывает Бобу своим m2, что тоже "в теме"
В оригинальном проверки на получение нулевых точек помнится были -- вероятно, их стоит встроить и здесь, чтоб оба (и А и Б) могли быть уверены в качестве общения и что посредник не понизил сложность за счет маленьких a и b, или не пытался представиться сервером чтобы выудить фактический секрет.
Хм... Пожалуй, играясь серверным числом получить x всё равно не получится. То есть максимум -- получить слабую сессию, играя на руку посреднику, если к серверу пришли кому-надо и сказали сделать так, чтоб незаметно но можно было снимать сливки
Спасибо за Вам ценное замечание. Действительно, Алиса, никак не застрахована от ситуаций, когда Боб в сговоре с Меллори и генерирует "слабые" точки. Боб может генерировать слабые точки и в результате ошибки программиста, или генератор случайных чисел использовать плохой. Тогда действительно, Меллори, сохранив дамп взаимодействия Алисы и Боба, сможет извлечь ключ сессии, подобрав секретный параметр b перебором.
К сожалению (или счастью) нет способов быстрой и достоверной проверки, что за точкой X = [n]G, прячется малое n. Если бы такой способ был, никакой криптографии на эллиптических кривых построить не удалось бы.
В своих частных экспериментах я заметил, что точки с малыми скалярами, группируются ближе к началу координат. Но это работает только в поле вещественных чисел и при "удачно" выбранной базовой точке.
Однако, хороший протокол я предложил, с закладочкой) Всякие АНБ одобряют)
Или генератор уровня "используйте одно из чисел 100500 или 10005000". Алиса и это проверить не может.
Насколько помню, соль, выданная клиентом, при регистрации, использовалась для защиты от этого в оригинальном SRP.
Можно ли добавить клиентскую соль здесь? 🤔
Нет, SRP просто никак не защищает от ошибки боба. Мы даже не знаем, боб ли это. 😂
Да, к сожалению, алиса не знает с кем общается: с бобом или кем-то другим. это существенный недостаток схемы. как это исправить - путей пока не вижу.
я пробовал добавлять бобу его публичный верификатор, при помощи которого аналогично алиса могла бы 100% верифицировать боба. но получилось не слишком красиво. и все равно проблематику неудачно выбранных a/b это не решает
Вообще обмен 6+7 разве не должен идти уже используя общий вычисленный S ?
ну формально точка S (из которой рождается k) на этом этапе используется. Функция HMAC_k - требует знание правильного ключа. Остальные параметры (A, B, i, V) открытые и всем известны (включая всяких Меллори). посылая m1 и m2 стороны демонстрируют друг другу, что пришли к общему знаменателю. Что делать дальше с общим ключом сессии - протокол не определяет. Можно, например, подписывать ajax-запросы той же hmac...
Реализация протокола SRP на эллиптических кривых