GeezerVison

Why use a cryptographic hash at all? Why not use .GetHashCode()?

We need a stable result but the GetHashCode could be randomized.

I believe GetHashCode() in .NET Core is now randomized as Ilya (@iSazonov) stated and we need something stable

CRC and MD5 are stable and both take less computation than SHA1. I don't believe this is a security issue, if it is, we shouldn't use SHA1. CRC is relatively simple to calculate we can implement it ourselves as I don't see anything to calculate it in DotNet Core.

https://github.com/dotnet/corefx/search?utf8=%E2%9C%93&q=crc32&type=

but I don't understand how much we will win.

I presume that this has to be calculated at most every startup. Switching to a less intensive hash algorithm will reduce our startup time which is a big factor in how people perceive performance.

cc Dongbo Wang (@daxian-dbw)

Travis Plunk (@TravisEz13) and I discussed this offline yesterday and I agree that we should go with CRC. The main gain is to potentially avoid loading System.Security.Cryptography.Algorithms.dll at powershell startup time, plus there is also gain in CPU time when running the hash algorithm. I will do this change as part of my startup improvement work.

Got this chart from StackOverflow about the collision rate of CRC32:

In our scenario, hashing would be done on each powershell core installation on a machine, and in case of any experimental features is enabled, the combination of feature names. I think 100 different hash inputs should be a fair large number for a local machine environment in our scenario, and thus the collision rate would be less than 1 in a million, which should be good.

We could use SSE from System.Runtime.Intrinsics.Experimental. We get this in runtime after .Net Core 3.0 release.