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] _______________________________________________
