4 ms·

I'd say it ultimately depends on the information you're encrypting. Information and secrecy around it often has some sort of temporal/time relationship tied to

I'd say it ultimately depends on the information you're encrypting. Information and secrecy around it often has some sort of temporal/time relationship tied to the information and surrounding context. If it's something you wish to protect indefinitely or for a long time into the future, it's important to consider now. If n the other hand it's some rotating fairly randomly generated password that expires monthly, quarterly, whatever or say session information that expires after a period then you don't need to worry so much about this. Context of the information you're protecting is important to determine time periods you wish to protect it for and you should already be considering this today when choosing protection strategies, IMO.

Cthulhu_ 3y ago
If it's a password, sure, rotating it every once in a while should secure your account if someone has stored a copy of the encrypted (usually hashed) version; that said, rotating passwords is no longer a recommended practice, and second, it's more important for encrypted data, like hard drives, online e2e-encrypted chats, internet usage, images/files, etc. You can change the password / key on those too, but if someone already has a copy of the old password encrypted data it may be cracked later on. In practice this is probsbly reserved for important people I suppose.
rainsford 3y ago
That's an approach that makes sense in theory, but in practice you're almost certainly better off assuming a long time horizon for protecting everything. For one thing, it's not always obvious what's short term vs long term information and you could end up applying short term protection to information that has long term value in a scenario you didn't consider. For example, encrypted session information that expires might not be useful in gaining access to an account, but it could potentially be used to track you in historical data. The other problem is that most systems (and people) aren't great at segregating information that needs short term vs long term protection, so it's hard in practice to have a strategy based on applying different cryptographic protection to different information. Most encrypted protocols and systems deal with a mix of information that ranges from inconsequential if revealed even now to requiring long term confidentiality because it's much harder to try to deal with that information separately. There's also the practical argument that once I have a protocol or system to protect high value, long term info, why wouldn't I just use that for everything? Modern HTTPS is ridiculous overkill for the vast majority of things it protects, but there's really no reason to use something worse even if you could get away with doing so. This is basically the premise of HTTPS everywhere and similar encrypt all the things concepts. It makes a lot more sense to just protect everything instead of trying to figure out what needs protection and what doesn't and hoping you didn't get it wrong or that nothing changes over the years. Same goes for post-quantum crypto. You might be OK not adopting it for things you think don't need protection beyond the time a practical quantum computer comes around (good luck guessing that time horizon btw), but it's both easier and less error prone to just post quantum all the things.

Cthulhu_ 3y ago

If it's a password, sure, rotating it every once in a while should secure your account if someone has stored a copy of the encrypted (usually hashed) version; that said, rotating passwords is no longer a recommended practice, and second, it's more important for encrypted data, like hard drives, online e2e-encrypted chats, internet usage, images/files, etc. You can change the password / key on those too, but if someone already has a copy of the old password encrypted data it may be cracked later on. In practice this is probsbly reserved for important people I suppose.

rainsford 3y ago

That's an approach that makes sense in theory, but in practice you're almost certainly better off assuming a long time horizon for protecting everything. For one thing, it's not always obvious what's short term vs long term information and you could end up applying short term protection to information that has long term value in a scenario you didn't consider. For example, encrypted session information that expires might not be useful in gaining access to an account, but it could potentially be used to track you in historical data. The other problem is that most systems (and people) aren't great at segregating information that needs short term vs long term protection, so it's hard in practice to have a strategy based on applying different cryptographic protection to different information. Most encrypted protocols and systems deal with a mix of information that ranges from inconsequential if revealed even now to requiring long term confidentiality because it's much harder to try to deal with that information separately. There's also the practical argument that once I have a protocol or system to protect high value, long term info, why wouldn't I just use that for everything? Modern HTTPS is ridiculous overkill for the vast majority of things it protects, but there's really no reason to use something worse even if you could get away with doing so. This is basically the premise of HTTPS everywhere and similar encrypt all the things concepts. It makes a lot more sense to just protect everything instead of trying to figure out what needs protection and what doesn't and hoping you didn't get it wrong or that nothing changes over the years. Same goes for post-quantum crypto. You might be OK not adopting it for things you think don't need protection beyond the time a practical quantum computer comes around (good luck guessing that time horizon btw), but it's both easier and less error prone to just post quantum all the things.