0

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?)

DannyNiu
  • 372

1 Answers1

1

32 bits is grossly inadequate.

If you're using a non-randomized hash, the attacker merely needs to try 2^32 candidate domain names to find one that matches the target. That's trivial on modern systems. Even if you use a slow, memory-intensive hash, some targets are valuable enough to spend hundreds of thousands of dollars setting up a compute farm.

If you're using a randomized hash, the birthday paradox applies: one time in 2^16, the program will start up with a hash matching that of some other program. This isn't reliable enough for a targeted attack against a specific program run by a specific person, but for a "spray and pray" attack to scrape things like passwords or cryptocurrency wallets, it'll have a high enough success rate to be worth doing.

Mark
  • 363