skip to content

What are SecureRandom 'algorithms' like NativePRNG, SHA1PRNG, and DRBG, and how does platform/provider selection affect portability and reproducibility?

level: principalimportance: nice to knowfreq 35%

answer

  1. NativePRNG = reads OS source (/dev/urandom); common Unix default
  2. SHA1PRNG = legacy self-contained; fixed seed -> deterministic
  3. DRBG = NIST SP 800-90A, configurable, modern/FIPS choice
  4. new SecureRandom() picks platform's highest-priority algorithm
  5. Pin getInstance("DRBG") for portability/compliance

basics

~20 s

SecureRandom is provided by named algorithms (NativePRNG reads the OS source, SHA1PRNG is a self-contained generator, DRBG is the modern NIST design). Which you get depends on the platform/provider, so behavior can differ across OSes unless you request one explicitly.

solid answer

~50 s

SecureRandom is a JCA service implemented by named algorithms registered by security providers. NativePRNG delegates to the OS CSPRNG (e.g. /dev/urandom), so it inherits the platform's entropy and is the common default on Unix. SHA1PRNG is a self-contained, JDK-internal generator (now considered legacy) that, if seeded immediately, can be made deterministic. DRBG is the modern, NIST SP 800-90A-based generator (configurable via the jdk.security.provider DRBG settings) and is preferred where you need a standards-based, configurable source. Because new SecureRandom() picks the highest-priority registered algorithm for the platform, the actual implementation can differ across OSes, JDK vendors, and containers — affecting blocking behavior and FIPS posture. For portability or compliance, request an explicit algorithm/provider via SecureRandom.getInstance("DRBG") (and configure it), rather than relying on the platform default. Reproducibility across platforms should never be a goal for security randomness; if a deterministic stream is needed for tests, isolate it.

code

java · 16 lines
java
import java.security.DrbgParameters;
import java.security.NoSuchAlgorithmException;
import java.security.SecureRandom;
import static java.security.DrbgParameters.Capability.PR_AND_RESEED;

class Algorithms {
    // Platform default: implementation varies by OS/provider.
    static final SecureRandom DEFAULT = new SecureRandom();

    // Explicit, standards-based DRBG with prediction resistance + reseed.
    static SecureRandom drbg() throws NoSuchAlgorithmException {
        return SecureRandom.getInstance(
            "DRBG",
            DrbgParameters.instantiation(256, PR_AND_RESEED, null));
    }
}

go deeper

for a junior

Aware that SecureRandom has different underlying algorithms and that the default is chosen by the platform.

for a middle

Can name NativePRNG (OS source), SHA1PRNG (legacy/deterministic-when-seeded), and DRBG (modern) and knows the default varies by OS.

for a senior

Explains provider selection, blocking/entropy implications across platforms, and when to pin an explicit algorithm.

for a principal

Designs for portability/FIPS by configuring providers/DRBG and security properties, anticipates container entropy issues, and prohibits reproducible-stream misuse for key derivation.

## The framework `SecureRandom` is a **JCA (Java Cryptography Architecture)** service. JCA is a provider-based plugin system: **security providers** (SUN, SunJCE, SunPKCS11, BouncyCastle, vendor FIPS modules…) register **implementations** of services under **algorithm names**. You obtain one either by `new SecureRandom()` (platform default) or `SecureRandom.getInstance("<algorithm>")` / `getInstance("<algorithm>", "<provider>")` (explicit). ## The main algorithms **NativePRNG** — Delegates to the **operating system's CSPRNG** (on Linux, `/dev/urandom` and friends). Variants exist (`NativePRNGBlocking`, `NativePRNGNonBlocking`) that map to blocking (`/dev/random`-style) vs non-blocking sources. Pros: uses the OS's well-maintained entropy. This is typically what `new SecureRandom()` selects on Unix. **SHA1PRNG** — A **self-contained** generator implemented inside the JDK (built on SHA-1 hashing of an internal state). It does not depend on the OS source. It is now regarded as **legacy** (not formally specified, and its seeding behavior surprises people). Notably, if you call `setSeed` on it before any output, the seed becomes the entire state → deterministic output. Avoid choosing it explicitly for new code. **DRBG** — The **Deterministic Random Bit Generator** introduced in JDK 9, implementing **NIST SP 800-90A** (Hash_DRBG / HMAC_DRBG / CTR_DRBG). It is configurable through the `securerandom.drbg.config` security property (mechanism, strength, prediction resistance, reseeding) and is the **modern, standards-based** choice, important for FIPS-style requirements. Request it with `SecureRandom.getInstance("DRBG")`. **Windows-PRNG** — The Windows analogue that reads the OS CSPRNG; typically selected by default on Windows. ## Provider/platform selection and its consequences Because `new SecureRandom()` resolves to the **highest-priority registered algorithm for the running platform/provider set**, the *same code* can use **different implementations** on Linux vs Windows vs a hardened FIPS JVM vs a stripped container image. Consequences: - **Blocking behavior** differs (NativePRNG non-blocking vs a blocking strong source) → potential startup stalls in some environments but not others. - **FIPS/compliance**: a FIPS-mode JVM may only permit DRBG or a certified provider; relying on the default can silently violate policy. - **Containers**: minimal images or low-entropy VMs historically caused entropy starvation; modern kernels mitigate this, but it's a known operational gotcha. ## Portability and reproducibility - For **portability/compliance**, pin the algorithm/provider explicitly (`getInstance("DRBG")`, or a named FIPS provider) and configure it via security properties, instead of leaning on the default. - **Cross-platform reproducibility of the random stream must never be a security goal.** SHA1PRNG with a fixed seed happens to be reproducible across JVMs, which historically tempted people to use it for 'deterministic key derivation' — that is a vulnerability, not a feature. Use a proper KDF for derived keys. - For **deterministic tests**, isolate a seeded source behind an interface; never let it leak into production selection. ## Configuration knobs (java.security) - `securerandom.source` — the entropy source URL (e.g. file:/dev/urandom) influencing NativePRNG/SHA1PRNG seeding. - `securerandom.strongAlgorithms` — what `getInstanceStrong()` returns. - `securerandom.drbg.config` — DRBG mechanism/strength/prediction-resistance. ## Practical guidance - App-level tokens/salts/IVs: `new SecureRandom()` is fine. - Standards/FIPS or you want explicit control: `SecureRandom.getInstance("DRBG")` (configured). - Never `SHA1PRNG`-with-fixed-seed for real key material; never rely on cross-platform stream reproducibility.

  • Which algorithm would you choose for a FIPS/standards-driven deployment, and why?
    DRBG — it implements NIST SP 800-90A and is configurable (mechanism, strength, prediction resistance) via security properties, so it satisfies standards-based requirements rather than relying on an unspecified platform default.
  • Why can the same SecureRandom code behave differently across environments?
    new SecureRandom() resolves to the highest-priority registered algorithm for that platform/provider set, so Linux, Windows, FIPS JVMs, and minimal containers may use different implementations with different blocking/entropy behavior.

saying these in an interview costs you the question

  • Using SHA1PRNG + fixed seed as a 'deterministic KDF' across platforms
  • Assuming new SecureRandom() yields the same implementation on every OS
  • Ignoring FIPS mode requirements and relying on the default provider
  • Treating cross-platform stream reproducibility as a desirable property

context

resolving links…