[matbech]

Description

sqlite3mcExtractRawKey classifies raw payloads as hex before checking their length. A valid 32-byte binary ChaCha20 key such as 32 bytes of 0x33 is then rejected because it is too short for a hex-encoded key. The same affects a binary key plus salt when all 48 bytes happen to be hexadecimal characters.

Only select hex decoding for a supported encoded length. Preserve binary key bytes and the existing handling of valid hex keys and optional salts.

[utelle]

sqlite3mcExtractRawKey classifies raw payloads as hex before checking their length. A valid 32-byte binary ChaCha20 key such as 32 bytes of 0x33 is then rejected because it is too short for a hex-encoded key. The same affects a binary key plus salt when all 48 bytes happen to be hexadecimal characters.

Yes, you are right that the length should be checked, too. However, it still doesn't solve the problem I tried to solve with the change, namely to avoid confusion with the AEGIS cipher where the key length and the salt length can both be 16.

Only select hex decoding for a supported encoded length. Preserve binary key bytes and the existing handling of valid hex keys and optional salts.

Actually, the design flaw was and is to allow to specify a raw key in non-hexadecimal notation.

In this regard the SQLCipher notation is explicit, because it allows only hexadecimal strings for raw key and salt. I'm wondering if it might be better to use separate prefixes to distinguish between the two cases, or to restrict the input to hexadecimal strings. IMHO the latter is the better choice.

[utelle]

In the meantime a secondary prefix was introduced in commit 175f41f to make the meaning of a raw key specification unambiguous. After the primary prefix raw: now a secondary prefix may follow to clarify how the raw key (and optionally the salt) is notated:

• Prefix raw:bin: - the value is interpreted as a binary string
• Prefix raw:hex: - the value is interpreted as a hexadecimal string
• Prefix raw: will be interpreted as a
  • hexadecimal string if it consists of hexadecimal characters only
  • binary string if it contains at least 1 non-hexadecimal character

In all cases the input length (excluding the prefix) must match the expected length:

• hexadecimal: 2*keyLength or 2*(keyLength+saltLength)
• binary: keyLength or (keyLength+saltLength)

An invalid input length or an invalid encoding will be reported as an error. The behaviour of the SQLCipher notation for raw key and salt was not changed.

This PR is therefore no longer relevant.