Алгоритм аутентификации

Я ему сразу написал:
Если между общающимися сторонами нет хотя бы аутентифицированного канала ..., то установить защищённое соединение невозможно.
Это и есть ответ. Видимо, ТС настолько ослеплён чувством собственного превосодства над жалкими людишками с этого форума, что даже не вдумывается в то, что ему отвечают.

А причем тут защищенное соединение к аутентификации? Challenge-responce он, например, не нужен.

ТСу хотелось бы увидеть конкретный протокол. Если он во что-то не вдумывается, то потому, что вместо конкретного ответа получает линк на простыни теоретических рассуждений. Которые с ходу понять тяжело, а вгрызаться – неизвестно, окупится ли это.

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

Что для этогог нужен именно пароль и никак иначе. Что только телепатией и можно понять. Просто странно сравнили как-то.

Ну это вполне приемлемый уровень телепатии :)

ТСу хотелось бы увидеть конкретный протокол. Если он во что-то не вдумывается, то потому, что вместо конкретного ответа получает линк на простыни теоретических рассуждений. Которые с ходу понять тяжело, а вгрызаться – неизвестно, окупится ли это.

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

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

Конкретный протокол можно обьяснить и на более простом уровне. Естественно, обычно придется кому-то на слово поверить, что он надежный, что поделаешь :)

Единственный способ установить надёжный канал между сторонами

Да что тебя заклинило? Речь идет об аутентификации. Для тебя процитирую пост выше

Challenge-responce он, например, не нужен.

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

Так вот я и спрашиваю, есть ли готовые протоколы, удовлетворяющие нужным характеристикам.

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

готовые протоколы, удовлетворяющие нужным характеристикам.

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

Да что тебя заклинило? Речь идет об аутентификации. Для тебя процитирую пост выше

Challenge-responce он, например, не нужен.

Что не нужен? Аутентифицированный канал? А первоначальный пароль в базу как попадает? Через libastral?

Ну может так, TC хочет ссылки на доверяемый протокол, где:

1. Есть пароли, но пользователю не нужно хранить ключи/сертификаты
2. Прослушивающей стороне сложно бы делать MITM (или на него всё-таки пофиг?)
3. Перехваченные данные сеанса было бы сложно использовать для брута паролей (по словарям, радужным таблицам, например).
4. Происходил обмен некими данными с сервером для аутентификации пользователя

Телепатия подсказывает опять же, что ТС видимо считает, что для установления аутентификации пользователю достаточно проверить сам сервер просто по IP-адресу, безо всяких сертификатов что-ли? И этого достаточно, чтобы начать аутентификацию уже с первого раза? Тогда не получиться п.2 (кроме недоумения в скобках).

Пусть ТС вопрос изложит связно (как принято в критериях проектирования протоколов — может даже сам вопрос отпадёт), что из него клещами-то вытаскивать к взаимному недоумению сторон?

Да что тебя заклинило? Речь идет об аутентификации.

Быдло-кун опять выходит на связь

Да что тебя заклинило? Речь идет об аутентификации.

Кто-то кого-то сильно недопонимает. Нет криптографии в протоколе — даже MITM'ить не надо, сразу сходу: resend-атаки, необнаружимые перехват и подмена сообщений (как со стороны сервера, так и клиента) внутри протокола, атакующий может выдавать себя как за сервер, так и за клиента... и всё тому прочее — полное раздолье для атакующего. Видимо, весь этот длинный список уязвимостей "выводится за рамки угрозы", и при этом ведутся пламенные речи про защиту от какого-то мифического MITM'ера. До MITM вам ещё дорасти надо.