crypton-2.2.5: Cryptography Primitives
LicenseBSD-style
MaintainerVincent Hanquez <vincent@snarc.org>
Stabilityexperimental
PortabilityGood
Safe HaskellSafe-Inferred
LanguageHaskell2010

Crypto.Random.Entropy.Unsafe

Description

 
Synopsis

Documentation

replenish :: Int -> [EntropyBackend] -> Ptr Word8 -> IO () Source #

Refill the entropy in a buffer

Call each entropy backend in turn until the buffer has been replenished.

Throws EntropyError: NoEntropySource when there is no backend at all, and EntropyShort when three passes over the backends still leave the buffer unfilled.

data EntropyError Source #

The system would not give the entropy it was asked for.

This is the one failure in the library with nothing to fall back on and nothing sensible to return: a key drawn from bytes that are not random is worse than no key. It used to be reported with error and fail, which left a caller no way to tell it from a bug in the library, and no way to say anything useful about it.

Constructors

NoEntropySource

The system offers no source of entropy at all. On Unix that means no getrandom(2), no getentropy(3) and no /dev to read from; a container built from nothing would look like this.

EntropyShort Int Int

The sources between them gave fewer bytes than were asked for, three times over. The two numbers are how many were wanted and how many arrived.

EntropySourceLost String

A source that could be opened once could not be opened again. The string names it.

data EntropyBackend Source #

Any Entropy Backend

supportedBackends :: [IO (Maybe EntropyBackend)] Source #

All supported backends, best first.

The system call comes before everything else: it is the kernel's own generator, it needs no descriptor, and it is what the rest of the world reaches for now. The device files are what is left when the system has no such call.

RDRAND is deliberately not here, though it used to be first on x86. A list like this one is a list of alternatives, and whichever answers first decides the bytes on its own -- which is the one thing #298 says RDRAND should not do. Nor does it contribute anywhere else: every system this builds for already feeds the instruction into the pool the call above draws from, so asking it again adds nothing. See the note in cbits/crypton_sysdrg.c.

gatherBackend Source #

Arguments

:: EntropyBackend

An open Entropy Backend

-> Ptr Word8

Pointer to a buffer to write to

-> Int

number of bytes to write

-> IO Int

return the number of bytes actually written

Gather randomness from an open handle