4 ms·

That is not the only mechanism for keys to leak. Timing side channels may reveal the key and not any of the old messages. The key could be guessed if it was ina

by zrm 6y ago

That is not the only mechanism for keys to leak. Timing side channels may reveal the key and not any of the old messages. The key could be guessed if it was inadvertently generated with a weak random number generator. The attacker could have an older backup of your device, which contains the long-term key and the older messages, but without forward secrecy they could then use the long-term key and traffic captures to decrypt the newer messages that weren't in the older backup.

upofadown 6y ago
These are all very difficult attacks that require the attacker to have recorded your traffic off the network. In general, end device security is much easier to attack. >...they could then use the long-term key and traffic captures to decrypt the newer messages that weren't in the older backup. I don't see how forward secrecy would change things for this situation.
- zrm 6y ago
  > These are all very difficult attacks that require the attacker to have recorded your traffic off the network. The entire premise of encrypting the traffic passing over the network is that an attacker may have access to your traffic off the network. > I don't see how forward secrecy would change things for this situation. Suppose there is an attacker capturing all your network traffic, waiting for an opportunity to decrypt it. You backed up your phone in 2015. Then, today, the machine containing the 2015 backup of your phone is compromised, e.g. because you discarded it without sanitizing it. The attacker now has all of your messages from before 2015, because they're in the backup. But without forward secrecy, they also get all of your messages after 2015, because they could use the long-term key from the backup to decrypt all your captured network traffic. They would also get any messages from before 2015 that you had deleted prior to backing up your phone.
  - upofadown 6y ago
    >...they also get all of your messages after 2015, because they could use the long-term key from the backup to decrypt all your captured network traffic. They would get all your messages after 2015 if they were willing and able to MITM the Diffie-Hellman handshake used in the forward secrecy scheme. Otherwise there would be no point in having long term identity keys in the first place. Your example brings up an interesting point for me. Perhaps forward secrecy is more important in systems that trade off secrecy for convenience by failing to protect the private keys with a strong passphrase. In that case forward secrecy is more valuable due to the larger chance of a private key compromise. I guess the same point would apply to deniability as well. So thanks for the discussion and generated insight.
h_anna_h 6y ago
Timing side-channels are extremely hard to perform, especially if it is over the internet. But all of this does not matter because all modern protocols use algorithms that are safe from timing attacks. If the master key was generated with a weak rng then the same would also be true for any ephemeral keys. That being said I doubt that any device capable of running signal is going to have a weak RNG. Only the backup thing is possible but at this point the adversary can pretend to be you to your contacts anyway (and well, read your past messages). The easiest solution here is to not backup the signal directory.
- zrm 6y ago
  > Timing side-channels are extremely hard to perform, especially if it is over the internet. Not all attackers are over the internet. Especially the ones who have had the opportunity to capture your past traffic, e.g. because they compromised your internet gateway, or have the ability to MITM you and may have used that ability to compromise other devices on your LAN or inject malicious javascript that could perform certain timing attacks from your own machine. > But all of this does not matter because all modern protocols use algorithms that are safe from timing attacks. New classes of timing attacks are discovered on a regular basis. Then existing implementations have to be hardened again. Moreover, it's generally not the algorithm itself that has to resist the attack. Sometimes it isn't even the cryptography -- Spectre can allow the attacker to read arbitrary memory from the address space of a vulnerable program, and the timing vulnerability doesn't have to be in the cryptography library, it could be in any part of the program. > If the master key was generated with a weak rng then the same would also be true for any ephemeral keys. That being said I doubt that any device capable of running signal is going to have a weak RNG. This is a thing that happened: https://www.schneier.com/blog/archives/2008/05/random_number_b.html https://www.schneier.com/blog/archives/2008/05/random_number... And even after they fixed it, so that ephemeral keys were no longer using the bad PRNG, the long-term keys generated with the bad PRNG were still in use by anyone not paying attention. There are also degrees of brokenness. A bad PRNG may produce output that can be guessed but not inexpensively. The attacker may be willing to pay the high price once to crack the long-term key but not pay the same price for each of thousands of messages. > The easiest solution here is to not backup the signal directory. But then you don't have a backup of the signal directory when your phone falls into a wood chipper.

by zrm 6y ago

upofadown 6y ago

These are all very difficult attacks that require the attacker to have recorded your traffic off the network. In general, end device security is much easier to attack. >...they could then use the long-term key and traffic captures to decrypt the newer messages that weren't in the older backup. I don't see how forward secrecy would change things for this situation.

zrm 6y ago
> These are all very difficult attacks that require the attacker to have recorded your traffic off the network. The entire premise of encrypting the traffic passing over the network is that an attacker may have access to your traffic off the network. > I don't see how forward secrecy would change things for this situation. Suppose there is an attacker capturing all your network traffic, waiting for an opportunity to decrypt it. You backed up your phone in 2015. Then, today, the machine containing the 2015 backup of your phone is compromised, e.g. because you discarded it without sanitizing it. The attacker now has all of your messages from before 2015, because they're in the backup. But without forward secrecy, they also get all of your messages after 2015, because they could use the long-term key from the backup to decrypt all your captured network traffic. They would also get any messages from before 2015 that you had deleted prior to backing up your phone.
- upofadown 6y ago
  >...they also get all of your messages after 2015, because they could use the long-term key from the backup to decrypt all your captured network traffic. They would get all your messages after 2015 if they were willing and able to MITM the Diffie-Hellman handshake used in the forward secrecy scheme. Otherwise there would be no point in having long term identity keys in the first place. Your example brings up an interesting point for me. Perhaps forward secrecy is more important in systems that trade off secrecy for convenience by failing to protect the private keys with a strong passphrase. In that case forward secrecy is more valuable due to the larger chance of a private key compromise. I guess the same point would apply to deniability as well. So thanks for the discussion and generated insight.

h_anna_h 6y ago

Timing side-channels are extremely hard to perform, especially if it is over the internet. But all of this does not matter because all modern protocols use algorithms that are safe from timing attacks. If the master key was generated with a weak rng then the same would also be true for any ephemeral keys. That being said I doubt that any device capable of running signal is going to have a weak RNG. Only the backup thing is possible but at this point the adversary can pretend to be you to your contacts anyway (and well, read your past messages). The easiest solution here is to not backup the signal directory.

zrm 6y ago
> Timing side-channels are extremely hard to perform, especially if it is over the internet. Not all attackers are over the internet. Especially the ones who have had the opportunity to capture your past traffic, e.g. because they compromised your internet gateway, or have the ability to MITM you and may have used that ability to compromise other devices on your LAN or inject malicious javascript that could perform certain timing attacks from your own machine. > But all of this does not matter because all modern protocols use algorithms that are safe from timing attacks. New classes of timing attacks are discovered on a regular basis. Then existing implementations have to be hardened again. Moreover, it's generally not the algorithm itself that has to resist the attack. Sometimes it isn't even the cryptography -- Spectre can allow the attacker to read arbitrary memory from the address space of a vulnerable program, and the timing vulnerability doesn't have to be in the cryptography library, it could be in any part of the program. > If the master key was generated with a weak rng then the same would also be true for any ephemeral keys. That being said I doubt that any device capable of running signal is going to have a weak RNG. This is a thing that happened: https://www.schneier.com/blog/archives/2008/05/random_number_b.html https://www.schneier.com/blog/archives/2008/05/random_number... And even after they fixed it, so that ephemeral keys were no longer using the bad PRNG, the long-term keys generated with the bad PRNG were still in use by anyone not paying attention. There are also degrees of brokenness. A bad PRNG may produce output that can be guessed but not inexpensively. The attacker may be willing to pay the high price once to crack the long-term key but not pay the same price for each of thousands of messages. > The easiest solution here is to not backup the signal directory. But then you don't have a backup of the signal directory when your phone falls into a wood chipper.