vanitasvitae @vanitasvitae@fosstodon.org
- Blog on the Fediverse
- @vanitasvitae
#freesoftware enthusiast and #computerscience student from #muenster, Germany.
Joined Oct 2018
#ProcessOne is removing facebook from their website and delets their fanpages.
Join the fediverse as a next step?
vanitasvitae
boosted
Google betreibt das größte Werbenetzwerk und produziert mit Chrome den am weitesten verbreiteten Browser, der bald auch den Kern von MS Edge bilden wird.
Jetzt will Chrome unabhängige Werbeblocker aussperren.
https://www.theregister.co.uk/2019/01/22/google_chrome_browser_ad_content_block_change/
https://www.ghacks.net/2019/01/22/chrome-extension-manifest-v3-could-end-ublock-origin-for-chrome/
@heiseonline@twitter.com @golem@twitter.com
vanitasvitae
boosted
Fosstodon is now on Mastodon version 2.7.0 that brings some interesting new features, including the new directory (https://fosstodon.org/explore)
Currently, I'm the only person on our directory. If you want to be listed, you can enable it within your account settings.
vanitasvitae
boosted
vanitasvitae
boosted
Guten Morgen, ich habe mich entschlossen, neben Twitter auch Mastodon zu nutzen, über die Instanz http://bonn.social (Hallo, @Sascha_Foerster@twitter.com). Freue mich auch dort über Gesprächspartner und bin gespannt, ob automatisches Crossposting funktioniert :-)
vanitasvitae
boosted
I wrote about my recent XMPP adventures over on my blog - Open Standards, Open Web
Would be happy to share the experience further with anyone interested.
vanitasvitae
boosted
This is why we need free and open source software: #backdoor in ES file explorer app for #android https://techcrunch.com/2019/01/16/android-app-es-file-explorer-expose-data/
#security
vanitasvitae
boosted
Requirements on encryption change from time to time. New technologies pop up and crypto protocols get replaced by new ones. There are also different use-cases that require different encryption techniques.
For that reason there is a number of encryption protocols specified for XMPP, amongst them OMEMO and OpenPGP for XMPP.
Most crypto protocols share in common, that they all aim at encrypting certain parts of the message that is being sent, so that only the recipient(s) can read the encrypted content.
OMEMO is currently only capable to encrypt the messages body. For that reason the body of the message is being encrypted and stored in a <payload/> element, which is added to the message. This is inconvenient, as it makes OMEMO quite inflexible. The protocol cannot be used to secure arbitrary extension elements, which might contain sensitive content as well.
<message to='juliet@capulet.lit' from='romeo@montague.lit' id='send1'>
<encrypted xmlns='eu.siacs.conversations.axolotl'>
<header>...</header>
<!-- the payload contains the encrypted content of the body -->
<payload>BASE64ENCODED</payload>
</encrypted>
</message>
The modern OpenPGP for XMPP XEP also uses <payload/> elements, but to transport arbitrary extension elements. The difference is, that in OpenPGP, the payload elements contain the actual payload as plaintext. Those <payload/> elements are embedded in either a <crypt/> or <signcrypt/> element, depending on whether or not the message will be signed and then passed through OpenPGP encryption. The resulting ciphertext is then appended to the message element in form of a <openpgp/> element.
<signcrypt xmlns='urn:xmpp:openpgp:0'>
<to jid='juliet@example.org'/>
<time stamp='...'/>
<rpad>...</rpad>
<payload>
<body xmlns='jabber:client'>
This is a secret message.
</body>
</payload>
</signcrypt>
<!-- The above element is passed to OpenPGP and the resulting ciphertext is included in the actual message as an <openpgp/> element -->
<message to='juliet@example.org'>
<openpgp xmlns='urn:xmpp:openpgp:0'>
BASE64_OPENPGP_MESSAGE
</openpgp>
</message>
Upon receiving a message containing an <openpgp/> element, the receiver decrypts the content of it, does some verity checks and then replaces the <openpgp/> element of the message with the extension elements contained in the <payload/> element. That way the original, unencrypted message is constructed.
The benefit of this technique is that the <payload/> element can in fact contain any number of arbitrary extension elements. This makes OpenPGP for XMPPs take on encrypting message content way more flexible.
A logical next step would be to take OpenPGP for XMPPs <payload/> elements and move them to a new XEP, which specifies their use in a unified way. This can then be used by OMEMO and any other encryption protocol as well.
The motivation behind this is, that it would broaden the scope of encryption to cover more parts of the message, like read markers and other metadata.
It could also become easier to implement end-to-end encryption in other scenarios such as Jingle file transfer. Even though there is Jingle Encrypted Transports, this protocol only protects the stream itself and leaves the metadata such as filename, size etc. in the clear. A unified <encrypted/> element would make it easier to encrypt such metadata and could be the better approach to the problem.
teilen teilen e-mail RSS-feed teilen
https://blog.jabberhead.tk/2019/01/17/unified-encrypted-payload-elements-for-xmpp/
Very interesting story about a mysterious #raspberrypi found in a corporate network.
https://blog.haschek.at/2018/the-curious-case-of-the-RasPi-in-our-network.html
Which is on and which is off @phoronix
#assholedesign #werespectyourprivacy
vanitasvitae
boosted
OMEMO is an XMPP extension protocol, which specifies end-to-end encryption for XMPP clients using the double ratchet algorithm of the Signal protocol. Introduced back in 2015 by GSoC student Andreas Straub in the Conversations client, OMEMO had a lot of press coverage and many privacy and security oriented websites praise XMPP clients that do support it. Its beyond debate, that OMEMO brought many new faces to XMPP. For many users, having end-to-end encryption built into their chat client is a must. Today OMEMO is implemented in a range of clients on different platforms. While Conversations, ChatSecure and Dino support it out of the box, there is a series of plugins that teach OMEMO to other clients such as Gajim, Pidgin and Miranda NG.
However, there is quite a lot of controversy around OMEMO. Part of it are technical discussions, others are more or less of a political nature. Let me list some of them for you.
Some users and client developers see no value in OMEMOs forward secrecy (the fact, that messages can only be decrypted once per device, so new devices do not have access to the chat history of the user). That is a fair point. Especially webclients have a hard time implementing OMEMO in a sensible way. Also the average user is probably having a hard time understanding what exactly forward secrecy is and what the consequences are. Communicating to the user, that not having access to past messages is actually a feature might be a hard task for a client developer.
OMEMOs trust management (still) sucks. One architectural key feature of OMEMO is, that every device does have its own identity key. If a user wants to send a message to one of their contacts, they’re presented with a list of all of their identity keys. Now they have to decide, which keys to trust and which not by comparing fingerprints (seamingly arbitrary strings of 64 characters). This is not a very comfortable thing to do. Some clients encourage the user to verify your contacts devices by scanning QR-Codes, which is way more comfortable, users do however have to meet up in person or share the QR code on another channel.
But what if you get a new device or just reinstall your chat application? Suddenly all your contacts have to decide whether to trust your new fingerprint or not. In the long run this will lead to the user just being annoyed and blindly accepting new fingerprints, ruining the concept of end-to-end encryption.
Daniel Gultsch introduced the concept of BTBV (Blind Trust Before Verification) which can be summed up as “do not bother the user with encryption and hope everything goes well until the user explicitly states that they are interested in having good security”. The principle is, that clients blindly trust any OMEMO identity keys until the user commits to verifying them manually. This makes OMEMO easy to use for those who don’t really care about it, while offering serious users who depend on it the needed security.
But what do you do, if suddenly a rogue fingerprint appears? Do you panic and message all your contacts not to trust the stranger key? In theory any device which has access to the users account (the users server too) can just add another OMEMO identity key to the users list of devices and there is not really anything the user can do about it. OMEMO does not have a “blacklist”-feature or a signed list of trusted keys. It would however be possible to implement such thing in the future by combining OMEMO with OpenPGP for example. Of course, if some stranger has access to your account, it is time to change the password/server anyways.
Another weakness of OMEMO is, that it is currently only usable for encrypting the messages body. Since XMPP is an extensible protocol with other use cases than messaging, it would be nice to have support for arbitrary extension element encryption. There is however the extension protocol “OX” (XEP-0373: OpenPGP for XMPP), which has such capabilities. This feature can be extracted from OX and reused in OMEMO relatively easy.
Lets now focus on the “political” controversies around OMEMO.
In 2016/2017 there has been a lot of discussions, whether or not OMEMO should become a standard in the first place. The problem is, that in it’s current form (which has not really changes since its introduction), OMEMO depends on the wire format used by libsignal (the Signal protocol library used by conversations). That library however is licensed under the GPLv3 license, preventing permissively licensed and closed source applications from implementing OMEMO. While the Signal protocol itself is openly documented, the wire format used by libsignal is not, so any implementations which want to be compatible to current OMEMO clients must implement the same wire format by looking into the libsignal source code, which in turn makes the implementation a derivative of libsignal, which must be licensed under the GPL as well. There has been a pull request against the OMEMO XEP which addressed this issue by specifying an independent wire format for OMEMO, however that pull request was more or less rejected due to inactivity of the author.
During the phases of hot debates around OMEMO, it was discussed to base the protocol on Olm instead of the Signal protocol. Olm is the encryption protocol used by matrix.org. However, up to this point there is no Olm based OMEMO implementation, that I know of, neither have there been any experiments in that direction from people that proposed the idea (again – not that I know of).
Another idea was to completely redesign OMEMOs double ratchet specification as OMEMO-NEXT from ground up without even mentioning a specific library as the foundation. This would obviously be a way more complex XEP, as all the cryptographic operations and primitives which are currently abstracted and hidden away behind the Signal protocol, would have to be written down in that XEP. However, recently the IETF announced that work is done to create MLS (Message Layer Security), which does exactly that. It specifies a completely open version of the double ratchet algorithm along with infrastructure to share key material and so on. I’m not sure whether this is a coincidence, or if some of those who proposed OMEMO-NEXT are directly involved with the development of MLS. We’ll see, when MLS is ready and whether it will compete against OMEMO. I’d really love to see a cross-protocol encryption algorithm btw 😉 #bridges #federateEverything
Now lets talk about the biggest problem of OMEMO. Currently the XEP does not have an active “legal guardian”. The author has been inactive for an extended period of time, ignoring requests for comments, causing a total halt in the development of the standard (making changes to the XEP needs the authors approval). Things like specifying a new wire protocol are possible and reasonably easy to do. However not having changes written down in the XEP makes it nearly impossible to make coordinated changes. I’m sure there is a ton of potential for OMEMO and it is sad to see its (protocol-) development having come to a halt.
I’m sure that many of its current issues can be addressed by changes to the XEP. This is what I think needs to be done to OMEMO to make it more usable:
Specify a new wire protocol: This could make OMEMO accesible for commercial applications and allow independent implementations -> broader deploymentSpecify a general payload encryption scheme: This could benefit other encryption protocols as well and would make it possible to apply end-to-end encryption to a wider variety of use cases.Reuse the payload encryption scheme in OMEMO: Utilize OMEMO for things besides body encryption.Specify a way to sign device lists with “persistent key” algorithms like OpenPGP: This could simplify trust management.Specify a way to backup the identity key: This could reduce the identity key chaos, since the key could be reused on new devices/installations. However clients would have to make it clear to the user, not to use the same key on multiple devices.
This have been my thoughts about OMEMOs current state. What do you think about it?
Happy Hacking!
teilen teilen e-mail RSS-feed teilen
@pfefferle hm, I just noticed, that the AP plugin retoots all posts that are edited :D
Nexus 6p battery is swapped. Holy shit was that a pain...
Is there a way to make past public toots visible for new followers?
vanitasvitae
boosted
Ha! Now even my #nextcloud instance is part of the #fediverse! We truely live in exciting times!
vanitasvitae
boosted
vanitasvitae
boosted
We've just released #Halcyon 2.2.0 with the following changes:
- Added new video and audio players
- PeerTube and privacy friendly YouTube and Vimeo embeds
- Added Docker support - thanks @kemonine
- Added Italian translation - thanks @silkevicious
- Improved Japanese translation - thanks @vaginaplant
- Improved German translation - thanks @vanitasvitae
You can download it from https://notabug.org/halcyon-suite/halcyon/releases
Logo Design using Gimp!
- Blog on the Fediverse
- @vanitasvitae
#freesoftware enthusiast and #computerscience student from #muenster, Germany.
Joined Oct 2018
