... | @@ -57,4 +57,10 @@ Consider the scenario where you have two identities, `A` and `B`. A contact of ` |
... | @@ -57,4 +57,10 @@ Consider the scenario where you have two identities, `A` and `B`. A contact of ` |
|
|
|
|
|
* First, the times when `A` and `B` are online. In a p2p network we can't hide this from our contacts
|
|
* First, the times when `A` and `B` are online. In a p2p network we can't hide this from our contacts
|
|
* Second, the network addresses that they use to communicate with `A` and `B`. If we use Tor then we can have a separate hidden service address for each identity, so that's fine. But with WiFi and Bluetooth, the contacts can compare the addresses we gave them and see that it's the same device.
|
|
* Second, the network addresses that they use to communicate with `A` and `B`. If we use Tor then we can have a separate hidden service address for each identity, so that's fine. But with WiFi and Bluetooth, the contacts can compare the addresses we gave them and see that it's the same device.
|
|
* Third, they could look for information leaks at the application layer. For example they could try to introduce `A` to `B`, and see if the protocol behaves differently than it would if `A` and `B` were on different devices. If we supported multiple identities, we'd have to be very careful to avoid any leaks like this in our application-layer code. |
|
* Third, they could look for information leaks at the application layer. For example they could try to introduce `A` to `B`, and see if the protocol behaves differently than it would if `A` and `B` were on different devices. If we supported multiple identities, we'd have to be very careful to avoid any leaks like this in our application-layer code.
|
|
\ No newline at end of file |
|
|
|
|
|
# How do I backup my account?
|
|
|
|
|
|
|
|
Short Answer: This is not possible at the moment, but planned.
|
|
|
|
|
|
|
|
Long answer: Storing any key material in the backup would defeat forward secrecy. The problem is that if the backup falls into the wrong hands at some point in the future, it can be used to decrypt all your traffic since the time when the backup was made (assuming the adversary recorded the encrypted traffic at the time). This violates forward secrecy, which is one of our security goals. So we need to modify the protocols to provide forward secrecy in this scenario before implementing a backup feature. The progress is tracked in ticket #110. |
|
|
|
\ No newline at end of file |