Commit Graph

11 Commits (81f5c4a3cdaf25fbb66c04453b357f5b09b1542f)

Author SHA1 Message Date
Hubert Chathi 37c8e14e53 make functions const where possible 2021-06-16 23:22:25 -04:00
Hubert Chathi 7263c4221b add functions to get the error codes rather than error strings 2021-06-16 22:40:14 -04:00
Denis Kasak 2f35e0bc61 olm_sas_set_their_key: Fail early on invalid base64. 2021-05-24 15:50:14 +02:00
Damir Jelić f46577a06a sas: Introduce a new calculate mac function to fix the base64 issue
Since it's important to keep backwards compatibility introduce a new
function to calculate the MAC using a SAS object.

Modifying the existing functions would break compatibility with older
releases of libolm.
2021-02-02 16:58:28 +01:00
Damir Jelić 4e927eb1cf sas: Fix the base64 encoding of the MAC.
When calculating the MAC for a message using olm_sas_calculate_mac() and
olm_sas_calculate_mac_long_kdf() the resulting MAC will be base64
encoded using _olm_encode_base64().

The _olm_encode_base64() method requires an input buffer and output
buffer to be passed alongside the input length. The method is called
with the same buffer, containing the MAC, for the input buffer as well
as for the output buffer. This results in an incorrectly base64 encoded
MAC.

For example the byte array:
    [121, 105, 187, 19, 37, 94, 119, 248, 224, 34, 94, 29, 157, 5,
     15, 230, 246, 115, 236, 217, 80, 78, 56, 200, 80, 200, 82, 158,
     168, 179, 10, 230]

will be encoded as  eWm7NyVeVmXgbVhnYlZobllsWm9ibGxzV205aWJHeHo
instead of as       eWm7EyVed/jgIl4dnQUP5vZz7NlQTjjIUMhSnqizCuY

Notice the different value at the 10th character.

The correct result can be independently checked using Python for
example:

>>> from base64 import b64encode
>>> mac = [121, 105, 187, 19, 37, 94, 119, 248, 224, 34, 94, 29, 157, \
           5, 15, 230, 246, 115, 236, 217, 80, 78, 56, 200, 80, 200, \
           82, 158, 168, 179, 10, 230]
>>> b64encode(bytearray(mac)).rstrip(b"=")
>>> b'eWm7EyVed/jgIl4dnQUP5vZz7NlQTjjIUMhSnqizCuY'

This happens because the encode_base64() method that is used does not support
in-place encoding in the general case. This is because the remainder for a 32
bit input will always be 2 (32 % 6 == 2).

The remainder will be used over here:
c01164f001/src/base64.cpp (L74)

The logic that gets executed if a remainder exists depends on the original input
values, since those already got in-place encoded the whole block will behave
differently if the input buffer is the same as the output buffer.
2021-01-31 12:56:32 +01:00
Hubert Chathi ec5ff1e032 also check that the pubkey is set when calculating the MAC 2020-09-23 16:47:00 -04:00
Hubert Chathi 78d9cbabb7 set their_key_set flag explicitly on init 2020-09-23 16:11:37 -04:00
Saúl Ibarra Corretgé 2ef1f6f4fc SAS: add olm_sas_is_their_key_set
Also make olm_sas_generate_bytes fail if their key wasn't set.
2020-09-23 15:27:55 -04:00
Hubert Chathi 0757e6df40 add comment about input buffers being overwritten
also make some params const where possible
2019-05-14 12:53:19 -04:00
Hubert Chathi 3148157ea4 add support for an incorrect KDF that snuck into Riot 1.0 2019-04-02 23:39:05 -04:00
Hubert Chathi 94f664e725
initial implementation of short authentication string generation 2019-01-21 23:21:41 -05:00