profile
viewpoint
Paul Schaub vanitasvitae Federation of Planets, Earth https://jabberhead.tk I like free software and open standards!

gsantner/dandelion 94

a diaspora* client for Android

vanitasvitae/EnigmAndroid 9

Android implementation of the famous Enigma machine

pgpainless/pgpainless 8

Simple to use OpenPGP API based on Bouncycastle

Flowdalic/xeps 4

Drafts and early versions of proposed XMPP Extension Protocols (XEP)

vanitasvitae/HomeMadeOMEMO 4

Home Made OMEMO Client in < 200 lines of code (MIRROR)

vanitasvitae/clocc 2

Command Line OMEMO Chat Client - ARCHIVED! Migrated to https://git.jabberhead.tk/vanitasvitae/clocc

sleistikow/Spherical 1

A simple FLOSS spherical image viewer for Android.

vanitasvitae/GSOC2017 1

Landing page for my GSoC 2017 project - OMEMO encrypted Jingle File Transfer in Smack

issue commentpgpainless/pgpainless

API for key editing

Changing passphrase of the whole keyring now works. Changing the passphrase of separate subkeys should work, but is not yet tested.

All in all I obviously need some more tests for the new API, but I'm making some progress :)

vanitasvitae

comment created time in 3 days

push eventpgpainless/pgpainless

Paul Schaub

commit sha 99af9e0171c6f436731003bd88386807bfe98eab

Re-encrypting whole keyring successful

view details

push time in 3 days

issue commentpgpainless/pgpainless

API for key editing

To be clear, the code that added the user-id "during creation" really just generated the key and added the user-id afterwards. I did it that way as I'm not aware of a way to "really" add the user-id during creation so that it is covered by the same signature.

See https://github.com/bcgit/bc-java/issues/801

vanitasvitae

comment created time in 3 days

issue commentpgpainless/pgpainless

API for key editing

I just did a first successful test of adding user-ids to a key using the new edit key API I'm working on.

I'll probably replace the existing "add user-id during key creation" code to this API.

vanitasvitae

comment created time in 3 days

push eventpgpainless/pgpainless

Paul Schaub

commit sha 623c4c930d5c7ef3889050ed822d08470399bc06

Adding user-ids works

view details

push time in 3 days

startedFuckRIAA/youtube-dl

started time in 3 days

delete branch vanitasvitae/Smack

delete branch : sint_wait-for-filter-to-propagate_fixed

delete time in 3 days

delete branch vanitasvitae/Smack

delete branch : muc-enter-race-condition_fixed

delete time in 3 days

delete branch vanitasvitae/Smack

delete branch : sint-use-specific-assertions_fixed

delete time in 3 days

PR opened guusdk/Smack

IntegrationTests: Fix checkstyle issues

Another set of checkstyle fixes

+45 -30

0 comment

3 changed files

pr created time in 4 days

create barnchvanitasvitae/Smack

branch : sint_wait-for-filter-to-propagate_fixed

created branch time in 4 days

PR opened guusdk/Smack

MultiUserChat: Avoid using deprecated DefaultParticipantStatusListener

Another fix to please the build system.

+1 -1

0 comment

1 changed file

pr created time in 4 days

create barnchvanitasvitae/Smack

branch : muc-enter-race-condition_fixed

created branch time in 4 days

PR opened guusdk/Smack

MultiUserChatIntegrationTest: Fix checkstyle issues

I fixed the checkstyle issues so that we can eventually proceed merging your PR :)

+5 -2

0 comment

1 changed file

pr created time in 4 days

create barnchvanitasvitae/Smack

branch : sint-use-specific-assertions_fixed

created branch time in 4 days

pull request commentigniterealtime/Smack

Add missing right parenthesis in SINT output

@Flowdalic it looks like although Github shows the travis pipeline as stagnant, the build actually went through successfully.

Could you restart the build, so that we don't loose track of this PR due to Github showing incomplete checks?

guusdk

comment created time in 4 days

pull request commentigniterealtime/Smack

Additional Pubsub integration tests

@guusdk I rebased your PR and fixed the checkstyle issues.

If you hard-reset this PRs branch to https://github.com/vanitasvitae/Smack/tree/sint-pubsub-moretests we could tackle merging this :)

guusdk

comment created time in 4 days

create barnchvanitasvitae/Smack

branch : sint-pubsub-moretests

created branch time in 4 days

create barnchvanitasvitae/Smack

branch : 4.4

created branch time in 4 days

push eventvanitasvitae/Smack

Paul Schaub

commit sha 4cc0f1d12996df636b52aff130c5c26257d8aa5b

Bump pgpainless version to 0.1.0

view details

Florian Schmaus

commit sha 9e9d30074ce0fe367faae53b05e8eb12cfc58362

Merge pull request #428 from vanitasvitae/pgpainlessalpha12 Bump pgpainless version to 0.1.0

view details

Florian Schmaus

commit sha 6533cb7ed18e848311476a116898ddfc4b2825af

Introduce smack-websocket-okhttp This uses Java's Service Provider Interface (SPI) to abstract different WebSocket implementations. SMACK-835

view details

Florian Schmaus

commit sha 9002be8e7a0c12523eb448134f7354b3bb753edb

s/Websocket/WebSocket/ Java SE as well as OkHttp use 'WebSocket' (not 'Websocket'). Let us do the same. SMACK-835.

view details

Florian Schmaus

commit sha 0a6c21982bbc4e88b17e6456fb8e19eacef87851

Merge pull request #430 from Flowdalic/websocket Introduce smack-websocket-okhttp

view details

Dan Caseley

commit sha 8c33f56047502963e77aab3b6c9c0088d42afafd

Mac & Windows build instructions

view details

Florian Schmaus

commit sha 9e4153435aea1a9ec16d9ce527c1a17337db28c8

Merge pull request #434 from Fishbowler/building_on_a_mac Mac & Windows build instructions

view details

Florian Schmaus

commit sha b7824f008d27d1f19ce8aa09cc1d6b4ebf0f3c2c

Introduce and use XmlStringBuilder.text() Smack currently does unnecessary escaping of XML text, where it escapes e.g. '"' to '&quot;'. This bloats the stanza size, especially if JSON payloads are involved. Fixes SMACK-892 (although there are probably still places where XmlStringBuilder.escape() is used when XmlStringBuild.text() could have been used).

view details

Florian Schmaus

commit sha 488d01796a5e64e9b62aecf58699daf1c3858f7c

[tcp] Fix TlsState by aborting the channel selected callback Instead of breaking in case the SSLEngine signals NEED_WRAP, which leads to an endless loop while holding the channelSelectedCallbackLock, we have to return, so that the asynchronously invoked callback can aquire it, and do its work.

view details

Florian Schmaus

commit sha 525ee09ea15d7843e20d2d376f343cd5fe8ab76a

[tcp] Do not send SM ack after we send a </stream:stream> Do net put an ack to the queue if it has already been shutdown. Some servers, like ejabberd, like to request an ack even after we have send a stream close (and hance the queue was shutdown). If we would not check here, then the ack would dangle around in the queue, and be send on the next re-connection attempt even before the stream open. See the following trace of the MUC bookmarks integration test. The fact that it is a MUC test does not matter, but this test does disconnect the connection and reconnect it. Not how the server, ejabberd in this case, requests an SM ack by sending an <r/> even though we already send the </stream:stream>: 22:22:05 SENT (4): <iq id='MD4UC-61' type='set'> <query xmlns='jabber:iq:private'> <storage xmlns='storage:bookmarks'> <conference name='Smack Inttest: 7in7j' autojoin='true' jid='y9jcn5@conference.salem.geekplace.eu'> <nick> Nick-P2VXD7 </nick> </conference> </storage> </query> </iq> 22:22:05 RECV (4): <r xmlns='urn:xmpp:sm:3'/> 22:22:05 SENT (4): <a xmlns='urn:xmpp:sm:3' h='29'/> 22:22:05 RECV (4): <message to='sinttest-7in7j-4@salem.geekplace.eu' from='sinttest-7in7j-4@salem.geekplace.eu' type='headline'> <event xmlns='http://jabber.org/protocol/pubsub#event'> <items node='storage:bookmarks'> <item id='current'> <storage xmlns='storage:bookmarks'> <conference name='Smack Inttest: 7in7j' autojoin='true' jid='y9jcn5@conference.salem.geekplace.eu'> <nick> Nick-P2VXD7 </nick> </conference> </storage> </item> </items> </event> <addresses xmlns='http://jabber.org/protocol/address'> <address jid='sinttest-7in7j-4@salem.geekplace.eu/1415073683806426185213090' type='replyto'/> </addresses> </message> 22:22:05 RECV (4): <iq xml:lang='en-US' to='sinttest-7in7j-4@salem.geekplace.eu/1415073683806426185213090' from='sinttest-7in7j-4@salem.geekplace.eu' type='result' id='MD4UC-61'/> 22:22:05 SENT (4): <presence id='6MS6J-20' type='unavailable'/> <a xmlns='urn:xmpp:sm:3' h='31'/> <!-- We have closed the stream --> </stream:stream> <!-- But the server still requests an SM ack --> 22:22:05 RECV (4): <r xmlns='urn:xmpp:sm:3'/> 22:22:05 RECV (4): </stream:stream> 22:22:05 XMPPConnection closed (XMPPTCPConnection[sinttest-7in7j-4@salem.geekplace.eu/1415073683806426185213090] (4)) 22:22:05 SENT (4): <a xmlns='urn:xmpp:sm:3' h='31'/> 22:22:05 SENT (4): <stream:stream xmlns='jabber:client' to='salem.geekplace.eu' xmlns:stream='http://etherx.jabber.org/streams' version='1.0' from='sinttest-7in7j-4@salem.geekplace.eu' xml:lang='en-US'> 22:22:05 RECV (4): ?xml version='1.0'?> <stream:stream id='3379123514446782311' ver 22:22:05 RECV (4): sion='1.0' xml:lang='en' xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client'> <stream:error> <invalid-xml xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> </stream:error> </stream:stream> 22:22:05 XMPPConnection closed due to an exception (XMPPTCPConnection[sinttest-7in7j-4@salem.geekplace.eu/1415073683806426185213090] (4)) org.jivesoftware.smack.XMPPException$StreamErrorException: invalid-xml You can read more about the meaning of this stream error at http://xmpp.org/rfcs/rfc6120.html#streams-error-conditions <stream:error><invalid-xml xmlns='urn:ietf:params:xml:ns:xmpp-streams'/></stream:error> at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:981) at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$700(XMPPTCPConnection.java:913) at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:936) at java.base/java.lang.Thread.run(Thread.java:834)

view details

Florian Schmaus

commit sha 08fc0ba0b4ecb33e882a9f3c722f5425e8772f0d

[tcp] Improve pendingWriteInterestAfterRead code comment

view details

Florian Schmaus

commit sha 4db7d787f7e4b6e525c9482d7088f673ff795026

[tcp] Add code comment why we have to copy the ByteBuffer

view details

Florian Schmaus

commit sha 6837c305e86593cf968dabf4fcfd45abb1ce05ec

Smack 4.4.0-beta2

view details

Florian Schmaus

commit sha 02341f6330e9b53938fba3c04f30785cee393fd1

Smack 4.4.0-beta3-SNAPSHOT

view details

Florian Schmaus

commit sha b857f33ac3d1feaf1d04d6b024fb71d09365cb7d

Merge branch '4.4'

view details

Florian Schmaus

commit sha c1b32f8e11e865aa95eb96f266a3cafe28fc3ee0

[carbons] Throw SmackParsingException instead of IOException

view details

Florian Schmaus

commit sha fe7d3bec3026c122eb75b371bac6202788fa4a5e

Make Forwarded a generic type Fixes SMACK-821.

view details

Florian Schmaus

commit sha 048226960b9360d85089a9f3c973ea8b0446efbf

Rename smack-java7 to smack-java8 Fixes SMACK-854.

view details

Florian Schmaus

commit sha 15e3d267f612f83f2a8ed9d2c444fd34a7dfcea9

Add Pair utility class

view details

Florian Schmaus

commit sha 6d39a4e3ac8abbef11b4a6f8f5d89363c2424980

[bob] Add BoBDataExtension, remove BoBExtension BoBExtension extending XHTMLExtension was poorly designed and only worked for a single paragraphy. Fixes SMACK-770.

view details

push time in 4 days

delete branch vanitasvitae/Smack

delete branch : oxExposeMethods

delete time in 4 days

PR opened igniterealtime/Smack

OpenPgpManager: Expose methods to generate and import keys

This PR exposes methods to generate OpenPGP keys in the OpenPgpManager.

The motivation for this change is to allow key generation without the user having to access the store.

+20 -8

0 comment

1 changed file

pr created time in 4 days

create barnchvanitasvitae/Smack

branch : exposeOxGenerateKeys

created branch time in 4 days

create barnchvanitasvitae/Smack

branch : oxExposeMethods

created branch time in 4 days

push eventpgpainless/pgpainless

Paul Schaub

commit sha 651a69c118b47a45ab5719a6980c1cba7b2a36ad

Work on the editing api

view details

push time in 5 days

issue openedpgpainless/pgpainless

JUnit: Switch to Jupiter test API

We would benefit from the new test api, especially from stuff like assertThrows.

created time in 5 days

issue commentpgpainless/pgpainless

API for key editing

Ah yes, passphrase changes are a use-case as well. Thanks for pointing out the issue of multiple passphrases per key-ring :+1:

vanitasvitae

comment created time in 6 days

startedflyway/flyway

started time in 6 days

issue commentpgpainless/pgpainless

API for key editing

Progress is tracked in https://github.com/pgpainless/pgpainless/tree/keyEditing

vanitasvitae

comment created time in 7 days

create barnchpgpainless/pgpainless

branch : keyEditing

created branch time in 7 days

issue commentpgpainless/pgpainless

API for key editing

The API should consist of actions that can be performed on a PGPSecretKeyRing.

Below is a sketch of how the API could look like:

PGPainless.modifyKeyRing(secretKeyRing)
    ...
    // This could be a shortcut method for adding a simple string user-id.
    // Later we could also add methods to add information like name, email, comments using a builder
    .addUserId("alice@wonderland.lit")

    .deleteUserId("alice@literature.club")

    .setExpiryDate(newExpiryDate|LocalDate)

    .addSubKey(keySpec|keyPair)

    .deleteSubKey(fingerprint|keyId)

    .revokeSubKey(fingerprint|keyId)
vanitasvitae

comment created time in 7 days

issue openedpgpainless/pgpainless

API for key editing

Currently stuff like additional user-ids can only be set on a key during key creation.

It would be more logical to have a key editing API that allows for addition/removal of user-ids and subkeys, as well as modification of other key attributes like extension/revocation of certifications.

The API could roughly resemble GnuPGs edit-key command.

created time in 7 days

issue closedpgpainless/pgpainless

Feature request: Adding more User IDs

I'm looking through the KeyRingBuilderInterface and it seems only Primary User ID can be set - there is no way to add more User IDs to the key and it would be a nice addition for people using several e-mail addresses.

closed time in 8 days

wiktor-k

issue commentpgpainless/pgpainless

Feature request: Adding more User IDs

This is now implemented.

wiktor-k

comment created time in 8 days

push eventpgpainless/pgpainless

Paul Schaub

commit sha f21231ad53e67df4b17e16b688c5a90c34b05f1a

Trim user-ids

view details

push time in 8 days

push eventpgpainless/pgpainless

Paul Schaub

commit sha c06bedd656223ad3a23d7d33eb496f5f37d7e618

Introduce SignatureType enum

view details

push time in 8 days

push eventpgpainless/pgpainless

Paul Schaub

commit sha 1b389f678a70d0b4cffb191cc5e7782626718470

Fix checkstyle issues

view details

push time in 8 days

push eventpgpainless/pgpainless

Paul Schaub

commit sha 8c30db9bf18537594070731ced16f92713ab0efe

Wip: Allow for additional user-ids to be added

view details

Paul Schaub

commit sha 11e7bc69fc032556951377ff924c36acd0bbaaa4

Fix NPE by initializing the SignatureGenerator

view details

Paul Schaub

commit sha 2f85c9a8d0755b8a34ccabe3416935d571594e48

Test if userId is present

view details

Paul Schaub

commit sha 9670e5ecb9c9c234e26b3c96e1286815c7fb6315

Prevent additional user-id from being equal to primary user-id

view details

push time in 8 days

push eventpgpainless/pgpainless

Paul Schaub

commit sha 9670e5ecb9c9c234e26b3c96e1286815c7fb6315

Prevent additional user-id from being equal to primary user-id

view details

push time in 8 days

starteddjabberd/DJabberd

started time in 8 days

push eventpgpainless/pgpainless

Paul Schaub

commit sha 2f85c9a8d0755b8a34ccabe3416935d571594e48

Test if userId is present

view details

push time in 12 days

push eventpgpainless/pgpainless

Paul Schaub

commit sha 618e3828eee4ff6d6df7540ddc5fee7b64bf07e0

Test if userId is present

view details

push time in 12 days

issue commentpgpainless/pgpainless

Feature request: Adding more User IDs

Update: Apparently it is possible to add additional user-ids after creation of the key ring. I did some experimentation and my POC code appears to be working, however, I'm not sure if this is how it's supposed to be done.

I created an issue upstream asking for clarification.

wiktor-k

comment created time in 12 days

push eventpgpainless/pgpainless

Paul Schaub

commit sha 11e7bc69fc032556951377ff924c36acd0bbaaa4

Fix NPE by initializing the SignatureGenerator

view details

push time in 12 days

issue openedbcgit/bc-java

Feature Request: Allow additional user IDs on PGP key

Hi! I would like to add additional (non-primary) user ids on a PGP key. While this apparently cannot be done during creation of the keyring using the PGPKeyRingGenerator, I figured that it may be possible to add the user-id attribute afterwards by calling PGPPublicKey.addCertification(publicKey, userId, signatureGenerator.generateCertification(userId, publicKey)).

However, I'm not sure it this is the intended way of doing this.

This is my code:

                // Generate secret key ring with only primary user id
                PGPSecretKeyRing secretKeyRing = ringGenerator.generateSecretKeyRing();

                Iterator<PGPSecretKey> secretKeys = secretKeyRing.getSecretKeys();

                // Attempt to add additional user-ids to the primary public key
                PGPPublicKey primaryPubKey = secretKeys.next().getPublicKey();
                PGPPrivateKey privateKey = secretKeyRing.getSecretKey().extractPrivateKey(secretKeyDecryptor);
                for (String additionalUserId : additionalUserIds) {
                    signatureGenerator.init(0x13, privateKey);
                    PGPSignature additionalUserIdSignature =
                            signatureGenerator.generateCertification(additionalUserId, primaryPubKey);
                    primaryPubKey = PGPPublicKey.addCertification(primaryPubKey,
                            additionalUserId, additionalUserIdSignature);
                }

                // "reassemble" secret key ring with modified primary key
                PGPSecretKey primarySecKey = new PGPSecretKey(
                        secretKeyRing.getSecretKey().extractPrivateKey(secretKeyDecryptor),
                        primaryPubKey, digestCalculator, true, secretKeyEncryptor);
                List<PGPSecretKey> secretKeyList = new ArrayList<>();
                secretKeyList.add(primarySecKey);
                while (secretKeys.hasNext()) {
                    secretKeyList.add(secretKeys.next());
                }
                secretKeyRing = new PGPSecretKeyRing(secretKeyList);

                // extract public key ring from secret keys
                List<PGPPublicKey> publicKeyList = new ArrayList<>();
                Iterator<PGPPublicKey> publicKeys = secretKeyRing.getPublicKeys();
                while (publicKeys.hasNext()) {
                    publicKeyList.add(publicKeys.next());
                }
                PGPPublicKeyRing publicKeyRing = new PGPPublicKeyRing(publicKeyList);

created time in 12 days

create barnchpgpainless/pgpainless

branch : additionalUserId

created branch time in 12 days

issue commentpgpainless/pgpainless

Feature request: Adding more User IDs

I agree that this would be an important feature. Adding support in PGPainless' builder structure is trivial, however unfortunately it doesn't seem easily possible to add additional user-ids in Bouncycastle. The PGPKeyRingGenerator calls the PGPSecretKey constructor here, which calls this method to certify the public key with the primary user id.

Ideally we would hook into BC here to generate and add additional certifications for the other user-ids to the public key before finishing the construction, but this doesn't seem to be possible.

As far as I understand Bouncycastle would need to be patched somehow to allow this. Correct me if I'm wrong of course :)

wiktor-k

comment created time in 12 days

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

startedtlambertz/seedvault_backup_parser

started time in 22 days

PullRequestReviewEvent

PR opened pluginkollektiv/antispam-bee

Add pattern to counter some trackback spam

Hi! Thank you for developing this great extension!

I recently received some trackback spam (basically trackback comments like below, but with slightly different wordings)

[…] Here you can find 61912 more Information to that Topic: <url to my blog post> […]

This PR adds a regex that should catch all those comments. I haven't yet received a new spam comment since applying this pattern, so I cannot yet verify if it's working, but I will come back here once I get "lucky".

+3 -0

0 comment

1 changed file

pr created time in a month

create barnchvanitasvitae/antispam-bee

branch : trackback

created branch time in a month

fork vanitasvitae/antispam-bee

„... another popular solution to fight spam is Antispam Bee“ – Matt Mullenweg, Q&A WordCamp Europe 2014

https://wordpress.org/plugins/antispam-bee/

fork in a month

Pull request review commentigniterealtime/Smack

WIP: Add support for XEP-0390: Entity Capability 2.0

+/**+ *+ * Copyright 2020 Aditya Borikar+ *+ * Licensed under the Apache License, Version 2.0 (the "License");+ * you may not use this file except in compliance with the License.+ * You may obtain a copy of the License at+ *+ *     http://www.apache.org/licenses/LICENSE-2.0+ *+ * Unless required by applicable law or agreed to in writing, software+ * distributed under the License is distributed on an "AS IS" BASIS,+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.+ * See the License for the specific language governing permissions and+ * limitations under the License.+ */+package org.jivesoftware.smackx.caps2.element;++import java.util.HashSet;+import java.util.Iterator;+import java.util.Set;++import org.jivesoftware.smack.packet.ExtensionElement;+import org.jivesoftware.smack.packet.XmlEnvironment;+import org.jivesoftware.smack.util.XmlStringBuilder;++public class Caps2Element implements ExtensionElement {++    public static final String NAMESPACE = "urn:xmpp:caps";+    public static final String ELEMENT = "c";++    private Set<Caps2HashElement> hashes;++    public Caps2Element(Caps2HashElement hashElement) {+        hashes = new HashSet<>();+        hashes.add(hashElement);+    }++    public Caps2Element(Set<Caps2HashElement> hashElementSet) {+        hashes = hashElementSet;+    }++    @Override+    public String getNamespace() {+        return NAMESPACE;+    }++    @Override+    public String getElementName() {+        return ELEMENT;+    }++    @Override+    public CharSequence toXML(XmlEnvironment xmlEnvironment) {+        XmlStringBuilder xml = new XmlStringBuilder(this, xmlEnvironment);+        xml.rightAngleBracket();++        Iterator<Caps2HashElement> iterator = hashes.iterator();+        while (iterator.hasNext()) {+            xml.append(iterator.next());+        }++        xml.closeElement(ELEMENT);+        return xml;+    }++    public static class Caps2HashElement implements ExtensionElement {++        public static final String NAMESPACE = "urn:xmpp:hashes:2";+        public static final String ELEMENT = "hash";++        private final String algorithm;+        private final String hash;++        public Caps2HashElement (String algorithm, String hash) {+            this.algorithm = algorithm;+            this.hash = hash;+        }++        @Override+        public String getNamespace() {+            return NAMESPACE;+        }++        @Override+        public String getElementName() {+            return ELEMENT;+        }++        @Override+        public CharSequence toXML(XmlEnvironment xmlEnvironment) {

Same here

adiaholic

comment created time in a month

Pull request review commentigniterealtime/Smack

WIP: Add support for XEP-0390: Entity Capability 2.0

+/**+ *+ * Copyright 2020 Aditya Borikar+ *+ * Licensed under the Apache License, Version 2.0 (the "License");+ * you may not use this file except in compliance with the License.+ * You may obtain a copy of the License at+ *+ *     http://www.apache.org/licenses/LICENSE-2.0+ *+ * Unless required by applicable law or agreed to in writing, software+ * distributed under the License is distributed on an "AS IS" BASIS,+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.+ * See the License for the specific language governing permissions and+ * limitations under the License.+ */+package org.jivesoftware.smackx.caps2.element;++import java.util.HashSet;+import java.util.Iterator;+import java.util.Set;++import org.jivesoftware.smack.packet.ExtensionElement;+import org.jivesoftware.smack.packet.XmlEnvironment;+import org.jivesoftware.smack.util.XmlStringBuilder;++public class Caps2Element implements ExtensionElement {++    public static final String NAMESPACE = "urn:xmpp:caps";+    public static final String ELEMENT = "c";++    private Set<Caps2HashElement> hashes;++    public Caps2Element(Caps2HashElement hashElement) {+        hashes = new HashSet<>();+        hashes.add(hashElement);+    }++    public Caps2Element(Set<Caps2HashElement> hashElementSet) {+        hashes = hashElementSet;+    }++    @Override+    public String getNamespace() {+        return NAMESPACE;+    }++    @Override+    public String getElementName() {+        return ELEMENT;+    }++    @Override+    public CharSequence toXML(XmlEnvironment xmlEnvironment) {

Change the method signature to return XmlStringBuilder instead of CharSequence.

adiaholic

comment created time in a month

PullRequestReviewEvent
PullRequestReviewEvent

push eventvanitasvitae/flowdalic-xeps

Paul Schaub

commit sha 86a89f17ac87eb62e643cdfc1e7e2977f00df579

Initial ikey proposal

view details

push time in a month

PR closed xsf/xeps

XEP-0060: Disallow '=' and ';' in NodeIDs to allow use in URIs and refer to PRECIS Stringprep Needs Council

Disclaimer: This might be a breaking change.

This PR limits node IDs by disallowing the characters '=' and ';'. The reason is that currently it is possible to forge possibly dangerous PubSub node IDs. Let's take a node with ID catpictures;node=dogpictures as an example. The URI for subscribing to above node might be xmpp:pubsub.example.org?pubsub;action=subscribe;node=catpictures;node=dogpictures which a client might interpret as xmpp:pubsub.example.org?pubsub;action=subscribe;node=dogpictures, which would subscribe the client to a different node.

Additionally @Flowdalic noted that the sentence

the pubsub service MUST ensure that the NodeID conforms to the Resourceprep profile of Stringprep as described in <cite>RFC 3920</cite>

is wrong and that PRECIS is used instead. RFC 7622 §3.4 states that

The resourcepart of a JID is an instance of the OpaqueString profile of the PRECIS FreeformClass, which is specified in [RFC7613]. The rules and considerations provided in that specification MUST be applied to XMPP resourceparts.

+19 -4

0 comment

1 changed file

vanitasvitae

pr closed time in a month

startedplausible/analytics

started time in a month

Pull request review commentigniterealtime/Smack

WIP: Add support for XEP-0390: Entity Capability 2.0

 private Caps2Manager(XMPPConnection connection) {         if (autoEnable) {             publishSupportForECaps2();         }--        connection.addConnectionListener(new ConnectionListener() {-            @Override-            public void connected(XMPPConnection connection) {-                 processCapsStreamFeatureIfAvailable(connection);-            }-            private void processCapsStreamFeatureIfAvailable(XMPPConnection connection) {-                Caps2Element caps2Element = connection.getFeature(Caps2Element.class);-                if (caps2Element == null) {-                    return;-                }-                DomainBareJid from = connection.getXMPPServiceDomain();-                addCapsExtensionInfo(from, caps2Element);-            }-        });     }      public void publishSupportForECaps2() {         ServiceDiscoveryManager sdm = ServiceDiscoveryManager.getInstanceFor(connection());         sdm.addFeature(Caps2Element.NAMESPACE);-        Logger.getAnonymousLogger().info("adiaholic : caps2 feature added");     } -    private static void addCapsExtensionInfo(DomainBareJid from, Caps2Element caps2Element) {-        from.asBareJid();-        caps2Element.getClass();+    public void publishEntityCapabilities() throws NoResponseException, XMPPErrorException, NotConnectedException, InterruptedException, UnsupportedEncodingException, NoSuchAlgorithmException {+        ServiceDiscoveryManager sdm = ServiceDiscoveryManager.getInstanceFor(connection());+        DiscoverInfo discoverInfo = sdm.discoverInfo(connection().getUser());++        List<String> algoList = new ArrayList<String>();

This could be Collections.singletonList(defaultAlgo), or does the list need to be mutable?

adiaholic

comment created time in a month

PullRequestReviewEvent
PullRequestReviewEvent

push eventvanitasvitae/xsf-xeps

Paul Schaub

commit sha 0bc611c591a54e9b4f03092c8128405b75e6eda5

XEP-0060: Disallow = and ; in NodeIDs to allow use in URIs and refer to PRECIS Stringprep The reason is that currently it is possible to forge possibly dangerous PubSub node IDs. Let's take a node with ID catpictures;node=dogpictures as an example. The URI for subscribing to above node might be `xmpp:pubsub.example.org?pubsub;action=subscribe;node=catpictures;node=dogpictures` which a client might interpret as `xmpp:pubsub.example.org?pubsub;action=subscribe;node=dogpictures`, which would subscribe the client to a different node. Additionally Florian Schmaus noted that the sentence 'the pubsub service MUST ensure that the NodeID conforms to the Resourceprep profile of Stringprep as described in RFC 3920' is wrong and that PRECIS is used instead. RFC 7622 §3.4 states that 'The resourcepart of a JID is an instance of the OpaqueString profile of the PRECIS FreeformClass, which is specified in [RFC7613]. The rules and considerations provided in that specification MUST be applied to XMPP resourceparts.' Thanks for the input!

view details

push time in a month

push eventvanitasvitae/xsf-xeps

Paul Schaub

commit sha 26bac6c71b231bd7131faffd1e81a2ec43d845c9

XEP-0060: Disallow = and ; in NodeIDs to allow use in URIs and refer to PRECIS Stringprep The reason is that currently it is possible to forge possibly dangerous PubSub node IDs. Let's take a node with ID catpictures;node=dogpictures as an example. The URI for subscribing to above node might be `xmpp:pubsub.example.org?pubsub;action=subscribe;node=catpictures;node=dogpictures` which a client might interpret as `xmpp:pubsub.example.org?pubsub;action=subscribe;node=dogpictures`, which would subscribe the client to a different node. Additionally @Flowdalic noted that the sentence 'the pubsub service MUST ensure that the NodeID conforms to the Resourceprep profile of Stringprep as described in RFC 3920' is wrong and that PRECIS is used instead. RFC 7622 §3.4 states that 'The resourcepart of a JID is an instance of the OpaqueString profile of the PRECIS FreeformClass, which is specified in [RFC7613]. The rules and considerations provided in that specification MUST be applied to XMPP resourceparts.'

view details

push time in a month

PR opened xsf/xeps

XEP-0060: Disallow '=' and ';' in NodeIDs to allow use in URIs and refer to PRECIS Stringprep

Disclaimer: This might be a breaking change.

This PR limits node IDs by disallowing the characters '=' and ';'. The reason is that currently it is possible to forge possibly dangerous PubSub node IDs. Let's take a node with ID catpictures;node=dogpictures as an example. The URI for subscribing to above node might be xmpp:pubsub.example.org?pubsub;action=subscribe;node=catpictures;node=dogpictures which a client might interpret as xmpp:pubsub.example.org?pubsub;action=subscribe;node=dogpictures, which would subscribe the client to a different node.

Additionally @Flowdalic noted that the sentence "the pubsub service MUST ensure that the NodeID conforms to the Resourceprep profile of Stringprep as described in <cite>RFC 3920</cite>" is wrong and that PRECIS is used instead. RFC 7622 §3.4 states that

The resourcepart of a JID is an instance of the OpaqueString profile of the PRECIS FreeformClass, which is specified in [RFC7613]. The rules and considerations provided in that specification MUST be applied to XMPP resourceparts.

+19 -4

0 comment

1 changed file

pr created time in a month

push eventvanitasvitae/xsf-xeps

Paul Schaub

commit sha 590c6185a161d9124efb8ce1c431f15548651bb3

XEP-0060: Disallow = and ; in NodeIDs to allow use in URIs and refer to PRECIS Stringprep

view details

push time in a month

push eventvanitasvitae/xsf-xeps

Paul Schaub

commit sha 1d4b7762149e25edcd2d3fbe8e5653109cc0f4b1

XEP-0060: Disallow = and ; in NodeIDs to allow use in URIs and refer to PRECIS Stringprep

view details

push time in a month

push eventvanitasvitae/xsf-xeps

Paul Schaub

commit sha e69b525bea4f727eae687d9dd2f76a6a48dac661

XEP-0060: Disallow & and ; in NodeIDs to allow use in URIs and refer to PRECIS Stringprep

view details

push time in a month

create barnchvanitasvitae/xsf-xeps

branch : pubsubnodename

created branch time in a month

push eventvanitasvitae/xsf-xeps

Linus Jahn

commit sha 4675f44a13b971dd885dea26b707af3f785d9e25

XEP-0060: Fix minor typo in form example

view details

Jonas Schäfer

commit sha f33f609b1b0e6a44d35e84a1e5ff13a95368f74c

XEP-0060: re-add revision block

view details

Paul Schaub

commit sha 387cc1e151fff03909079d75cd41fcac68e0b529

XEP-0060: Add missing querytype 'retrieve' action and 'item' key to registry submission

view details

Jonas Schäfer

commit sha ed292eab5df186c2c5d8bfdd7ec2a213316cc6a0

Merge branch 'feature/xep-0060-2' into premerge

view details

Jonas Schäfer

commit sha 96df927111b42aab80d3e5ec8f99ebd600542cf3

Accept inbox/xep-mam-prefs.xml as XEP-0441

view details

Jonas Schäfer

commit sha fc8526d02b14d6d9b704410de50f5f84f4d27fdc

Accept inbox/xep-pubsub-mam.xml as XEP-0442

view details

Jonas Schäfer

commit sha 023964abe6e66c33b8702cd142ca432dfca54c6d

Merge branch 'premerge' into 'main' Premerge See merge request xsf/xeps!16

view details

Jonas Schäfer

commit sha 6fc01da729d83d08491c0bee9c89e0899f6f2583

xep.ent: Fix name of XEP-0402

view details

Maxime “pep” Buquet

commit sha c7166ab94a3ca34f00a38b8f0c0ac48d47f0fb15

Merge remote-tracking branch 'gitlab/main' into master

view details

push time in a month

startedjanboddez/share-on-mastodon

started time in a month

delete branch vanitasvitae/xsf-xeps

delete branch : pubsubregistry

delete time in 2 months

starteddino/libomemo-c

started time in 2 months

PR closed igniterealtime/Smack

EqualsUtil, HashCode: Add methods for lists

This PR adds methods to process lists to the EqualsUtil and HashCode utility classes.

+28 -0

0 comment

2 changed files

vanitasvitae

pr closed time in 2 months

PR opened igniterealtime/Smack

EqualsUtil, HashCode: Add methods for lists

This PR adds methods to process lists to the EqualsUtil and HashCode utility classes.

+28 -0

0 comment

2 changed files

pr created time in 2 months

create barnchvanitasvitae/Smack

branch : listEqualsHashcode

created branch time in 2 months

delete branch vanitasvitae/jxmpp

delete branch : fulljidnpe

delete time in 2 months

pull request commentigniterealtime/Smack

WIP: Add support for XEP-0390: Entity Capability 2.0

Nice! I see you are not yet fed up with Smack development :+1:

adiaholic

comment created time in 2 months

push eventpgpainless/pgpainless

Paul Schaub

commit sha 6a4fa47c1288dd900245fbe00b74ba57e404ccd6

Remove unused imports

view details

push time in 2 months

startedCalyxOS/calyxos

started time in 2 months

Pull request review commentxsf/xeps

WIP: ProtoXEP: Automatic session healing for OMEMO

+<?xml version='1.0' encoding='UTF-8'?>+<!DOCTYPE xep SYSTEM 'xep.dtd' [+  <!ENTITY % ents SYSTEM 'xep.ent'>+  <!ENTITY ns "urn:xmpp:omemo:1">+%ents;+]>+<?xml-stylesheet type='text/xsl' href='xep.xsl'?>+<xep>+<header>+  <title>Session Healing for OMEMO</title>+  <abstract>This specification provides a protocol and rules extension for OMEMO (XEP-0384) to achieve (automatic) session healing.</abstract>+  &LEGALNOTICE;+  <number>xxxx</number>+  <status>ProtoXEP</status>+  <type>Standards Track</type>+  <sig>Standards</sig>+  <approver>Council</approver>+  <dependencies>+    <spec>XMPP Core</spec>+    <spec>XEP-0384</spec>+  </dependencies>+  <supersedes/>+  <supersededby/>+  <shortname>NOT_YET_ASSIGNED</shortname>+  <author>+    <firstname>Tim</firstname>+    <surname>Henkes</surname>+    <email>me@syndace.dev</email>+  </author>+  <revision>+    <version>0.0.1</version>+    <date>2020-09-06</date>+    <initials>th</initials>+    <remark><p>First draft.</p></remark>+  </revision>+</header>+<section1 topic='Introduction' anchor='intro'>+  <p>&xep0384; consists of the &doubleratchet; encryption scheme and the &x3dh; key agreement protocol, specified by Trevor Perrin and Moxie Marlinspike. Both parts are robust to some potential issues of messaging, like delayed, out-of-order or lost messages. Still, there are cases in which the protocol struggles to uphold its robustness, the most prominent example being backup/restore mechanisms. Due to OMEMO's forward secrecy, restoring old and outdated OMEMO sessions inevitably results in so-called "broken sessions". Broken sessions are sessions, in which the ratchets of two communicating parties have diverged, meaning that no message will ever be successfully transferred using those sessions. The only way to recover from this situation is to discard the broken sessions and replace them with new ones. Doing so in an automated manner needs careful consideration and rules, otherwise clients might become vulnerable to downgrade attacks, where an attacker could effectively downgrade sessions to only use &x3dh; and never arrive at the point where &doubleratchet; takes over and provides its security properties. This specification provides a small protocol extension for &xep0384;, which enables clients to detect broken sessions without being susceptible to downgrade attacks. In conjunction with the rules introduced in this specification, clients will be able to securely recover from certain broken session situations without user interaction. Note that there are still cases, in which automatic session healing is not possible, even when following this specification.</p>+</section1>+<section1 topic='Requirements' anchor='reqs'>+  <ul>+    <li>Provide a means for clients to securely perform automated OMEMO session healing.</li>+    <li>Be fully optional on top of &xep0384;.</li>+    <li>Work seamlessly, i.e. communication between clients with and without support still works as before without the need of explicit support discovery.</li>+  </ul>+</section1>+<section1 topic='Protocol Extension' anchor='protocol-extension'>+  <section2 topic='Double Ratchet' anchor='protocol-double_ratchet'>+    <p>This section extends <link url="https://xmpp.org/extensions/xep-0384.html#protocol-double_ratchet">the corresponding section in XEP-0384</link>.</p>+    <dl>+      <di><dt>ratchet initialization</dt><dd>+        In addition to the ratchet initialization as speecified in &xep0384;, the state is extended with the following values:+        <ul>+          <li><strong>DHrc</strong> &#8211; Tracks the Diffie-Hellman ratchet counter of the other party, initialized to 0.</li>+          <li><strong>DHsc</strong> &#8211; Tracks the own Diffie-Hellman ratchet counter, initialized to 0.</li>+        </ul>+      </dd></di>+      <di><dt>RatchetEncrypt</dt><dd>As specified in the &doubleratchet; specification, with one addition: if <tt>header.n</tt> equals zero, increment <tt>state.DHsc</tt> once.</dd></di>+    </dl>+  </section2>+</section1>+<section1 topic='Use Cases' anchor='usecases'>+  <section2 topic='Sending a message' anchor='usecases-messagesend'>+    <section3 topic='Message structure description' anchor='message-structure-description'>+      <p>This section extends <link url="https://xmpp.org/extensions/xep-0384.html#message-structure-description">the corresponding section in XEP-0384</link>. Three new attributes are introduced, otherwise the structure is untouched. Clients that don't support this specification should ignore the (for them) unknown attributes, resulting in seamless compatibility. The data needed to fill the new attributes is explained below the updated example.</p>+      <p>The &lt;keys&gt; element is extended to also have an attribute called 'dhcs_sig' containing the base64 encoded signature of the Diffie-Hellman ratchet counters.</p>+      <p>The &lt;key&gt; element is extended to also have two attributes called 'dhc' (holding an unsigneed integer) and 'ekid' (holding base64 encoded data).</p>+      <p>The <link url="https://xmpp.org/extensions/xep-0384.html#example-7">example</link> is updated to include the newly introduced attributes:</p><!-- TODO: Anchor for the example -->

I'd s/The example/The message header/g

Syndace

comment created time in 2 months

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentxsf/xeps

WIP: XEP-0384: Version 0.7.0

     </section3>     <section3 topic='Message structure description' anchor='message-structure-description'>       <p>-        An OMEMO encrypted message is specified to include an &lt;encrypted&gt; element in the <tt>&ns;</tt> namespace. It always contains two child nodes, the &lt;header&gt; and the &payload; element.-        The &lt;header&gt; element has an attribute named 'sid' referencing the device id of the sending device and contains one or multiple &lt;keys&gt; elements, each with an attribute 'jid' of one of the recipients bare JIDs as well as one or multiple &lt;key&gt; elements.+        An OMEMO encrypted message is specified to include an &lt;encrypted&gt; element in the <tt>&ns;</tt> namespace. It contains up to two child nodes, the &lt;header&gt; and the &payload; element. The &lt;header&gt; element must always be present, the &payload; element must be present unless an empty message is sent, as described below.+        The &lt;header&gt; element has an attribute named 'sid' referencing the device id of the sending device and contains one or multiple &lt;keys&gt; elements, each with an attribute 'jid' of one of the recipients bare JIDs, as well as one or multiple &lt;key&gt; elements.         A &lt;key&gt; element has an attribute named 'rid' referencing the device id of the recipient device, and an attribute named 'kex' which defaults to 'false' and indicates if the enclosed encrypted message includes a key exchange. The key and HMAC encrypted using the long-standing OMEMO session for that recipient device are encoded using base64 and placed as text content into the &lt;key&gt; element.         The encrypted &content; element is encoded using base64 and placed as text content into the &payload; element.       </p>+      <p>A special case are <em>empty</em> messages, which are used in various places throughout the protocol purely to manage sessions and not to transfer content. With empty messages, the step of creating and encrypting the &payload; element is skipped. Instead of encrypting the key and authentication tag of the &payload; ciphertext with the Double Ratchet session, 32 zero-bytes are encrypted with the Double Ratchet session directly. The resulting OMEMOKeyExchange or OMEMOAuthenticatedMessage are put into &lt;key&gt; elements as usual, but the &payload; element is omitted altogether, so that the &lt;encrypted&gt; element only contains a &lt;header&gt;.</p>

Ah, great! :)

Syndace

comment created time in 2 months

PullRequestReviewEvent

Pull request review commentxsf/xeps

WIP: XEP-0384: Version 0.7.0

     </section3>     <section3 topic='Message structure description' anchor='message-structure-description'>       <p>-        An OMEMO encrypted message is specified to include an &lt;encrypted&gt; element in the <tt>&ns;</tt> namespace. It always contains two child nodes, the &lt;header&gt; and the &payload; element.-        The &lt;header&gt; element has an attribute named 'sid' referencing the device id of the sending device and contains one or multiple &lt;keys&gt; elements, each with an attribute 'jid' of one of the recipients bare JIDs as well as one or multiple &lt;key&gt; elements.+        An OMEMO encrypted message is specified to include an &lt;encrypted&gt; element in the <tt>&ns;</tt> namespace. It contains up to two child nodes, the &lt;header&gt; and the &payload; element. The &lt;header&gt; element must always be present, the &payload; element must be present unless an empty message is sent, as described below.+        The &lt;header&gt; element has an attribute named 'sid' referencing the device id of the sending device and contains one or multiple &lt;keys&gt; elements, each with an attribute 'jid' of one of the recipients bare JIDs, as well as one or multiple &lt;key&gt; elements.         A &lt;key&gt; element has an attribute named 'rid' referencing the device id of the recipient device, and an attribute named 'kex' which defaults to 'false' and indicates if the enclosed encrypted message includes a key exchange. The key and HMAC encrypted using the long-standing OMEMO session for that recipient device are encoded using base64 and placed as text content into the &lt;key&gt; element.         The encrypted &content; element is encoded using base64 and placed as text content into the &payload; element.       </p>+      <p>A special case are <em>empty</em> messages, which are used in various places throughout the protocol purely to manage sessions and not to transfer content. With empty messages, the step of creating and encrypting the &payload; element is skipped. Instead of encrypting the key and authentication tag of the &payload; ciphertext with the Double Ratchet session, 32 zero-bytes are encrypted with the Double Ratchet session directly. The resulting OMEMOKeyExchange or OMEMOAuthenticatedMessage are put into &lt;key&gt; elements as usual, but the &payload; element is omitted altogether, so that the &lt;encrypted&gt; element only contains a &lt;header&gt;.</p>

And even if AES-CBC was vulnerable, all you could find is the key for a single message, which, due to OMEMO's ratcheting, is useless except for that single message, which is known anyway :)

Not sure about that. Since the key for the next message going the same direction is directly derived from the key an attacker would have discovered, they'd potentially gain access to more than just one message. I'm not an expert in crypto, so I can't tell how likely it is that a known-plaintext attack will affect AES, but it also wouldn't hurt to simply encrypt 32 bytes of randomness, would it?

Syndace

comment created time in 2 months

PullRequestReviewEvent

startedEzike/Baking-App-Kotlin

started time in 2 months

Pull request review commentxsf/xeps

WIP: XEP-0384: Version 0.7.0

 <section1 topic='Business Rules' anchor='rules'>   <p>Before publishing a freshly generated device id for the first time, a device MUST check whether that device id already exists, and if so, generate a new one.</p>   <p>Clients SHOULD NOT immediately fetch the bundle and build a session as soon as a new device is announced. Before the first message is exchanged, the contact does not know which PreKey has been used (or, in fact, that any PreKey was used at all). As they have not had a chance to remove the used PreKey from their bundle announcement, this could lead to collisions where both Alice and Bob pick the same PreKey to build a session with a specific device. As each PreKey SHOULD only be used once, the party that sends their initial OMEMOKeyExchange later loses this race condition. This means that they think they have a valid session with the contact, when in reality their messages MAY be ignored by the other end. By postponing building sessions, the chance of such issues occurring can be drastically reduced. It is RECOMMENDED to construct sessions only immediately before sending a message.</p>-  <p>There are various reasons why decryption of an OMEMOKeyExchange or an OMEMOAuthenticatedMessage could fail. One reason is if the message was received twice and already decrypted once, in this case the client MUST ignore the decryption failure and not show any warnings/errors. In all other cases of decryption failure, clients SHOULD respond by forcibly doing a new key exchange and sending a new OMEMOKeyExchange with a potentially empty SCE payload. By building a new session with the original sender this way, the invalid session of the original sender will get overwritten with this newly created, valid session. This does NOT apply to the actual SCE content. If decrypting the SCE content fails, e.g. because the HMAC does not verify, this is not a reason to forcibly initiate a new key exchange.</p>+  <p>After receiving an OMEMOKeyExchange and successfully building a new session, the receiving device SHOULD automatically respond with an empty message to the source of the OMEMOKeyExchange. This is to notify the device that the session initiation was completed successfully and that the device can stop sending OMEMOKeyExchanges.</p>

"... the receiving device SHOULD automatically respond with an empty OMEMO message to the source of the OMEMOKeyExchange."

Syndace

comment created time in 2 months

Pull request review commentxsf/xeps

WIP: XEP-0384: Version 0.7.0

     </section3>     <section3 topic='Message structure description' anchor='message-structure-description'>       <p>-        An OMEMO encrypted message is specified to include an &lt;encrypted&gt; element in the <tt>&ns;</tt> namespace. It always contains two child nodes, the &lt;header&gt; and the &payload; element.-        The &lt;header&gt; element has an attribute named 'sid' referencing the device id of the sending device and contains one or multiple &lt;keys&gt; elements, each with an attribute 'jid' of one of the recipients bare JIDs as well as one or multiple &lt;key&gt; elements.+        An OMEMO encrypted message is specified to include an &lt;encrypted&gt; element in the <tt>&ns;</tt> namespace. It contains up to two child nodes, the &lt;header&gt; and the &payload; element. The &lt;header&gt; element must always be present, the &payload; element must be present unless an empty message is sent, as described below.+        The &lt;header&gt; element has an attribute named 'sid' referencing the device id of the sending device and contains one or multiple &lt;keys&gt; elements, each with an attribute 'jid' of one of the recipients bare JIDs, as well as one or multiple &lt;key&gt; elements.         A &lt;key&gt; element has an attribute named 'rid' referencing the device id of the recipient device, and an attribute named 'kex' which defaults to 'false' and indicates if the enclosed encrypted message includes a key exchange. The key and HMAC encrypted using the long-standing OMEMO session for that recipient device are encoded using base64 and placed as text content into the &lt;key&gt; element.         The encrypted &content; element is encoded using base64 and placed as text content into the &payload; element.       </p>+      <p>A special case are <em>empty</em> messages, which are used in various places throughout the protocol purely to manage sessions and not to transfer content. With empty messages, the step of creating and encrypting the &payload; element is skipped. Instead of encrypting the key and authentication tag of the &payload; ciphertext with the Double Ratchet session, 32 zero-bytes are encrypted with the Double Ratchet session directly. The resulting OMEMOKeyExchange or OMEMOAuthenticatedMessage are put into &lt;key&gt; elements as usual, but the &payload; element is omitted altogether, so that the &lt;encrypted&gt; element only contains a &lt;header&gt;.</p>

Why do we use zeros here? Wouldn't that allow for potential known plaintext attacks?

Syndace

comment created time in 2 months

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentxsf/xeps

WIP: XEP-0384: Version 0.7.0

       <li>Use HKDF-SHA-256 to generate 80 bytes of output from the key by providing the key as HKDF input, 256 zero-bits as HKDF salt and &quot;OMEMO Payload&quot; as HKDF info.</li>       <li>Divide the HKDF output into a 32-byte encryption key, a 32-byte authentication key and a 16 byte IV.</li>       <li>Encrypt the plaintext using AES-256-CBC with PKCS#7 padding, using the encryption key and IV derived in the previous step.</li>-      <li>Calculate the HMAC-SHA-256 using the authentication key and the ciphertext from the previous steps.</li>+      <li>Calculate the HMAC-SHA-256 using the authentication key and the ciphertext from the previous steps. Truncate the output of the HMAC to 16 bytes/128 bits.</li>

Again, what part gets discarded?

Syndace

comment created time in 2 months

PullRequestReviewEvent

Pull request review commentxsf/xeps

WIP: XEP-0384: Version 0.7.0

           <li>Encrypt the plaintext (which consists of a 32 bytes key and a 32 bytes HMAC as specified in the section about <link url="#protocol-message_encryption">Message Encryption</link>) using AES-256-CBC with PKCS#7 padding, using the encryption key and IV derived in the previous step.</li>           <li>Split the associated data as returned by <tt>CONCAT</tt> into the original ad and the <tt>OMEMOMessage.proto</tt> structure.</li>           <li>Add the ciphertext to the <tt>OMEMOMessage.proto</tt> structure.</li>-          <li>Serialize the ad and the <tt>OMEMOMessage.proto</tt> structure into a parseable byte array by concatenating ad and the serialized protobuf structure.</li>-          <li>Calculate the HMAC-SHA-256 using the authentication key and the input material as derived in the steps above.</li>-          <li>Put the <tt>OMEMOMessage.proto</tt> structure and the HMAC into a new <tt>OMEMOAuthenticatedMessage.proto</tt> structure.</li>+          <li>Serialize the <tt>OMEMOMessage.proto</tt> structure into a parseable byte array. To avoid potential problems regarding non-uniqueness of the serialization, make sure to only serialize <em>once</em> and to use that exact byte sequence in the following steps.</li>+          <li>Concatenate the ad and the <tt>OMEMOMessage.proto</tt> structure into a parseable byte array. The result builds the HMAC input material for the next step.</li>+          <li>Calculate the HMAC-SHA-256 using the authentication key and the input material as derived in the steps above. Truncate the output of the HMAC to 16 bytes/128 bits.</li>

Truncate by discarding what portion of bytes?

Syndace

comment created time in 2 months

PullRequestReviewEvent
more