2015-05-27 15:42 GMT+02:00 Joel Rees <joel.r...@gmail.com>: > On Tue, May 26, 2015 at 9:50 PM, Simon > <openbsd.li...@whitewinterwolf.com> wrote: > > [...] > > > > Unless specific cases, I do not think that programmers assume that PID > > are especially sequential or not, but merely rely on the hypothesis > > that: > > > > - PID are unguessable, > > - PID will not be reused quickly. > > > > And yes, it seems possible to fulfill these two properties by > > providing unguessable and not quickly reusable PID instead of pure > > random PID. > > But not in 16 bits. > > To a patient remote attacker, the difference between 2 minutes and 2 > days is not significant. > > 64 bit PIDs anyone? High 16 and low sixteen randomized and the middle > 32 backwards sequential, just to really throw the unwary attacker off > the trail? ;-/ > > Having a part of the PID being sequential and a part being random is non-sense.
The more bit you throw in the random part, the less chance you have to have collision. The more bit you throw in the sequential part, the more time you have before you start to have a chance to have a collision. Problem is, those bit turn into power of two. So going from 16bit to 8bit is the same as going from 65,536 to 256. OpenBSD found a way out of this problem. All the bits used in a PID are random and you have to wait for an arbitrary 100 PID before you start to have a chance to get duplicate. But like Theo said, the problem is that PID shouldn't have been used in the first place.
