Vendor ID from hash of reverse DNS name - collision resistance consideration

I'm considering embarking on an operating system kernel project. One of the "features" that I intend it to have, is a mandatory access control framework that can be purposed to sandbox software vendors to protect user privacy. In this regard, processes need to have additional "vendor" ID, which if were to be fitted in general-purpose registers on CPUs, would only portably have a width of 32 bits. I intend to derive the vender IDs of processes from sources such as reverse DNS notation "software package IDs", which (along with code signing, etc.) are common practice nowadays. Q: Are such 32-bit hash considered sufficient for the purpose of distiguishing software vendors on a running system? Or since it's a MAC framework, I could afford longer hashes in some kind of "buffer" (similar to the limited-in-number supplementary groups in POSIX?)

May 23, 2025 - 17:00

I'm considering embarking on an operating system kernel project.

One of the "features" that I intend it to have, is a mandatory access control framework that can be purposed to sandbox software vendors to protect user privacy. In this regard, processes need to have additional "vendor" ID, which if were to be fitted in general-purpose registers on CPUs, would only portably have a width of 32 bits.

I intend to derive the vender IDs of processes from sources such as reverse DNS notation "software package IDs", which (along with code signing, etc.) are common practice nowadays.

Q: Are such 32-bit hash considered sufficient for the purpose of distiguishing software vendors on a running system? Or since it's a MAC framework, I could afford longer hashes in some kind of "buffer" (similar to the limited-in-number supplementary groups in POSIX?)