[DRE-maint] Bug#960066: schleuder: decide about the future of Recommends: haveged

[Georg Faerber]

Package: schleuder
Version: 3.5.1-1
Forwarded: https://0xacab.org/schleuder/schleuder/-/issues/194
Tags: help

Upstream recommends "to run a random number generator like haveged. This
ensures Schleuder won't be blocked by lacking entropy, which otherwise
might happen especially during key generation."

Still there are concerns ([1], other examples do exist) about the
reliability of haveged to provide cryptographically secure randomness:

    can create blocking situations during key generation effectively
    creating a deadlock and thus security problems. haveged's design is
    from 2002, it has never been audited, there're only papers by the
    original authors available. Additionally, the design rationale is
    based on 2002 ISA for architectures like UltraSparc II - these are
    far from relevant these days. The removed section already mentioned
    that haveged's memory footprint is too high for embedded use-cases,
    additionally in most embedded boards the design will not even work.

Quoting further:

    Linux 4.9+ has a new design for `/dev/urandom`: it XORs RdRAND/SEED
    with ChaCha20 (this design is borrowed from Adam Langley's
    implementation in BoringSSL, also used in libsodium) thus providing
    a fast and save interface for cryptographically secure pseudo random
    numbers.

This needs further research and real-world tests.


[1] https://lists.cert.at/pipermail/ach/2017-May/002251.html