# Re: Аутентификация поинтов через несекьюрное соединение
shaos (spnet, 2) → revoltech – 14:23:46 2024-10-29
Ну это типа кастомное расширение
HOTP потяжелее наверное - и там ведь ещё больший «огород с хешами» ?
shaos (spnet, 2) → revoltech – 14:23:46 2024-10-29
Ну это типа кастомное расширение
HOTP потяжелее наверное - и там ведь ещё больший «огород с хешами» ?
# Re: Станции ii/IDEC в .onion (Tor)
shaos (spnet, 2) → tuple – 14:20:18 2024-10-29
O - вот этот текст я искал ;)
Оригинал давно протух…
shaos (spnet, 2) → tuple – 14:20:18 2024-10-29
O - вот этот текст я искал ;)
Оригинал давно протух…
# Re: Стандарт
shaos (spnet, 2) → Andrew Lobanov – 14:14:20 2024-10-29
> Да.
Ну дык значит bloat уже на половину IDEC :)
shaos (spnet, 2) → Andrew Lobanov – 14:14:20 2024-10-29
> Да.
Ну дык значит bloat уже на половину IDEC :)
# Re: Стандарт
shaos (spnet, 2) → Andrew Lobanov – 14:12:22 2024-10-29
Ну я добавил их в /x/features и типа сразу видно что оно у меня есть ;)
shaos (spnet, 2) → Andrew Lobanov – 14:12:22 2024-10-29
Ну я добавил их в /x/features и типа сразу видно что оно у меня есть ;)
# Re: Стандарт
Andrew Lobanov (tavern,1) → tuple – 10:14:36 2024-10-29
AL>> Имеет смысл читать ii, а не кривую документацию по IDEC.
tuple> Между прочим, а где её найти? На лоре ссылки на умерший 51.ru, который тот самый с девочками, судя по веб-архиву. В интернете - IDEC.
Не знаю. Мы уже давно отдельно.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → tuple – 10:14:36 2024-10-29
AL>> Имеет смысл читать ii, а не кривую документацию по IDEC.
tuple> Между прочим, а где её найти? На лоре ссылки на умерший 51.ru, который тот самый с девочками, судя по веб-архиву. В интернете - IDEC.
Не знаю. Мы уже давно отдельно.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Станции ii/IDEC в .onion (Tor)
tuple (ping,54) → revoltech – 08:54:26 2024-10-29
tuple>> > На официальном сайте сказано о наличии “филиала” IDEC в сети Tor по адресу mtgbjhifvi4sl773.onion, но сейчас он не работает (закрыт по причине непопулярности)
revoltech> Это очень старый onion-адрес, сейчас они гораздо длиннее. Такие уже даже давно не резолвятся вроде бы.
Это единственный известный onion-адрес, увы. Про другие никто не распространялся, возможно они есть и живут своей жизнью у кого-то, но закрыто - только для себя.
tuple (ping,54) → revoltech – 08:54:26 2024-10-29
tuple>> > На официальном сайте сказано о наличии “филиала” IDEC в сети Tor по адресу mtgbjhifvi4sl773.onion, но сейчас он не работает (закрыт по причине непопулярности)
revoltech> Это очень старый onion-адрес, сейчас они гораздо длиннее. Такие уже даже давно не резолвятся вроде бы.
Это единственный известный onion-адрес, увы. Про другие никто не распространялся, возможно они есть и живут своей жизнью у кого-то, но закрыто - только для себя.
# Re: Станции ii/IDEC в .onion (Tor)
revoltech (spnet, 4) → tuple – 08:48:20 2024-10-29
tuple> > На официальном сайте сказано о наличии “филиала” IDEC в сети Tor по адресу mtgbjhifvi4sl773.onion, но сейчас он не работает (закрыт по причине непопулярности)
Это очень старый onion-адрес, сейчас они гораздо длиннее. Такие уже даже давно не резолвятся вроде бы.
revoltech (spnet, 4) → tuple – 08:48:20 2024-10-29
tuple> > На официальном сайте сказано о наличии “филиала” IDEC в сети Tor по адресу mtgbjhifvi4sl773.onion, но сейчас он не работает (закрыт по причине непопулярности)
Это очень старый onion-адрес, сейчас они гораздо длиннее. Такие уже даже давно не резолвятся вроде бы.
# Re: Аутентификация поинтов через несекьюрное соединение
revoltech (spnet, 4) → shaos – 08:47:04 2024-10-29
shaos> Да - в /x/features поддерживаемые кодировки можно перечислить таким макаром
Вот это в стандарт точно тащить не надо. Кому в 2024 году нужно что-то, кроме UTF-8? А всякие кои и 1251 за пределами постсовка и раньше никому не нужны были.
По передаче паролей — ума не приложу, как люди с паролями по plain http раньше жили. Конечно, времена поменялись, но зачем городить огород с хэшами? Не проще ли сделать что-то типа HOTP/TOTP и использовать одноразовый код в качестве authstring, если уж так приспичило? Но опять же, это вопрос реализации, в стандарт это тоже тащить не стоит, имхо.
revoltech (spnet, 4) → shaos – 08:47:04 2024-10-29
shaos> Да - в /x/features поддерживаемые кодировки можно перечислить таким макаром
Вот это в стандарт точно тащить не надо. Кому в 2024 году нужно что-то, кроме UTF-8? А всякие кои и 1251 за пределами постсовка и раньше никому не нужны были.
По передаче паролей — ума не приложу, как люди с паролями по plain http раньше жили. Конечно, времена поменялись, но зачем городить огород с хэшами? Не проще ли сделать что-то типа HOTP/TOTP и использовать одноразовый код в качестве authstring, если уж так приспичило? Но опять же, это вопрос реализации, в стандарт это тоже тащить не стоит, имхо.
# Re: Стандарт
tuple (ping,54) → Andrew Lobanov – 08:34:12 2024-10-29
AL> Имеет смысл читать ii, а не кривую документацию по IDEC.
Между прочим, а где её найти? На лоре ссылки на умерший 51.ru, который тот самый с девочками, судя по веб-архиву. В интернете - IDEC.
tuple (ping,54) → Andrew Lobanov – 08:34:12 2024-10-29
AL> Имеет смысл читать ii, а не кривую документацию по IDEC.
Между прочим, а где её найти? На лоре ссылки на умерший 51.ru, который тот самый с девочками, судя по веб-архиву. В интернете - IDEC.
# Re: Станции ii/IDEC в .onion (Tor)
tuple (ping,54) → revoltech – 08:21:52 2024-10-29
https://vk.com/@hatahack-ii-idec
> На официальном сайте сказано о наличии “филиала” IDEC в сети Tor по адресу mtgbjhifvi4sl773.onion, но сейчас он не работает (закрыт по причине непопулярности). Клиенты IDEC Mobile и CutieFeed по заверениям разработчика поддерживают настройки прокси, и в том числе успешно тестировались им на сетях Tor и i2p.
tuple (ping,54) → revoltech – 08:21:52 2024-10-29
https://vk.com/@hatahack-ii-idec
> На официальном сайте сказано о наличии “филиала” IDEC в сети Tor по адресу mtgbjhifvi4sl773.onion, но сейчас он не работает (закрыт по причине непопулярности). Клиенты IDEC Mobile и CutieFeed по заверениям разработчика поддерживают настройки прокси, и в том числе успешно тестировались им на сетях Tor и i2p.
# Re: Стандарт
Andrew Lobanov (tavern,1) → shaos – 07:43:31 2024-10-29
shaos> https://github.com/idec-net/new-docs/blob/master/iibonds.md
shaos> Минусы оригинального ii:
shaos> - Название эхоконференций от 3 до 60 символов, эха обязана заканчиваться на постфикс (точка и число).
shaos> - Когда в эхе накапливается по 3000 сообщений и более, получать индекс со станции становится долго.
shaos> - Из-за предыдущей причины приходилось "перекатывать" эхи, периодически переходя из одной в другую
Имеет смысл читать ii, а не кривую документацию по IDEC.
shaos> Наши улучшения
shaos> - Название эх от 3 до 120 символов, из них обязательный символ - только точка (без цифровых постфиксов)
shaos> - Небольшие расширения, которые помогают экономить трафик, защищают от переполнения эх и делают ещё пару полезных вещей.
shaos> ВСЁ!
Да.
>> Читать далее
Andrew Lobanov (tavern,1) → shaos – 07:43:31 2024-10-29
shaos> https://github.com/idec-net/new-docs/blob/master/iibonds.md
shaos> Минусы оригинального ii:
shaos> - Название эхоконференций от 3 до 60 символов, эха обязана заканчиваться на постфикс (точка и число).
shaos> - Когда в эхе накапливается по 3000 сообщений и более, получать индекс со станции становится долго.
shaos> - Из-за предыдущей причины приходилось "перекатывать" эхи, периодически переходя из одной в другую
Имеет смысл читать ii, а не кривую документацию по IDEC.
shaos> Наши улучшения
shaos> - Название эх от 3 до 120 символов, из них обязательный символ - только точка (без цифровых постфиксов)
shaos> - Небольшие расширения, которые помогают экономить трафик, защищают от переполнения эх и делают ещё пару полезных вещей.
shaos> ВСЁ!
Да.
>> Читать далее
# Re: Стандарт
Andrew Lobanov (tavern,1) → shaos – 07:43:31 2024-10-29
shaos> Ну т.е. теперь исключается сама возможность торкнуться на узел специальным образом, чтобы узнать одним списком а какие собственно расширения он поддерживает...
Почему? Хочешь сказать, что со старым стандартом исключалась сама возможность получить у тебя /list.txt с хешиками?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → shaos – 07:43:31 2024-10-29
shaos> Ну т.е. теперь исключается сама возможность торкнуться на узел специальным образом, чтобы узнать одним списком а какие собственно расширения он поддерживает...
Почему? Хочешь сказать, что со старым стандартом исключалась сама возможность получить у тебя /list.txt с хешиками?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Аутентификация поинтов через несекьюрное соединение
Andrew Lobanov (tavern,1) → shaos – 07:43:24 2024-10-29
shaos> Вобщем мне никогда не нравилось, что в /u/point у вас пароль идёт прямым текстом (ну скажем https:// и POST ещё ок, но если речь идёт о ретроклиентах, которые умеют только http:// ?)
shaos> Для несекьюрных каналов можно попробовать альтернативный способ аутентификации пользователя скажем через подпись HMAC-RIPEMD-160-96. Алгоритм HMAC это hash-based message authentication code (код аутентификации сообщения на основе хеша), который использует один секретный ключ, известный обеим сторонам, и над каким-то стандартным хешом - в данном случае это RIPEMD-160 (алгоритм хеширования с наименьшей длиной хеша, который ещё не сломали), причём этот алгоритм был представлен ещё в 1992 году (т.е. ему уже 32 года!) - он в частности используется в биткоине (вместе с SHA-256). Ну и для укорачивания такой подписи берутся первые 96 бит (12 байт). Это всё стандартизовано на уровне RFC:
shaos> RFC2104 (February 1997) - HMAC: Keyed-Hashing for Message Authentication
shaos> https://datatracker.ietf.org/doc/html/rfc2104
shaos> RFC2286 (February 1998) - Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128
shaos> https://datatracker.ietf.org/doc/html/rfc2286
shaos> RFC2857 (June 2000) - The Use of HMAC-RIPEMD-160-96 within ESP and AH
shaos> https://datatracker.ietf.org/doc/html/rfc2857
shaos> Конечно было бы лучше использовать SHA-256, но RIPEMD-160 проще в вычислительном плане, а нам надо будет его считать на слабых платформах. Вобщем суть такая - секретный ключ (это может быть строка текста длиной до 20 символов) загружается на узел через секьюрное соединение (https:// или скажем через емейл сисопу) один раз. Далее когда пользователь хочет отправить сообщение на узел (в описанном выше формате) по несекьюрному каналу, то его клиент считает по телу сообщения и секретному ключу подпись HMAC-RIPEMD-160-96 и посылает 12-байтовый результат как PAUTH (можно наверное в base64url его завернуть), а сервер при получении будет считать по полученному телу сообщения свой вариант HMAC-RIPEMD-160-96 и будет сравнивать с присланной подписью - если результат совпадёт, то отправитель считается аутентифицирован (плюс будет проверена целостность самого сообщения). До кучи в урл можно добавить кодировку, на тот случай если софт поинта не поддерживает UTF8:
shaos> URL/u/point2/koi7/B64AUTH/B64STRING
shaos> для больших сообщений можно задействовать метод POST:
shaos> URL/u/point2/koi7/B64AUTH
shaos> TEXT
shaos> причём тело сообщения в данном случае можно заслать прямым текстом без кодировки (Content-Type: plain/text)
shaos> Обсуждаем? :)
>> Читать далее
Andrew Lobanov (tavern,1) → shaos – 07:43:24 2024-10-29
shaos> Вобщем мне никогда не нравилось, что в /u/point у вас пароль идёт прямым текстом (ну скажем https:// и POST ещё ок, но если речь идёт о ретроклиентах, которые умеют только http:// ?)
shaos> Для несекьюрных каналов можно попробовать альтернативный способ аутентификации пользователя скажем через подпись HMAC-RIPEMD-160-96. Алгоритм HMAC это hash-based message authentication code (код аутентификации сообщения на основе хеша), который использует один секретный ключ, известный обеим сторонам, и над каким-то стандартным хешом - в данном случае это RIPEMD-160 (алгоритм хеширования с наименьшей длиной хеша, который ещё не сломали), причём этот алгоритм был представлен ещё в 1992 году (т.е. ему уже 32 года!) - он в частности используется в биткоине (вместе с SHA-256). Ну и для укорачивания такой подписи берутся первые 96 бит (12 байт). Это всё стандартизовано на уровне RFC:
shaos> RFC2104 (February 1997) - HMAC: Keyed-Hashing for Message Authentication
shaos> https://datatracker.ietf.org/doc/html/rfc2104
shaos> RFC2286 (February 1998) - Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128
shaos> https://datatracker.ietf.org/doc/html/rfc2286
shaos> RFC2857 (June 2000) - The Use of HMAC-RIPEMD-160-96 within ESP and AH
shaos> https://datatracker.ietf.org/doc/html/rfc2857
shaos> Конечно было бы лучше использовать SHA-256, но RIPEMD-160 проще в вычислительном плане, а нам надо будет его считать на слабых платформах. Вобщем суть такая - секретный ключ (это может быть строка текста длиной до 20 символов) загружается на узел через секьюрное соединение (https:// или скажем через емейл сисопу) один раз. Далее когда пользователь хочет отправить сообщение на узел (в описанном выше формате) по несекьюрному каналу, то его клиент считает по телу сообщения и секретному ключу подпись HMAC-RIPEMD-160-96 и посылает 12-байтовый результат как PAUTH (можно наверное в base64url его завернуть), а сервер при получении будет считать по полученному телу сообщения свой вариант HMAC-RIPEMD-160-96 и будет сравнивать с присланной подписью - если результат совпадёт, то отправитель считается аутентифицирован (плюс будет проверена целостность самого сообщения). До кучи в урл можно добавить кодировку, на тот случай если софт поинта не поддерживает UTF8:
shaos> URL/u/point2/koi7/B64AUTH/B64STRING
shaos> для больших сообщений можно задействовать метод POST:
shaos> URL/u/point2/koi7/B64AUTH
shaos> TEXT
shaos> причём тело сообщения в данном случае можно заслать прямым текстом без кодировки (Content-Type: plain/text)
shaos> Обсуждаем? :)
>> Читать далее
# Re: Стандарт
Andrew Lobanov (tavern,1) → shaos – 07:43:16 2024-10-29
shaos> А как же делать кастомные расширения теперь?...
Я ж говорю, важна поддержка стандарта. Что там кто себе сбоку наворотил, это их личное дело и не должно влиять на всю сеть.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → shaos – 07:43:16 2024-10-29
shaos> А как же делать кастомные расширения теперь?...
Я ж говорю, важна поддержка стандарта. Что там кто себе сбоку наворотил, это их личное дело и не должно влиять на всю сеть.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Стандарт
Andrew Lobanov (tavern,1) → revoltech – 06:53:52 2024-10-29
shaos>> это как так? перечисляемые расширения были основной фишкой IDEC :(
revoltech> Ну а теперь три из них являются частью стандарта, а остальные — нет. Вообще нет. Если я всё правильно понял.
Всё так. Расширения стандарта это путь вникуда. Лучше потихоньку принимать в стандарт полезняшки, если они будут действительно нужны.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → revoltech – 06:53:52 2024-10-29
shaos>> это как так? перечисляемые расширения были основной фишкой IDEC :(
revoltech> Ну а теперь три из них являются частью стандарта, а остальные — нет. Вообще нет. Если я всё правильно понял.
Всё так. Расширения стандарта это путь вникуда. Лучше потихоньку принимать в стандарт полезняшки, если они будут действительно нужны.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Стандарт
Andrew Lobanov (tavern,1) → tuple – 06:53:52 2024-10-29
AL>> Словарик будет отдельным документом.
tuple> Лучше в самом документе словарик иметь.
Словарик не является частью стандарта.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → tuple – 06:53:52 2024-10-29
AL>> Словарик будет отдельным документом.
tuple> Лучше в самом документе словарик иметь.
Словарик не является частью стандарта.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Стандарт
shaos (spnet, 2) → Andrew Lobanov – 07:06:16 2024-10-29
https://github.com/idec-net/new-docs/blob/master/iibonds.md
Минусы оригинального ii:
- Название эхоконференций от 3 до 60 символов, эха обязана заканчиваться на постфикс (точка и число).
- Когда в эхе накапливается по 3000 сообщений и более, получать индекс со станции становится долго.
- Из-за предыдущей причины приходилось "перекатывать" эхи, периодически переходя из одной в другую
Наши улучшения
- Название эх от 3 до 120 символов, из них обязательный символ - только точка (без цифровых постфиксов)
- Небольшие расширения, которые помогают экономить трафик, защищают от переполнения эх и делают ещё пару полезных вещей.
ВСЁ!
shaos (spnet, 2) → Andrew Lobanov – 07:06:16 2024-10-29
https://github.com/idec-net/new-docs/blob/master/iibonds.md
Минусы оригинального ii:
- Название эхоконференций от 3 до 60 символов, эха обязана заканчиваться на постфикс (точка и число).
- Когда в эхе накапливается по 3000 сообщений и более, получать индекс со станции становится долго.
- Из-за предыдущей причины приходилось "перекатывать" эхи, периодически переходя из одной в другую
Наши улучшения
- Название эх от 3 до 120 символов, из них обязательный символ - только точка (без цифровых постфиксов)
- Небольшие расширения, которые помогают экономить трафик, защищают от переполнения эх и делают ещё пару полезных вещей.
ВСЁ!
# Re: Аутентификация поинтов через несекьюрное соединение
shaos (spnet, 2) → shaos – 06:59:56 2024-10-29
Да - в /x/features поддерживаемые кодировки можно перечислить таким макаром:
/u/point2/utf8
/u/point2/koi7
/u/point2/koi8r
/u/point2/cp866
/u/point2/cp1251
При получении узел будет сам переконвечивать это в UTF-8 (если пришёл не UTF-8)
shaos (spnet, 2) → shaos – 06:59:56 2024-10-29
Да - в /x/features поддерживаемые кодировки можно перечислить таким макаром:
/u/point2/utf8
/u/point2/koi7
/u/point2/koi8r
/u/point2/cp866
/u/point2/cp1251
При получении узел будет сам переконвечивать это в UTF-8 (если пришёл не UTF-8)
# Re: Стандарт
shaos (spnet, 2) → Andrew Lobanov – 06:54:44 2024-10-29
Ну т.е. теперь исключается сама возможность торкнуться на узел специальным образом, чтобы узнать одним списком а какие собственно расширения он поддерживает...
shaos (spnet, 2) → Andrew Lobanov – 06:54:44 2024-10-29
Ну т.е. теперь исключается сама возможность торкнуться на узел специальным образом, чтобы узнать одним списком а какие собственно расширения он поддерживает...
# Аутентификация поинтов через несекьюрное соединение
shaos (spnet, 2) → All – 06:50:51 2024-10-29
Вобщем мне никогда не нравилось, что в /u/point у вас пароль идёт прямым текстом (ну скажем https:// и POST ещё ок, но если речь идёт о ретроклиентах, которые умеют только http:// ?)
Для несекьюрных каналов можно попробовать альтернативный способ аутентификации пользователя скажем через подпись HMAC-RIPEMD-160-96. Алгоритм HMAC это hash-based message authentication code (код аутентификации сообщения на основе хеша), который использует один секретный ключ, известный обеим сторонам, и над каким-то стандартным хешом - в данном случае это RIPEMD-160 (алгоритм хеширования с наименьшей длиной хеша, который ещё не сломали), причём этот алгоритм был представлен ещё в 1992 году (т.е. ему уже 32 года!) - он в частности используется в биткоине (вместе с SHA-256). Ну и для укорачивания такой подписи берутся первые 96 бит (12 байт). Это всё стандартизовано на уровне RFC:
RFC2104 (February 1997) - HMAC: Keyed-Hashing for Message Authentication
https://datatracker.ietf.org/doc/html/rfc2104
RFC2286 (February 1998) - Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128
https://datatracker.ietf.org/doc/html/rfc2286
RFC2857 (June 2000) - The Use of HMAC-RIPEMD-160-96 within ESP and AH
https://datatracker.ietf.org/doc/html/rfc2857
Конечно было бы лучше использовать SHA-256, но RIPEMD-160 проще в вычислительном плане, а нам надо будет его считать на слабых платформах. Вобщем суть такая - секретный ключ (это может быть строка текста длиной до 20 символов) загружается на узел через секьюрное соединение (https:// или скажем через емейл сисопу) один раз. Далее когда пользователь хочет отправить сообщение на узел (в описанном выше формате) по несекьюрному каналу, то его клиент считает по телу сообщения и секретному ключу подпись HMAC-RIPEMD-160-96 и посылает 12-байтовый результат как PAUTH (можно наверное в base64url его завернуть), а сервер при получении будет считать по полученному телу сообщения свой вариант HMAC-RIPEMD-160-96 и будет сравнивать с присланной подписью - если результат совпадёт, то отправитель считается аутентифицирован (плюс будет проверена целостность самого сообщения). До кучи в урл можно добавить кодировку, на тот случай если софт поинта не поддерживает UTF8:
>> Читать далее
shaos (spnet, 2) → All – 06:50:51 2024-10-29
Вобщем мне никогда не нравилось, что в /u/point у вас пароль идёт прямым текстом (ну скажем https:// и POST ещё ок, но если речь идёт о ретроклиентах, которые умеют только http:// ?)
Для несекьюрных каналов можно попробовать альтернативный способ аутентификации пользователя скажем через подпись HMAC-RIPEMD-160-96. Алгоритм HMAC это hash-based message authentication code (код аутентификации сообщения на основе хеша), который использует один секретный ключ, известный обеим сторонам, и над каким-то стандартным хешом - в данном случае это RIPEMD-160 (алгоритм хеширования с наименьшей длиной хеша, который ещё не сломали), причём этот алгоритм был представлен ещё в 1992 году (т.е. ему уже 32 года!) - он в частности используется в биткоине (вместе с SHA-256). Ну и для укорачивания такой подписи берутся первые 96 бит (12 байт). Это всё стандартизовано на уровне RFC:
RFC2104 (February 1997) - HMAC: Keyed-Hashing for Message Authentication
https://datatracker.ietf.org/doc/html/rfc2104
RFC2286 (February 1998) - Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128
https://datatracker.ietf.org/doc/html/rfc2286
RFC2857 (June 2000) - The Use of HMAC-RIPEMD-160-96 within ESP and AH
https://datatracker.ietf.org/doc/html/rfc2857
Конечно было бы лучше использовать SHA-256, но RIPEMD-160 проще в вычислительном плане, а нам надо будет его считать на слабых платформах. Вобщем суть такая - секретный ключ (это может быть строка текста длиной до 20 символов) загружается на узел через секьюрное соединение (https:// или скажем через емейл сисопу) один раз. Далее когда пользователь хочет отправить сообщение на узел (в описанном выше формате) по несекьюрному каналу, то его клиент считает по телу сообщения и секретному ключу подпись HMAC-RIPEMD-160-96 и посылает 12-байтовый результат как PAUTH (можно наверное в base64url его завернуть), а сервер при получении будет считать по полученному телу сообщения свой вариант HMAC-RIPEMD-160-96 и будет сравнивать с присланной подписью - если результат совпадёт, то отправитель считается аутентифицирован (плюс будет проверена целостность самого сообщения). До кучи в урл можно добавить кодировку, на тот случай если софт поинта не поддерживает UTF8:
>> Читать далее
# Re: Стандарт
Andrew Lobanov (tavern,1) → shaos – 06:46:25 2024-10-29
shaos> Ну у него эхи без цифр, значит уже наполовину IDEC ;)
Да не было в ii требования эх с циферками. Это была просто договорённость, а не стандарт. Эхи без циферек там прекрасно работали всю дорогу.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → shaos – 06:46:25 2024-10-29
shaos> Ну у него эхи без цифр, значит уже наполовину IDEC ;)
Да не было в ii требования эх с циферками. Это была просто договорённость, а не стандарт. Эхи без циферек там прекрасно работали всю дорогу.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Стандарт
Andrew Lobanov (tavern,1) → shaos – 06:46:24 2024-10-29
shaos> это как так? перечисляемые расширения были основной фишкой IDEC :(
Перечисляемые расширения вынуждают стандартизировать расширения. Придём к джабберу, где у каждого свой зоопарк и по факту в рамках сети рабоает только основа стандарта и пара расширений. Нафиг-нафиг.
А так, никто не мешает лепить любые расширения у себя. Просто не надо полагаться на то, что их будут поддерживать. Ситуация ровно та же, только более свободная.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → shaos – 06:46:24 2024-10-29
shaos> это как так? перечисляемые расширения были основной фишкой IDEC :(
Перечисляемые расширения вынуждают стандартизировать расширения. Придём к джабберу, где у каждого свой зоопарк и по факту в рамках сети рабоает только основа стандарта и пара расширений. Нафиг-нафиг.
А так, никто не мешает лепить любые расширения у себя. Просто не надо полагаться на то, что их будут поддерживать. Ситуация ровно та же, только более свободная.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
# Re: Стандарт
shaos (spnet, 2) → revoltech – 06:37:40 2024-10-29
А как же делать кастомные расширения теперь?...
shaos (spnet, 2) → revoltech – 06:37:40 2024-10-29
А как же делать кастомные расширения теперь?...
# Re: Стандарт
revoltech (spnet, 4) → revoltech – 06:12:16 2024-10-29
revoltech> три из них являются частью стандарта
Пардон, /u/push не увидел. В таком варианте — даже четыре.
revoltech (spnet, 4) → revoltech – 06:12:16 2024-10-29
revoltech> три из них являются частью стандарта
Пардон, /u/push не увидел. В таком варианте — даже четыре.