Internal Checksum method SHA-1

[Thorsten Koch]

Hello,

in the help documentation concerning the SignTool it says:

Note: If you use a Sign Tool and your Setup contains a large amount of data, it is recommended that you enable Disk spanning with DiskSliceSize set to max. If you don't do this, the user might experience a long delay after starting Setup caused by Windows verifying the digital signature against all your data. There should be no security reduction from using disk spanning in practice: all files extracted from the unsigned .bin files undergo SHA-1 verification (provided dontverifychecksum isn't used). The SHA-1 hashes for this (along with all other metadata) are kept inside Setup's EXE, which is protected by the digital signature.

Given the fact that SHA-1 is now compromised (https://borncity.com/win/2017/02/24/warning-sha1-has-been-hacked-successfully)- is this documentation still up do date? Or is SHA256 used internally (as it is already supported by some internal functions).

If SHA-1 is still used, wouldn't is be a good idea to update to SHA256 ?

Kind regards,

Thorsten

[Bill Stewart]

SHA1 for hashing isn't a security issue. (The purpose for storing the hashes is to detect changes, not for encryption.)

[Jernej Simončič]

On Friday, March 19, 2021, 21:30:03, Bill Stewart wrote:

> SHA1 for hashing isn't a security issue. (The purpose for storing the
> hashes is to detect changes, not for encryption.)

In this specific case (ensuring that the signed setup wasn't modified), SHA-1 is used for security, and thus likely ineffective at detecting that with specially crafted files.

--
< Jernej Simončič ><><><><>< https://eternallybored.org/ >

Technologie don't transfer.
-- Conrad's Conundrum (Stentson's Law)

[Martijn Laan]

Still, this isn't an actual weakness is it? Like you said, it requires a specially crafted source file to be able to replace it with another file after compilation without breaking the checksum.

A much easier way to achieve getting the other file installed is simply using it as the source file directly.

Even if the specially crafted file is given to you by someone else they could just give you the other file directly instead, because apparently you trust them otherwise you wouldn't have used either file.

Greetings,
Martijn

[Thorsten Koch]

I think the scenario would be that someone takes an official setup of a "regular" company, then takes the bin file, replaces some of the files inside with malicious files and after this tweeks the file so that the checksum is the same as before. So the last step shouldn't be too easy. Impossible at best.

[Martijn Laan]

> Op 20 mrt. 2021 om 23:00 heeft 'Thorsten Koch' via innosetup <inno...@googlegroups.com> het volgende geschreven:
>
> I think the scenario would be that someone takes an official setup of a "regular" company, then takes the bin file, replaces some of the files inside with malicious files and after this tweeks the file so that the checksum is the same as before

But that is now how the SHA1 weakness works. The files you want to replace need to be specially prepared (by you) for it to work. You can just replace any file.

Greetings,
Martijn

[Martijn Laan]

Op 20-3-2021 om 23:28 schreef Martijn Laan:

You can just replace any file.

*can't*