Hallo,
für Interessierte:
Kryptographie in der IT - Empfehlungen zu Verschlüsselung und Verfahren [heise/security]
Hallo,
für Interessierte:
Kryptographie in der IT - Empfehlungen zu Verschlüsselung und Verfahren [heise/security]
Hi,
falls jemand den Artikel gelesen hat:
ZitatDer Pferdefuß bei dem Ganzen ist, dass bisher nur die von der NIST spezifizierten Kurven große Verbreitung gefunden haben. Da bei der Wahl der Parameter die NSA die Hand im Spiel hatte, standen die jedoch zunächst unter dem Verdacht, der US-Geheimdienst könnte sich einmal mehr eine Hintertür eingebaut haben. Diese Besorgnis hat sich in der Krypto-Szene weitgehend gelegt.
Wieso arbeitet noch irgend jemand mit diesen Typen zusammen, die schon Schwachstellen bewußt eingebaut haben, und hofft tatsächlich, dass sie es nie wieder tun?
Was Quantencomputer (geklaut bei fefe) betrifft, so bin ich weniger pessimistisch, die sind wahrscheinlich sowas wie die gesteuerte Kernfusion, die sehr, sehr bald praktisch einsetzbar sein wird - und das seit 50 Jahren oder so.
Natürlich hat die NSA fast unbegrenzt Kohle, aber die Mathematik und Physik können sie auch nicht ohne weiteres überlisten
cu, frog
Der Artikel stammt aus 2016 und diesbezüglich nicht mehr ganz up-to-date. Das Gerangel um Curve25519 ist noch nicht beendet, aber es sieht ganz gut aus.
ZitatSeit 2014 bemüht sich die Kryptographie-Arbeitsgruppe der Internet Engineering Task Force (IETF) um die Standardisierung neuer elliptischer Kurven für asymmetrische Kryptographie im Internet. Curve25519 gilt als vielversprechendster Kandidat für die Standardisierung einer elliptischen Kurve, welche die vom National Institute of Standards and Technology (NIST) standardisierten Kurven ablösen sollen.[6] Diese sind in Verruf geraten, da sie von der National Security Agency (NSA) aus unerklärten Ausgangsdaten abgeleitet wurden und eine Hintertür nicht ausgeschlossen werden kann. Außer mehr Transparenz soll sie auch bei der Implementierung weniger fehleranfällig sein.[8]
aus https://de.wikipedia.org/wiki/Curve25519
ZitatDas SafeCurves-Projekt von Bernstein hat mit den sicheren, akademischen Kurven Curve25519 (bzw. Ed25519), Ed448-Goldilocks und E-521 inzwischen einen De-facto-Standard geschaffen. Die staatlichen Kurven haben das Vertrauen der führenden Kryptographen verloren, da die Kurvenwahl nicht vollständig transparent nachvollziehbar ist[19] und somit eine ähnliche kleptographische Hintertür wie bei Dual_EC_DRBG oder eine sonstige Hintertür nicht sicher ausgeschlossen werden kann.
aus https://de.wikipedia.org/wiki/Elliptic_Curve_Cryptography
Ich habe mir gerade erst kürzlich neue Schlüssel erstellt und dabei auf die Kurve 25519 gesetzt. Mach' doch einfach mit!
Versuch mit Enigmail:
2018-12-10 01:34:02.553 [DEBUG] enigmailKeygen.js: Terminate:
2018-12-10 01:34:02.578 [DEBUG] enigmailCommon.jsm: dispatchEvent f=resizeDlg
2018-12-10 01:34:17.376 [DEBUG] enigmailKeygen.js: Start
2018-12-10 01:34:17.408 [DEBUG] enigmailCommon.jsm: dispatchEvent f=resizeDlg
2018-12-10 01:34:18.759 keyRing.jsm: generateKey:
2018-12-10 01:34:18.760 [CONSOLE] /usr/bin/gpg2 --charset utf-8 --display-charset utf-8 --no-auto-check-trustdb --batch --no-tty --no-verbose --status-fd 2 --gen-key2018-12-10 01:34:18.760 [CONSOLE] %echo Generating key
Key-Type: EDDSA
Key-Curve: Ed25519
Key-Usage: sign
Subkey-Type: ECDH
Subkey-Curve: Curve25519
Subkey-Usage: encrypt
Name-Real: frog
Name-Email: xx@yy.de
Expire-Date: 1500
2018-12-10 01:34:18.763 [DEBUG] keyRing.jsm: generateKey: subprocess = [object Object]
2018-12-10 01:34:18.763 enigmailKeygen.js: Start: gKeygenRequest = [object Object]
2018-12-10 01:34:18.819 [DEBUG] enigmailKeygen.js: onDataAvailable() gpg: Generating key
2018-12-10 01:34:19.067 [DEBUG] enigmailKeygen.js: onDataAvailable() gpg: agent_genkey failed: Invalid flag
gpg: key generation failed: Invalid flag
[GNUPG:] ERROR key_generate 16777288
[GNUPG:] KEY_NOT_CREATED
gpg: done
2018-12-10 01:34:19.075 [DEBUG] enigmailKeygen.js: Terminate:
2018-12-10 01:34:19.101 [DEBUG] enigmailCommon.jsm: dispatchEvent f=resizeDlg
2018-12-10 01:34:32.311 [DEBUG] enigmailKeygen.js: CloseRequest
2018-12-10 01:34:40.277 [DEBUG] enigmailMessengerOverlay.js: updateOptionsDisplay:
2018-12-10 01:34:40.278 [DEBUG] funcs.jsm: collapseAdvanced:
2018-12-10 01:34:41.731 [DEBUG] enigmailMessengerOverlay.js: updateOptionsDisplay:
2018-12-10 01:34:41.731 [DEBUG] funcs.jsm: collapseAdvanced:
2018-12-10 01:34:43.343 [DEBUG] enigmailConsole.js: consoleLoad
2018-12-10 01:34:43.343 [DEBUG] windows.jsm: getFrame: name=contentFrame
2018-12-10 01:35:17.393 [DEBUG] enigmailConsole.js: consoleUnload
2018-12-10 01:35:20.158 [DEBUG] enigmailMessengerOverlay.js: updateOptionsDisplay:
2018-12-10 01:35:20.160 [DEBUG] funcs.jsm: collapseAdvanced:
2018-12-10 01:35:21.860 [DEBUG] enigmailMessengerOverlay.js: updateOptionsDisplay:
2018-12-10 01:35:21.860 [DEBUG] funcs.jsm: collapseAdvanced:
2018-12-10 01:35:23.065 [DEBUG] enigmailHelp.js: enigLoadPage
2018-12-10 01:35:23.065 [DEBUG] windows.jsm: getFrame: name=contentFrame
Alles anzeigen
EM wählt zwar Curve 25519 aus, kann's aber dann offenbar doch nicht (?).
Kommandozeile funktioniert, nur muss man da die Optionen kennen und verstehen.
gpg2 --expert --full-gen-key # natürlich, nur für Experten :-/
...
Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
(1) RSA und RSA (voreingestellt)
(2) DSA und Elgamal
(3) DSA (nur signieren/beglaubigen)
(4) RSA (nur signieren/beglaubigen)
(7) DSA (Leistungsfähigkeit selber einstellbar)
(8) RSA (Leistungsfähigkeit selber einstellbar)
(9) ECC und ECC
(10) ECC (nur signieren)
(11) ECC (Leistungsfähigkeit selber einstellbar)
Ihre Auswahl? 9
Bitte wählen Sie, welche elliptische Kurve Sie möchten:
(2) NIST P-256
(3) NIST P-384
(4) NIST P-521
(5) Brainpool P-256
(6) Brainpool P-384
(7) Brainpool P-512
Alles anzeigen
Will ich alles nicht! Nur wenn ich oben (11) auswähle, kriege ich auch Curve 25519 angeboten. Verwirrend.
Nichts für Nicht-Experten! Die haben es bis jetzt noch nicht mal geschafft, ein neues Schlüsselpaar zu generieren, nachdem die Geschichte mit der Integritätsprüfung sie erwischt hat
Für heute reichts.
cu, frog
Über Enigmail hatte ich es nicht probiert. Aus den Fehlermeldungen kann ich auch nur das lesen, was dort steht. Der Schlüssel konnte aufgrund eines invaliden Flags nicht erstellt werden. Das ist ein vielleicht ein Fall für das Forum von Enigmail?
Ich habe meine neuen Schlüssel über die Konsole erstellt. Dass musste ich schon allein deshalb, weil ich mir diesmal einen Off-Line-Key erstellen wollte. Das war eigentlich mein Hauptziel. Ich habe dann die Gelegenheit genutzt und habe auch gleich ECC-Schlüssel erstellt. Ich hatte mich auch gewundert, dass die Curve nicht unter Option 9 angeboten wird. Aber ebenso wie du habe ich sie am Ende doch gefunden.
Ich stimme dir absolut zu. Verschlüsselung mit GnuPG einzurichten ist alles andere als einfach. Da muss man sich nicht wundern, dass es so wenig Verbreitung findet.
Ich musste mich bei meinem Vorhaben immer wieder ziemlich konzentrieren und überlegen, ob das überhaupt alles so passt, wie ich es mir ausgedacht hatte. Ich war mir auch unsicher, wie Enigmail sich im Detail verhält.
Andererseits gibt es Anleitungen, mit denen sich tatsächlich auch ein Laie Enigmail/GnuPG in einer halben Stunde einrichten kann. Noch einfacher ist der Weg über Mailvelope, wie GMX und Web.de es anbieten und natürlich mittels p≡p.
Man muss dazu nicht verstehen, wie Verschlüsselung funktioniert.
Ich würde sagen pEp-en kann fast ein jeder. Kompliziert wird es erst, wenn man Sonderwünsche hat und vom Standard abweicht.
Ganz nett übrigens: Innerhalb weniger Tage, nachdem ich die neuen Schlüssel verteilt hatte, habe ich von zwei Bekannten ebenfalls neue Schlüssel erhalten. Die haben die Gelegenheit auch beim Schopf gepackt und sich Off-Line-Schlüssel mit ECC-Subkeys erstellt.
Derzeit ist ja Emotet in aller Munde, weil dadurch auch in Deutschland große Schäden angerichtet wurden und bestimmt auch weiterhin werden. Siehe beispielsweise https://www.heise.de/security/artik…le-4243695.html
Was Emotet u.a. so gefährlich macht, ist dass die Mails täuschend echt gemacht sind. Sie scheinen von einem Kollegen oder Bekannten zu kommen, die Anrede stimmt usw. usw. . Da passiert es dann doch einigen, dass sie die Fälschung nicht sofort bemerken.
Als Gedankenanregung ...
Kryptographie kann auch hier helfen. Man muss nicht verschlüsseln. Es genügt eine digitale Signatur des Absenders. Dadurch wird beim Empfang sofort angezeigt, ob der Absender gefälscht wurde oder nicht.
Ich habe mir deshalb schon vor Jahren angewöhnt, eine selbst erstellte S/MIME-Signatur an meine Mails anzuhängen.
Obwohl ich GPG bevorzuge, benutze ich hier S/MIME. Und zwar deshalb, weil es bei vielen Mailprogrammen, darunter Outlook und Thunderbird, gleich dabei ist.
Der Empfänger muss nichts installieren und sieht dennoch gleich, ob die Mail wirklich von mir ist. Er kann sich gar nicht dagegen wehren.
Für private Zwecke genügt ein selbst oder von Bekannten erstelltes Zertifikat oder auch ein kostenloses von einer Zert-Stelle. Die Hemmschwelle ist nach meiner Erfahrung viel geringer als bei der Verschlüsselung, wohl auch, weil dazu keine Fachkenntnis nötig ist.