[О блоге]
[наверх]
[пред]
[2025-10-28 08:36:37+03:00]
[af48dd5e7b3ea4ea9764438eee5c73413a7c651f]
Темы: [crypto][keks][web]
Критика age
https://groups.google.com/g/age-dev/c/r-gwwcN3L-0/m/EhEvUbG5AwAJ
https://neilmadden.blog/2019/12/30/a-few-comments-on-age/
https://www.imperialviolet.org/2014/06/27/streamingencryption.html
https://news.ycombinator.com/item?id=21898332
https://moxie.org/2011/12/13/the-cryptographic-doom-principle.html
https://www.chosenplaintext.ca/2015/03/31/jwt-algorithm-confusion.html
https://mailarchive.ietf.org/arch/msg/jose/sz6XzHkVP2eWip_OiV5OkPggWWA/
https://neilmadden.blog/2018/09/30/key-driven-cryptographic-agility/
В JOSE/JWT есть опаснейшая атака, которая позволяет сделать подписанные
токены всегда валидными. Вот что будет, если web-related разрабы делают
криптографические протоколы.
Neil Madden критикует age за то, что в нём типа такая же уязвимость
потенциально есть: злоумышленник может заставлять выбирать другие
алгоритмы принимающую сторону. Потом согласился, что это не так и
алгоритм только помогает найти требуемый ключ, а дальше уже всё от типа
ключа зависит. Критикует age за то, что в нём нет sender authentication,
что автор и не скрывает и подчёркивает чтобы были аккуратными.
Мой cm/encrypted (KEKS/CM) вроде тоже не подвержен чему-то подобному.
Ищется ключ, а алгоритм указывается чтобы упростить этот поиск и
убедиться что мы об одном и том же ключе говорим. Если злоумышленник
укажет другой ключ и другой алгоритм, то на нём будут произведены
вычисления KEK ключа, но ведь всё обломается из-за проверки MAC на
keywrap контейнере с CEK ключом.
[оставить комментарий]