close
  • Xm chevron_right

    XMPP OX - OpenPGP

    DebXWoody · pubsub.movim.eu / xmpp-messenger · Tuesday, 19 May - 18:56 edit · 5 minutes

Vorwort

Brainstorming zur Implementierung von XMPP OX (XEP-0373: OpenPGP for XMPP). Es gibt verschiedene Arten wie man die Verwendung von OpenPGP in XMPP implementieren kann. In diesem Dokument soll das Thema diskutiert werden.

Grundlage ist XEP-0373: OpenPGP for XMPP Version 0.4.0 (2018-07-30)

GnuPG Home und Keyring

In GnuPG ist es möglich einen eigenen Home Directory zu verwenden oder einen eigenen Keyring zu definieren. Eine Änderung würde bewirken, dass der XMPP Client und der eigene Keyring / GnuPG Instanz unabhängig von einander verwendet werden. Es ist zu klären welche Vor- oder Nachteile die Verwendung eines eigen Keyring oder Homedir hat.

Für Anwender die schon einen Key besitzen und diesen auch für XMPP nutzen wollen, sehe ich hier einen komplexeren Ablauf, wenn die Schlüssel auf mehrere Keyrings verteilt sind.

Aus Sicht für der Anwender sehe ich einen Key mehr als eine Eigenschaft eines Kontakts in einem Adressbuch. So ist vom Anwendungsdesign eine Überlegung die "Kontakte" in einem Adressbuch darzustellen und diese auch individuell zu nutzen.

Screenshot_Addressbook_OpenPGP

Eine Aufteilung der Kontakte in noch mehr Quellen macht die Verwendung und Verwaltung nur komplexer. Ferner ist die Zertifizierung und die Bildung des Trust-DB aufwendiger.

Für Nutzer, die ohnehin OpenPGP nur für XMPP verwenden, würde der Ort keine Rolle spielen. Die Verwendung eines Keyring auch mit unterschiedlichen Account sehe ich nicht als Problem.

Verwaltung des eigenen Schlüssel

Beim Verwenden von OpenPGP in XMPP sehe ich die folgenden Anwendungsfälle:

  • Der Benutzer hat noch keinen privaten OpenPGP Schlüssel
  • Der Benutzer hat einen privaten Schlüssel, jedoch noch kein Zuordnung zu XMPP
  • Der Benutzer hat einen privaten Schlüssel und eine Zuordnung zu XMPP

Wenn der Benutzer noch keinen privaten Schlüssel hat, sollte die Anwendung einen OpenPGP Key erzeugen. Ein Experten-Modus für die Angabe von Schlüsseltyp und Schlüssellänge, sowie Verfallsdatum. In einem "normalen" Modus wird der Schlüssel automatisch generiert: rsa3072 / 2 Jahre. In beiden Fällen wird die XMPP Adresse (JID) im URI Format als UID eingetragen:

sec   rsa3072 2020-05-16 [SC] [verfällt: 2022-05-16]
      A8431A0170B3EBB564CE294D0C1CE873ED588C2B
uid        [ ultimativ ] xmpp:alice@domain.tld
ssb   rsa3072 2020-05-16 [E] [verfällt: 2022-05-16]

Sind im Keyring private Schlüssel vorhanden, kann der Benutzer auswählen, ob er einen neuen Key erzeugen will (siehe oben) oder einen der Schlüssel verwenden will. Hat der Benutzer sich für einen Schlüssel entschieden, wird für diesen Schlüssel eine UID angelegt mit der JID angelegt.

Existiert ein Key mit der JID als UID wird diese verwenden. Wenn jedoch mehrere existieren, ist die Verwendung des Schlüssels nicht eindeutig. Zu klären ist, was in diesem Fall passieren soll?

Damit ist der Punkt 8.5 "OpenPGP User IDs" in XEP-0373 erfüllt.

Synchronisieren der privaten Schlüssel

In Kapitel 5 wird das synchronisieren de privaten Schlüssel via PEP Node beschriebe.

Meiner Meinung nach sollte die Synchronisation niemals automatisch erfolgen und immer eine bewusste Entscheidung des Benutzer sein. Es gibt keinen Bedarf für die Synchronisation eines privaten Schlüssels, wenn

  • der private Schlüssel auf einer Smartcard / Token ist
  • der Benutzer nur ein Endgerät benutzt
  • der Benutzer dies nicht möchte

Was passiert, wenn der Key auf eine Smartcard ist? Wird dann der Stub synchronisiert?

Schlüssel Validierung

Die Herausforderung ist die Validierung der Schlüssel. Das trust-model pgp verwendet WoT in dem der Schlüssel einer anderen Person via Fingerprint geprüft werden muss. Danach wird öffentliche Schlüssel des Kommunikationspartners signiert. Durch die Eintragung einer owner-trust ist es möglich das WoT abzubilden.

Der Nachteil bei diesem Konzept ist, dass es einfach keiner macht. Für diejenigen, die schon mit OpenPGP arbeiten, sollt das Modell kein Problem sein. Eine Kommunikation mit einem Kommunikationspartner kann in diesem Fall nur statt finden, werde der Schlüssel des Kommunikationspartner zertifiziert wurde.

Für die Benutzer, die mit der Schlüsselverwaltung nicht zu tun haben wollen, könnt man versuchen dies über ein eigenes trust-model abzubilden. Ich habe dies jedoch selber noch nicht ausprobiert, und müsste man erst einmal validieren.

Annahme: Gehen wir mal davon aus, dass wir das gleiche Homedir und die gleichen Keyrings verwenden können, jedoch einen andere trustdb. Wir nehmen die pgp TrustDB und verwenden diese mit dem trust-model pgp, wie man dies kennt. In einem "Nicht-Experten-Modus" wir man nun eine eigene Trust-Db verwenden, welche mit tofu oder tofu+pgp läuft.

Denkfehler: Ob man ToFu oder gpg verwenden, ist abhängig vom Anwender und nicht von der Anwendung. Wir gehen jetzt einfach mal davon aus, dass der Benutzer einfach gpg oder tofu+pgp benutzt.

Entweder der Anwender verwendet trust-model tofu+pgp oder trust-model pgp.

Beispiel

Ich versuche ein Text zu verschlüsseln:

echo "Test" | gpg --homedir /tmp/testpgp --trust-model pgp -r 66C40DE0782393BA65D23E6C8459A4A77CAFA894 --encrypt -a 

In diesem Fall kommt ein Meldung

gpg: 90ED0F38F201CF29: Es gibt keine Garantie, daß dieser Schlüssel wirklich dem angegebenen Besitzer gehört.

sub  rsa3072/90ED0F38F201CF29 2020-05-19 Name Name <rtfm@domain.tld>
 Haupt-Fingerabdruck  = 66C4 0DE0 7823 93BA 65D2  3E6C 8459 A4A7 7CAF A894
 Unter-Fingerabdruck  = 2A75 B79D 46E1 5655 39E4  CEC9 90ED 0F38 F201 CF29

Es ist NICHT sicher, daß der Schlüssel zu dem in der User-ID
Genannten gehört. Wenn Sie *wirklich* wissen, was Sie tun,
können Sie die nächste Frage mit ja beantworten

Diesen Schlüssel trotzdem benutzen? (j/N) 

Der Grund ist, dass der Schlüssel nicht signiert wurde.

Nutze ich jedoch ToFu:

echo "Test" | gpg --homedir /tmp/testpgp --trust-model tofu+pgp -r 66C40DE0782393BA65D23E6C8459A4A77CAFA894 --encrypt -a 

so ist die Verschlüsselung möglich.

Im Vergleich

gpg --homedir /tmp/testpgp --trust-model tofu+pgp -k 66C40DE0782393BA65D23E6C8459A4A77CAFA894 
gpg: WARNUNG: Unsichere Zugriffsrechte des Home-Verzeichnis `/tmp/testpgp'
pub   rsa3072 2020-05-19 [SC] [verfällt: 2022-05-19]
      66C40DE0782393BA65D23E6C8459A4A77CAFA894
uid        [  marginal ] Name Name <rtfm@domain.tld>
sub   rsa3072 2020-05-19 [E] [verfällt: 2022-05-19]
gpg --homedir /tmp/testpgp --trust-model pgp -k 66C40DE0782393BA65D23E6C8459A4A77CAFA894 
gpg: WARNUNG: Unsichere Zugriffsrechte des Home-Verzeichnis `/tmp/testpgp'
pub   rsa3072 2020-05-19 [SC] [verfällt: 2022-05-19]
      66C40DE0782393BA65D23E6C8459A4A77CAFA894
uid        [ unbekannt ] Name Name <rtfm@domain.tld>
sub   rsa3072 2020-05-19 [E] [verfällt: 2022-05-19]
  • Pictures

  • visibility
  • favorite

    2 Like

    preptorrent , debacle

  • Xm chevron_right

    eagle Prototyp

    DebXWoody · pubsub.movim.eu / xmpp-messenger · Sunday, 10 May - 06:07 edit

Ich habe gestern einen ersten Prototyp von eagle auf codeberg hochgeladen.

Der Prototyp hat aktuell eine sehr einfache Implementierung von

  • Lesen der Adressen von abook
  • Lesen von VCard Dateien aus einem Verzeichnis
  • Lesen der Informationen aus einem GnuPG Keyring
  • Lesen der Kontakte aus einem XMPP Roster
  • Schreiben einer signierten und verschlüsselten Nachricht via XEP-0373: OpenPGP for XMPP

Mehr Informationen und Screenshots sind im Wiki: https://codeberg.org/xmpp-messenger/eagle/wiki

#XMPP #eagle #OpenPGP #gnupg

  • eagle

    Das XMPP eagle Projekt (XEP-0374: OpenPGP for XMPP Instant Messaging (OX) )

  • favorite

    1 Like

    debacle

  • 2 Comments

  • 11 May debacle

    Eagle oder egale? Egal!

  • 11 May DebXWoody

    Ich habe mich beim programmieren auch schon 2x vertippt :-D

  • Xm chevron_right

    XMPP eagle

    DebXWoody · pubsub.movim.eu / xmpp-messenger · Sunday, 3 May - 17:50 edit

Ich habe dieses Wochenende etwas mit gtk programmiert. Für die UI habe ich glade verwendet. Das lief eigentlich ganz gut.

Ich bin am überlegen, ob man eine Anwendung programmiert die Microblog via XMPP unterstützt, wie es auch bei Movim zum Einsatz kommt, aber auch OpenPGP integriert.

Die Nachrichten könnte man wie eine "E-Mail" aufbauen. Es ist somit mehr etwas für längere Texte anstatt viele kurze Nachrichten wie man es von IMs kennt.

Die GUI könnte auch gleich die Verwendung von OpenPGP etwas erleichtern.

#OpenPGP #XMPP #Movim #GTK #glade

  • favorite

    1 Like

    debacle

  • Xm chevron_right

    xmppc - Pre-Release 0.0.3

    DebXWoody · pubsub.movim.eu / xmpp-messenger · Saturday, 18 April - 06:31 edit · 1 minute

Hallo zusammen,

ich habe in xmppc zwei neue Funktionen eingebaut. Die Version ist mit 0.0.3 auf codeberg getagged.

  • Implementation for XEP-0373: OpenPGP for XMPP.
  • Module for XMPP Monitoring

XEP-0373: OpenPGP for XMPP

Mit dem Mode openpgp und dem Befehl signcrypt sollte es jetzt möglich sein, verschlüsselte und signierte XMPP Nachrichten via XEP-0373 zu verschicken.

XMPP Monitoring

Mit dem Mode monitor und dem Befehl stanza bekommt man die XML Daten angezeigt.

xmppc 0.0.3

Die aktuelle Version hat somit die folgenden Befehle:

xmppc --jid user@domain.tld --pwd "password" --mode roster list
xmppc -j user@domain.tld -p "password" -m roster list
xmppc -j user@domain.tld -p "password" -m roster export
xmppc -j user@domain.tld -p "password" -m message chat friend@domain.tld "Message"
xmppc -j user@domain.tld -p "password" -m pgp chat friend@domain.tld "Message"
xmppc -j user@domain.tld -p "password" -m openpgp signcrypt friend@domain.tld "Message"
xmppc -j user@domain.tld -p "password" -m omemo list
xmppc -j user@domain.tld -p "password" -m monitor stanza
xmppc 0.0.3
Usage: xmppc --jid <jid> --pwd <pwd> --mode <mode> <command> <parameters>
Options:
  -h / --help             Display this information.
  -j / --jid <jid>        Jabber ID
  -p / --pwd <password>   Passwort
  -m / --mode <mode>      xmppc mode

Modes:
  -m --mode roster      xmppc roster mode
    list                  List all contacts
    export                Exports all contacts

  -m --mode message     xmppc message mode
    chat <jid> <message>  Sending unencrypted message to jid

  -m --mode pgp         xmppc pgp mode (XEP-0027) 
    chat <jid> <message>  Sending pgp encrypted message to jid

  -m --mode omemo       xmppc omemo mode
    list                  List the device IDs and fingerprints

  -m --mode openpgp          xmppc openpgp mode (XEP-0373)
    signcrypt <jid> <message>  Sending pgp signed and encrypted message to jid

  -m --mode monitor     Monitot mode    stanza              Stanza Monitor
    monitor             microblog Monitor microblog (XEP-0277: Microblogging over XMPP)


Examples:
  Usage: xmppc --jid user@domain.tld --pwd "secret" --mode roster list
  Usage: xmppc --jid user@domain.tld --pwd "secret" --mode pgp chat friend@domain.tld "Hello"

Feedback (Verbesserungen, Fragen, Fehler) sind willkommen: Issue Tracker.

#XMPP #xmppc #OpenPGP #GnuPG

  • xmppc

    xmppc - XMPP Comand Line Interface (CLI) Client

  • Pictures

  • visibility
  • favorite

    2 Like

    movtux , DebXWoody

  • 1 Comments

  • 18 April DebXWoody

    Als nächstes wollte ich mir XEP-0030: Service Discovery ansehen. Vorher jedoch den existierenden Code etwas aufräumen.

  • chevron_right

    OpenPGP mit GnuPG

    DebXWoody · Sunday, 23 February - 07:45 edit · 1 minute

Ich verwende für die Signatur und die Verschlüsselung von Daten OpenPGP mit GnuPG.

OpenPGP ist ein standardisiertes Dateiformat. Es kann zur Signatur und zur Verschlüsselung von Daten verwendet werden. GnuPG ist eine freie Software, welche diesen Standard implementiert.

OpenPGP lässt sich unter anderem für die Verschlüsselung von Daten verwenden, wie bzw. E-Mails oder Dateien. Die Korrektheit von Informationen, kann man durch eine Signatur von Daten oder E-Mail gewährleisten.

Jeder Benutzer hat ein Schlüsselpaar. Ein Schlüsselpaar besteht aus einem
privaten Schlüssel und einem öffentlichen Schlüssel. Auf der Homepage des BSI für Bürger gibt es ein nettes Video, was es sehr gut veranschaulicht.

E-Mail Verschlüsselung: Schlüsseltausch einfach gemacht

Zunächst installiert man sich die Software auf seinem PC. Danach generiert man sich das Schlüsselpaar. Dies kann man mit der Anwendung gpa machen, oder auf der Shell mit einem Befehl. Einige Informationen zum Thema GnuPG haben wir auf der Homepage der devLUG zusammengetragen:

Signieren und Verschlüsseln von E-Mails

Mit GnuPG lassen sich E-Mails signieren und verschlüsseln. So kann sichergestellt werden, dass der Inhalt einer E-Mail wirklich von einer Person kommt und auch nur von der Person gelesen werden kann, für die die E-Mail gedacht war.

XMPP

Einige XMPP Messenger unterstützen ebenfalls OpenPGP zum senden von verschlüsselten Nachrichten.

XMPP MUC über GnuPG

Ich habe für den Austausch rund um OpenPGP und GnuPG einen MUC auf jabber.de angelegt xmpp:gnupg@conference.jabber.de?join

Links

#OpenPGP #GnuPG

  • chevron_right

    Software, Dienste und myself

    DebXWoody · Saturday, 25 January - 06:35 edit · 2 minutes

Betriebssysteme

Für die Workstations und Server nehme ich Debian GNU/Linux. Das Betriebssystem ist sehr stabil und ist schon immer ein treuer Begleiter. Einer der wichtigsten Gründe ist jedoch der Debian-Gesellschaftsvertrag weshalb ich mich für Debian entschieden habe. Ich habe ca. 2000 mit SuSE Linux angefangen und bin seit Debian Woody Linux User.

Debian GNU/Linux 3.0 (a.k.a. woody) was released on 19th of July, 2002.

Auf dem Smartphone nutze ich LineageOS, eine Android Distribution ohne Anwendungen und Dienste von Google. Software lässt sich über F-Droid installieren. Mehr Infos zum Thema Smartphone.

Dienste

Für die öffentlichen Repositories nutze ich Codeberg. Der Dienst wird von einem Verein bereitgestellt und hat für meine privaten Freizeitprojekte immer Vorrang gegenüber GitLab und GitHub.

Für die Kommunikation nutze ich XMPP. XMPP ist ein Protokoll für Instant Messaging. Hier empfehle ich den Dienst Anoxinon Messenger. Anoxinon ist ein Verein der sich für Open Source und Datenschutz einsetzt. Ich bin Anfang 2019 dem Verein beigetreten, da er in vielen Punkte meine Meinungen vertritt und Open Source und Bildung wichtige Punkte für mich sind.

@skyfar und Team, der Verein hat Ziel und Zweck was für uns alle wichtig ist. Weiter so!!!

OpenStreetMap ist ein Dienst für Karten.

Sicherheit

Besonders für die Signatur und Verschlüsselung von Daten und E-Mails nehme ich OpenPGP mit GNU Privacy Guard. OpenPGP kann man auch in XMPP nutzen.

Wenn du Fragen zu OpenPGP / GnuPG hast, dann kannst du mich gerne ansprechen oder komm vorbei xmpp:gnupg@conference.jabber.de?join vielleicht kann ich helfen.

pub   rsa4096/0xC2DC916F35751C24 2019-05-14 [SC] [verfällt: 2021-05-13]
  Schl.-Fingerabdruck = A602 F768 93F1 38B4 A8EF  DDD5 C2DC 916F 3575 1C24

pub   rsa4096/0xB08D23A4A857085D 2019-07-21 [SC] [verfällt: 2021-07-20]
  Schl.-Fingerabdruck = C7F4 7DE0 BA30 7CBD A584  60E9 B08D 23A4 A857 085D

Für OTP für 2FA habe ich eine APP auf dem Smartphone, aber auch den Nitrokey, der mich immer begleitet.

Social Media

Für Social Media habe ich Movim entdeckt. Es basiert auf XMPP. Es kann als RSS Feed, Microblog oder zum schreiben von Artikel und als XMPP Client verwendet werden. Ich find Movim super!

@edhelas, Thanks for this great community platform based on XMPP.

E-Mail

E-Mails bearbeite ich mit getmail, procmail, notmuch und neomutt. Dies ist mehr etwas für fortgeschrittene Linux User und sicher nicht für jeden etwas. getmail ruft die E-Mails von einem POP3/IMAP Server ab und gibt diese an procmail weiter. procmail sortiert die E-Mail in verschiedene Maildir Verzeichnisse, abhängig von Regeln. Danach werden die E-Mails mittels notmuch getagged. Mein neomutt ist dann basierend der tags konfiguriert. So habe ich eine physikalische Sicht via Maildir Verzeichnisse und eine logische Sicht via notmuch virtuelle Mailboxes. Zum schreiben von E-Mails verwende ich vim. Einen kleinen Artikel hab ich auf der Homepage der devLUG erstellt, Neomutt und Co.

@flatcap, Thanks for your good and hard work on neomutt!!!

XMPP

Für Instant Messaging verwende ich nur noch XMPP. Als XMPP Clients nutze ich gajim, profanity und Conversations / Pix-Art Messenger für Android.

#Debian #Codeberg #OpenPGP #GnuPG #Anoxinon #XMPP #neomutt #OpenStreetmap

  • chevron_right

    Things I don't like with OMEMO as it is today

    debacle · Tuesday, 13 November, 2018 - 19:21 edit · 2 minutes

I use OMEMO every day, because I prefer end-to-end encrypted messaging for many purposes. OMEMO is much better than OTR, and it works well enough to be useful. But OMEMO has a number of usability issues, that should be addressed by the IM and XMPP community at some point.

  1. It relates to devices instead of users. I don't want to know, whether my contacts own a new device, nor should they care when I do.
  2. Forward secrecy is a good thing for TLS. But when used for messaging, I cannot decrypt my old messages stored on the server in all cases. Also, it makes key escrow impossible, which is a killer for using it in business.
  3. Deniability. I want verifiable signatures instead. Maybe I want to conclude a contract via XMPP? For deniability I would use an anonymous account in the first place.
  4. OMEMO does not encrypt the complete stanza, but only the textual part of a message.
  5. It does not work with local, serverless messaging. I don't use this feature a lot, but still, encryption should work with it, too.
  6. OMEMO seems to be pretty complex, which makes implementation relatively hard. In fact, bugs related to OMEMO are still frequent in some clients.
  7. I already have an OpenPGP key, that is trusted (and occasionally signed) by many. Why not re-use it for IM purposes?
  8. (added 2019-02-15) This is an amendment to the first point: If we accept the concept of keys per device, at least improve the management. The keys should have a label, e.g. "mobile" or "PC at work", to be less confusing. Or why not automatically cross-sign keys from all devices?

Some of the points can be addressed in later OMEMO versions, but some points seem to be woven into the fabric. Fortunately, I see the light at the end of the tunnel (and I hope it is not the oncoming train): OX or "OpenPGP for XMPP". I hope, that it will heal all my OMEMO aches:

https://xmpp.org/extensions/xep-0373.html

https://xmpp.org/extensions/xep-0374.html

The only thing, I do not like is synchronising of encrypted private keys using PEP, which involves storing it on the server, only secured by the PGP passphrase and the "backup code", generated by the device. But nobody forces me to use the backup feature and I assume, that it can be blocked by admins who feel uneasy about it. Also, OpenPGP seems to have a higher per message overhead than OMEMO. This is probably unavoidable.

Edit: Correction about OX private key encryption, thanks to lovetox!

Edit: Add point about OMEMO complexity and errors, thanks to Holger!

#omemo #xmpp #im #ox #openpgp #e2ee