1. Forum
  2. Usenet
  3. LINUX.DEBIAN.USER.GERMAN

  • Entropie seit Buster

    From Paul Muster@21:1/5 to All on Mon Aug 28 14:50:01 2023
    Hallo,

    seit eine Xen-VM auf Buster ge-upgrade-t wurde, ist der
    Entropie-Speicher immer bei 256 Bytes. Auch haveged und rng-tools ändern
    daran nichts. Vor dem Upgrade war der Pool durch haveged immer auf ca.
    1.800 Bytes gehalten worden.

    Fehlermeldungen oder Warnungen von Services/Serverdiensten tauchen
    allerdings auch nicht auf. Dies war früher der Fall, wenn die Entropie
    nicht ausreichte, um z.B. TLS-Verbindungen sicher aufzubauen.

    Nun steht im Internet, dass moderne Kernel den Entropie-Pool sehr
    schnell nachfüllen und daher nicht viel als Reserve vorgehalten werden
    müsse. Ein Test mit 'cat /dev/random > datei' in einer und 'watch -n1
    cat /proc/sys/kernel/random/entropy_avail' in einer anderne Konsole
    ergibt kein Abfallen des Werts. Und die Datei wird schnell größer,
    sodass ich den Eindruck habe, es werde in der Tat viel Entropie vom
    Kernel nachgeliefert.

    Ist also alles fein und ich kann mich wieder hinlegen? Oder gibt es bei
    der Entropie doch etwas zu tun?


    Danke & viele Grüße

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Steigerwald@21:1/5 to All on Thu Aug 31 13:40:02 2023
    Hi Paul, hallo,

    Paul Muster - 28.08.23, 14:36:23 CEST:
    Ist also alles fein und ich kann mich wieder hinlegen? Oder gibt es bei
    der Entropie doch etwas zu tun?

    Meines Wissens liefert der Kernel mittlerweile sowohl wie bislang sowohl
    f�r "/dev/urandom" als neuerdings eben auch f�r "/dev/random" schnell
    genug neue Werte. Jedoch sind das ohne ausreichende Entropie Pseudo- Zufallszahlen. Im Englischen hei�t dieses Verhalten "non blocking". D.h. "/dev/random" blockiert au�er offenbar bei einigen Architekturen beim
    Booten grunds�tzlich nicht mehr (lange).

    Detaillierter gibt es das unter anderem in:

    Won't the new nonblocking architecture for /dev/random make it less
    secure?

    https://unix.stackexchange.com/questions/694419/wont-the-new-nonblocking-architecture-for-dev-random-make-it-less-secure

    Aber ich gehe auch jede Wette ein, dass Linux Weekly News (lwn.net)
    dar�ber geschrieben hat.

    Wahrscheinlich gibt es dazu noch eine deutlich pr�zisere und
    vollst�ndigere Antwort, aber das ist, was mir gerade dazu als Ungef�hr-
    Wissen in den Sinn kommt.

    Ciao,
    --
    Martin

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Muster@21:1/5 to All on Fri Sep 1 14:50:01 2023
    Am 31.08.2023 um 13:37 schrieb Martin Steigerwald:
    Martin Steigerwald - 31.08.23, 13:35:37 CEST:

    Meines Wissens liefert der Kernel mittlerweile sowohl wie bislang sowohl
    für "/dev/urandom" als neuerdings eben auch für "/dev/random" schnell
    genug neue Werte. Jedoch sind das ohne ausreichende Entropie Pseudo-
    Zufallszahlen. Im Englischen heißt dieses Verhalten "non blocking".
    D.h. "/dev/random" blockiert außer offenbar bei einigen Architekturen
    beim Booten grundsätzlich nicht mehr (lange).

    Da ist ein "sowohl" zu viel. Und "neuerdings" trifft es auch nicht mehr so ganz. Die Änderungen im Kernel dazu sind schon länger her.

    Ja, schon länger her. Für Debian stable-Anwender griffen sie mit dem
    Wechsel auf Buster.

    Danke dir für die Ausführungen. Ich nehme mit: Das passt so und stellt
    kein Problem dar.


    Viele Grüße

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)