Agility does nothing to stop the "ciphertext from the past is broken due to crypto improvements". It's just a means to shorten response time to crypto breaks for _new_ traffic.
This project is plenty agile, upgrading the primitive is very easy as it's not a communication protocol but a data at rest protocol.
> this one doesn't have parameter negotiation and key management
You're thinking in terms of live communication protocols between endpoints. There is no "parameter negotiation" when you are both the sender and receiver of a static ciphertext.
There is no existing remediation for protecting your existing ciphertexts against future cryptanalysis.
I really do hear what you're saying and think you're making a great point.
The part that I think applies is that this is a "data at rest protocol". Communication protocols are assumed (but maybe shouldn't be - a la PRISM disclosures?) ephemeral.
As an attacker, I need to have been in the middle for that specific instance of the communication, and save it for decades, to attack it. Crypto agility shortens the window from a break or weakness to a fix, forcing any adversary who has not already recorded communication traffic to do so in a hurry.
In this setting as a "data at rest" protocol, the work to persist the ciphertext has been done for the attacker. If there's a weakness or break it's up the defender to clean up all copies of the old secret ciphertext that's out there and publish new ones. In cases where the secret has been cached (e.g. Wayback Machine) that may not be possible.
I hope you agree with this nuance that there's something the defender needs to consider. I agree with you that not all defenders will find this consideration will be decisive in their decision to use this method or not.
I just think it's a misleading analysis to say "this system is vulnerable to XYZ" without including the fact that ALL systems in this class are equally vulnerable. Crypto agility is not a thing that can be applied to encryption at rest.
It's similar to criticizing an alcoholic drink by saying "this drink will cause liver damage" as opposed to saying "this drink, like all alcoholic drinks, will cause liver damage"
Without that caveat people will see that criticism as evidence that other alcoholic drinks do not cause liver damage. The absence of words can convey the wrong impression.
At this point I can not edit the top comment. I would have edited with something like: "this property is not an implementation bug but a design outcome shared with any deployment of cryptography that persists ciphertext data in public."
Of course in future I will endeavour for more clarity and hope others read into this thread.
This project is plenty agile, upgrading the primitive is very easy as it's not a communication protocol but a data at rest protocol.
> this one doesn't have parameter negotiation and key management
You're thinking in terms of live communication protocols between endpoints. There is no "parameter negotiation" when you are both the sender and receiver of a static ciphertext.
There is no existing remediation for protecting your existing ciphertexts against future cryptanalysis.