Я планирую написать поддержку ключей Ed25519 в кодах i8080A (с возможностью работы на Z80), но начну с хешей RIPEMD-160 и аутентификации HMAC-RIPEMD-160-96 - это всё будет основой моей сети ретромашин Sprinternet, за транспорт в которой будет отвечать протокол ii :)

Думаю, уже нигде.

А всё - нашёл. Ну главное что сам хэш тот же:

def hsh(s,l=20):
    a = base64.urlsafe_b64encode(hashlib.sha256(s).digest())
    a = a.decode('utf-8')
    a = a.replace('-', 'A').replace('_', 'z')[:l]
    return a

По идее это у меня может пойти в категорию KINDA и подсветится жёлтым цветом как частично сходящееся...

ahamai> Спецификация, в смысле. В сети кризис контента а не кризис безопасности. И я не понимаю смысла цепляться за ценность аккаунта, я даже когда имя меняю, всем понятно, что это я пишу.

Да. А еще для ключей нужна криптография. И это сразу опустит порог вхождения в написание клиента/сервера и список поддерживаемых машин (тут же есть любители писать с старых компов xD)

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

ahamai> point.py. потом был целый квест, где надо было убежать из лап интернета в ii :) и только потом приделал простую регистрацию. приделал, даже не проверив, как она работает :) для нас приход нового юзера уже праздник.

Где можно найти этот квест? Интересно почитать

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

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

Я не понимаю, зачем это вообще для сети с девятью калеками? :) Нужно привлекать народ писать серверы и клиенты, для этого регистрация должна быть максимально простой. А так, юзер или поинтит на нужной станции, или сам делает свою ноду, так, как ему больше нравится.

> А когда все пишут со всех, то непонятно чей вообще пойнт и с кого вообще спрашивать.

Ну эту идеологию можно оставить - пользователь изначально регается на какой-то ноде и её сисоп за него как бы «отвечает», однако пользователь генерирует пару секретный ключ / открытый ключ, публикует свой открытый коюч через своего сисопа и начинает писать откуда угодно, однако если он накосчил, то его сисоп отзывает его открытый ключ (всё это делается через специальную эху) и юзер теряет способность писать откуда угодно - в общем как-то так…

В смысле, это разные сущности, для простоты понимания, для примера были варианты где регцентр и нода разные сайты, и где регцентр и нода это один сайт.

point.py. потом был целый квест, где надо было убежать из лап интернета в ii :) и только потом приделал простую регистрацию. приделал, даже не проверив, как она работает :) для нас приход нового юзера уже праздник.

Ненадо регцентры - зачем регцентры? У нас децентрализованная структура - каждый сисоп работает как регцентр :)

Изначально вообще регистрации не было. Только запуск point.txt на сервере, юзер оставлял заявку и обратную связь и небольшой сопроводительный текст, я принимал. Пойнт привязан к ноду - это фидошное, и это указывает на точку ответственности. А когда все пишут со всех, то непонятно чей вообще пойнт и с кого вообще спрашивать.

> Хотелось бы, чтобы юзеры стали глобальными - чтобы могли писать в сеть откуда угодно, а не только с той ноды, где они поинты

Такое было в elp, регцентр отдельно, станции отдельно, на станциях хранятся публичные ключи регцентров. Не понял, зачем это нужно, вообще в мелкосети ценность аккаунтов околонулевая, можно хоть каждый день новый создавать :) ahamai2, ahamai2000 и т.д.

Тогда правда наша сеть превратится в эдакий распределённый двач и потонет в море треша…

Будет эха которую фетчат все где будут распространяться ключи. С новым мылом фокус не пройдёт т.к. нет способа проверить что это тот же юзер - потерял мыло, потерял юзера. Теоретически если секретный ключ не утёк, а мыло потерял, то можно предусмотреть механизм восстановления, но как проверить что это кто-то не украл секретный ключ и теперь хочет перепривязать его к новому мылу? Нужен либо ещё один канал связи либо ещё одна пара ключей которые были созданы как запасные (вроде какие-то криптовалюты допускают замену ключей при утрате - надо почитать как у них это сделано)

shaos> Емейл будет нужен для замены скомпрометированного публичного ключа, если пользователь хочет продолжать писать под тем же самым именем. Также наличие подтверждения через другой канал (е-мейл) поможет избежать ситуации, когда некто на новой станции скажет, что он теперь shaos и будет писать везде вместо меня подписываясь своим новым ключом который ко мне не имеет никакого отношения :)

А как без общей между всеми нодами базы ключей некто на новой станции не сможет провернуть такое же с новым мылом?
И обратно: а что делать, если скомпрометирован не ключ, а мыло? Или вообще оба сразу? И как тебе с новым мылом и новым ключом доказать сисопу, что ты — это ты?

Вариант «сгенерил пару ключей и вперёд» подходит когда юзера устраивает полная анонимность - сегодня он ggJg123 а через месяц 809jGh :)

Емейл будет нужен для замены скомпрометированного публичного ключа, если пользователь хочет продолжать писать под тем же самым именем. Также наличие подтверждения через другой канал (е-мейл) поможет избежать ситуации, когда некто на новой станции скажет, что он теперь shaos и будет писать везде вместо меня подписываясь своим новым ключом который ко мне не имеет никакого отношения :)

shaos> Хотелось бы, чтобы юзеры стали глобальными - чтобы могли писать в сеть откуда угодно, а не только с той ноды, где они поинты

Ну тогда тем более keys.txt становится важен. А вот к мылу привязываться — так себе идея. Сейчас вообще не очень тот концепт, что сисоп даёт юзеру authstr. Наверное, куда лучше, чтобы юзер сгенерил у себя пару ключей и отправил публичный сисопу. Ну и про постинге, соответственно, подписывал сообщение приватным и отправлял подпись в качестве auth_string.

Хотя для начала можно и локальными ключами поработать, а глобальных пользователей добавить потом - причём так, чтобы они даже именем отличлись, например имели бы какой-то спецсимвол в начале типа @ или $

Хотелось бы, чтобы юзеры стали глобальными - чтобы могли писать в сеть откуда угодно, а не только с той ноды, где они поинты

Сделать расширение аналогичное list.txt - keys.txt содержащий user:publickey

А что такое hp?

Я предлагал подписывать контент (всё что ниже тега @repto) на стороне клиента (добавлять тег @sign), но надо продумывать надёжный способ распространения открытых ключей, скажем привязанных к е-мейлу (чтобы кто-то левый не мог перераспространить левый ключ)

Вообще изначально надо было msgid делать как неизменяемая часть [1] + изменяемая часть [2]
1. unixtime (как uint64 ) + node_name + username, закодированы в base64, первые 20 символов (например)
2. хэш от сообщения т.е. то что сейчас считается msgig

Это бы обеспечило достаточную уникальность + возможность редактировать сообщения с проверкой целостности. Правда тогда нужен костыль для того чтобы сообщить нодам что нужно переполучить сообщение.

> А вообще на лоре ещё одну проблемку подбросили

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

foxears> Можно в тэги сообщения добавлять хэш от usernme+authstring или что-то такое.

Ну, в принципе, да, но тогда тем более надо обязать все msgid соответствовать реальному хэшу, чтобы можно было проконтролировать целостность. А на данный момент какая-то полнейшая отсебятина с этим наблюдается.

def _y():
    return time.strftime('%y')

в mkmsg
    h = rh or _y() + sx.hsh(s,18)

в savemsg
    h = _y() + sx.hsh(s,18)
    h = hp + h[:14] if hp else h

для меня блин величайшая загадка природы, почему у меня есть mkmsg, а есть savemsg, которые делают одно и то же :)

Можно в тэги сообщения добавлять хэш от usernme+authstring или что-то такое.

shaos> Каждый раз код вводить это неудобно

Только для тех, кто постит в режиме чата. :)

А вообще на лоре ещё одну проблемку подбросили: если вдруг недобросовестная нода, с которой все фетчат, начнёт подделывать новые сообщения типа от других авторов (с других нод), как доказать, что они тут ни при чём? Как мы можем контролировать целостность сообщений, которыми обмениваемся?

Может, в поле адреса нода будет ещё и добавлять какую-то ЭЦП от себя, исходя из текста сообщения?