KP
(До сих пор удивляюсь, что WPA3 его не взяли, а придумали свой собственный, dragonfly — и предсказуемо огребли dragonblood ещё до релиза)
Size: a a a
2020 February 03
NL
Хмм. Мой вариает не выглядит "сильно дырявым" на первый взгляд?
KP
Хмм. Мой вариает не выглядит "сильно дырявым" на первый взгляд?
Зависит от модели угрозы
KP
Есть ли активные атакующие, или только пассивные, одноразовая ли это история, или возможны раунды и так далее
KP
Собственно, все проблемы всегда вот тут, на стыках текстур, бывают
NL
есть активный mitm, k_i меняется с каждым соединением, атакующий не обладает возможностью за разумное время ломать sha256
KP
есть активный mitm, k_i меняется с каждым соединением, атакующий не обладает возможностью за разумное время ломать sha256
Если есть активный mitm то пиздец.
Или откуда у тебя изначальный nonce берётся?
Или откуда у тебя изначальный nonce берётся?
NL
у клиента и сервера nonce генерится из рандома и хэшится с солью. Полученый хэш и есть k_i
NL
ирл есть что-нибудь, устойчивое к активному mitm?
KP
у клиента и сервера nonce генерится из рандома и хэшится с солью. Полученый хэш и есть k_i
Не понял, k_i — это не общий ключ, он разный для клиента и для сервера?
Как тогда север знает, какой k_i у клиента и наоборот?
Как тогда север знает, какой k_i у клиента и наоборот?
KP
ирл есть что-нибудь, устойчивое к активному mitm?
Одна из ключевых проблем дизайна криптосистем, установка доверия.
Ты не модешь доверие просто "создать" в цифре, увы.
Но ты можешь его умело перелить из офлайна.
Самое тупое — обменяться ключами в виде оффлайновых объектов, типа как у QubesOS на всех футболках слепок их релиз-ключа
Ты не модешь доверие просто "создать" в цифре, увы.
Но ты можешь его умело перелить из офлайна.
Самое тупое — обменяться ключами в виде оффлайновых объектов, типа как у QubesOS на всех футболках слепок их релиз-ключа
NL
клиент шлет пару username, xor(hashed_key, hash(nonce)), сервер ищет у себя в базе по username сохраненный заранее hashed_key, получает hash(nonce) как результат xor(hashed_key, message)
NL
дыра тут в том, что mitm может захватить пакет от клиента, и позже переслать его серверу, представившись клиентом, это да
KP
Одна из ключевых проблем дизайна криптосистем, установка доверия.
Ты не модешь доверие просто "создать" в цифре, увы.
Но ты можешь его умело перелить из офлайна.
Самое тупое — обменяться ключами в виде оффлайновых объектов, типа как у QubesOS на всех футболках слепок их релиз-ключа
Ты не модешь доверие просто "создать" в цифре, увы.
Но ты можешь его умело перелить из офлайна.
Самое тупое — обменяться ключами в виде оффлайновых объектов, типа как у QubesOS на всех футболках слепок их релиз-ключа
Более хитрое — черпать доверие из экономики, скажем на PoS блокчейне доверие переходит в цифру за счёт того что стейк-токены имеют ценность (и тут сразу возникает nothing at stake-атака и тд)
KP
клиент шлет пару username, xor(hashed_key, hash(nonce)), сервер ищет у себя в базе по username сохраненный заранее hashed_key, получает hash(nonce) как результат xor(hashed_key, message)
А, ну вот у тебя есть заранее
KP
У этого заранее нет митма?
NL
нет, это как было сказано, происходит физически
NL
а, не было сказано. Каюсь.
KP
дыра тут в том, что mitm может захватить пакет от клиента, и позже переслать его серверу, представившись клиентом, это да
Не только.
Митм, скажем, может ксорить пролетающие мимо пакеты.
И в итоге на сервере будет не A, а AxorZ получаться, где Z полностью под контролем атакующего
Митм, скажем, может ксорить пролетающие мимо пакеты.
И в итоге на сервере будет не A, а AxorZ получаться, где Z полностью под контролем атакующего
KP
(То есть тебе ещё нужна аутентификация как минимум, HMAC там)