Рад, что понравлось! Однако в статье есть также и код, который позволяет самостоятельно протестировать все нюансы реализации Kerberos на Windows. Рекомендую закрепить новые знания сразу на практике.
А вообще я где-то встречал описание keytab. Может завтра найду ещё раз. А по второму вопросу: в статье я описал, как ищется адрес KDC с помощью DNS. То есть ищется запись типа SRV со стандартным префиксом и суффиксом в виде имени домена.
При U2U в сессии сервиса нет информации об имени пользователя и пароле. Такая ситуация возникает, например, когда сервис аутенцифицируется с использованием PKINIT. При использовании PKINIT сервису нет необходимости знать имя пользователя и его пароль. Вместо этого для шифрования пре-аутентификационных сообщений используется закрытый ключ сертификата. KDC возвращает NTLM хэш в TGT полученном по PKINIT, однако реализация стандартного сервиса Kerberos этот хэш нигде не сохраняет и не использует. Расширение U2U используется не всегда, оно просто предназначено для специального случая когда сервис прошёл аутентификацию без использования имени пользователя и пароля.
Изначально я делал статью на гораздо более простом уровне объяснений. Что-то вроде «Kerberos для бухгалтеров». Но в процессе мне стало так скучно, что я даже был вынужден взять перерыв и заняться другими делами. В конце концов написал как можно более просто и в достаточной мере интересно для себя.
Любой патент просто признаёт, что подобное в данной патентной системе отсутствует (новизна изобретения), а также как-то закрепляет право на это изобретение за заявителем. Корретно ли изобретение для патента маловажно.
Конкретные числа действительно большие. Однако если уж предлагаете какую-то "инновацию" рекомендую предусматривать возможность разрастания базы. Это всегда полезно. И где же обещанный документ, объясняющий мне остальные мои вопросы?
Проблема в том, что любая сделанная на этой основе система через какое-то время просто прекратит свою работу. И просто технически будет невозможно как-то эту работу продолжить: закончится «ёмкость».
Есть несколько вопросов. Может тут хоть кто-то остался, кто сможет на них ответить.
Откуда берется Hash(n, 0) для нулевой транзакции?
Что именно содержится в «нотификате»? Только публичный ключ или что-то ещё? Например в X.509 сертификате предусмотрены политики применения сертификата (ограничения области применения);
Опишите как можно подробнее какой-либо сценарий использования «нотификата». Желательно прямо от процесса подписывания чего-то и до процесса проверки, что вот это что-то подписано именно вот этим «нотификатом» (откуда берется «нотификат» для проверки
На рисунке, поясняющем процесс проверки нулевой транзакции элемент «общедоступный ключ» не нужен: публичный ключ для кошелька берется из поля «signature». Или это какой-то другой «общедоступный ключ»? В этом случае непонятно как он используется для создания нулевой транзакции
Зачем нужна «служебная ключевая пара»? Фактически в статье она применяется как некий идентификатор для определённого кошелька. Однако у самого кошелька уже есть своя ключевая пара. Этот же ключ кошелька может быть использован и для проверки транзакций отличных от нулевой. А если рассматривать использование «служебной пары» как доказательства регистрации субъекта в системе, то для такой регистрации опять можно использовать ключ самого кошелька
Предположим, что злоумышленник зарегистрирован как участник системы. Затем он перехватывает несколько идущих подряд сообщений от другого пользователя и знает несколько предыдущих значений H(n-x). Как мне кажется, в этом случае злоумышленник сможет в новой транзакции от другого пользователя заменить все H корректными значениями и подставить свой публичный ключ. Так злоумышленник может присвоить публичный ключ
Понимают ли создатели данной системы, что «ёмкость» данной системы (количество публичных ключей хранящихся в системе) ограничена 2^256 при применении SHA-256? Эта цифра обусловлена тем, что информация об общедоступных ключах тут хранится в виде хэшей
В начале статьи обозначены две проблемы PKI: централизация системы и начальная аутентификация пользователей. Было предложено решение только для первой проблемы. Использование же blockchain системы ведёт к противоречию: изначально blockchain обезличивает пользователей, а в системе DPKI стоит задача корректной идентификации таких пользователей
https://www.ioplex.com/utilities/keytab.txt - формат keytab
Рад, что понравлось! Однако в статье есть также и код, который позволяет самостоятельно протестировать все нюансы реализации Kerberos на Windows. Рекомендую закрепить новые знания сразу на практике.
Такие нюансы надо смотреть непосредственно в коде клиента Kerberos на вашей ОС. Если уж разговор про krb5.conf, то это *nix. А там вроде всё открытое.
А вообще я где-то встречал описание keytab. Может завтра найду ещё раз. А по второму вопросу: в статье я описал, как ищется адрес KDC с помощью DNS. То есть ищется запись типа SRV со стандартным префиксом и суффиксом в виде имени домена.
Я ведь не полный функционал klist реализовал, только в части показа текущих билетов.
Так вы код мой поглядите, там всё есть. Разбора keytab там нет, есть разбор билетов, которые есть в текущей сессии.
Предлагаю вам самостоятельно поискать скажем в Google. К моей статье эти вопросы не имеют отношения.
При U2U в сессии сервиса нет информации об имени пользователя и пароле. Такая ситуация возникает, например, когда сервис аутенцифицируется с использованием PKINIT. При использовании PKINIT сервису нет необходимости знать имя пользователя и его пароль. Вместо этого для шифрования пре-аутентификационных сообщений используется закрытый ключ сертификата. KDC возвращает NTLM хэш в TGT полученном по PKINIT, однако реализация стандартного сервиса Kerberos этот хэш нигде не сохраняет и не использует. Расширение U2U используется не всегда, оно просто предназначено для специального случая когда сервис прошёл аутентификацию без использования имени пользователя и пароля.
Изначально я делал статью на гораздо более простом уровне объяснений. Что-то вроде «Kerberos для бухгалтеров». Но в процессе мне стало так скучно, что я даже был вынужден взять перерыв и заняться другими делами. В конце концов написал как можно более просто и в достаточной мере интересно для себя.
Ключевая информация об этом находится прямо в первом предложении статьи: "в сентябре 2021 года..."
В настоящий момент и лично у меня скачать ничего невозможно, только online.
У вас ошибка: "концепция shit left". Улыбнулся, спасибо.
LOL. Я вообще-то у вас просто ответы спрашивал. Сотрудничество? Об этом речи нет.
Любой патент просто признаёт, что подобное в данной патентной системе отсутствует (новизна изобретения), а также как-то закрепляет право на это изобретение за заявителем. Корретно ли изобретение для патента маловажно.
У меня есть подозрения, что описываемая здесь система достаточно ущербна. Но чтобы это подтвердить или опровергнуть мне нужны дополнительные сведения.
Конкретные числа действительно большие. Однако если уж предлагаете какую-то "инновацию" рекомендую предусматривать возможность разрастания базы. Это всегда полезно. И где же обещанный документ, объясняющий мне остальные мои вопросы?