3 ms·

I'd probably be looking at a shorter timeline, just because of the Harvest Now, Decrypt Later strategy[0]. [0]: https://en.wikipedia.org/wiki/Harvest_now,_decr

I'd probably be looking at a shorter timeline, just because of the Harvest Now, Decrypt Later strategy[0]. [0]: https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later

Frost1x 3y ago
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.
Strilanc 3y ago
You also probably want post-quantum crypto if you're making anything that can be updated, and there's a chance the thing may sit in a drawer for 10 years before being connected to the internet. The crypto you use to authenticate an update's origin needs to still be secure at take-out-of-drawer time.
mthiim 3y ago
True - on the other hand, that fear/principle could be applied to all algorithms that could theoretically be broke in the future. There's a lot of uncertainty concerning the scalability of quantum computers and quantum error corrections. In the neare future it seems more likely that the post-quantum algorithms might be broken (even on normal computers) compared to quantum computers cracking RSA/ECC (so one should at least combine to get the best of both worlds)

Frost1x 3y ago

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.

Strilanc 3y ago

You also probably want post-quantum crypto if you're making anything that can be updated, and there's a chance the thing may sit in a drawer for 10 years before being connected to the internet. The crypto you use to authenticate an update's origin needs to still be secure at take-out-of-drawer time.

mthiim 3y ago

True - on the other hand, that fear/principle could be applied to all algorithms that could theoretically be broke in the future. There's a lot of uncertainty concerning the scalability of quantum computers and quantum error corrections. In the neare future it seems more likely that the post-quantum algorithms might be broken (even on normal computers) compared to quantum computers cracking RSA/ECC (so one should at least combine to get the best of both worlds)