Size: a a a

Clojure — русскоговорящее сообщество

2019 December 11

MP

Maxim Penzin in Clojure — русскоговорящее сообщество
то есть генерится пара ключей для каждого подписанта, потом зная публичный ключ того, кто подписал, можно проверить действительно ли это так
источник

IG

Ivan Grishaev in Clojure — русскоговорящее сообщество
Andrew Rudenko
> И можно взять любой контент, подписанный кем-то, добавить поле и подписать еще раз

так вопрос как при этом обеспечить выполнение 1)
это я пропустил; но вообще, токен это же публичный ключ? Даже если его увидят, секретного ключа-то к нему нет.
источник

IG

Ivan Grishaev in Clojure — русскоговорящее сообщество
разве что если надо скрыть автора оригинального сообщения.
источник

MP

Maxim Penzin in Clojure — русскоговорящее сообщество
источник

AR

Andrew Rudenko in Clojure — русскоговорящее сообщество
Maxim Penzin
то есть генерится пара ключей для каждого подписанта, потом зная публичный ключ того, кто подписал, можно проверить действительно ли это так
ты меня не слушаешь? ) у меня нет проблем с подписать / проверить какой-то документ, у меня проблема ровно с тем, что я описал. как можно обеспечить слоенность подписей
источник

MP

Maxim Penzin in Clojure — русскоговорящее сообщество
Andrew Rudenko
ты меня не слушаешь? ) у меня нет проблем с подписать / проверить какой-то документ, у меня проблема ровно с тем, что я описал. как можно обеспечить слоенность подписей
слоеность это как именно?
источник

AR

Andrew Rudenko in Clojure — русскоговорящее сообщество
Andrew Rudenko
о, ребят, давайте спрошу, вдруг кто в курсе, у меня тут проблемка:

Есть unforgeable токен (token1), которые нужно иметь возможность "оборачивать" (token2), т.е. добавлять новую информацию (data2) и подписывать своим ключом(secret2). Должны соблюдаться следующие условия:

1. Обладая token2 не должно быть возможности получить валидный token1
2. Верификатор должен иметь возможность проверить валидность всей цепочки.

Структрура токенов примерно следующая:

token1 = data1.apikey1.signature1
 where signature1 = sign(data1.apikey1, secret1)

token2 = data1.apikey1.data2.apikey2.signature2
 where signature2 = sign(data1.apikey1.signature1.data2.apikey2, secret2)


Используя hmac с симметричными ключами это легко сделать (apikeys в данном случае это просто идентификаторы по которым верификатор получает секреты), на этапе верификации мы просто воспроизводим всю цепочку и сравниваем итоговую подпись. Однако этот подход требует знания верификатором всех секретов.

Идеально было бы использовать асимметричные подписи: подписывать данные разными приватными ключами аккумулируя результат в одну подпись (сохраняя валидным требование 1.), проверять списком публичных.

Наиболее точное описание того, что я хочу я нашел тут [1], но оно все что дальше введения сильное академично, без имплементаций. Возможно, я просто не знаю как надо искать и это общеизвестный алгоритм? Или я хочу неправильного? Спасибо.

[1] https://eprint.iacr.org/2005/335.pdf
вот так
источник

AR

Andrew Rudenko in Clojure — русскоговорящее сообщество
token1 = data1.apikey1.signature1
 where signature1 = sign(data1.apikey1, secret1)

token2 = data1.apikey1.data2.apikey2.signature2
 where signature2 = sign(data1.apikey1.signature1.data2.apikey2, secret2)
источник

AR

Andrew Rudenko in Clojure — русскоговорящее сообщество
Ivan Grishaev
разве что если надо скрыть автора оригинального сообщения.
не надо ничего скрывать, нужно уметь проверить валидность token2 (т.е. что он был подписан обладателем token1) и при этом обеспечить невозможность получения token1 из token2
источник

IG

Ivan Grishaev in Clojure — русскоговорящее сообщество
токен это приватная вещь или?
источник

AR

Andrew Rudenko in Clojure — русскоговорящее сообщество
нет
источник

AR

Andrew Rudenko in Clojure — русскоговорящее сообщество
ну т.е. как
источник

AR

Andrew Rudenko in Clojure — русскоговорящее сообщество
это приватная )
источник

AR

Andrew Rudenko in Clojure — русскоговорящее сообщество
это секрет, обладание им дает тебе привелегии
источник

IG

Ivan Grishaev in Clojure — русскоговорящее сообщество
тут просто намешаны api-key, secret-key и token, и тому, что решает задачу нужно понять, что публично, что приватно.
источник

MP

Maxim Penzin in Clojure — русскоговорящее сообщество
ммм... токен2 чтобы как-то появился без участия владельца токен1?
источник

IG

Ivan Grishaev in Clojure — русскоговорящее сообщество
И зачем тогда токен, если есть открытый и закрытый ключи
источник

IG

Ivan Grishaev in Clojure — русскоговорящее сообщество
просто подписываешь а сервер проверяет
источник

AR

Andrew Rudenko in Clojure — русскоговорящее сообщество
нет, каждый владелец токен1 может сделать токен2 подписав его своим ключом
источник

AR

Andrew Rudenko in Clojure — русскоговорящее сообщество
Ivan Grishaev
тут просто намешаны api-key, secret-key и token, и тому, что решает задачу нужно понять, что публично, что приватно.
Ну ок, пойдем этим путем )

Я хочу сделать что-то вроде Capabilities-Based Access Control для распределенных систем. Т.е. сервис при создании ресурса генерирует (forge) некий рутовые токены (capabilities), которые и должны использоваться при операциях с этим ресурсом. Обладание таким токеном само по себе означает право (authority) на совершение этих действий. Обладатель токена может его свободно передавать другим агентам (delegation). Кроме того, любой обладатель токена может "обернуть" его, т.е. сузить возможности токена. Добавив к нему слой и подписав его.

Для того чтобы как-то решить проблему возможности отзыва (и не только, на этом же строится аудит и квоты) токенов при каждом таком оборачивании в токен добавляется key. Верификатор проверяет, что все такие key валидны и не были отозваны.

Структурно это такой JWT с возможность наслаивания. И если с имплементацией симметричных подписей у меня проблем нет (верификатор по key вытаскивает соответсвующие secrets), то вот асимметричная криптография поставила в тупик.
источник