subject: IDEC identity
21.04.2018 12:40
Difrex(mobile) (tavern,23)
== IDEC Identity
Я придумал несколько вариантов, как мы можем шарить юзеров. Думаю, что можно пообсуждать.
Общая тема этого - использование gpg для подтверждения и шифрования.
В чем приимущества gpg:
- есть везде
- прост, как полено
- сеть доверия
- можно передавать секреты без всяких ssl
Все будет рассматриваться на примере 3-х нод, операторы которых подняли некий абстрактный(реализации нет)
сервер авторизации, добавили и подписали ключи друг-друга.
Так же, мне кажется, что эта штука может служить генератором points.txt.
== Вариант № раз
Identity service предоставляет API, например, по ~POST /x/i/points~. Запрос поинтов с ноды должен быть в виде
plain text сообщения подписанного ключом запрашивающего и зашифрованного публичным ключом целевой ноды.
Структура сообщения мне предсталяется как-то так:
====
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
idec/ok
sync
-----BEGIN PGP SIGNATURE-----
SIGNATURE
-----END PGP SIGNATURE-----
====
Нода, получившая этот запрос, расшифровывает полученный запрос, проверяет валидность подписи и степень доверия
к ключу запрашивающего, после чего парсит запрос и отдает список поинтов в формате points.txt(подписынный и зашифрованный конечно же).
== Плюсы
1. Реализуется с минимумом усилий
2. Очень все просто
== Минусы
1. Все поинты со всех нод хранятся на каждой из нод
2. Если подламывают одну из нод, то утекают все поинты сети
== Вариант № два
Identity сервис предоставляет API для валидации и проталкивания(push) поинтов.
== Валидация
На ноду приходит запрос требующий authstring, но соответсвующего поинта на ноде не существует.
Итак, с этим authstring делаются запросы на ноды-соседи. Сообщение запроса примерно такое(шифрованное):
====
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
idec/ok
validate
authstring
-----BEGIN PGP SIGNATURE-----
SIGNATURE
-----END PGP SIGNATURE-----
====
Если поинт существует, то возвращается(подписано и шифровано) true, никнейм и адрес поинта. Нода открывает
сессию(например, на 12 часов) для этого поинта и хранит данные авторизации в памяти без записи в points.txt. Можно добавлять что-то в адрес, чтобы было видно, что это не родной поинт этой станции.
== Проталкивание
Отправляем строку поинта на станции-соседи. Принимающая сторона записывает поинта в points.txt. Все.
== Плюсы
- Безопасно, при подломе станции все поинты не утекут
== Минусы
- Чуть сложнее, чем вариант номер раз.
Мне видится предпочтительным второй вариант. PoC постараюсь выложить в ближайшее время.
Обсудим?
--------------------------------------------------------------------------------
subject: Re: IDEC identity
22.12.2021 12:14
shaos (tavern,34) => WXiV7YVq8Cje91XqIeCY
По поводу общих поинтов - PGP/GPG тяжеловат потому как многообразен - надо что-то одно широко известное выбрать и поддержать, но только цифровую подпись - без шифрования (которое в IDEC по-моему противопоказано), например можно взять отданный в общенародное достояние алгоритм Ed25519, существующий уже 10 лет и не подпадающий ни под какие патенты - в нём есть 32-байтовый публичный ключ и 64-байтовый секретный ключ (половина из которого это копия публичного ключа). Публичные ключи распространяются по всем узлам и клиентам (например посредством специальной эхо-конференции от имени пользователя как поинта своего узла) и идентифицируют глобальных пользователей (которые всё также могут оставаться поинтами на своих узлах). К сообщению подписанному цифровой подписью Ed25519 цепляется 64-байтовя signature (в строке тэгов после тэга signature/ например как 128-символьная шестнадцатиричная строка либо как 103-символьная строка в кодировке BASE32 либо как 86-символьная строка в кодировке BASE64URL, либо как 80-символьная строка в кодировке ASCII85 где символ / подменён скажем на | - хотя наверное надо таки использовать BASE64URL как родной способ кодирования бинарных данных в IDEC). Чтобы проверить валидность сообщения, по имени пользователя (msgfrom) берётся его публичный ключ (предварительно распространённый) и по телу сообщения проверяется его цифровая подпись, чтобы удостовериться, что письмо не подменено или не подписано поддельным ключом.
Подробнее про внедрения Ed25519: https://ianix.com/pub/ed25519-deployment.html
P.S. Правда надо ещё придумать процедуру восстановления identity если секретный ключ утёк или утрачен, а узел с которого пользователь изначально идентифицировался более не существует (т.е. пользователь не может перепослать новый публичный ключ со старого узла, а должен сделать это с другого узла где сисоп каким-то образом должен удостовериться, что это тот же самый человек, что идентифицировался ранее со старого более недоступного узла - например изначально вместе с публичным ключом должен был быть распространён адрес емейл, который ни в коме случае не должен быть скомпрометирован или что-то типа этого).
--------------------------------------------------------------------------------