maytonЯ не до конца понял что разрабатывает Дима. Но RSA стандартизирован и имеет фиксированные
разрядности алгоритмов и ключей.

Хотя если брать математическое описание алгоритма - то его можно адаптировать под любые разрядности.
Главное чтоб наши комьютеры не захлебнулись.
RSA как по учебнику. Алгоритм с википедии, он же в каментах кода 21776202

Единственное ограничение - вписаться в 32 бита, чтобы использовать стандартные целые типы.

Dimitry SibiryakovDima TЭто-то тут при чем?
Это тут при том, что авторизация не зависит от того кем она проводится. Если сервер верит Алисе на слово, а Боб доверяет серверу, то Боб может спокойно верить Алисе на слово и степень безопасности от этого не изменится. Получит ли Боб ключ Алисы от сервера или от Алисы непосредственно - совершенно всё равно.

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

PS: Эх, а я-то считал себя безалаберным используя для идентификации 381-битные ключи...
Еще раз - давай оставим в стороне тему создания новых учеток. Я ее не поднимал. Тема сильно зависит от области применения.

Обычно эта задача решается так что с улицы никого не пускают, а пускают из другой системы, где пользователь уже присутствует.
Если ты банк, то сначала пакет документов в ответ учетка. Если мессенджер, то давай номер телефона и получи код в смс-ке и т.д. и т.п.
У меня эта тема уже порешана, учетки заводятся не без участия администраторов. Проблем с нездоровой активностью фантомных учеток у меня нет и не было.
maytonКак я понял сеть - централизованная. Есть сервер но он иногда недоступен. Верно?
Верно, но при отсутствии сервера учетки могут обмениваться сообщениями, главное убедиться что тот кто пишет является тем за кого выдает. Это надо только при отсутствии сервера.

maytonDima Tпропущено...

Верно, но при отсутствии сервера учетки могут обмениваться сообщениями, главное убедиться что тот кто пишет является тем за кого выдает. Это надо только при отсутствии сервера.
Ок. Тогда следующий вопрос-предложение. Или мысль. Или statement.
Если я буду неправ - сообщи.

1) При установке софта в каждое приложение прошивается сертификат (публичный ключ + реквизиты) сервера.
2) Все клиенты обмениваются сообщениями по принципу все-со всеми. Протокол и формат сейчас не имеет значения. TCP/UDP, Jabber, JMS.
3) Имеет значение аутентичноть. Тоесть все сообщения от всех имеют отправителя. Например.


В данном случае в сети может существовать только 1 mayton.
4) Сообщения от лже-mayton должны
- игнорироваться?
- помечаться как непроверенные? Ненадёжные? Non-confident.
5) Любой контрагент может войти в сеть без сервера и (теоретически) начать писать другим
сообщения. Данный пункт является архитектурной проблемой и его надо как-то разрешить.
1. Клиент как-то получает логин/пароль. Нет смысла расписывать всю схему. Клиент - это конкретный пользователь конкретной копии БД, но не только. Есть еще роботы.
2. Верно.
3. Верно.
4. лже-mayton вообще не должен попасть в систему, т.е. если один mayton онлайн в системе, то второй не может залогинится.
5. Собственно это и есть проблема о которой топик. Я придумал как ее минимизировать 21771725 .

С другой стороны мне хочется понять насколько полезно неполноценное шифрование: в общем случае мой самодельный RSA32 ломается меньше чем за секунду (до написания в инете видел заявления что до суток продержится, но увы и ах, kealon(Ruslan) отрезвил), с другой стороны он нужен для редких случаев когда нет инета. Мой RSA32 может и дырявый насквозь, но если обеспечить получение открытого ключа только проверенными пользователями, то он вполне будет криптостоек, т.к. при прослушке зашифрованное не прочитать без ключей.

Заменил проверку на простое с Миллера-Рабина, на тупую проверку остатка от деления всех простых до sqrt(x). Стало быстрее в два раза. Наверно это особенность x32, на больших разрядностях такая проверка захлебнется.

Поделюсь немного своим жизненным опытом: на клиенте шифрование БД было, обмен с сервером был по HTTP (не HTTPS) с открытой передачей пароля по самодельному протоколу.

Конкуренты (их прога стояла там же где моя) не стали вникать в тонкости, а пошли сначала путем подмены DNS, т.е. в hosts на мои домены прописали свои шлюзы, где пытались анализировать трафик и рубить им не угодный, хотели скомпромитировать что у меня обмен не надежен. Не получилось. Затем просто за DDOS-или мой сервер.

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

PS Никому не навязываю свою точку зрения, т.к. всем начальство может задать вопрос "а может быть что шпиьон прочитает нашу переписку?", ответить "нет" можно дать только при применении общеизвестных и проверенных способов шифрования.

exp98Dima T, ведь в цикле вместо всех нечётных достаточно 6х+-1, т.е. 1/3 всех значений вместо половины.
Знаю, но для x32 это не сильно ускорит.

Dimitry SibiryakovDima Tлже-mayton вообще не должен попасть в систему, т.е. если один mayton онлайн в системе, то второй не может залогинится.
А если сервера нет, то как этот первый сможет залогиниться?
Никак. Но есть локалка, где 2-3 юзера заинтересованных в обмене друг с другом. Найти друг-друга элементарно через mailslot`ы. Дальше надо убедиться что они те за кого себя выдают, что и есть тема топика.

Dimitry SibiryakovDima TСобственно это и есть проблема о которой топик. Я придумал как ее минимизировать
А я предлагаю как её устранить на корню. При этом центральный сервер вообще можно выкинуть из картины за ненадобностью. Что и сделано у биткоина и прочих блокчейнов.
Не стоит исключение превращать в правило. Серверов я могу пачку поднять и наладить между ними репликацию и оповещение клиентов какие сервера доступны. Это неубиваемо и гораздо эффективней блокчейнов

Dimitry Sibiryakov, самое главное что по UDP не будет работать без сервера. Наты и брандмауры не пропустят.
Алиса спрашивает у сервера адрес Боба.
Сервер пишет Алисе адрес Боба и Бобу адрес Алисы .
Алиса и Боб начинают писать друг-другу и пробивают все наты и брандмауры.
Ключевое слово "друг-другу", без этого никак.