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
patch_20220505IST0032_urandomid_against_dnspoison.patch
Description: Binary data
_______________________________________________ devel mailing list -- devel@uclibc-ng.org To unsubscribe send an email to devel-le...@uclibc-ng.org
