powered by Jive Software

Smack OMEMO UndecidedOmemoIdentityException#getUntrustedDevices returns only undecidedOmemoIdentity

Smack Omemo handling of the “UNSTRUSTED” omemoDevices are transparent to the application when sending OMEMO encrypted messages. In muc or single user chat, omemoManager just encrypted and send the the message without the embedding the untrusted </key rid> for decryption. No UndecidedOmemoIdentityException is being thrown. The method getUntrustedDevices() returns only devices that are undecided but not the untrusted.

In a single user chat, when there is only one untrusted device, user may not aware that the omemo messages although are being sent but to unreachable destination.

aTalk currently implements a local check for unTrusted device to alert user of this case in single user chat and muc. Just uploaded aTalk released version 0.8.3.


  • Check to see if all muc recipients are verified or trusted

  • @param multiUserChat

  • MultiUserChat

  • @return return true if all muc recipients are verified or trusted. Otherwise

  • false
    private boolean isAllTrusted(MultiUserChat multiUserChat)
    boolean allTrusted = true;
    OmemoFingerprint fingerPrint;
    BareJid recipient;

    for (EntityFullJid e : multiUserChat.getOccupants()) {
    recipient = multiUserChat.getOccupant(e).getJid().asBareJid();
    CachedDeviceList theirDevices
    = mOmemoStore.loadCachedDeviceList(mOmemoManager, recipient);
    for (int id : theirDevices.getActiveDevices()) {
    OmemoDevice recipientDevice = new OmemoDevice(recipient, id);
    try {
    fingerPrint = mOmemoManager.getFingerprint(recipientDevice);
    allTrusted = mOmemoManager.isTrustedOmemoIdentity(recipientDevice, fingerPrint)
    && allTrusted;
    catch (CannotEstablishOmemoSessionException e1) {
    logger.warn("AllTrusted check exception: " + e1.getMessage());
    return allTrusted;

May be smack Omemo would consider to include the unTrusted devices in UndecidedOmemoIdentityException#getUntrustedDevices().

========= OMEMO encrypted chat message to untrusted device =================

07-11 14:54:31.432 D/SMACK: SENT (0): I sent you an OMEMO encrypted message but your client doesn’t seem to support that. Find more information on https://conversations.im/omemoa922d234-89c8-491b-b665-969f064050e8FudDR5iu+XgFvFvgR2XzOA==SZs=</paylo ad>

========= OMEMO encrypted MUC message to ntrusted device =================

07-12 09:44:46.471 D/SMACK: SENT (1): I sent you an OMEMO encrypted message but your client doesn’t seem to support that. Find more information on https://conversations.im/omemoMwohBahtoHlbzwR7oy0flhpXOMGULr8t+/visw5W1xAlerV1EAEYBCIwVxoJ0w xZbI7QbKzMuYPpuLkXia0c4AAGcXpfQqGWB9w1U6tD5tGe5L3s5iBIcf/H7o9igDVg1EQ= 9wHU010d+g9XSvmOTQWqrw==rbLiavI=

Sorry for the method name being missleading. It should be named “getUndecidedDevices()” instead.

The purpose of the method is to return all the undecided devices of the recipient(s), so the user can make a decision. The user should not be bothered to trust already untrusted devices once again.

The Exception is thrown when there is at least one undecided device among the recipient devices. In such a case the message gets not sent at all. The user first has to decide whether to trust the device or not and then try again. The client should keep the message in the text box, so the user does not lose the text they wrote.

Sorry for the confusion, actually I am not so much into the naming of the method.

In aTalk implementation, an UI is provided to allow user to mark a omemoDevice as untrusted in respective of its previous trust state i.e.

UNDECIDED, TRUSTED or VERIFIED. If the user later starts a omemo session with the buddy having only a single untrusted omemDevice; all messages entered by the user appear to have been sent, but the transmitted Olm messages are not received by his buddy. The user will wonder why he receives no reply from his buddy (user may have forgotten he has earlier marked his buddy only device as untrusted). aTalk performs a pre-check on untrusted devices, and display a system message on the chat window to that effect if none of the buddy devices are able to receive the olm messages.

Personally I am not sure if the above implementation has deviated from the XEP-0384 standards, but thinking that it may be good for smack OMEMO to consider such pre-check for untrusted devices and throw an untrustedException.

This will be solved once https://github.com/igniterealtime/Smack/pull/177 gets merged.