[erledigt] S/MIME: Tb->gpgsm (KMail, Claws Ml) verwendet

mhoeller

Hallo,

ich erhalte in der letzten Zeit verschlüsselte (S/MIME) mails die ich nicht entschlüsseln kann. Gemäß dem gpgsm log liegt dieses darin begründet dass die empfangene Mail mit dem nicht unterstützten Protokoll RC2 verschlüsselt ist.
Ich selber nutze (noch) nicht Thunderbird, es sei mir hoffentlich verziehen. Ich würde gerne wissen ob man in Thunderbird einstellen kann welches Protokoll zum verschlüsseln genutzt wird. Aktuell scheint AES oder triple DES zeitgemäß zu sein.

Vielen Dank und viele Grüße
Michael

strombrief

Hallo Michael,

ich bin nicht so der Fachmann in der Materie, habe aber mal im TB geschaut.
Dort konnte ich keine Einstellungsmöglichkeit für die Wahl eines Protokolls für S/MIME finden.
Soweit ich gelesen habe, kann man den Algorithmus in den "enveloped-data" einer verschlüsselten E-Mail auslesen. Dieser Teil ist aber base64 codiert, so daß ich leider nicht auslesen kann welches Protokoll Thunderbird nutzt.
Ist dir eine Möglichkeit bekannt, diese "envelope-datas" mit base64 zu decodieren?

Welchen E-Mail Client setzt du ein, KMail ?

Grüße,
André

Peter_Lehmann

Hi,

es stimmt, dass es dafür im TB keine Einstell- bzw. Auswahlmöglichkeit gibt.
TB nutzt für die symmetrische Verschlüsselung 3DES.
Ich kann das täglich sehen, da unser Mailclient auf Arbeit (LoNo mit einem zusätzlichen Kryptoplugin) bei jeder Mail nicht nur die 6 Buttons für die Zertifikats- und Signaturprüfung, sondern auch den symmetrischen Algorithmus und die Schlüssellänge anzeigt. (*)

Sicherlich wäre AES (genau so wie ein anderer, zeitgemäßer Hash-Algorithmus an Stelle SHA-1) angebracht. Aber abgesehen davon, dass 3DES ggw. noch als sicher gilt (sicher für die zu übertragenden Informationen ...), kann wohl kaum der relativ unbedeutende Thunderbird damit anfangen.

(*) Lustige Begebenheit am Rande:
Jahrelang haben wir uns über von Auskuck-Schnell versandte Mails gewundert. Obwohl nachweislich darin 3DES/168 bit eingestellt war, erfolgte die Verschlüsselung mit NSA-freundlichen 40 bit und DES. Arg, wer böses dabei denkt ... .

MfG Peter

mhoeller

Hallo,

vielen Dank für die Antworten. Ich nutze KMail 1.9.2 mit KDE 3.5.6 (also alles aktuell) mit openSUSE 10.2. Dazu kommt noch gpgsm 1.9.22.

Ich habe verschlüsselte Mails mit Zertifikaten von CAcert.org und Thawte erhalten. Beide liefern mir den Fehler "RC2 not supported" gesendet von Thunderbird.
Leider habe ich die Daten erst heute Abend zur Verfügung, dann kann ich den Fehler aus dem gpgsm log und die Thunderbird Version hier posten.
Vielleicht läßt sich das Problem eingrenzen.
Ich würde gerne einmal die grundsätzliche Funktion des Entschlüsselns vom SMIME Mails, die mit Thunderbird versandten wurden, testen. Macht jemand mit?

Vielen Dank schon mal
Michael

strombrief

Moin,

ich bin dabei!
Teste als eingefleischter GPG-User gerade die "S/MIME"-Welt an und bin absolut interessiert hier mehr zu erfahren...

Hab mir zur Lektüre "Sicherheit und Kryptographie im Internet" von Jörg Schwenk besorgt, ich denke das ist ein guter Einstieg; liest sich bis jetzt klasse auch wenn ich nicht immer ganz folgen kann
(ISBN: 3834800422)

Grüße,
André

mhoeller

Hallo,

nun kann ich Details liefern die verwendete gpgsm Version ist 1.9.22 und unterstütz definitiv nicht RC2 aus patentrechlichen Gründen.

Hier sind die Headerdaten der Mail die ich erhalten habe:

User-Agent: Thunderbird 1.5.0.10 (X11/20070306)
MIME-Version: 1.0
X-Enigmail-Version: 0.94.0.0
OpenPGP: id=BDD13B90; url=http://tinyurl.com/5d8mm
Content-Type: application/x-pkcs7-mime; name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"
Content-Description: S/MIME Encrypted Message

und hier ist das log von gpgsm:

4 - 2007-04-16 21:32:46 gpgsm[7623.0x8084a98] DBG: <- DECRYPT
4 - 2007-04-16 21:32:46 gpgsm[7623]: unsupported algorithm `1.2.840.113549.3.2'
4 - 2007-04-16 21:32:46 gpgsm[7623]: (Dies ist der RC-2 Algorithmus)
4 - 2007-04-16 21:32:46 gpgsm[7623.0x8084a98] DBG: -> S ERROR decrypt.algorithm 50331732 1.2.840.113549.3.2
4 - 2007-04-16 21:32:46 gpgsm[7623.0x8084a98] DBG: -> S DECRYPTION_FAILED
4 - 2007-04-16 21:32:46 gpgsm[7623]: message decryption failed: Nicht unterstütztes Verfahren
4 - 2007-04-16 21:32:46 gpgsm[7623.0x8084a98] DBG: -> ERR 50331732 Nicht unterstütztes Verfahren
4 - 2007-04-16 21:32:47 gpgsm[7623.0x8084a98] DBG: <- BYE

demnach muss Thunderbird eine RC2 Verschlüsselung geschickt haben. Wie kann das sein wenn diese von TB gar nicht unterstützt wird?

Hoffe es weis jemand Rat.

Viele Grüße
Michael

wurstsemmel

Hallo zusammen,

das gleiche Problem tritt bei uns auch auf.

Folgende Dinge habe ich herausgefunden:

TB benutzt 3DES und RC2/40, siehe http://www.mozilla.org/projects/security/pki/nss/smime/ (Feature List Punkt 11). Danke an Peter_Lehmann.
S/MIME (allgemein) benutzt für die symmetrische Verschlüsselung 3DES, AES oder RC2/40; der Sender liefert eine Präferenz-Liste der Algorithmen mit, sonst wir 3DES verwendet (?) siehe pdf von Jeschke, Seite 17
KMail bzw. gpgsm sollte in der Signatur den symmetrischen Schlüssel auf 3DES festlegen, eventuell geschieht dies nicht, wie in diesem Thread bei Eudora festgestellt.
Das Problem tritt mit gpgsm und _einigen_ (nicht allen?) Thunderbird und Outlook 11 MUAs auf (Claws Mail FAQ / S/MIME HowTo)
Das Problem tritt mit MS OE und Thawte auf (a-netz.de)
und nochmal: Im Zusammenhang mit Thawte Zertifikat und Thunderbird tritt der Fehler auch auf. RC2/40 ist ein schwacher Algorithmus. KDE mailing list
gpgsm unterstützt RC2 nicht (zugehöriger bug report)
Laut pdf Grundpraktikum wird der verwendete Algorithmus in dem Bereich envelopedData unter Encryption Algorithm angezeigt.

Die envelopedData ist, wie weiter oben erwähnt BASE64 kodiert. Zum dekodieren bietet sich http://www.opinionatedgeek.com/DotNet/Tools/B…de/default.aspx an.

Leider krieg ich es nicht hin, die EnvelopedData von meinen Mails auszulesen.* Wäre interessant, welche Verschlüsselung TB benutzt, wenn man sich selbst eine verschlüsselte Mail schickt. TB sollte 3DES verwenden, wie Peter_Lehmann weiter oben festgestellt hat. Nun könnte man die EnvelopedData von einer KMail eMail anschauen und vergleichen. Eventuell kommt man so auch an die bei mir als ersten Punkt erwähnte Präferenz-Liste.

Meine Vermutung ist, dass KMail nicht nach 3DES verlangt und TB daher RC2 verwendet. Vielleicht könnte dies getestet werden, indem man TB das Zertifikat nicht automatisch hinzufügen lässt, sondern das öffentliche Zertifikat des KMail Nutzers in TB direkt importiert. Eventuell benutzt TB dann standardmäßig 3DES, da es keine eventuell fehlerhafte Signatur von KMail kennt??

Ist es möglich, dass der Verschlüsselungsalgorithmus im Zertifikat festgelegt wird? Konnte dazu nix finden, war nur so eine Idee.

Ich selbst benutze Thunderbird 2.0 RC1 (localized build de, kein language pack). KMail läuft mit gpgsm unter OpenSuse 10.2.

Vielleicht kommen wir ja weiter, wenn jemand die envelopedData auslesen kann.

Ciao,

wurstsemmel

* Ich habe mir unter Ansicht -> Nachrichten-Quelltext den Quelltext angesehen und den unleserlichen Teil unter dem Header in das Webformular kopiert.

Peter_Lehmann

Hi,

ich nutze schon seit längeren privat ausschließlich den TB, kann deswegen keine Aussagen zu gpgsm machen. Kann also nur den täglichen "praktischen Test" mit unserem Plugin machen. Und natürlich den jetzt folgenden Test:

Der verwendete Algorithmus ist als OID in der ASN.1-Struktur eincodiert. Diese Angabe benötigt der Empfänger, um den richtigen Algorithmus zum Entschlüsseln zu verwenden.
Vielleicht liegt es an der Information "smimeCapabilities", die bei signierten Mails in der PKCS#7 Struktur mit übergeben werden kann. Outlook und Outlok Express sind ja dafür bekannt, dass sie ohne diese Info vom Empfänger nur RC2 40 bit senden.

Wenn man den "Anhang" smime.p7m aus einer Mail löst, kann man diesen mit folgender Kommandozeile betrachten:
openssl asn1parse -in smime.p7m |less

Die Angabe zum Algorithmus findet man in der aufgeschlüsselten ASN.1-Struktur als eine der letzten Angaben (hier: des-ede3-cbc):
...
320:d=5 hl=2 l= 8 prim: OBJECT :des-ede3-cbc
...

Ich habe das gerade noch einmal an einer Reihe von empfangenen Mails getestet => und damit die Aussage unseres LoNo-Plugins bestätigt. Habe auch bewusst ein paar Mails von anderen Clients und mit anderen Algn. gesendet. Auch hier die richtige Anzeige.

Einschränkend muss ich noch ergänzen:
Ich benutze ausschließlich exakt dem Standard entsprechende Schlüssel und Zertifikate unseres Trustcenters sowie privat ebenso standardgemäße aus meiner kleinen "Privat-CA". D.h., bei beiden stimmen die Profile. Das muss bei den kostnix-Zertifikaten einiger Herausgeber nicht unbedingt der Fall sein.

MfG Peter
(und tnx an Jan ...)

mhoeller

Hallo,

ich habe soeben eine sign., verschl. Mail von TB 1.5.0.9 erhalten
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.5.666:

Ich habe den base64 Datenteil in eine Datei 'datenmail' kopiert
und dann mit cat datenmail | mimencode -u | ./dumpasn1 - entschlüsselt.

Dumpasn1 gibt es unter http://www.cs.auckland.ac.nz/~pgut001/ nach
"Security Standards" gucken mit gcc dumpasn1.c -o dumpasn1 compilieren.
Bitte noch dumpasn1.cfg kopieren.

Hier ist dann die Ausgabe die ich erhalten habe von der o.g. Mail. Die Mail wurde unter Verwendung von RC2 verschlüsselt.

>> OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2)

Ich hoffe Ihr könnte herausbekommen warum TB diesen Algo verwendet. Ich übrigens auch bestätigen das es mit Claw Mail und TB die selben Probleme gibt.

Und in Ergänzung zur obigen Liste, bei mir ist es ein CAcert Zertifikat ...

Viele Grüße
Michael

cat datenmail | mimencode -u | ./dumpasn1 -
Warning: Input is non-seekable, some functionality has been disabled.
0 NDEF: SEQUENCE {
2 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
13 NDEF: [0] {
15 NDEF: SEQUENCE {
17 1: INTEGER 0
20 787: SET {
24 370: SEQUENCE {
28 1: INTEGER 0
31 90: SEQUENCE {
33 84: SEQUENCE {
35 20: SET {
37 18: SEQUENCE {
39 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
44 11: PrintableString 'CAcert Inc.'
: }
: }
57 30: SET {
59 28: SEQUENCE {
61 3: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
66 21: PrintableString 'http://www.CAcert.org'
: }
: }
89 28: SET {
91 26: SEQUENCE {
93 3: OBJECT IDENTIFIER commonName (2 5 4 3)
98 19: PrintableString 'CAcert Class 3 Root'
: }
: }
: }
119 2: INTEGER 9491
: }
123 13: SEQUENCE {
125 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
136 0: NULL
: }
138 256: OCTET STRING
: 24 4A 22 F8 B5 93 E3 13 74 BB 0C C3 30 F3 A0 49
: C9 52 CB 38 14 DB 6E 71 86 A6 4C A3 C4 A0 89 E4
: 06 59 CA B3 34 43 39 2D 62 0B 3A 8B AB E0 13 52
: 27 0F F8 80 9C 46 3A 56 D8 5B D2 85 B9 12 F8 6E
: C3 34 69 DC FB 66 4B EB D2 03 EA EA CF 2C 5B 6F
: 4D 1B FC 27 6B 5F FA 9B 48 2C 3C 37 90 C0 95 93
: B5 5E 2F 13 9A 17 5E D1 9A 67 57 59 14 50 4E 5F
: F9 3B 45 B4 24 91 41 72 DC 38 49 15 9A F2 F5 60
: [ Another 128 bytes skipped ]
: }
398 409: SEQUENCE {
402 1: INTEGER 0
405 128: SEQUENCE {
408 121: SEQUENCE {
410 16: SET {
412 14: SEQUENCE {
414 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
419 7: PrintableString 'Root CA'
: }
: }
428 30: SET {
430 28: SEQUENCE {
432 3: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
437 21: PrintableString 'http://www.cacert.org'
: }
: }
460 34: SET {
462 32: SEQUENCE {
464 3: OBJECT IDENTIFIER commonName (2 5 4 3)
469 25: PrintableString 'CA Cert Signing Authority'
: }
: }
496 33: SET {
498 31: SEQUENCE {
500 9: OBJECT IDENTIFIER
: emailAddress (1 2 840 113549 1 9 1)
511 18: IA5String [email='\'support@cacert.org'][/email]'
: }
: }
: }
531 3: INTEGER 224505
: }
536 13: SEQUENCE {
538 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
549 0: NULL
: }
551 256: OCTET STRING
: 73 C3 8F A9 FB AB 48 68 BF CE DD 77 FB 47 87 FB
: 05 23 54 7E E6 A1 9B 80 F7 8A 59 94 BC 82 5F 34
: 25 6C 66 28 1A 65 3E 53 BA 97 76 06 FC 05 63 87
: A5 26 81 C5 DB 84 B8 31 FC 7E 4A 41 D8 05 99 9F
: F0 FF 38 F5 20 82 76 A3 D8 AA 7C 21 0A 6B 6B 96
: 13 2B 51 2E 3F 10 3A 09 68 67 5B 2A 7B 92 95 E4
: 7C 3B B4 51 8F CB 32 BB AD 35 3D E6 66 33 77 01
: 2C DA BF 1D 0A 7A 59 E9 91 07 14 50 2C 69 D6 41
: [ Another 128 bytes skipped ]
: }
: }
811 NDEF: SEQUENCE {
813 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
824 26: SEQUENCE {
826 8: OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2)
836 14: SEQUENCE {
838 2: INTEGER 160
842 8: OCTET STRING 92 83 C2 FE 59 2C ED 8F
: }
: }
852 NDEF: [0] {
854 7632: OCTET STRING
: E6 7F A2 41 5B E7 E5 D7 09 B7 61 89 0D FF 9D E8
: 1C 74 4F 6A 77 CD 36 CD 4B 32 E4 CA E2 73 6C 2F
: 06 F5 86 92 C1 8D 97 3F E6 1B 8A 93 18 EF 38 F8
: 1F 96 59 84 7D 49 45 F5 BE 6E 48 4E 75 F0 B0 9C
: C9 A4 4B 14 0E 21 B6 1F 94 E2 E4 B7 DF AB 44 85
: 66 21 5E 07 55 F4 59 80 15 F6 0D 88 8B ED 8B C1
: 52 2E 1B 48 65 77 BA 47 B9 15 AC C7 CF D7 2B 8E
: 3A 4B 19 40 8D 3E 5F DD 0C 9B 4B 66 19 31 D5 9A
: [ Another 7504 bytes skipped ]
8490 8: OCTET STRING 41 8E 8C 05 13 46 FD 3F
: }
: }
: }
: }
: }

0 warnings, 0 errors.
michael@akazia:~/Documents>

mhoeller

Guten Morgen,

mir wurde auf der gpg-devel Liste bestätigt dass gpgsm nicht die Ursache sein können (es war eine wirklich sachliche Diskussion) also bitte nicht in Schuldzuweisungen abdriften.
Es wird ehr vermutet dass TB defaults verwendet. Frage: kann es bei TB zu einen Zustand kommen das die Interpretation des Algo für ein Zertifikat fehlschlägt und dann der älteste Standard verwendet wird, auch wenn der mittlerweile nicht mehr überall unterstützt wird?

Für diese Theorie spricht dass es auch bei andern Mail Clients in Verbindung mit TB so ein Problem gibt..

Gruß
Micha

wurstsemmel

Guten Tag,

leider schaffe ich es immer noch nicht, die envelopedData auszulesen. Bei der Methode von Peter_Lehmann erhalte ich die Meldung "offset too large", bei der von mhoeller kommt ein "invalid data at position xx". Leider kenne ich mich dazu unter Linux zu schlecht aus. Aber Peter_Lehmann hat ja schon klargestellt, dass Tb nicht immer RC2 verwendet.

Vielleicht kann ja jemand das Problem und die Vermutung von mhoeller in der Newsgroup von Mozilla (siehe http://www.mozilla.org/projects/security/pki/nss/smime/) schildern. Newsserver news.mozilla.org.
Ich habe leider im Moment zu wenig Zeit und nicht das nötige Wissen... Mit Peter_Lehmann testen wir noch, ob das Problem mit seinem Tb, der ja normalerweise mit 3DES verschlüsselt, auch auftritt.

Viele Grüße,

wurstsemmel

mhoeller

Hallo

Zitat von "wurstsemmel"

Guten Tag,
leider schaffe ich es immer noch nicht, die envelopedData auszulesen. Bei der Methode von Peter_Lehmann erhalte ich die Meldung "offset too large", bei der von mhoeller kommt ein "invalid data at position xx". wurstsemmel

das Probelm hatte ich auch, ich hatte schlicht weg am Ende noch eine Leerzeile. Guckmal das du vor und hinter dem kopieren Block KEIN einizges Zeichen hast. Also auch keinen Zeileumbruch am Ende.

Kopiert werden nur die verschüsselten Daten. Sonst nix.

Gruß
Michael

Vic~

---

Peter_Lehmann

Hi,

ich habe das Wochenende "genutzt" und von jedem (!) meiner vielen Mailpartner je eine Mail analysiert. Ich erinnere: bei mir werden ca. 85% aller Mails mit S/MIME "behandelt" ... .

Ergebnis:
100% Verschlüsselung mit 3DES bei Nutzern, die Thunderbird verwenden. Dabei spielte es keine Rolle, ob selbige Freunde des Tux, der WinDOSe oder des Apfels sind.
Bei einigen wenigen alten (!) Mails, welche per OE gesendet wurden, trat der o.g. Effekt mit DES/40 auf. Aber wie gesagt, das ist jetzt vorbei.
Per Kmail gesendete Mails konnte ich leider "mangels Masse" nicht untersuchen.

Vorgehensweise:
Aus der Quellansicht den body in eine Textdatei kopiert. Und dann folgender Befehl:
openssl asn1parse -in Textdatei > ergebnis.absender.txt

Eine weitere Möglichkeit ist auch, per Webmail den smime.p7m-Container abzulösen und dann weiter wie oben.

MfG Peter

mhoeller

Guten Morgen,

danke für die Nachricht. Wurstsemmel hat einen ganz interssanten Punkt gebracht den ich mit einem andern Mailpartner bestätigen konnte:

Person A nutzt Thunderbird
Person B nutzt KMail

Das Problem ist das Person B (KMail) keine mit seinem öffentlichen Zertifikat bei A verschlüsselten Mails lesen kann weil A/TB den Algorithmus RC" verwendet
Die Frage ist warum.

Der Test:
Person A löscht das Zert. von B und importiert manuell das per Mail verschickter öffentliche Zert als pem
Person A schickt B eine oder beliebig viele Mails verschlüsselt, Person B KANN diese lesen es wird nun
des-EDE3-CBC verwendet..

Folgenden Teil konnte ich aus rein zeitlichen Gründen noch nicht testen werde das heute aber noch nachliefern.

Wenn Person B nun eine Mail an PErson A (Thunderbird) schickt und Person B dann wieder eine Antwort von Person A erhält
dann wird wieder der Algorithmus RC2 verwendet!!

Hat jemand einen Idee was passiert ist als TB die Mail von Person B erhalten hat?

Viele Grüße
Michael

Peter_Lehmann

Hi,

ich habe mir mal die ersten Mails von euch angesehen. Sie waren ja nur signiert.
Bei der Mail von Michael (kMail) wurden die smimeCapabilities mit gesendet.
==> Analogien zu meinem zweiten Beitrag (alter OE) sind zu sehen.

Aber dazu gleich eine Frage:
Ich hatte ja vor dem TB auch kMail genutzt. Und kMail kann doch von Hause aus mit S/MIME umgehen (wenn ich mich recht entsinne ...).
Wozu verwendest du dann dieses "gpgsm"?

Also werde ich das schöne Wetter ignorieren, und mich heute Abend wieder mal mit kMail befassen

MfG Peter

wurstsemmel

Also,

ich erzähl mal noch kurz die Geschichte von meinem Microsoft Outlook Express (MS OE) Test. Ich habe OE nur zum testen verwendet, da es standardmäßig installiert ist. Dies hat also nix mit dem vorher gesagten zu MS OE zu tun, OE beherrscht 3DES.

OE zeigt unter "Einstellungen des Absenders | Empfohlener Verschlüsselungsalgorithmus" den empfohlenen Algorithmus an.

Also die Ergebnisse:

Tb -> OE: In OE wird 3DES als empfohlener Algorithmus angezeigt.
OE -> Tb: Tb kann die Mail lesen, OE warnt nicht, dass die Verschlüsselungsstärke zu gering ist. Daher tippe ich auf 3DES.
KMail -> OE: In OE wird *0.1.101.3.4.1.2 als empfohlener Algorithmus angezeigt. Da das Feld zu klein ist, kann ich die Zahl nicht komplett lesen, daher auch das *. M_hoeller könnte überprüfen, was diese Nummer bedeutet, in dem er sich selbst eine verschlüsselte email schickt und asn1dump ausführt. Ich denke, dass es sich um AES handelt.
OE -> KMail: Die Nachricht wird mit RC2 verschlüsselt. Dies konnte M_hoeller bestätigen, außerdem zeigt OE eine Warnung wegen zu geringer Schlüsselstärke an.

Meine Vorschläge wären also:

a) in Tb sollte RC2 ausgeschaltet werden, wenn dies nicht zu Kompatibilitätsproblemen führt.
b) Tb sollte einen Fallback auf 3DES machen, wenn es den Algo nicht kennt. In diesem Fall erkennt Tb den Algo (AES) nicht und fällt auf RC2 zurück
c) KMail sollte eine Präferenzliste mitschicken, falls so etwas möglich ist. Nach dem Motto: Nimm AES, wenn du es nicht kannst, nimm 3DES!
d) zur Not könnte man KMail auf 3DES umstellen, weiß allerdings nicht wie das geht. Außerdem wäre dann der Vorteil von AES Verschlüsselung zwischen KMail Usern weg.

Wegen a) und b) werde ich am Mittwoch in die News-Group von Mozilla posten. Wenn dies jemand anders tun will oder schon getan hat, möge er sich doch bitte kurz melden.

@ Peter_Lehmann: Soweit ich weiß benutzt, KMail gpgsm für die Verschlüsselung.

Meine Aussagen decken sich mit denen von M_hoeller und Peter_Lehmann. Allerdings widerspricht Werner aus der gpgsm-devel-list:

Zitat von "Werner"

> ==> Is it possible that KMAIL/gpgsm sends or stores some information
> in the mail which leads to the fact that Thunderbird sends RC2 ????

Definitely not.

Achso, ich habe mal FIPS aktiviert in Tb, dadurch konnte ich Tb aber auch nicht dazu bewegen, AES zu benutzen.

Ich wünsche Euch einen wunderschönen Tag,

wurstsemmel

P.S.: Danke an Peter_Lehmann für das aufwändige Testen.

Peter_Lehmann

Und dir wünsche ich (im Namen aller Leser) viel Erfolg und ein glückliches Händchen bei den beiden Prüfungen!

MfG Peter

mhoeller

Hallo

auch von mir viel Erfolg !!

Ich habe noch was interessantes. Mein Test Mailpartner hat mein Z. manuell in TB importiert und seit her haben wir schon einige Mails ausgetauscht. Aller verschlüsselt!! Hier weiche ich also ab von den Entdeckungen.

Ich werde den Test morgen wiederholen mit einem CAcert Z., das bisherige war von der FernUni Hagen.

Viele Grüße
Michael

wurstsemmel

So jetzt bin ich wieder da und bedanke mich für Eure wünsche. Hat geholfen, Studium ist in der Tasche!

M_Hoeller und ich konnten bei einem wiederholten Test bestätigen, dass Tb wieder RC2 benutzt, wenn man auf eine eMail von KMail antwortet. Bei der ersten Mail mit manuell importiertem Z. wird von Tb 3DES verwendet.

Daher liegt es nahe, dass Tb die Smimecapabilities ausliest und aktualisiert, wenn man auf Antworten drückt.

Ich werden den Fall nun im englischen Forum fortführen, wer Lust hat kann ja mal vorbeischauen.

Schönen Gruß,

wurstsemmel

[erledigt] S/MIME: Tb->gpgsm (KMail, Claws Ml) verwendet

Thunderbird 128.4.4 ESR veröffentlicht

Thunderbird 115.16.3 ESR veröffentlicht