Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle KeyTransport message correctly #33

Open
wants to merge 2 commits into
base: dev
Choose a base branch
from

Conversation

root-hardenedvault
Copy link

@root-hardenedvault root-hardenedvault commented Feb 10, 2021

Handle KeyTransport message correctly

omemo_message_export_encrypted() should not return early if only its
payload is absent.

omemo_message_prepare_encryption() should be able to accept an
outgoing_message without body, which would become a template of a
KeyTransport message.

omemo_message_export_encrypted() should not return early if only its
payload is absent.

omemo_message_prepare_encryption() should be able to accept an
outgoing_message without body, which would become a template of a
KeyTransport message.

Signed-off-by: HardenedVault <[email protected]>
@root-hardenedvault root-hardenedvault changed the title omemo_messages without payload should be allowed to export encrypted Handle KeyTransport message correctly Feb 11, 2021
root-hardenedvault added a commit to hardenedvault/lurch that referenced this pull request Feb 11, 2021
Simply calling omemo_message_create() cannot compose a valid
KeyTransport message, which should at least have an ordinary "message"
node, so we should first make up such message without a "body", then
let omemo_message_prepare_encryption() of libomemo hamdle such case:

gkdr/libomemo#33

Signed-off-by: HardenedVault <[email protected]>
root-hardenedvault added a commit to hardenedvault/lurch that referenced this pull request Feb 11, 2021
Simply calling omemo_message_create() cannot compose a valid
KeyTransport message, which should at least have an ordinary "message"
node, so we should first make up such message without a "body", then
let omemo_message_prepare_encryption() of libomemo hamdle such case:

gkdr/libomemo#33

Signed-off-by: HardenedVault <[email protected]>
According to:
https://xmpp.org/extensions/xep-0384.html#message-structure-description

Nodes for encrypted symmetric <key/> for a particular recipient should be nested
in a <keys/> node with its "jid" attribute set to the recipient's bare JID, with
an optional "kex" attribute for key exchange usage.

Functions related to these above are modified accordingly.

Signed-off-by: HardenedVault <[email protected]>
@gkdr
Copy link
Owner

gkdr commented Mar 3, 2021

hi @root-hardenedvault, thank you for your contribution!

  • you're probably right, the shortcut in omemo_message_export_encrypted() is wrong and it should not exit on an empty payload, as this should result in a key transport message.
  • i don't think this is true for omemo_message_prepare_encryption() however, as it is intended to be used on existing, intercepted messages. it is simply a different entry point. for creating a fresh, empty message, which will ever only be done by the application code, omemo_message_create() is to be used.
  • the last commit is not related to the rest of the PR, i think, its contents seem to refer to the newest version of the standard, which uses a different namespace. this library so far only tries to work with the old version outlined in versoin 0.3.0 of the standard: https://xmpp.org/extensions/attic/xep-0384-0.3.0.html

@root-hardenedvault
Copy link
Author

But how to compose a valid KeyTransport message from omemo_message_create()? as stated in:

gkdr/lurch#162

@Neustradamus
Copy link
Contributor

@gkdr: Any news on it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants