You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given that crypto/Rand uses /dev/urandom or its equivalent on on other platforms, are there any good reasons not to switch away from math/Rand to crypto/Rand.
Indeed, your own documentation seems to suggest this would be a good idea, because you state (in irtt-server man page) that:
Allowing non-random fills insecure on public servers
But then you're not really doing much to help secure public servers if you then go and use math/Rand.
At least if you are not willing to replace it, you should provide crypto/Rand as a config option, e.g. --fill=crypto.
The text was updated successfully, but these errors were encountered:
udf2457
changed the title
Switch to crypto/Rand
Consider switching to crypto/Rand
Feb 20, 2022
The reason not to switch to crypto by default is the increased CPU needed.
The concern in the doc was not that someone would send pseudo-random data in the payload, but that someone could use the payload as a covert channel. I'm not sure how serious an issue that is, so I'm not sure that math/Rand is being used in an insecure way here.
If there's a need, I could add crypto/Rand as an additional option at some point, if the binary size doesn't inflate too much.
Given that
crypto/Rand
uses/dev/urandom
or its equivalent on on other platforms, are there any good reasons not to switch away frommath/Rand
tocrypto/Rand
.Indeed, your own documentation seems to suggest this would be a good idea, because you state (in
irtt-server
man page) that:But then you're not really doing much to help secure public servers if you then go and use
math/Rand
.At least if you are not willing to replace it, you should provide
crypto/Rand
as a config option, e.g.--fill=crypto
.The text was updated successfully, but these errors were encountered: