Before the introducee sends her ACK,
she derives a master key from the ephemeral shared secret as before.
Two nonces and a MAC key are then derived from the master key.
The local introducee signs one of the nonces and calculates a MAC
over her own identity public key, ephemeral public key,
transport properties and timestamp.
The local introducee includes the signature and MAC in her ACK.
On receiving the remote introducee's ACK,
the local introducee verifies the signature and MAC.
Should the verification fail, an ABORT is sent to the introducer and
the remote introducee that was added as inactive is deleted again.
This commit replaces the old ForumSharingManagerImpl with a new one
which is based on state machines and the ProtocolEngine.
There is a SharerEngine and a InviteeEngine that take care of state
transitions, messages, events and trigger actions to be carried out by
the ForumSharingManagerImpl. This is all very similar to the
Introduction Client.
The general sharing paradigm has been changed from sharing as a state to
sharing as an action. Now the UI can allow users to invite contacts to
forums. The contacts can accept or decline the invitiation. Also, the
Forum Sharing Manger is notified when users leave a forum.
Closes#322
Methods for creating, adding and removing forums have been moved to the
`ForumManager`. In order to still handle removing forums properly, a
`RemoveForumHook` has been introduced.
Methods for sharing forums with all current and future contacts have
been removed along with the localGroup where this information was saved.
The `ShareForumActivity` now has the proper label.
The `SessionId` and the `ProtocolEngine` have been moved to the
`clients` package.
This addresses part of #322 and part of what has been discussed in #320.
* If the user has already declined, we don't show that the other
introducee has declined as well. The backend doesn't have that information, so
this is compatible with the principle of showing what we know.
* If the user has already accepted or hasn't yet responded, we show the
decline response in the private conversation with the introducer. If
the user hasn't yet responded, we hide the accept/decline buttons
in the introduction request message.
Messages an introducee receives in a `FINISHED` state are now being
ignored and deleted.
Closes#295
* force decline when two of our own identities are introduced to each
other
* throw away introduction requests to the same identity
(impossible to trigger from UI)
Closes#284
When devices' clocks are out of sync, it is possible that a response is
shown before the request. This commit makes sure that the timestamp of
responses is always later than the last message in the conversation.
Some wording could be misunderstood to thing introductions were
successful even though they were not. That has been clarified.
A new database transaction was created when getting contacts and local
transport properties. This has been changed to re-use the existing
transaction.
Also addresses minor issues found in review.
The code made the assumption that a session state can be identified by
the unique session ID. However, when multiple identities from the same
device are involved, there are two sessions with the same ID running on
the device.
Hence, a second identifying criteria has to be used to uniquely identify
the correct session. Here, the ID of the group was chosen.
Unfortunately, the session state can not be cached easily anymore
leading to a small performance penalty when getting all messages for the
UI.
This Introduction BSP Client uses its own group to communicate with
existing contacts. It uses four types of messages to facilitate
introductions: the introduction, the response, the ack and the abort.
The protocol logic is encapsulated in two protocol engines, one for the
introducer and one for the introducee. The introduction client keeps the
local state for each engine, hands messages over to the engines and
processes the result and state changes they return.
