[#] IDEC identity
Difrex(mobile)(tavern,23) — All
2018-04-21 10:40:14

== 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 постараюсь выложить в ближайшее время.
Обсудим?

[#] Re: IDEC identity
shaos(tavern,34) — Difrex(mobile)
2021-12-22 09:14:47

По поводу общих поинтов - 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 если секретный ключ утёк или утрачен, а узел с которого пользователь изначально идентифицировался более не существует (т.е. пользователь не может перепослать новый публичный ключ со старого узла, а должен сделать это с другого узла где сисоп каким-то образом должен удостовериться, что это тот же самый человек, что идентифицировался ранее со старого более недоступного узла - например изначально вместе с публичным ключом должен был быть распространён адрес емейл, который ни в коме случае не должен быть скомпрометирован или что-то типа этого).