User verification via room might fail depending on the encryption settings

[BillCarsonFr]

Step to reproduce:

• Alice logs in on Element X
• Alice creates a DM with Bob
• Alice logs in on web but does not verify this new session.
• (Notice that at this point, Alice sending a message from Element X will fail because Alice has an insecure device.)
• On Element X, Alice goes to Bob's profile and tries to verify him

Actual:
Nothing happens

Expected:
Verification should start

The error is:

2025-03-06T18:45:00.024483Z ERROR elementx: Failed requesting verification for user @xxxx:matrix.org with error: Generic(msg: "encryption failed due to an error collecting the recipient devices: one or more verified users have unsigned devices") | SessionVerificationControllerProxy.swift:113 | spans: root

2025-03-06T18:45:00.024632Z  INFO elementx: Transitioning from `requestingVerification` to `initial` with event `didFail` | SessionVerificationScreenStateMachine.swift:128 | spans: root

As per spec:

When using in-room messages and the room has encryption enabled, clients should ensure that encryption does not hinder the verification. For example, if the verification messages are encrypted, clients must ensure that all the recipient’s unverified devices receive the keys necessary to decrypt the messages, even if they would normally not be given the keys to decrypt messages in the room. Alternatively, verification messages may be sent unencrypted, though this is not encouraged.

A similar "fix" was done on legacy sdks, to "allow" sending verification messages even to insecure devices

[andybalaam]

We think this will be fixed by "Exclude Insecure Devices" - we should check that assumption.

[andybalaam]

Andreas will check this.

[mxandreas]

On Element X, Alice goes to Bob's profile and tries to verify him

Tested and can confirm that if before doing this Alice turns ON the feature flag to exclude insecure devices, the user verification works.

[BillCarsonFr]

We think this will be fixed by "Exclude Insecure Devices" - we should check that assumption.

Might fix this specific case, but there are probably other cases.

For example if the other user is in verification violation, there are 2 options to restore communication:

• re-verify
• withdraw verification

But in that case re-verify won't work in Exclude Insecure Devices mode, because all the devices of the other users will be excluded, so verification is impossible. Unless of course you withdraw verification first, but then if the verification fails you have reverted security.

[mxandreas]

But in that case re-verify won't work in Exclude Insecure Devices mode, because all the devices of the other users will be excluded, so verification is impossible. Unless of course you withdraw verification first, but then if the verification fails you have reverted security.

That's a valid point, we do want to allow re-verify without requiring withdrawing verification. We then have to do the same fix as for the legacy apps which is to send such messages even when the device is insecure.