Assume an operating system uses digital signatures to ensure executable files can be authenticated and can't be modified; where the digital signatures are constructed by creating a hash of the executable file (e.g. SHA256), encrypting the hash with a private key (e.g. RSA), then attaching the encrypted hash and public key (the signature) to the executable file.
Assume there's 1000 pieces of software (from multiple publishers) that are updated (on average) once per month for 5 years.
An attacker collects the hash and the digital signature for all 60000 pieces of software. The attacker writes their own trojan malware with some spare padding at the end of their executable file. The attacker calculates a partial hash of their executable, but stops (saving hash calculation state) just before the padding.
The attacker resets the hash calculation state, finishes the hash calculation extremely quickly, then checks if the hash corresponds to one of the 60000 digital signatures they've collected. If it doesn't, they increment the padding at the end of their executable file and retry. The attacker does this on multiple (multi-CPU) computers in parallel, until they find something else's signature they can use to sign their malware.
How can this be prevented?
The strength of the encryption scheme is unimportant. Increasing the hash size just means the attacker needs to collect more digital signatures and/or use more CPUs for longer to find a valid signature for their malware. Assume the attacker can get more CPUs by hiding javascript in a popular web page, using cloud services, hiding it in software published with their own legitimate signature (e.g. a crypto-currency mining utility), etc.
Is any existing hash algorithm strong enough?