Посоветуйте криптостойкий метод расширения общего секрета, исключающий man-in-the-middle attack

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

> дыры в ссш задолбали,

Какие у вас были проблемы с дырами в ssh?

> да и не нужна несимметричная криптуха для логина на сервер

Простейший варинт handshake (так называется то, что вы хотите) заключается в том, что одна из сторон генерирует ключ для симметричного зашифрования канала данных, зашифровывает его открытым ключом другой стороны и передаёт его другой стороне, где он расшифровывается закрытым ключом, которого никто не знает, что и исключает перехват сессионного ключа злоумышленником. Но для этого как раз необходима несимметричная криптография.

Так же курите алгоритм Диффи-Хеллмана.

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

> Но для этого как раз необходима несимметричная криптография.

Читай внимательно: в начале обе стороны имеют общую инфу, оба -- клиент и сервер знают короткий логин и короткий пароль.

Похоже, тут без несимметричной криптографии можно обойтись.

> и подпись авторити вышестоящего уровня

Это мне не нужно тоже.

На последующие предложения осилить Д-Х буду отвечать: идите в жопу, Д-Х я осилил уже 15 лет назад.

Что я примерно предполагаю увидеть:

1. Клиент берет длинный рандом и, зашифровав его паролем, шлет серверу.

2. Сервер берет другой длинный рандом и, зашифровав его паролем, шлет клиенту.

3. Оба комбинируют эти два рандома (например, записывают друг за другом) и юзают как ключ АЕS для сессии.

Однако тут есть сомнения, ибо возможны атаки.

Пароль предполагается коротким (например, 10^9 возможных паролей). Сессий предполагается немного (например, 10 000 на 1 пароль). Инфы через сессию предполагается прокачать много.

> Д-Х я осилил уже 15 лет назад.

Судя по продемонстрированным знаниям ты абсолютный ноль не только в этом но и в программировании. Я бы порекомендовал тебе почитать любую книжку/статью по openssl,(или хотя бы доки по тому как ssh работает) но тебе понты не позволят это сделать.

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

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

кстати, на всякий случай:

man skey

http://en.wikipedia.org/wiki/One-time_password

Спасибо, посмеялся.

это стандартный способ "улучшения" маленьких паролей. В каком-то PKCS прописан.

> 1. Клиент берет длинный рандом и, зашифровав его паролем, шлет серверу.

> 2. Сервер берет другой длинный рандом и, зашифровав его паролем, шлет клиенту.

> 3. Оба комбинируют эти два рандома (например, записывают друг за другом) и юзают как ключ АЕS для сессии.

Эм.. И каким образом это защищает от атаки man-in-the-middle?

Вдогонку:

> Судя по продемонстрированным знаниям ты абсолютный ноль

+1

Можно симметричное шифрование с тройной пересылкой попробовать --- первый шифрует своим ключом, второй шифрует своим, первый расшифровывает своим, второй расшифровывает своим. Естественно, два ключа должны быть разные.

> Можно симметричное шифрование с тройной пересылкой попробовать --- первый шифрует своим ключом, второй шифрует своим, первый расшифровывает своим, второй расшифровывает своим. Естественно, два ключа должны быть разные.

И где взять эти ключи?

>(З.Ы. дыры в ссш задолбали, да и не нужна несимметричная криптуха для логина на сервер.)

поставь его на нестандартный порт и прикройся knock'ом.

> Так же курите алгоритм Диффи-Хеллмана.

анонимус, я тебя вычислил -- это тоже был ты: http://www.linux.org.ru/view-message.jsp?msgid=3288951#3289048

>И где взять эти ключи?

из /dev/random или более случайного источника и побитовый XOR с этим. Только ключ надо сохранять между первым и вторым шифрованием.

> анонимус, я тебя вычислил -- это тоже был ты

Да, это был я, только другой.

> из /dev/random или более случайного источника и побитовый XOR с этим

И как ты себе это всё представляешь? Первый зашифровал с ключом из /dev/random, переслал, и второй расшифровал опять с помощью /dev/random?? )))

нет, второй расшифрует с помощью /dev/urandom... ты разве не знал об этих встроенных механизмах шифрования в *nix системах? ;)

xD

> ты разве не знал об этих встроенных механизмах шифрования в *nix системах? ;)

ч0рд... )

/me побежал учить матчасть

:D :D :D

+1

Если так хочется потрахаться: http://en.wikipedia.org/wiki/Needham-Schroeder_protocol http://en.wikipedia.org/wiki/Kerberos_(protocol) http://en.wikipedia.org/wiki/PBKDF2

> Если так хочется потрахаться

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

> клиент и сервер знают короткий логин и короткий пароль

> 1. Аутентификация клиента сервером.

> 2. Аутентификация сервера клиентом.

не вполне совместимо :) для однозначной аутенфикации для КАЖДОГО каждого объекта должны быть некие УНИКАЛЬНЫЕ аттрибуты. В данном случае - логин/пароль или проще говоря секретный ключ.

на входе : K1,K2 - секретные ключи объектов 1 и 2,
Z(K,N) - шифруем N на ключе K
U(K,S) - дешифруем N на ключе K
R - достаточно случайные блоки (хоть с /dev/random)

объект 1 генерирует и передаёт S1=Z(K2,R1)

объект 2 принимает и вычисляет R1=U(K2,S1)

объект 2 генерирует и передаёт S2=Z(R1,K1)

объект 1 принимает и проверяет K1==U(R1,S2)

объект 1 генерирует и передаёт S3=Z(R1,K2)

объект 2 принимает и проверяет K2==U(R1,S3)

далее обмен ведётся на сгенерированном на первом шаге ключе R1

оба объекта убедились, что разделяют общий секрет K1K2 и сгенерировали сессионный ключ R1, При этом открытые данные по каналу не передавались

минусы - не стоек если возможно вскрытие на основе пары Z(A,B) Z(B,A)
если злыдню известен K2 вскрывается на первом шаге. Плюс - работает доже если скомпрометирован K1

>И как ты себе это всё представляешь? Первый зашифровал с ключом из /dev/random, переслал, и второй расшифровал опять с помощью /dev/random?? )))

Первый сгенерил случайную последовательность A и посчитал X XOR A A сохранил; то, что посчитал отправил второму Второй сгенерил случайную последовательность B и посчитал X XOR A XOR B B сохранил; то, что посчитал отправил первому Первый посчитал X XOR A XOR B XOR A = X XOR B и отправил второму Второй посчитал X XOR B XOR B = X

В таком виде, как выше написано, хоть X нигде не ходит в открытом виде, но легко находится.

блин, но man in the middle то тоже X легко находит

> И где взять эти ключи?

В условии задачи сказано, что общий секрет __уже__ имеется, только короткий.

> Эм.. И каким образом это защищает от атаки man-in-the-middle?

Имея сессию это уже элементарно. Ну хотя бы клиент шлет через сессию 24358230453+968239435, а сервер складывает и отвечает. Если пришел бред -- значит трафик на проходе искажался.

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

> блин, но man in the middle то тоже X легко находит

xor вообще вещь опасная :-)

ну так нормальные алгоритмы шифрования несколько сложнее xor работают.

> объект 1 генерирует и передаёт S1=Z(K2,R1)

Не подходит.

Если К2 -- короткий (см. условие) и трафик, зашифрованный R1 хотя бы чуть-чуть избыточный, то можно подслушать первый пакет S1 и просто *перебрать* все К2, генеря R1 и пытаясь им расшифровать трафик.

> Он не хочет трахаться. Он хочет, чтоб ключи передавались прямо в мозг с использованием libastral.

Дислексия, да? В условии написано -- есть общий секрет. Только маленький (1 000 000 000 вариантов).

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

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

Хотя в условии не было сказано, но предполагалось, что все алгоритмы взломщику известны. Это практически всегда предполагается для анализа алгоритмов.

> Опять ломается элементарно. Взломщик перебирает все 1Г первоначальных ключаей, для каждого вычисляет те самые "несколько сотен длинных ключей" и пытается ими расшифровать трафик.

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

Ну что вы такое предлагаете. Его же и Диффи-Хеллмана алгоритм не устраивает. Чем-то..

Где-то читал примерно такой вариант: нужно взять публичный генератор большого количества случайностей. Очень большого. И сохранять из него какую-то часть для ключей шифрования в соответствии с общим секретом. Возможно удастся заменить маленькую стоимость перебора секрета большой стоимостью хранения "истории" потока случайностей.

Но, похоже, гораздо проще увеличить "пароль".