On one hand it means that your software and protocols can outlast the algorithm (so you’re creating software intended to be functional and secure in 10-25 years time without modifying its protocols and/or data formats in that time).

On the other hand the pluggable algorithm approach introduces a completely new class of errors and insecurity:

- You introduce an additional layer of abstraction that must be coded securely, increasing the footprint of highly trusted code.

- Is the protocol negotiation secure with respect to algorithm choice, or can an attacker force the use of a weak algorithm, defeating the entire point of pluggable algorithms?

- Can the attacker mix & match algorithms (e.g. use the same RSA keypair with SHA1, SHA256 and SHA512)? This can provide a way to extract sensitive information from the system.

- Deciding what algorithm(s) to use is always a trade-off. This approach moves part of the trade-off decision from the developer to the end-user, but most end-users are completely unable to take an appropriate decision.

It is also well-worth noting that SHA-1 was never meant to be secure for “36 billion years”. If you take a look at NIST SP800-57 you will see that a 160-bit hash function has 80 bits of security in digital signatures and hash-only applications, and should only be used for a security lifetime ending in 2010! Applied cryptographers have long considered 80 bits of security to be insufficient for long-term (10-20 years) security.

NISTs computations take into account the current state of the art (approx. 2^54 computations per second on dedicated hardware by a hostile adversary with government-level resources), Moore’s law, historical rate of breakthroughs in algorithm or number analysis, and other factors.

And the XKCD comic is fairly stupid; I mean it’s clearly a joke and ignores the real world, everyday, totally valid uses of encryption.