Talk:Np1sec
- [View source↑]
- [History↑]
Contents
| Thread title | Replies | Last modified |
|---|---|---|
| Various notes | 1 | 16:05, 15 December 2014 |
| You don't have to be first | 0 | 05:29, 9 December 2014 |
 First page |
 Previous page |
 Next page |
 Last page |
Typos/mistakes
Are the "naunces" and "nuances" generally supposed to be nonces? Is it an alternative spelling I have not encountered?
Should the keyid/sid be included in the plaintext part of the message? Why not inside the encryption? I would assume that some sort of session information would be available as part of the chat transport, and thus should not have to be a part of the plaintext. Am I missing something?
Transcript transport assumtion
To me is a rather rash assumption to make - that the underlying transport can be relied on to deliver messages in the exact same order. In XMPP this is generally the case, but I would assume that the aspiration is for this protocol to be used also for other underlying protocols, such as IRC and Bonjour/Avahi based mesh chat, which as far as I know provide nothing of the sort. What would the potential consequences be in such circumstances? Would it be possible to reconstruct the reorderings from the recieved messages?
All in all, splendid work!
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.
First page |
Previous page |
Next page |
Last page |
