Downgrading hashing algorithm from SHA3 to SHA1 for caching checksum #5711
Replies: 3 comments 2 replies
-
I don't think there is a reason for that. Let's use the fastest possible option if other people agree. Btw, if MD5 is even faster, it sound like even better solution. |
Beta Was this translation helpful? Give feedback.
-
@JaroslavTulach @Akirathan @4e6 Would you be OK with the change? |
Beta Was this translation helpful? Give feedback.
-
So that change is now implemented. But I noticed another place where we use SHA3 extensively - versioning text buffers, used by both IDE and engine (language server). The change would need to be done in lock step and can be potentially disruptive. On the upside, the quicker we do it the easier it is to deal with it later. |
Beta Was this translation helpful? Give feedback.
-
IR caching currently uses SHA3-224 for calculating hashes of individual module sources and their serializations.
The hash is stored in IR metadata and compared during de-serialization.
As noted in documentation this is mostly for consistency since in other places we also seem to stick to SHA3.
Except that in our case we are paying a non-negligible price for using SHA3:
![Screenshot from 2023-02-20 21-47-32](https://user-images.githubusercontent.com/292128/220196853-eadb3a45-1f8d-40dd-be8f-a73839479f1a.png)
![Screenshot from 2023-02-20 21-46-58](https://user-images.githubusercontent.com/292128/220196891-0cfd69f2-7541-4289-afe1-b5f88f829e0f.png)
Compare this with timings when I switched to SHA1:
Is there any particular reason why we stick to a more secure version for a simple checksum? Even plain MD5 should be sufficient.
Beta Was this translation helpful? Give feedback.
All reactions