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.
rendegast
Beiträge: 14297
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 » 17.02.2017 13:36:11

TomL hat geschrieben: ... kernel: alg: aead: Test 3 failed on encryption for rfc4106-gcm-aesni
... kernel: alg: hash: Test 14 failed for crc32c-intel

Und dennoch können wir wohl darin übereinstimmen, dass er eine "Macke" hat.
Möchte ich nicht mit übereinstimmen.
google-Treffer finde ich nicht derart, daß mir eine solche Aussage gerechtfertigt wäre.
Es könnte genausogut ein kernel-Fehler(?) sein,
meine Idee mit der einfachen Feature-Probe scheint mir auch nicht widerlegt.
Das immer wieder heraufbeschworene "gut dokumentiert" scheint nur für Vollprofis zu gelten.
Es findet sich nichts, von dem ich sagen würde, es paßt zu diesen Meldungen.
Es finden sich entfernt ähnliche mit stacktrace ("echte Fehler"), über die kernel-devs lamentieren.
Aber auch bzgl. stacktrace,
hier auf einer stretch-VM schmeissen floppy und ppdev/parport stacktrace, obwohl der einzige Grund ist, daß die devices gar nicht existieren.


Hier (Anm. kein hardware-crypto) sind um die Meldung des cryptomgr die Meldungen zum signed-Zert angeordnet.
Feb 14 21:45:15 debian kernel: Loading compiled-in X.509 certificates
Feb 14 21:45:15 debian kernel: alg: No test for pkcs1pad(rsa,sha256) (pkcs1pad(rsa-generic,sha256))
Feb 14 21:45:15 debian kernel: Loaded X.509 cert 'Debian Project: Ben Hutchings: 008a018dca80932630'
Arbeitest Du mit dem signed- oder unsigned-Kernel?






-------------------------------------------------------------------
TomL hat geschrieben: Das Script crypto_Tabelle.sh funktioniert bei mir überhaupt nicht... es bricht völlig unerklärlich mit "keine Berechtigung ab".
mktemp, csplit, printf und paste sind aus Debiancoreutils, sollten mit hoher Wahrscheinlichkeit verfügbar sein.
Das sed formatiert zu gequotetem Variablensyntax

Code: Alles auswählen

xxx       :     yyyy(zzzz)
aaa      :     bbb
cc dd   :     ee
->
xxx="yyyy(zzzz)"
aaa="bbb"
cc_dd="ee"
In einem Satz nicht vorhandene Merkmale werden als "--" ausgegeben.
Die printf sorgen für jeweils gleichbreite Zeilen, damit beim paste kein Versatz der Spalten stattfindet.
Im erstellten $TMPd/ hat der Benutzer alle Rechte.

$TMPd/ wird normalerweise in /tmp/ erstellt, ist dieses vielleicht 'noexec' gemountet?
Eventuell TMPd woanderhin verlegen, zBsp.

Code: Alles auswählen

TMPd=$(mktemp -d)
->
TMPd=$(mktemp -d -p ~)
(wobei /home/ dann wiederum nicht mit 'noexec' belegt sein sollte)
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

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

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

Beitrag von TomL » 17.02.2017 14:17:19

rendegast hat geschrieben:
TomL hat geschrieben:Und dennoch können wir wohl darin übereinstimmen, dass er eine "Macke" hat.
Möchte ich nicht mit übereinstimmen.
Ich hatte bei der Formulierung den Rechner als "Summe seiner Teile" im Sinn, also als ein Ganzes, ohne jetzt zu unterscheiden, ob es letztendlich CPU, Board, Kernel oder SSL-Implemenierung oder Debian oder sonst was ist. Mein Rechner als Frontend hat als einziger diese Probleme. Sogar die VMs auf der Maschine zeigen keine solcheart Symptome.
rendegast hat geschrieben:google-Treffer finde ich nicht derart, daß mir eine solche Aussage gerechtfertigt wäre.
Letztendlich bleibt die Frage, mit welchem Fazit man das Kapitel zufriedenstellend abschließen kann. Offensichtlich scheint das wirklich was einmaliges zu sein, oder zumindest etwas sehr seltenes.... eben weil so wenig im Web darüber gefunden werden kann.
rendegast hat geschrieben:meine Idee mit der einfachen Feature-Probe scheint mir auch nicht widerlegt.
Was bedeutet Feature-Probe? Ist das etwas aus dem Web, worauf Du Dich berufst? Oder ist das etwas, was ich machen müsste? Sollte ich explizit bestimmte Features "proben"?
Arbeitest Du mit dem signed- oder unsigned-Kernel?

Das ist eine Frage, die ich mir noch nie gestellt habe......welchen Kernel installiert der Installer bzw. welcher kam zuletzt automatisch mit dem dist-upgrade? Was ist überhaupt der Unterschied?
mktemp, csplit, printf und paste sind aus Debiancoreutils, sollten mit hoher Wahrscheinlichkeit verfügbar sein.
Das sed formatiert zu gequotetem Variablensyntax
Coreutils war installiert, allerdings war mir dieser Zusammenhang neu. Und da ich neugierig war, ob ich die Befehle überhaupt "habe" und was die tun, habe ich natürlich mit "which" gegengeprüft und mir jeweils die man-page angesehen. Was mir so Probleme bereitet, ist die Abgrenzung der while-Schleifen. Ich formatiere selber immer streng nach cpp-Syntax, mit konsequenter und leicht reproduzierbarer Einrückung. Aber bei dem Script bin ich leicht überfordert .... wobei das jetzt keine Kritik sein soll... ich kann nur einfach nicht die mehrzeiligen Statements so abgenzen, dass ich das verstehe. Ich selber neige eher dazu, "geschwätzig" und selbsterklärend zu coden, mit eingebauten Trace-Ausgaben... und nehme lieber Performance-Einbußen hin, zugunsten der leichteren Lesbarkeit und zum besseren Verständnis von Code-Zusammenhängen. Aber wie gesagt, das ist jetzt keine Kritik. Es fällt mir halt nur schwer, als Laie so komprimierten Code zu lesen.

Nachtrag
Jetzt läuft das Script und ich bekomme eine ordentliche Tabellen-Ausgabe. Aber was kann ich jetzt hier herauslesen? Welche verwertbahren Erkenntniss enthält die Tabelle für mich?
vg, Thomas

rendegast
Beiträge: 14297
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 » 17.02.2017 15:31:00

TomL hat geschrieben:

meine Idee mit der einfachen Feature-Probe scheint mir auch nicht widerlegt.
Was bedeutet Feature-Probe? Ist das etwas aus dem Web, worauf Du Dich berufst? Oder ist das etwas, was ich machen müsste? Sollte ich explizit bestimmte Featurs "proben"?
Ich hatte "Probe" vorher anders formuliert:
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.
Ich dachte dabei an etwas in diese Richtung

Code: Alles auswählen

[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 000000000000 mask FFFF80000000 write-back
[    0.000000]   1 base 000080000000 mask FFFFC0000000 write-back
[    0.000000]   2 base 0000C0000000 mask FFFFF0000000 write-back
[    0.000000]   3 disabled
[    0.000000]   4 disabled
[    0.000000]   5 disabled
[    0.000000]   6 disabled
[    0.000000]   7 disabled

[    0.000000] ACPI: Early table checksum verification disabled

[    0.005915] Security Framework initialized
[    0.005920] Yama: disabled by default; enable with sysctl kernel.yama.*
[    0.005931] AppArmor: AppArmor disabled by boot time parameter
verbunden mit einer unglücklichen Meldungsformulierung des cryptomgr.

Sollte ich explizit bestimmte Featurs "proben"?
Ich sehe für den Anwender wohl nur die crypto-Benchmarks und die Ausgabe von /proc/crypto.
Das Crypto des Kernels zu bewerten/debuggen ist wohl eine Aufgabe,
die nur echten Profis dieser Sparte zukommt.
Ich hoffe/vertraue mal, daß das ganze so angelegt ist, daß nichts wirklich schlimmes passieren kann,
also daß nicht (unbemerkt) eine ausgewählte betroffene Verschlüsselung durch Nichtverschlüsselung ersetzt wird.
Also derart, daß wenn ein hardware-Modus nicht entsprechend benutzt werden kann,
(nur) das software-Pendant benutzt wird / möglich ist. Zwar langsamer, aber letztlich sicher.


Arbeitest Du mit dem signed- oder unsigned-Kernel?
... Was ist überhaupt der Unterschied?
Das Ben Hutchings Zertifikat für Betrieb unter secure boot.
Die nicht damit ausgerüsteten kernel-Pakete heißen "-unsigned".
Das "-unsigned"-Paket muß normalerweise explizit ausgewählt werden,
es ersetzt das signed-Paket.




----------------------------------------
Was mir so Probleme bereitet, ist die Abgrenzung der while-Schleifen.
Ich benutze das 'while' in diesem Fall, um eine zeilenweise Abarbeitung der Eingabe sicherzustellen.
Aber was kann ich jetzt hier herauslesen?
Auf einem genügend breiten Bildschirm sind die Werte für eine Option nebeneinandergestellt
(Zeilenmarkierungsmöglichkeit des 'less'),
wobei ich direkt sehen kann, zu welchem Modus ("name") das gehört.
Das erleichtert hoffentlich die Einordnung/Bewertung der /proc/crypto-Datensätze.
ZBsp. haben einige ja kein 'digestsize'.
Dazu müßte aber auch die Bedeutung der Optionen verstanden sein,
wobei es bei mir geflissentlich hapert.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

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

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

Beitrag von TomL » 17.02.2017 20:07:00

rendegast hat geschrieben:Ich sehe für den Anwender wohl nur die crypto-Benchmarks und die Ausgabe von /proc/crypto. Das Crypto des Kernels zu bewerten/debuggen ist wohl eine Aufgabe, die nur echten Profis dieser Sparte zukommt. Ich hoffe/vertraue mal, daß das ganze so angelegt ist, daß nichts wirklich schlimmes passieren kann, also daß nicht (unbemerkt) eine ausgewählte betroffene Verschlüsselung durch Nichtverschlüsselung ersetzt wird. Also derart, daß wenn ein hardware-Modus nicht entsprechend benutzt werden kann, (nur) das software-Pendant benutzt wird / möglich ist. Zwar langsamer, aber letztlich sicher.
Wenn ich Dich nun richtig verstanden haben, kommen wir in etwa zu einem gleichen Ergebnis. Man muss bei diesem Symptom auch darauf vertrauen, dass eine erfolgreiche Verschlüsselung immer noch stattfindet. Alle Tests und Ausgaben zeigen ja, dass entsprechende Module vorhanden sind und anscheinend auch "arbeiten".
Warum speziell diese Test's während der Boot-Phase fehlschlagen und warum 'security.tls.version.max=3' beim Browser permanent 'ssl_error_bad_mac_read' auslöst, ist durch uns nicht feststellbar... beides kann möglicherweise sogar auf der gleichen Fehlerquelle beruhen. Fakt ist, sowohl https-Seiten als auch LUKS-AES-verschlüsselte Devices kann ich problemlos handhaben. Und das die AES-Verschlüsselung gerade bei LUKS-Devices (auch sehr komfortable) funktioniert, ist dadurch bestätigt, dass eben auch -durch andere Rechner erzeugte- portable Devices fehlerfrei gehandhabt werden.

Wärst Du mit diesem Fazit einverstanden? Wenn ja, ergibt sich daraus für mich, dass ich 'notest' bei den Kerneloptionen belasse und nun einfach darauf vertraue, dass der Rechner tut, was er soll und was ich von ihm erwarte.
vg, Thomas

Antworten