Hi,
Attached is an updated patch, where I have updated/modified dnsrand_next to
int from uint16_t, so that it is the same as local_id (even though local_id
does discard the upper 16/...bits), just in case there is some issue in
some combination of buildtools/endieness/...
In future / Other possibilities:
In case reading /dev/urandom is considered to be too much overhead or
leading to eating up of entropy in the system from other users perspective
or so, one could change to a two level logic, where /dev/urandom is read
once every 128 or 256 dns queries to (re)set the seed for the random prng
call. And in turn use the random c call for getting the dns query id. As
the random prng is reseeded every 128 or 256 calls, so I am lazily assuming
that its state cant be leaked from such a short run, to allow anyone to
predict the id, before reseeding.
--
Keep ;-)
HanishKVC
Show replies by date
Hi,
Do note that the local_id passed to dnsrand_next requires pre increment for simple counter
based fallback to work.
ie ++local_id rather than local_id++