R
Кажется, что это не имеет смысла. Т.к. основная фишка кейстора - не светить ключи. А тут они в стрингпуле оседают
Size: a a a
2020 August 10
R
Кстати, покажи POC как положить рандомный ключ от сервера в кейстор @LionZXY
R
Как раз выше про это беседа была
NK
NK
Вроде можно отправить сгенеренный, нет?
NK
Видел подход когда с сервера приходит с каждым респонсом ключ, кидается в кейстор, там выплевывается уникальный ключ для каждого запроса. В кейстор залезть нельзя даже с рутом
Я вот это реверсил, мог не так понять
R
Ну вот я выше как раз обсуждал с @eugeneeku и докопался, что ключ от PBKDF нельзя положить в кейстор. У SecretKeyFactory, что его генерит, нет такого провайдера
R
И вообще там разные интерфейсы
NK
R
А от сервера тебе совсем глупая строка приходит. Как ты из нее ключ сваришь? =)
R
Да еще и кейсторный
NK
Так?
R
Это работа с ключем, который уже в кейсторе
R
Ты генерацию покажи =) По рандомной строке
NK
Это работа с ключем, который уже в кейсторе
Так про это и речь
NK
Мы строку с сервера подписываем на клиенте ключом из кейстора
R
Так а чего там “протухает” тогда? =)
R
И зачем каждый раз новый ключ генерить?
NK
Как я понял чтобы проверить валидность запросов. Что они из приложения приходят
R
Ну тогда тут чуть обратная схема должна быть. Если я тебя верно понял. На клиентенте генериться пара ключей. Публичный отправляется на сервер. Далее строка от сервера шифруется приватным ключем и отправляется вместе с запросом. Сервер, имея публичный ключ, может это расшифровать. Только тут вопрос - как он в этот момент понимает, что запрос от приложения, а не от python скрипта? )