According to this report : http://www.ecrypt.eu.org/csa/documents/D5.4-FinalAlgKeySizeProt.pdf
SHA2-512, SHA3-512, Whirlpool and Blake2b are hash functions that could be safe for the next 50 years.

For a system that will never receive security updates, to hash passwords, what of these 4 functions should I use for maximum security ?

  • $\begingroup$ As long as a hash function has preimage resistance, password choice is more critical to long term security than algorithm choice. Using the string "Password1" will be a bad decision no matter how advanced of a password hashing algorithm you have. At the other extreme, any one-way function, like SHA-2, suffices if brute-forcing the (randomly generated) password is as difficult as brute-forcing a key. $\endgroup$ Commented Oct 25, 2019 at 20:36
  • $\begingroup$ @JamesReinstateMonicaPolk a quantum computer will not break these algorithms, rather weaken their bits of security. $\endgroup$ Commented Nov 27, 2019 at 7:52
  • $\begingroup$ @09182736471890: I actually know that, I have no idea what I was thinking of when I wrote that comment. Deleting it now. $\endgroup$ Commented Nov 27, 2019 at 22:48

2 Answers 2


None. Cryptographic hashes are not directly suitable to store password hashes.

You should use a password hash (also known as a Password Based Key Derivation Function or PBKDF if it is used to derive a key) such as one of the secure variants of Argon2 to store passwords, not a generic cryptographically secure hash function.

However, if you're working with passwords then not updating your security for 50 years is madness; there is a lot of debate on the security of passwords as it is. Passwords generally only deliver a certain amount of security, often in the range 30-50 bits. That already doesn't provide enough entropy, let alone in 50 years time.

Password hashes add a work factor, but in 50 years this work factor may well have become insignificant due to progress in chip manufacturing. So the additional work factor (e.g. introduced by an iteration count) has become a much smaller hurdle to take. Note that finding passwords is an easily parallelized task, so it is not very dependent on single core CPU speeds.

You could also go for 128 or even 256 bits of security and let people write down a randomly generated password / key instead (for instance as 32 / 64 hexadecimal digits). That way you could use a simple hash just to hide the password / key at rest. For this you could use one of the hash algorithms above; I'd go for SHA-3. However, due to the larger password, your password management becomes more complicated as humans will probably not be able to remember it.

This can be solved by having people use a password manager that is secured with an easy to remember / less complex password or phrase. Such a password manager should then be directly available to hackers. Another advantage of using a password manager is that the passwords can be updated if a password has possibly become vulnerable in any way.

Similarly you could encrypt with e.g. a large EC public key and protect the private key of the key pair. However, most common asymmetric algorithms are vulnerable against quantum computers. Those could well become large and interconnected enough in the next 50 years. Post Quantum Cryptography is by and large still the domain of specialists (even more than common modern crypto).

  • $\begingroup$ There may be other solutions that are applicable in your problem domain (which we don't know), but this is a relatively generic solution that should work. $\endgroup$
    – Maarten Bodewes
    Commented Jul 24, 2018 at 13:26
  • $\begingroup$ Thanks a lot. I'm planning it for 50 years because the update process needs manual intervention (it's for a embedded system with no internet). I'm considering to switch to something else for passwords. However, If I need to get the checksum of a file, is SHA3 good enough ? (To prevent a file from being edited with a collision attack like with MD5 en.wikipedia.org/wiki/MD5#Security) $\endgroup$
    – user60569
    Commented Jul 24, 2018 at 17:37
  • 11
    $\begingroup$ @Myrage2000 If you are designing a system like that, you really need a threat model. Then you demonstrate that you are safe against that threat model. Much of the time, generic advice is good and useful, but if you're pushing the limits of what can possibly be said about cryptography, it's worth your time to actually do a one-off analysis of your unique individual problem. $\endgroup$
    – Cort Ammon
    Commented Jul 24, 2018 at 19:03
  • 4
    $\begingroup$ At the moment I am unaware of any cryptographic algorithm that has survived unbroken for 50 years, though RSA is getting up there. Someone with more experience may be able to correct me on that. Given our track record, you'll at least want to define what "safe" means to you on the 50 year scale. $\endgroup$
    – Cort Ammon
    Commented Jul 24, 2018 at 19:06
  • 6
    $\begingroup$ @CortAmmon I'm unaware of any implementation of RSA or other cryptographic algorithm where serious bugs (or design decisions in retrospective) aren't found every other year. This seems to be the much larger issue at hand. Who cares if the mathematical algorithm is theoretically sound for eternity, if someone finds a serious issue in the implementation (or the used hardware) next year? (from this point of view it might even make sense to go with the most tested implementation of an older algorithm instead of going with the latest , coolest algorithm) $\endgroup$
    – Voo
    Commented Jul 25, 2018 at 9:17

As Maarten writes you should use specialized password hashing algorithms and not generic hash functions.

But I would like to discuss the futility of planning for 50 years into the future. It's really impossible to know what the future so far ahead has in store for us. There could be all kind of changes we can't even imagine now.

Nevertheless our best bet for what will change in 50 years, is to look back 50 years ago. In the last 50 years everything changed. Cryptography was reinvented. We didn't even have DES 50 years ago, let alone anything we consider secure. We didn't salt passwords, we didn't have memory hard functions or side channel attacks or anything we consider essential now.

The oldest password hashing which gives some security is probably the unix crypt based on DES; it had a salt and iterations to slow it down. But it only supported 8 byte passwords, couldn't tune the iteration count, and had small salt. And that was 40 years ago.

Perhaps cryptography will plateau and our best crypto of today will hold. But I won't give you very good odds for that.

We may find specific weaknesses in whatever you chose, we may find broad new generic attacks. We may discover there are no one-way functions at all.

Planning crypto for 50 years in the future is a futile exercise.

  • $\begingroup$ Thanks. This is for a embedded system with no internet so it requires manual intervention to update it. This is why I'm planning it for 50 years. $\endgroup$
    – user60569
    Commented Jul 24, 2018 at 17:30
  • 2
    $\begingroup$ nobody knows what will hold in 50 years. But you can be paranoid today and hope for the best. Use the best, make no compromises and you have a chance. With embedded you mayvjave to compromise due to performance. For password hashing argon2i is a safe choice(except for being a bit new) for file fingerptinting sha3. $\endgroup$
    – Meir Maor
    Commented Jul 24, 2018 at 18:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.