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
We discovered that various routines pass a deterministic randomness source to RSA routines in tests to guarantee deterministic output (which is fine) but then they also end up implicitly relying on the fact that each RSA routine reads a certain amount of randomness given certain inputs (which is maybe not fine), which sets up the next read from that randomness source a certain way. If RSA were to read extra bytes, it would break the future reads from the random source.
https://golang.org/cl/63912 adds tests for this in dev.boringcrypto, to match Go 1.9, but @agl suggests that maybe we should break this code, to reserve future flexibility for crypto/rsa. It would suffice to read just a few extra bytes, and the randomness here does not have to be crypto-strength. Something like:
c := make(chan int)
close(c)
var n int
select {
case <-c:
n = 0
case <-c:
n = 1
case <-c:
n = 2
case <-c:
n = 3
}
would be good enough, or we could expose the runtime's fastrand to crypto/rsa.
rsc
changed the title
proposal: crypto/rsa: vary amount of randomness used by operations
crypto/rsa: vary amount of randomness used by operations
Oct 16, 2017
We discovered that various routines pass a deterministic randomness source to RSA routines in tests to guarantee deterministic output (which is fine) but then they also end up implicitly relying on the fact that each RSA routine reads a certain amount of randomness given certain inputs (which is maybe not fine), which sets up the next read from that randomness source a certain way. If RSA were to read extra bytes, it would break the future reads from the random source.
https://golang.org/cl/63912 adds tests for this in dev.boringcrypto, to match Go 1.9, but @agl suggests that maybe we should break this code, to reserve future flexibility for crypto/rsa. It would suffice to read just a few extra bytes, and the randomness here does not have to be crypto-strength. Something like:
would be good enough, or we could expose the runtime's fastrand to crypto/rsa.
/cc @agl @FiloSottile
The text was updated successfully, but these errors were encountered: