ethereum/go-ethereum · critical
Could not create random uuid: %v
Error message
Could not create random uuid: %v
What it means
newKeyFromECDSA assigns each freshly generated keystore key a random UUID (uuid.NewRandom). UUID generation requires OS entropy; if that fails the library cannot produce a valid key file identifier and panics with the underlying error. This is effectively an unrecoverable environment failure, not a usage error.
Source
Thrown at accounts/keystore/key.go:135
addr, err := hex.DecodeString(keyJSON.Address)
if err != nil {
return err
}
privkey, err := crypto.HexToECDSA(keyJSON.PrivateKey)
if err != nil {
return err
}
k.Address = common.BytesToAddress(addr)
k.PrivateKey = privkey
return nil
}
func newKeyFromECDSA(privateKeyECDSA *ecdsa.PrivateKey) *Key {
id, err := uuid.NewRandom()
if err != nil {
panic(fmt.Sprintf("Could not create random uuid: %v", err))
}
key := &Key{
Id: id,
Address: crypto.PubkeyToAddress(privateKeyECDSA.PublicKey),
PrivateKey: privateKeyECDSA,
}
return key
}
// NewKeyForDirectICAP generates a key whose address fits into < 155 bits so it can fit
// into the Direct ICAP spec. for simplicity and easier compatibility with other libs, we
// retry until the first byte is 0.
func NewKeyForDirectICAP(rand io.Reader) *Key {
randBytes := make([]byte, 64)
_, err := rand.Read(randBytes)
if err != nil {
panic("key generation: could not read from random source: " + err.Error())
}View on GitHub (pinned to 6bb0588ad8)
Solutions
- Ensure /dev/urandom exists and is readable inside the environment (docker run with a proper /dev).
- On VMs, install haveged or a virtio-rng device so entropy is available.
- Check the wrapped error in the panic message to identify the blocked syscall and adjust the sandbox policy.
- Retry key creation once the entropy source is fixed; pre-existing keys are unaffected.
Defensive patterns
Strategy: try-catch
Prevention
- Run key generation only on hosts with a working OS entropy source.
- In containers, verify /dev/urandom is mounted and readable.
- Use haveged/virtio-rng on entropy-starved VMs.
When it happens
Trigger: Any key creation path — newAccount, account creation in geth/clef, NewKeyForDirectICAP — on a system where the entropy source is broken: exhausted entropy in a container/VM, /dev/urandom unavailable, or a hardened runtime blocking random reads.
Common situations: Minimal Docker images or chroots without /dev/urandom properly mounted, early-boot VMs with low entropy, restrictive seccomp/sandbox profiles blocking getrandom(2).
Related errors
- key generation: could not read from random source:
- key generation: ecdsa.GenerateKey failed:
- reading from crypto/rand failed:
- nil chainID
- error decoding contract deployer hex %s: %v
AI-assisted analysis of ethereum/go-ethereum@6bb0588ad8 (2026-08-15).
Data as JSON: /api/errors/5ac9cee66673dbcc.
Report an issue: GitHub.