kernel: alg: aead: Test 3 failed on encryption for rfc4106-g

Du kommst mit der Installation nicht voran oder willst noch was nachfragen? Schau auch in den "Tipps und Tricks"-Bereich.
TomL
Beiträge: 3088
Registriert: 24.07.2014 10:56:59

kernel: alg: aead: Test 3 failed on encryption for rfc4106-g

Beitrag von TomL » 14.02.2017 10:44:43

Moin

So langsam nähere ich mich dem Punkt, an dem alle Unwägbarkeiten meiner neuen Stretch-Installation beseitigt sind. Die folgende Meldung im Journal sehe ich schon länger, aber weil bisher alles gut lief, habe ich das erst mal hinten an gestellt.

Code: Alles auswählen

journalctl -b -p err
Feb 14 10:05:11 thomaspc kernel: alg: aead: Test 3 failed on encryption for rfc4106-gcm-aesni
Feb 14 10:05:11 thomaspc kernel: alg: hash: Test 14 failed for crc32c-intel
Das hat -so weit ich das herausfinden konnte- mit der ipsec-AES-Verschlüsselung durch den Kernel zu tun. Passend zur Fehlermeldung gibts auch einen rfc-Text dazu:
https://tools.ietf.org/html/rfc4106

Ich vermute nun, dass mir einfach ein Kernel-Treiber fehlt, den ich in meiner Custom-Distri noch nachinstallieren muss.

Code: Alles auswählen

lsmod | grep cryp -i
fscrypto               28672  1 ext4
cryptd                 24576  3 ablk_helper,ghash_clmulni_intel,aesni_intel
Ich habe nur keine Idee, welcher das sein könnte. Mit den gegebenen Stichworten finde ich weder im Repo etwas passendes, noch mit der Web-Suche auf der Debian-Seite:

Code: Alles auswählen

apt-cache search gcm-aesni
root@thomaspc:~
# apt-cache search rfc4106
root@thomaspc:~
# apt-cache search crc32c-intel
root@thomaspc:~
Hat jemand eine Idee, wie ich die Meldungen beseitigen kann?
vg, Thomas

rendegast
Beiträge: 14272
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: kernel: alg: aead: Test 3 failed on encryption for rfc41

Beitrag von rendegast » 14.02.2017 12:02:38

Da war doch mal etwas mehr viewtopic.php?f=33&t=164022
Feb 04 10:51:50 thomaspc kernel: alg: aead: Test 3 failed on encryption for rfc4106-gcm-aesni
Feb 04 10:51:50 thomaspc kernel: alg: hash: Test 14 failed for crc32c-intel
Feb 04 10:51:50 thomaspc kernel: alg: hash: Test 13 failed for crc32-pclmul
Vielleicht einfach nur eine Bewertung Deiner crypto-Engine.
Ist ja "nur" ein "Test .. failed". kein error oder fail des Moduls mit stacktrace.

Vielleicht Debianintel-microcode?
BIOS-Upgrade?

(Versuch) kernel "normal" (signed) <-> '-unsigned'?
(Versuch) Eigenbau kernel 4.10?
Zuletzt geändert von rendegast am 14.02.2017 12:24:10, insgesamt 1-mal geändert.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

TomL
Beiträge: 3088
Registriert: 24.07.2014 10:56:59

Re: kernel: alg: aead: Test 3 failed on encryption for rfc41

Beitrag von TomL » 14.02.2017 12:18:15

rendegast hat geschrieben:Da war doch mal etwas mehr viewtopic.php?f=33&t=164022
Ja, klar, aber das ist alles behoben. Aktuell keine weiteren Fehlermeldungen im Log.
rendegast hat geschrieben:Vielleicht einfach nur eine Bewertung Deiner crypto-Engine.
Ist ja "nur" ein "Test .. failed". kein error oder fail des Moduls mit stacktrace.
::::
Vielleicht Debianintel-microcode?
Intel-CPU, der Hinweis auf "intel" in der Meldung wird mir jetzt erst bewusst.

Code: Alles auswählen

lscpu
Architecture:          x86_64
Vendor ID:             AuthenticAMD
Model name:            AMD FX(tm)-4300 Quad-Core Processor
Denkst Du, ich muss da nichts weiter unternehmen?
rendegast hat geschrieben:Eigenbau kernel 4.10?
Nein, kein Eigenbau. Es ist der normale Kernel, zuerst vom Installer, jetzt automatisch durch dist-upgrade aktualisiert. Ich habe nicht dran geschraubt.
vg, Thomas

rendegast
Beiträge: 14272
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: kernel: alg: aead: Test 3 failed on encryption for rfc41

Beitrag von rendegast » 14.02.2017 12:23:20

lscpu
Architecture: x86_64
Vendor ID: AuthenticAMD
Model name: AMD FX(tm)-4300 Quad-Core Processor
Dann halt mit Debianamd64-microcode versuchen.
Eigenbau kernel 4.10?
Nein, kein Eigenbau.
Das habe ich mir schon gedacht,
ich meinte es damit zu versuchen.


Ja, klar, aber das ist alles behoben. Aktuell keine weiteren Fehlermeldungen im Log.
Hast Du denn etwas spezielles unternommen, um
Feb 04 10:51:50 thomaspc kernel: alg: hash: Test 13 failed for crc32-pclmul
wegzubekommen?
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

TomL
Beiträge: 3088
Registriert: 24.07.2014 10:56:59

Re: kernel: alg: aead: Test 3 failed on encryption for rfc41

Beitrag von TomL » 14.02.2017 12:29:06

rendegast hat geschrieben:Dann halt mit Debianamd64-microcode versuchen.
Das war schon installiert. Ich vermute, der Installer hat es bei der Auswahl "Alle unfreien Treiber für dieses Gerät installieren" automatisch installiert.
Hast Du denn etwas spezielles unternommen, um
Feb 04 10:51:50 thomaspc kernel: alg: hash: Test 13 failed for crc32-pclmul
wegzubekommen?
Ich hatte die 3 Meldungen zusammen als EIN Problem verstanden, und das eine Lösung alle Meldungen beseitigt. Ist das ein "eigenes" Problem?
vg, Thomas

rendegast
Beiträge: 14272
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: kernel: alg: aead: Test 3 failed on encryption for rfc41

Beitrag von rendegast » 14.02.2017 12:42:52

Ist das ein "eigenes" Problem?
Es ist ein anderer Test für ein anderes Modul.
Was die Test bedeuten, erschließt sich aber wohl nur aus dem Quelltext des kernel.
Feb 03 13:33:51 thomaspc kernel: alg: aead: Test 3 failed on encryption for rfc4106-gcm-aesni
Feb 03 13:33:51 thomaspc kernel: alg: hash: Test 14 failed for crc32c-intel
Feb 03 13:33:51 thomaspc kernel: alg: hash: Test 13 failed for crc32-pclmul
...
Feb 03 15:28:53 thomaspc kernel: alg: aead: Test 3 failed on encryption for rfc4106-gcm-aesni
Feb 03 15:28:53 thomaspc kernel: alg: hash: Test 13 failed for crc32-pclmul
<Nix mehr crc32c-intel>
...
Wenn diese Meldung nicht mehr auftaucht,
hat sich wohl irgendwas verändert.
kernel-Upgrade? Obwohl
linux-signed (4.1) unstable; urgency=medium
* Update to linux version 4.9.6-3
-- Ben Hutchings <ben@decadent.org.uk> Sat, 28 Jan 2017 15:32:33 +0000

linux-signed (4) unstable; urgency=medium
* Update to linux version 4.9.2-2
-- Ben Hutchings <ben@decadent.org.uk> Fri, 13 Jan 2017 14:51:14 +0000

...
ist die tatsächliche Verfügbarkeit auf dem Server wohl jeweils ein paar Tage später.
Eventuell betraf die Meldung auch den Installationskernel des verwendeten Iso.
Irgendwas im BIOS ab/angeschaltet?

Vielleicht hängt es ja auch mit anderen Modulen zusammen.
Hier zBsp. wird crc32c-generic wegen btrfs geladen,
kein btrfs dann kein crc32c.
Und cryptd verwendet/bewertet dann einfach nur geladene Module, statt selbst welche aufzurufen?
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

TomL
Beiträge: 3088
Registriert: 24.07.2014 10:56:59

Re: kernel: alg: aead: Test 3 failed on encryption for rfc41

Beitrag von TomL » 14.02.2017 15:17:39

Ich habe jetzt gerade noch mal neu gebootet. So ist jetzt die aktuelle Situation:

Code: Alles auswählen

# journalctl -b -p err
-- Logs begin at Mon 2017-02-13 16:00:32 CET, end at Tue 2017-02-14 15:01:46 CET. --
Feb 14 15:01:20 thomaspc kernel: alg: aead: Test 3 failed on encryption for rfc4106-gcm-aesni
Feb 14 15:01:20 thomaspc kernel: alg: hash: Test 14 failed for crc32c-intel

# lsmod | grep crc -i
crct10dif_pclmul       16384  0
crc32_pclmul           16384  0
crc16                  16384  1 ext4
crc32c_generic         16384  2
crc32c_intel           24576  0

# lsmod | grep crypt -i
fscrypto               28672  1 ext4
cryptd                 24576  3 ablk_helper,ghash_clmulni_intel,aesni_intel
Ich würde jetzt annehmen, der früher vorhandene Fehler (crc32-pclmu) scheint sich mit dem Kernel-Upgrade behoben zu haben, denn explizit habe ich bisher nicht darauf reagiert. Wie gesagt, weil alles lief, habe ich das erst mal hinten an gestellt und heute mir ist gar nicht aufgefallen, dass von den Anfangs 3 Fehlern bereits einer weg ist.... mannomann, das Du Dich daran erinnern kannst.... :hail:

Aber die Frage ist, wie man die Meldungen bewerten muss. Auch wenn hier nur ein Test "failed", heisst das vielleicht, dass möglicherweise der ganze AES-Mechanismus jetzt tot oder inaktiv ist? Ich kann überhaupt nicht einschätzen, ob das ein Grund zur Sorge ist oder ob man das einfach ignorieren kann. Oder ist das nur ein temporäres Problem, weil Stretch eben derzeit noch nicht st able ist und man kann das einfach aussitzen?
vg, Thomas

rendegast
Beiträge: 14272
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: kernel: alg: aead: Test 3 failed on encryption for rfc41

Beitrag von rendegast » 14.02.2017 18:11:16

Die Test kommen wohl aus
crypto/testmgr.*

Es gibt noch per CRYPTO_MANAGER > CRYPTO_TEST
crypto/tcrypt.*
("Quick $ dirty crypto test module")

tcrypt ist ein separates Modul (das sich bei mir gar nicht laden läßt, "Invalid cross-device link"),
testmgr wird wohl irgendwo implizit verwurstet.
------------------------
EDIT wegen kernel-parameters.txt
901 cryptomgr.notests
902 [KNL] Disable crypto self-tests
('notests' ist ein Parameter von testmgr)
ist es wohl Bestandteil des inline-Moduls cryptomgr (CRYPTO_MANAGER).
------------------------

Darin stecken viele 'case XX' mit Bezug auf crypto-Modi
(und in testmgr.h viel binäres Zeug),
wie das aber mit den "Test YY" zusammengebracht werden kann?



der früher vorhandene Fehler (crc32-pclmu) scheint sich mit dem Kernel-Upgrade behoben zu haben, denn explizit habe ich bisher nicht darauf reagiert.
Eine Liste der gebooteten Kernel

Code: Alles auswählen

NUM=$(journalctl --list-boots | wc -l)
seq -$NUM 0 | while read ID; do
    #journalctl -b $ID | head -n 10 | grep "Linux version"
    journalctl -b $ID | egrep "Linux version|Test.*failed"
done
(Das 'head' dient der Beschleunigung)
(Ein journalctl-Match auf "Linux version" habe ich nicht hinbekommen)
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

TomL
Beiträge: 3088
Registriert: 24.07.2014 10:56:59

Re: kernel: alg: aead: Test 3 failed on encryption for rfc41

Beitrag von TomL » 14.02.2017 20:42:50

rendegast hat geschrieben:EDIT wegen kernel-parameters.txt
901 cryptomgr.notests
('notests' ist ein Parameter von testmgr)
Ich habe mich mal "umgesehen". Auf allen meinen Stretch-Installationen habe ich den gleichen Fehler, bis sogar rein in die VM's. Und ich habe diesen von Dir gefundenen Parameter beginnend mit den VMs nun auf alle Systeme ausgerollt. Damit sieht der aktuelle Stand nun bei mir so aus:

Code: Alles auswählen

# journalctl -b -1 -p err
-- Logs begin at Mon 2017-02-13 16:05:33 CET, end at Tue 2017-02-14 20:30:59 CET. --
Feb 14 15:01:20 thomaspc kernel: alg: aead: Test 3 failed on encryption for rfc4106-gcm-aesni
Feb 14 15:01:20 thomaspc kernel: alg: hash: Test 14 failed for crc32c-intel

# journalctl -b -p err
-- No entries --
Jetzt bleibt wirklich nur noch die Frage, ob die Deaktivierung der Tests in etwa der Haltung entspricht "Ein Problem, welches ich nicht sehen kann, existiert auch nicht." .,.. weil das letztendlich auch beinhalten kann, dass ein wirkliches Problem immer noch besteht. Andersrum frag ich mich, der Sinn eines solchen Parameters kann sich doch nur daraus ergeben, dass dieser Test eigentlich entbehrlich ist. Würdest Du bei so einer Situation auf Deinem Rechner noch etwas unternehmen?
vg, Thomas

rendegast
Beiträge: 14272
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: kernel: alg: aead: Test 3 failed on encryption for rfc41

Beitrag von rendegast » 15.02.2017 05:20:22

Ich würde das cryptomgr.notests nicht setzen.
Eher eine Übersetzungstabelle suchen, die die Meldungen verständlicher macht.

Ich habe irgendwann mal eine Abfragemöglichkeit an die crypto-Engine gesehen.
'openssl engine' ?
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

breakthewall
Beiträge: 259
Registriert: 30.12.2016 23:48:51

Re: kernel: alg: aead: Test 3 failed on encryption for rfc41

Beitrag von breakthewall » 15.02.2017 12:48:53

TomL hat geschrieben:Damit sieht der aktuelle Stand nun bei mir so aus:

Code: Alles auswählen

# journalctl -b -1 -p err
-- Logs begin at Mon 2017-02-13 16:05:33 CET, end at Tue 2017-02-14 20:30:59 CET. --
Feb 14 15:01:20 thomaspc kernel: alg: aead: Test 3 failed on encryption for rfc4106-gcm-aesni
Feb 14 15:01:20 thomaspc kernel: alg: hash: Test 14 failed for crc32c-intel

# journalctl -b -p err
-- No entries --
Jetzt bleibt wirklich nur noch die Frage, ob die Deaktivierung der Tests in etwa der Haltung entspricht "Ein Problem, welches ich nicht sehen kann, existiert auch nicht." .,.. weil das letztendlich auch beinhalten kann, dass ein wirkliches Problem immer noch besteht. Andersrum frag ich mich, der Sinn eines solchen Parameters kann sich doch nur daraus ergeben, dass dieser Test eigentlich entbehrlich ist. Würdest Du bei so einer Situation auf Deinem Rechner noch etwas unternehmen?
Beim Systemstart testet der Linux-Kernel auf so viel Hardware. Allein bei mir gibt es mehrere Meldungen dieser Art, wo auf Geräteklassen getestet wird, die zwar theoretisch seitens des Mainboards unterstützt werden, aber real kein solches Gerät existiert womit jene Tests entsprechend fehlschlagen. Würde diverse Testroutinen niemals abschalten, sondern weniger in solche Meldungen hinein interpretieren.

Was ich mich frage ist, warum dich beispielsweise crc32c-intel überhaupt interessiert, bei einer offensichtlichen AMD-CPU. Die andere Meldung ist AES-NI bezogen. Und ob das auch funktioniert, kannst mit einem realen Test herausfinden. Wenn sich hier AES nicht deutlich von anderen Verschlüsselungsalgorithmen abhebt, in Sachen Geschwindigkeit, dann hast sicher ein reales Problem was behoben werden sollte. Auch wenn das die Sicherheit der Verschlüsselung nicht beeinträchtigen sollte.

TomL
Beiträge: 3088
Registriert: 24.07.2014 10:56:59

Re: kernel: alg: aead: Test 3 failed on encryption for rfc41

Beitrag von TomL » 16.02.2017 11:12:47

Moin zusammen
rendegast hat geschrieben:Ich würde das cryptomgr.notests nicht setzen.Eher eine Übersetzungstabelle suchen, die die Meldungen verständlicher macht.
breakthewall hat geschrieben:Würde diverse Testroutinen niemals abschalten, sondern weniger in solche Meldungen hinein interpretieren.
Ihr habe beide Recht damit, eigentlich sehe ich das genauso. Aber andererseit möchte ich mich nicht daran gewöhnen, den zunächst immergleichen Fehlermeldungen keine Aufmerksamkeit zu schenken. Über kurz oder lang läuft das nämlich darauf hinaus, dass ich auf andere Meldungen vielleicht ebenfalls nicht reagiere, weil das alles zu schnell durchrauscht und ich nicht mitbekomme, dass möglicherweis neue Probleme bestehen. Und das vor dem Hintergrund des Gedankens "Ist ja eh immer der selbe Fehler". Im Moment kriege ich jedes "Rot" sofort mit und schaue ins Log. Aber wenn ich mich einmal dran gewöhne, "Rot" zu ignorien, halte ich das für ein Risiko.

Ich habe mich gestern abend mal mit einigen Test beschäftigt:

Code: Alles auswählen

grep -m1 -o aes /proc/cpuinfo   
sort -u /proc/crypto | grep module
openssl engine 
openssl speed
openssl speed aes-128-cbc
openssl speed aes-192-cbc
openssl speed aes-256-cbc
openssl speed sha1
openssl speed sha256
openssl speed sha512
Mir ist nichts aufgefallen, was vielleicht irgendwie fehlerhaft sein könnte oder nicht ordnungsgemäß läuft. Ich habe die Ergebnisse mal im Web verifiziert und scheinbar ist alles gut und der CPU-Leistungsfähigkeit entsprechend.

Welche Alternativen gibts denn vielleicht noch, mit diesem Problem umzugehen .... die nicht darin bestehen, die Fehlermeldungen zu ignorieren? :roll:
vg, Thomas

rendegast
Beiträge: 14272
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: kernel: alg: aead: Test 3 failed on encryption for rfc41

Beitrag von rendegast » 16.02.2017 21:36:22

etwas off-topic
[np]39761[/np] crypto_Tabelle.sh
um /proc/crypto in Tabellenform darzustellen.
EDIT Unterlassungssünde im Skript: Test auf funktionierendes 'mktemp'(!),
damit $TEMPd nicht leer ist und das Skript nicht Dateien in $HOME verarbeitet, derart:

Code: Alles auswählen

which mktemp >/dev/null  ||  exit 0
-> NoPaste-Eintrag39762

Anwendung

Code: Alles auswählen

./crypto_Tabelle.sh  |  less -S
TomL hat geschrieben: Welche Alternativen gibts denn vielleicht noch, mit diesem Problem umzugehen .... die nicht darin bestehen, die Fehlermeldungen zu ignorieren?
Anderer Rechner, dessen crypto die entsprechenden feature bietet?

Wenn ich die www so lese und mir selber auch denken kann,
haben die hardware-crypto (CPU oder dediziertes device) die Eigenschaft,
nicht alle Modi zu bieten.
Bsp. https://events.linuxfoundation.org/site ... o-user.pdf

Wegen der blackbox-Artigkeit braucht es da wohl die Tests.
software (engine "dynamic") hat dieses Manko nicht, ist aber langsamer.
Zuletzt geändert von rendegast am 17.02.2017 13:42:45, insgesamt 1-mal geändert.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

breakthewall
Beiträge: 259
Registriert: 30.12.2016 23:48:51

Re: kernel: alg: aead: Test 3 failed on encryption for rfc41

Beitrag von breakthewall » 17.02.2017 02:04:01

TomL hat geschrieben:Ich habe mich gestern abend mal mit einigen Test beschäftigt:
Wurde schon Folgendes getestet?

Code: Alles auswählen

cryptsetup benchmark
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   182,8 MiB/s   212,2 MiB/s
 serpent-cbc   128b    75,9 MiB/s   198,0 MiB/s
 twofish-cbc   128b   177,6 MiB/s   215,1 MiB/s
     aes-cbc   256b   147,7 MiB/s   161,0 MiB/s
 serpent-cbc   256b    76,2 MiB/s   188,9 MiB/s
 twofish-cbc   256b   177,7 MiB/s   217,5 MiB/s
     aes-xts   256b   199,1 MiB/s   203,9 MiB/s
 serpent-xts   256b   182,4 MiB/s   181,7 MiB/s
 twofish-xts   256b   196,4 MiB/s   195,1 MiB/s
     aes-xts   512b   156,2 MiB/s   156,9 MiB/s
 serpent-xts   512b   177,7 MiB/s   185,1 MiB/s
 twofish-xts   512b   199,9 MiB/s   198,1 MiB/s
Da meine CPU kein AES-NI unterstützt, ist AES natürlich entsprechend langsam. Bei dir sollte das Gegenteil der Fall sein, sofern alles funktioniert.

TomL
Beiträge: 3088
Registriert: 24.07.2014 10:56:59

Re: kernel: alg: aead: Test 3 failed on encryption for rfc41

Beitrag von TomL » 17.02.2017 11:30:28

Moin

Das sind meine Ergebnisse:

Code: Alles auswählen

cryptsetup benchmark
# Die Tests sind nur annähernd genau, da sie nicht auf den Datenträger zugreifen.
PBKDF2-sha1       819200 iterations per second for 256-bit key
PBKDF2-sha256    1101445 iterations per second for 256-bit key
PBKDF2-sha512     748982 iterations per second for 256-bit key
PBKDF2-ripemd160  697191 iterations per second for 256-bit key
PBKDF2-whirlpool  360087 iterations per second for 256-bit key
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   567,6 MiB/s  2229,2 MiB/s
 serpent-cbc   128b    69,6 MiB/s   326,2 MiB/s
 twofish-cbc   128b   186,2 MiB/s   244,7 MiB/s
     aes-cbc   256b   427,3 MiB/s  1755,4 MiB/s
 serpent-cbc   256b    75,3 MiB/s   313,9 MiB/s
 twofish-cbc   256b   193,3 MiB/s   248,1 MiB/s
     aes-xts   256b  1864,9 MiB/s  1885,7 MiB/s
 serpent-xts   256b   307,9 MiB/s   314,8 MiB/s
 twofish-xts   256b   235,9 MiB/s   231,1 MiB/s
     aes-xts   512b  1495,7 MiB/s  1498,9 MiB/s
 serpent-xts   512b   314,2 MiB/s   320,5 MiB/s
 twofish-xts   512b   241,8 MiB/s   240,6 MiB/s
AES ist beim Wertevergleich also bald um den Faktor 10 schneller. Das kann man doch wohl als gutes Ergebnis verstehen.... oder? Gefühlsmäßig erlebe ich meinen Rechner sowieso in keinster Weise als Spassbremse. Er macht alles gut und und meinen Erwartungen vollständig entsprechend. Und dennoch können wir wohl darin übereinstimmen, dass er eine "Macke" hat. Das ist nicht neu, das hat mich bereits schon mal über ein 3/4 Jahr hinweg beschäftigt, dann hier wieder, und jetzt erneut in diesem Thread. Dabei geht es immer um Probleme mit der Verschlüsselung.
rendegast hat geschrieben:
TomL hat geschrieben:Welche Alternativen gibts denn vielleicht noch, mit diesem Problem umzugehen .... die nicht darin bestehen, die Fehlermeldungen zu ignorieren?
Anderer Rechner, dessen crypto die entsprechenden feature bietet?
Das ist meine CPU: AMD FX(tm)-4300 Quad-Core Processor
Und das mein Board: Gigabyte Board GA-78LMT-usb3

Welche Schlüsse kann man denn nun aus den gegebenen Fakten ziehen? Tatsächlich ein neuer Rechner als einzige Alternative? Oder vielleicht nur eine neue CPU. Soweit ich das verstanden habe, kann mein Board nur AMD-CPUs *hmmm*... Intel geht dann wohl leider nicht. Aber die einzige wichtige Frage ist doch die nach dem "ob überhaupt"?

Kann man anhand der bisherigen Erkenntnisse sagen, dass es mit meinem Rechner ein echtes Sicherheitsproblem gibt? Ich bin mit so einer Einschätzung hoffnungslos überfordert. So wie ich das sehe, funktioniert auf der von mir wahrnehmbaren Oberfläche doch alles prima. Gibt es jedoch trotzdem möglicherweise Anlass zur Sorge, wegen der Beinträchtigung der Aufgaben unterhalb der wahrnehmbaren Oberfläche? Scheinbar funktioniert aber auch AES, ob nun seitens CPU oder Softwareseitig kann ich nicht beantworten, aber anscheinend gehts ja. Zu keiner Zeit habe ich das Gefühl von Schlaftabletten-Tempo... alles funktioniert ausreichend flott.

Mt der Einstellung TLS-Max = 3 (siehe beide Links) hatte ich lange ein Problem, aber mit 2 als Einstellung gibts diese Störungen jetzt auch nicht mehr. Wahrscheinlich hängt das alles zusammen, bzw. hat den gleichen Fehlerursprung, also der frühere Fehlercode ssl_error_bad_mac_read und jetzt aktuell die fehlgeschlagenen Tests. Das scheint mir jedenfalls ein logischer Rückschluss zu sein. Allein die Frage bleibt: Ist das eher ein kosmetisches Problem oder ein echtes Integritätsrisiko (bzw. könnte dazu werden)?

Was wäre sinnvolles tun? Mal eben ein für mich leistungsmäßig ausreichendes Board und ne CPU zu entsorgen, nur um vielleicht einen kosmetischen Mangel zu beheben, möchte ich eigentlich nicht. Wenn die Probleme allerdings wirklich eine sicherheitsrelvante Beeinträchtigung darstellen, dann ist klar, was zu tun ist.

Das Script crypto_Tabelle.sh funktioniert bei mir überhaupt nicht... es bricht völlig unerklärlich mit "keine Berechtigung ab". Ich habs als root gestartet, geprüft, ob die Aufrufe alle möglich sind..... ich kann nix feststellen, woran es scheitert. Allerdings ist es mit der gegebenen Formatierung für mich auch nicht mehr nachvollziehbar, wie der Ablauf ist oder sein soll, um da mal Debug-Breaks einzubauen.
vg, Thomas

Antworten