Привет прогерам! Вопросец по криптографии возник, наверняка кто-то баловался — помогите пожалуйста с конкретикой.

Есть т.н. "схема Шнорра" для авторизации без пересылки пароля . Звучит круто и хотелось бы её применить.
Но как вы сами видите, педивикия — чистая "галиматья на математическом" тупо для формального изложения материала.
В целом-то я их сикарашки понимаю,
но алгоритмически это просто белиберда. Типа "Выбирается простое число P" — ну да, блин, мне же в C# надо просто написать "GimmeSimpleP()"!
Умом-то я понимаю, что там буквально три функции вызвать(причём наверняка в .NET FW они есть) и всё заработает, но вот кого и куда посылать — непонятно.

Я немного игрался с эллиптическими кривыми и даже могу сгенерить ключи/проверить подпись; чую, это почти то, что нужно.
Итак, без "выбирается число" — как это на сишарпном?

Здравствуйте, Baiker, Вы писали:

B>Я немного игрался с эллиптическими кривыми и даже могу сгенерить ключи/проверить подпись; чую, это почти то, что нужно.
B>Итак, без "выбирается число" — как это на сишарпном?

Видимо как-то так:
https://github.com/p1zza/Scheme_Klauss_Shnorr

А на сиплюсплюсном как-то так:
https://github.com/TheIncred1ble/Schnorr_Authenticate

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

Здравствуйте, VladD2, Вы писали:

VD>Видимо как-то так:
VD>https://github.com/p1zza/Scheme_Klauss_Shnorr

Выглядит крайне подозрительно. Начиная с использования double для дискретки...

Здравствуйте, Sinclair, Вы писали:

S>Выглядит крайне подозрительно. Начиная с использования double для дискретки...

Мопед не мой. ©

Наверно какой-нить математик решил блеснуть талантом.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Baiker, Вы писали:

B>>Я немного игрался с эллиптическими кривыми и даже могу сгенерить ключи/проверить подпись; чую, это почти то, что нужно.
B>>Итак, без "выбирается число" — как это на сишарпном?

VD>Видимо как-то так:
VD>https://github.com/p1zza/Scheme_Klauss_Shnorr

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

VD>Вот только смысл во всём этом, если это все ломается при получении доступа к закрытому ключу. Двойная аутентификация решает проблему лучше.

Да всё на свете ломается! То на квантовом компе расшифруют, то в середину залезут (MitM)
Тут всё зависит от задач и ценности данных.
Моя задача достаточно проста — авторизация работников на внутреннем сервере. И даже если предположить полную лояльность людей, нельзя допускать, чтобы какой-нть "офисный гость" проснифал трафик и ушёл с паролями.
Отдельный затык в том, что я не могу хранить приватный ключ — люди запросто могут менять компы между собой. Так что буду думать в сторону SRP6.

Двойная а. — согласен, надёжно, но слишком геморно для внутреннего продукта. Пароль — максимум, что они готовы вводить.

Здравствуйте, Baiker, Вы писали:

B>Моя задача достаточно проста — авторизация работников на внутреннем сервере. И даже если предположить полную лояльность людей, нельзя допускать, чтобы какой-нть "офисный гость" проснифал трафик и ушёл с паролями.

Для защиты от сниффа используют шифрование канала. К примеру https.

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, Baiker, Вы писали:

B>>Моя задача достаточно проста — авторизация работников на внутреннем сервере. И даже если предположить полную лояльность людей, нельзя допускать, чтобы какой-нть "офисный гость" проснифал трафик и ушёл с паролями.

Z>Для защиты от сниффа используют шифрование канала. К примеру https.

...что сразу же приводит либо к покупке сертификата (нафик никому не нужного), либо генерить "девелоперский сертификат", который (вместе с тестовым CA) придётся ставить каждому.
Тут по факту "секрет" только в паролях, сами данные — никтому не нужный шлак.

Здравствуйте, Baiker, Вы писали:

B>...что сразу же приводит либо к покупке сертификата (нафик никому не нужного),

Сертификат стоит на порядки дешевле разработки и поддержки велосипедов.

Здравствуйте, Baiker, Вы писали:

B>...что сразу же приводит либо к покупке сертификата
1. Let's encrypt раздают сертификаты задаром
B>(нафик никому не нужного),
Ну почему же "не нужного". Нужного. Инфраструктура PKI придумана не просто так. В ней решены все задачи, которые перед вами стоят (включая те, о которых вы не подумали), и те, которые перед вами могут встать в будущем.
B> либо генерить "девелоперский сертификат", который (вместе с тестовым CA) придётся ставить каждому
Нет такого понятия "девелоперский сертификат". Весь вопрос в том, откуда берётся цепочка доверия. Если вас беспокоит публичная инфраструктура — делаете свой "корневой" сертификат, его публичный ключ вшиваете в тот софт, который собираетесь распространять, и подписываете все временные сертификаты этим корневым.
Это всё ещё на порядок дешевле, чем изобретать и "ставить всем" свою собственную схему шифрования.