After having experienced the issue quite often, I've been looking at the code just now to make sure the behaviour hadn't changed since I had the issue. If I'm missing something, just close this :)
Basically, keys are flushed, status is retored, and the thread goes on.
So if Alice and Bob were having a secure exchange, and Alice aborts the secure session, she never notifies Bob of this.
The result is that Bob still has the symmetric encrypton key in his memory, and more importantly, he will use them to communicate with Alice on the next message, even a month after Alice flushed the keys...
This forces most users to keep the secure sessions ON all the time. Which means keys are not flushed ASAP as they probably should be. I think Textsecure should allow for an usable application of the best practice of ending secure sessions when an exchange has been completed.
This could be fixed very easily by sending a "I'm aborting the session" notification accross the secure channel before clearing everything. This should probably not require an ACK of any sort, so it would be quite cheap, and then it's up to the other person to close its side of the session too (but Textsecure should recognize that the other side of the covnersation has already ended its secure session, so no notification should be sent when Bob closes its session too.)
You could even automatically close the session upon receiving this notification.
I'm tempted to say that we could also use this additionnal step to disclose authentication keys and get plausible deniability, but I'm not sure if it's possible to do this without screwing up the secure channel big time, so it's probably better to not do that ATM :)
I know SMSes are not cheap for everyone, but making the other party of the conversation doesn't stay unsynced with the conversation state would probably be a great improvement... I'm tired of receiving messages encrypted with month-long-gone encryption keys, because they never see that I closed the session.
FYI - I'm working on a fix for this. Its implemented, but I'm working on fixing a bug with the 'send lock icon' not being correctly reset to normal upon receiving the abort session message.
After having experienced the issue quite often, I've been looking at the code just now to make sure the behaviour hadn't changed since I had the issue. If I'm missing something, just close this :)
So, if I'm not mistaken, when aborting a secure session, this happens : https://github.com/WhisperSystems/TextSecure/blob/master/src/org/thoughtcrime/securesms/crypto/KeyUtil.java#L79
Basically, keys are flushed, status is retored, and the thread goes on.
So if Alice and Bob were having a secure exchange, and Alice aborts the secure session, she never notifies Bob of this.
The result is that Bob still has the symmetric encrypton key in his memory, and more importantly, he will use them to communicate with Alice on the next message, even a month after Alice flushed the keys...
This forces most users to keep the secure sessions ON all the time. Which means keys are not flushed ASAP as they probably should be. I think Textsecure should allow for an usable application of the best practice of ending secure sessions when an exchange has been completed.
This could be fixed very easily by sending a "I'm aborting the session" notification accross the secure channel before clearing everything. This should probably not require an ACK of any sort, so it would be quite cheap, and then it's up to the other person to close its side of the session too (but Textsecure should recognize that the other side of the covnersation has already ended its secure session, so no notification should be sent when Bob closes its session too.)
You could even automatically close the session upon receiving this notification.
I'm tempted to say that we could also use this additionnal step to disclose authentication keys and get plausible deniability, but I'm not sure if it's possible to do this without screwing up the secure channel big time, so it's probably better to not do that ATM :)
I know SMSes are not cheap for everyone, but making the other party of the conversation doesn't stay unsynced with the conversation state would probably be a great improvement... I'm tired of receiving messages encrypted with month-long-gone encryption keys, because they never see that I closed the session.