OH, so there's nothing in the spec against having multiple identical `rid`. I was passing them back and forth to my application as <rid,key> dictionaries assuming that rid *should* always be unique across all users and devices, which was the cause of my confusion about how to handle collisions when encrypting. Will have to fix that to use an array.
So just to verify, is this logic correct? When sending a message, I'm iterating over all the devicesIds to send, if I see duplicate `rid` I just add them all to the list and keep going. When receiving `rid`, if there's dupes, I just jam them in all of the matching sessions until it works (or doesn't). On Thu, Oct 6, 2016 at 11:47 PM, Daniel Gultsch <[email protected]> wrote: > Hi, > > 2016-10-06 23:56 GMT+02:00 Chris Ballinger <[email protected]>: > >> I don't see any duplicate data here. The auth tag is moved from the > >> end of the payload into the 'key'. Moved. Not copied. > > > > Although it's moved (not copied), it's still appended to each key, so you > > have sizeof(authTag)*numKeys instead of just sizeof(authTag). Doesn't > matter > > too much, but it still adds to the overhead. For AE I don't see much of a > > reason to further encrypt the auth tag, is there something that came up > in > > the audit about this? > > You are totally right about the duplication. I didn't think of that last > night. > > Yes this is something that came up in the audit. It's not so much > about the encryption of the auth tag but about the verification of the > auth tag. > If the auth tag is not verified (as it currently is in the > conversations namespace) there is no link between an individual > session and the payload. > Every (trusted) device can modify the payload without the receiver > noticing. By verifying the auth tag we can circumvent that. > > Last page(ish) of the audit I believe. > > Regarding your rid questions from earlier: > > Assume our device has id A. The source ID is B. There are multiple > keys marked with rid=A. We grab the first of those keys marked A and > try to decrypt them in our session with B. That fails because the key > either isn't for us or was maliciously added. If decryption (in the > signal session with B) fails we move on to the next key marked with > rid=A. > Signal is immune against 'garbage messages'. Trying to decrypt a wrong > signal message in session B doesn't hurt the session. (Or if it would > we would have a problem anyway) > > cheers > Daniel > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
