From af48dd5e7b3ea4ea9764438eee5c73413a7c651f Mon Sep 17 00:00:00 2001 From: Sergey Matveev Date: Tue, 28 Oct 2025 08:36:37 +0300 Subject: [PATCH] =?utf8?q?=D0=9A=D1=80=D0=B8=D1=82=D0=B8=D0=BA=D0=B0=20age?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit 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 ключом. -- 2.52.0