Nheko Possibly Causes Key Backup Error in Element

[wj25czxj47bu6q]

Describe the bug

There are at least two known cases where use of Nheko is correlated with the error "Unable to query secret storage status" in Element. A more verbose error message "Error: Failed decoding Curve25519 key from base64: Invalid number of bytes for Curve25519, expected 32, got 45." is printed by Element to the console. This also prevents Element from resetting key backup ("secure backup"), because apparently Element validates the existing key backup before allowing the user to reset it.

element-hq/element-meta#2471

After using the DELETE /_matrix/client/v3/room_keys/version/{version} API to manually erase the existing key backup, Element no longer gives the error and allows setting up a fresh key backup.

Obviously Element's unnecessary validation problem is not relevant to Nheko, but the root cause whereby Element believes the key backup created from Nheko is malformed probably deserves further investigation.

To Reproduce

Exact details unknown. The issue is most likely reproducible by setting up key backup in Nheko and then attempting to reset it in Element.

What happened?

No response

Expected behavior

No response

Screenshots

No response

Version

Unknown

Operating system

No response

Installation method

No response

Qt version

No response

C++ compiler

No response

Desktop Environment

No response

Did you use profiles?

• Profiles used?

Relevant log output

No response

Backtrace

No response

[deepbluev7]

Well, the spec doesn't define a limit for the automatically generated key. Since we need to provide it in base64 and need 32 bytes of entropy (iirc), we base64 encode the random number, which causes the 45 bytes, since there is a 30% overhead to base64 encoding. I'm not sure if that is an issue on our end, having extra bytes isn't really an error usually.

[richvdh]

Since we need to provide it in base64 and need 32 bytes of entropy (iirc),

Yes, 32 bytes. The key that is causing the problem is a public Curve25519 key, which is 32 bytes in length.

we base64 encode the random number, which causes the 45 bytes, since there is a 30% overhead to base64 encoding.

32 bytes in base64 is 44 bytes:

echo "01234567890123456789012345678901" | base64 -w0  | wc -c
44

TBH I'm not entirely sure which key is causing the problem. Any ideas?

[richvdh]

oh, it's the public_key in the auth_data for the backup.