# Using system time in nano-seconds as source of entropy in a smart contract

I am working on a smart-contract to be deployed on ETH chain.

I am using an oracle(not the company!) system to get the information from off-chain (outside of the blockchain). Basically, we can think of the oracle as an API call which returns a random number. But for this api call I need a random seed.

Questions:

1. Can I use last few digits of system time (in nano or milli seconds) as the seed?
2. Since I don't really trust the randomness of the oracle provider, I would like to multiply the result of the random number with the system time again,

Does that make sense? Can the randomness of this number be used for encrypting sensitive data? Does that sound like a good idea?

P.S. Frequency of this call will be around 10 calls per minute.

New contributor
Marci-man is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
• Are you sure that the precision of the timer is really nano-seconds? I'm really doubting it. Jun 22 at 15:03

Can I use last few digits of system time (in nano or milli seconds) as the seed?

That not a good idea:

• It's hard to tell with which accuracy an adversary could get to know your system time. Often it's openly disclosed by some process open to the outside (e.g. an https server, or log system). Best practice is to consider system time is not secret.
• The API to get system time in nanosecond often has a much coarser granularity. For example, on my Windows 10 machine, _timespec64_get always returns a multiple of 100 (thus 0.1 μs granularity). And that's closer to the best case than from the worse: often that's millisecond, sometime second.
• Each decimal digit contains < 3.33 bit of information, thus 9 digits give at best < 30 bits of information, which is not enough for a key/challenge/nonce.
• Depending on environment, the problem of obtaining entropy is already solved in much more robust ways: /dev/urandom (Unix/Linux), CryptGenRandom (Windows), SecureRandom (Java), secrets (Python).

Since I don't really trust the randomness of the oracle provider, I would like to multiply the result of the random number with the system time again.

It does make sense to combine several sources of entropy, but care must be exercised. Multiply is not suitable: e.g. if the oracle provider returns zero, then multiplying that with anything still yields the constant 0. One option for independent inputs is using a group binary operation, so that the combination is at least as good as the two inputs. The simplest possible group binary operation for combining independent entropy sources is bitwise exclusive OR. There are better ways, including suitable for dependent entropy sources, see comment.

Can the randomness of this number be used for encrypting sensitive data?

For modern security, a symmetric encryption key should have 128 bit of entropy, and there's reason to believe we are short of that. More generally, I fear the question is indicative of insufficient knowledge to design a system requiring encryption.

• Xor is only good to combine independent entropy sources. There are very few circumstances where it's a good choice. Instead, pass all the entropy as input(s) to a CSPRNG. Or at the very least through a key derivation function such as HKDF. 2 days ago