What causes "error while generating ed25519 keys: %s" in slackhq/nebula?

Check the wrapped message for the underlying rand failure (e.g. 'getrandom: function not implemented')

error while generating ed25519 keys: %s

Error message

error while generating ed25519 keys: %s

What it means

Wraps a failure from ed25519.GenerateKey(rand.Reader) when generating the CA key pair for the 25519 curve in `nebula-cert ca`. Ed25519 key generation essentially only fails when the system cryptographic random source is unavailable.

Source

Thrown at cmd/nebula-cert/ca.go:277

			return fmt.Errorf("error while creating PKCS#11 client: %w", err)
		}
		defer func(client *pkclient.PKClient) {
			_ = client.Close()
		}(p11Client)
		pub, err = p11Client.GetPubKey()
		if err != nil {
			return fmt.Errorf("error while getting public key with PKCS#11: %w", err)
		}
	} else {
		switch *cf.curve {
		case "25519", "X25519", "Curve25519", "CURVE25519":
			if fips140.Enforced() {
				return errors.New("use of Curve25519 is not allowed in FIPS 140-only mode")
			}
			curve = cert.Curve_CURVE25519
			pub, rawPriv, err = ed25519.GenerateKey(rand.Reader)
			if err != nil {
				return fmt.Errorf("error while generating ed25519 keys: %s", err)
			}
		case "P256":
			var key *ecdsa.PrivateKey
			curve = cert.Curve_P256
			key, err = ecdsa.GenerateKey(elliptic.P256(), rand.Reader)
			if err != nil {
				return fmt.Errorf("error while generating ecdsa keys: %s", err)
			}

			// ecdh.PrivateKey lets us get at the encoded bytes, even though
			// we aren't using ECDH here.
			eKey, err := key.ECDH()
			if err != nil {
				return fmt.Errorf("error while converting ecdsa key: %s", err)
			}
			rawPriv = eKey.Bytes()
			pub = eKey.PublicKey().Bytes()
		default:

View on GitHub (pinned to dd8f660c0a)

Solutions

Check the wrapped message for the underlying rand failure (e.g. 'getrandom: function not implemented')
Ensure /dev/urandom is available and readable inside the container/sandbox
Upgrade the kernel or container runtime so getrandom(2) is supported
Retry — transient entropy pressure typically resolves on retry

Defensive patterns

Strategy: try-catch

Validate before calling

// preflight: ensure the OS random source is readable
if _, err := os.ReadFile("/dev/urandom"); err != nil {
	return fmt.Errorf("entropy source unavailable: %w", err)
}

Try / catch

out, err := exec.Command("nebula-cert", "ca", "-curve", "25519", ...).CombinedOutput()
if err != nil && strings.Contains(string(out), "error while generating ed25519 keys") {
	log.Printf("key generation failed (entropy?): %s", out)
	// retry or fail fast with guidance on /dev/urandom
}

Prevention

Verify /dev/urandom and getrandom(2) work in your container image
Run a one-line entropy preflight in CI before cert issuance
Avoid kernels/runtimes that stub out getrandom
Prefer P256 in FIPS-restricted environments where 25519 is blocked anyway

When it happens

Trigger: nebula-cert ca -curve 25519 (or any 25519 alias) when crypto/rand.Reader cannot read from the OS entropy source (e.g. getrandom(2) fails, /dev/urandom unreadable, blocked entropy in constrained containers).

Common situations: Containers with restricted /dev/urandom access; kernels lacking getrandom; sandboxed environments blocking the random syscall; heavily depleted entropy pools on embedded Linux.

Related errors

AI-assisted analysis of slackhq/nebula@dd8f660c0a (2026-09-03). Data as JSON: /api/errors/b84a2e14b2da445c. Report an issue: GitHub.