 Time |
User | Activity | Comment |
|---|---|---|---|
| No results | |||
keyid/sid are there to decide which key is to be used to decrypt the message. So as you mentioned, we are not assuming that "some sort of session information would be available as part of the chat transport". In the same room you can have multiple sessions being established at the same time (due to join, leave and rekey). We also use Keyid in p2p communication to determine the recipients of the message. session/key id is included in the encrypted message as well, so one can easily detect if the plaintext info is tampered.
Our assumption here is that (attempt) at reliable delivery is to be carried out by the transport layer (think of TLS vs TCP). (n+1)sec is supposed to detect if an adversary tampered with the delivery mechanism in place. It is possible to implement and interject an intermediary reliable transport layer, pretty much like TCP, between (n+1)sec and the original chat protocol (say IRC) which takes care of resend etc.