Comment by admax88qqq
4 years ago
> Con: Eventually the secrets will become exposed due to advances in crypt-analysis
You can claim this con for literally any crypto. And I'm not actually sure it's a reasonable assumption.
Block ciphers seem to be pretty unbreakable so far. Even good ol Triple-DES is secure in practice barring some caveats (don't encrypt more than a certain amount of data)
I'd wager if I gave you a real world message encrypted with AES with a strong key it won't be broken in our lifetimes.
That's a good point, I wasn't very specific about this (trying to keep it concise). To be specific here, the con is that there isn't what the industry calls Cryptographic Agility. https://en.wikipedia.org/wiki/Cryptographic_agility.
It is not true this con applies to all cryptography (e.g. look at TLS). It has more to do with how cryptography is configured, parameters are negotiated and keys are managed, than with point-in-time choices about algorithms. The con here is that unlike other deployments of cryptography, this one doesn't have parameter negotiation and key management - and therefore doesn't have cryptographic agility.
Re: "I'd wager that... AES..." is a also a good point. Modern cryptography has shown to be robust for decades and past their deprecation point. However, as you said, it IS a wager. There have been catastrophic failures of cryptographic primitives in the past. The con of this system is you will need to make a wager and tie yourself to the fate - you can't mitigate the risk if the catastrophic event comes or appears to be coming to pass.
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.
2 replies →
Contrary to what Wikipedia says, I don't think agility is considered a desirable property by most cryptographers: you still have the "attacker stored encrypted material" problem, and now you have to worry about downgrade attacks.
Many of the most interesting/effective attacks on SSL/TLS have been downgrade attacks that stem directly from the protocol's (historically) agile design.
I disagree with your speculation as to what most cryptographers think. Are you basing this on any data you can share?
Please also see the other thread about how this secret storage system is different from a communication protocol. Namely, communication protocols have a two step attack: first attacker must MITM and record ciphertext, then they must wait. This secret storage method is different (one step attack): attacker looks for ciphertexts on either targeted or non-targeted basis that use old standard. Persistence, caches and publication of these secrets has been done for them.
It's a good point about downgrade attacks. They have been brutal for TLS to deal with.
1 reply →