Random bytes, drawn either from the system or from a generator whose seed you hold.

Drawing from the system

getRandomBytes in IO is the ordinary way to get bytes nobody can predict. The length is in bytes and the type is any ByteArray, so the result is usually pinned down by where it goes:

import Crypto.Random (getRandomBytes)
import Data.ByteString (ByteString)

nonce <- getRandomBytes 12 :: IO ByteString

Everything in this library that needs randomness takes it the same way, through a MonadRandom m => constraint, so running it in IO is the whole of choosing this source:

import qualified Crypto.PubKey.RSA as RSA

(pub, priv) <- RSA.generate 256 0x10001

Where the operating system offers getrandom(2) or getentropy(3) the bytes come from a ChaCha20 generator belonging to the operating system thread the call runs on, seeded from the system and reseeded as it goes; see Crypto.Random.SysDRG for what that is and what it is not. Where it does not -- Windows, for now -- they come from the system on every call, as they always did. Either way the caller writes the same line.

Any Haskell thread may draw, and none has to say which generator it wants:

import Control.Concurrent (forkIO)

mapM_ (\_ -> forkIO (getRandomBytes 32 >>= use)) [1 .. 64 :: Int]

The generator belongs to the operating system thread that happens to be carrying the Haskell thread when the call is made, and is found through that thread's own storage rather than by anything the caller passes. A forkIO thread moves between capabilities, so two draws from one Haskell thread may be answered by two generators; they are seeded independently of each other, so it makes no difference which one answers.

Drawing from a generator you hold

A generator of your own is the way to draw many times from one seed. The system is asked once, when the generator is made, and not again. That is how tls does a connection: seedNew when it opens, and everything the handshake needs afterwards from the generator, whose state the connection carries from one draw to the next.

import Crypto.Random (ChaChaDRG, drgNewSeed, seedNew, withDRG)

data Connection = Connection { connRNG :: ChaChaDRG }

newConnection :: IO Connection
newConnection = do
    seed <- seedNew                   -- the only draw from the system
    return (Connection (drgNewSeed seed))

-- every later draw advances the connection's own generator
connRandom :: Int -> Connection -> (ByteString, Connection)
connRandom n conn =
    let (bytes, rng') = withDRG (connRNG conn) (getRandomBytes n)
     in (bytes, conn{connRNG = rng'})

Inside withDRG the same getRandomBytes resolves to the instance for MonadPseudoRandom rather than the one for IO, so it touches neither the system nor the per-thread generator: it advances the generator it was given and hands it back. Keep that generator and the bytes are reproducible from the seed, which is what makes a test repeatable -- and what makes a generator unfit for keys unless its seed came from the system.

drgNew is seedNew and drgNewSeed in one step; drgNewTest takes four numbers instead of a seed, for a test that must give the same answer twice.

Drawing from a monad stacked on IO

There are two instances, one for IO and one for MonadPseudoRandom, and none for the transformers, so a ReaderT env IO or a StateT s IO reaches the system through liftIO:

import Control.Monad.IO.Class (liftIO)
import Control.Monad.Trans.Reader (ReaderT)

newKey :: ReaderT env IO ByteString
newKey = liftIO (getRandomBytes 32)

What that draws is what the first section describes, no more and no less: the IO instance, the generator of the operating system thread the call lands on, seeded from the system and reseeded as it goes. liftIO says which monad the draw happens in and nothing about where the bytes come from.

Writing an instance for the stack instead would make the choice invisible at the call site, and the class cannot tell a strong source from a weak one -- see MonadRandom.

When the system will not give any

Drawing randomness is the one thing here with nothing to fall back on, so the failure is an exception rather than a value: there is no sensible Maybe to return and no partial answer worth having. Since 2.2 it is an EntropyError and not a Control.Exception.ErrorCall or an Control.Exception.IOException, which is worth knowing if you were catching one of those:

import Control.Exception (catch)
import Crypto.Random (EntropyError (..), getRandomBytes)

key <- getRandomBytes 32 `catch` \e -> case e of
    NoEntropySource   -> fail "this system offers no randomness at all"
    EntropyShort w g  -> fail (show w ++ " bytes wanted, " ++ show g ++ " arrived")
    EntropySourceLost s -> fail ("the source " ++ s ++ " went away")

Catching it at all is a decision rather than a default. A program that cannot get randomness cannot make a key, and stopping is usually the honest thing; the reason to catch is to say so in the program's own terms rather than in crypton's.