encrypting to untrusted devices means no degradition of security
compared to not encrypting at all. Trust status display (shield) is made
independently at a later stage.
DIGEST and HMAC were static variables. Those are initialized by
what ever concrete implementation gets executed first.
(Perform SCRAM-SHA1 first and those variables got initialized with
SHA1 variants)
For subsequent SHA256 executions those variables contained wrong
values.
Ever since Android 9+ switched to Conscrypt we can no longer efficiently
encrypt (and decrypt) large files with AES-GCM. We did’t notice this before
because when using 16 byte IVs even modern Androids will fall back to bouncy
castle. However the 'bug'/'feature' in Conscrypt surfaced when we switched over
to 12 byte IVs (which uses Conscrypt on Android 9+)
Switching back entirely to 16 byte IVs is undesirable as this would break
compatibility with Monal. So we end up with a weird compromise where we use
12 byte for normale plain text OMEMO messages and 'small' files where the
inefficiencies aren’t a problem.
The result of this commit is that Monal won’t be able to receive our files
larger than 768KiB. However the alternative is that Conversations would always
OOM when attempting to send larger files (where large depends on the available
RAM.)
fixes#3653
usually this wasn’t a problem as this is only the fallback after no IPs
have been discovered.
this also isn‘t a security issue as worst case is the hostname doesn’t get
accepeted as fallback in cert validation.
thanks @genofire for spotting this
finishing (sending a key transport message in response to pre key message) as
well as reparing sessions will leak resource and availability and might in
certain situations in group chat leak the Jabber ID.
Therefor we disable that. Leaking resource might not be considered harmful by
a lot of people however we have always doing similar things with receipts.
