☰

Fragen zur Generierung von RSA-Schlüsseln mit GnuPG

tag-icon • tag-icon gpg time gnupg
Fragen zur Generierung von RSA-Schlüsseln mit GnuPG

Ich arbeite derzeit an einem Highschool-Projekt, bei dem ich RSA-Schlüssel studiere, um sie theoretisch und praktisch besser zu verstehen. Ein Teil des Projekts besteht aus einem Experiment, bei dem ich testen möchte, wie groß die Arbeitsbelastung für die CPU ist, wenn RSA-Schlüssel unterschiedlicher Länge generiert werden. Ich möchte die Zeit auch als Datenpunkt speichern, falls ich zu einer Schlussfolgerung kommen muss.

Auf der Maschine läuft Ubuntu 16.04 und die Anwendungen werden aus den Standard-Repositorys heruntergeladen.

Der Plan ist, GnuPG zu verwenden, um RSA-Schlüssel unterschiedlicher Länge (1024, 2048 und 4096) zu generieren, und GNU Time, um die Arbeitslast der CPU und die Zeit zur Ausführung des Prozesses zu ermitteln. Der Prozess wird mit einem Python-Skript automatisiert und sieht ungefähr so ​​aus:

  1. Für die Länge in [1024, 2048, 4096]:

    1.1. Für X-mal:

    1.1.1. Führen Sie den Gnu PG-Befehl aus und überwachen Sie die Systemressourcen

    1.1.2. Verwendung der Systemressourcen in Datei schreiben

Ich werde anschließend einige Diagramme erstellen, um zu sehen, ob meine Hypothese zutrifft.

Ich habe jedoch einige Fragen zur Implementierung meines GnuPG-Tests erhalten. Eine Erklärung meiner Implementierung folgt im Anschluss an die Fragen. Meine Fragen sind:

  • Erfüllt diese Einstellung meinen Zweck?
  • Kann ich die automatische Erstellung von Widerrufszertifikaten irgendwie deaktivieren?
  • Warum dauert die Generierung mancher Schlüssel viel länger?
  • Warum gibt GnuPG die Antwort aus, dass die Schlüsselerstellung im Userspace 0 CPU-Sekunden gedauert hat? Wird dies in einem anderen Prozess durchgeführt?
  • Warum zeigt der Parameter „CPU-Arbeitslast“ nur einen Wert (0 < CPU) an, wenn das Erstellen der Schlüssel weniger als eine Sekunde gedauert hat (Uhrzeit > 1)?

Beim Lesen des Handbuchs scheint es, dass die Schlüssel am einfachsten generiert werden können, wenn diese --batchOption aktiviert ist. Ich habe die Optionen in einer Datei mit den folgenden Anweisungen festgelegt:

# Text syntax in this file
#%dry-run

%echo Generating RSA key...

# Don't ask after passphrase
%no-protection

Key-type: RSA
Key-Length: 1024
Name-Real: Real Name
Name-Email: [email protected]
Expire-Date: 0

# Generate RSA key
%commit

%echo Done!

Der Befehl, der diese Datei ausführt, besteht aus zwei Teilen, dem Gnu Time-Teil und dem GnuPG-Teil. Der GNU Time-Befehl sieht folgendermaßen aus:

$ time --format="Wall clock: %e[s], CPU (userspace): %U[s], CPU (workload): %P%"

Und der GnuPG-Befehl ist der folgende.

$ gpg2 --gen-key --homedir=./rsa-keys --batch [filename]

Der Befehl, den ich in meiner Shell ausführe (Fish-Shell, falls das wichtig ist), ist der folgende (GNU Time + GnuPG):

$ time --format="Wall clock: %e[s], CPU (userspace): %U[s], CPU (workload): %P%" gpg2 --gen-key --homedir=./rsa-keys --batch [filename]

Ausgabe des Befehls:

Wall clock: 36.83[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 0.04[s], CPU (userspace): 0.00[s], CPU (workload): 8%
Wall clock: 4.76[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 72.39[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 57.52[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 84.71[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 63.32[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 51.10[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 47.58[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 64.72[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 0.05[s], CPU (userspace): 0.00[s], CPU (workload): 6%
Wall clock: 0.03[s], CPU (userspace): 0.00[s], CPU (workload): 11%
Wall clock: 29.62[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 55.02[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 36.08[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 42.92[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 40.41[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 204.36[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 246.42[s], CPU (userspace): 0.00[s], CPU (workload): 0%
Wall clock: 51.50[s], CPU (userspace): 0.00[s], CPU (workload): 0%

Antwort1

GnuPG liest von /dev/random, das blockiert, wenn nicht genügend Entropie verfügbar ist (Das ist ein fragwürdiges Verhalten). Der tatsächliche Rechenaufwand ist eher vernachlässigbar. Sie werden vielleicht auch feststellen, dass der erste Durchlauf/die ersten paar Durchläufe schneller beendet werden, da der Entropiepool noch mit „frischen Bits“ gefüllt war. Ich empfehle, watch cat /proc/sys/kernel/random/entropy_availin einem zusätzlichen Terminal zu laufen, um ein Verständnis zu bekommen, wann GnuPG in einen „Niedrigen-Entropie“-Modus läuft.

Auf aktuellen Hardwareplattformen werden durch E/A blockierte oder im Ruhezustand befindliche Prozesse in den Hintergrund gestellt, sodass keine CPU-Zeit berücksichtigt wird.

$ time --format='Wall clock: %e[s], CPU (userspace): %U[s], CPU (workload): %P%' sleep 5
Wall clock: 5.00[s], CPU (userspace): 0.00[s], CPU (workload): 0%

Dies ist auch sichtbar, wenn einige Bytes kopiert werden /dev/random(was insbesondere in virtuellen Maschinen einige Zeit in Anspruch nehmen kann):

time --format='Wall clock: %e[s], CPU (userspace): %U[s], CPU (workload): %P%' dd if=/dev/random of=/dev/null bs=1 count=512
512+0 records in
512+0 records out
512 bytes copied, 210.672 s, 0.0 kB/s
Wall clock: 210.67[s], CPU (userspace): 0.00[s], CPU (workload): 0%

Dies erklärt schließlich auch, warum die schnellen Iterationen eine viel höhere CPU-Auslastung hatten: Da die Prozesse für einen viel kürzeren Zeitraum im IO-Wait blockiert waren, ist der Anteil der tatsächlichen Rechenzeit an der gesamten Ausführungszeit viel größer.

verwandte Informationen