п

Подскажи

обана, рассказывай

Кстати, я совсем забыл один нюанс расписать

Пространство ключей, все еще очень мало. А это означает, что я могу взять 10к получившихся plaintext-ов и послать их в сервер с 10к машин. Одна из них получит ответ 200. Все, пинкод взломан

не можешь RT привязан к DeviceId, и если будет 3 неправильных попытки для DeviceId все токены заинвалидируются

Tinkoff Enterprise Mobile Bank, в ios версии

@Jacks0n23 а ты не знал? =)

А почему в Android не сделали так?

я сам не знаю, помню что написали код, но переехать забыли по ходу

Но вообще занятно, надо поразмыслить над векторами атаки на эту схему

Кстати, раз уж речь зашла. @NeonLost ты не разбирался почему происходит эффект с одинаковыми шифротекстами при перешифровке мусора? Я видимо не настолько хорошо понимаю AES, чтобы сходу найти объяснение.

неа, я же не там, тем более ios вообще не копал

вопрос по применению tink-android
Предполагается пересылка данных о локации между приложением источником и приложением-подписчиком.
Схема работы - у подписчика может быть сколько угодно источников, пересылаемые данные надо шифровать.
Напрашивается применение гибридной схемы - то есть подписчик публикует свой открытый ключ, источники шифруют им данные и шлют.
как при этом исключить возможность вскрытия данных MiTM - если, допустим, канал не защищен от любых изменений, послать сообщение любого формата в обе стороны может кто угодно, хакнувший приложение? Защитить надо данные, отправленные  источником от разглашения, "фальшивые данные"  нас не интересуют, пусть шлют.

Tink умеет только в симметричную крипту насколько я знаю

да там дофига всего

т.е. ты боишься, что пошлют MiTM открытый ключ?

https://habr.com/en/company/virgilsecurity/blog/459370/ - продолжаем криптонеделю в чате =)

да. При этом что бы не усложнять ux как максимум будет норм сгенерить для пары подписчик-источник одноразовый PIN при первом установлении связи

ну и по tink - кто работал, может сразу подскажет, какая именно из его схем и типов ключей тут подходит?