Perfect Forward Secrecy

[aaannndddyyy]

1. Do you create a random public/private keypair per session, or do you directly create per session symmetric keys?

2. Please rekey after a given time! Let's say after 2 hours or 500 text messages or 10MB of transferred data, depending on which happens first.

unrelated: Please do not cryptographically sign any chat messages or data packets (video, file transfer). I couldn't find information if that is done somewhere, maybe you can point me to the spec.

[srkunze]

Please do not cryptographically sign any chat messages or data packets (video, file transfer)

How come?

[srkunze]

Please do not cryptographically sign any chat messages or data packets (video, file transfer)

How come?

[aaannndddyyy]

@srkunze because you could then prove that i said what i said.

[aaannndddyyy]

@srkunze because you could then prove that i said what i said.

[SafwatHalaby]

Perfect Forward Secrecy does not contradict message signing. You can have both.

[SafwatHalaby]

Perfect Forward Secrecy does not contradict message signing. You can have both.

[irungentoo]

I think he's speaking about deniability.

Toxcore doesn't sign anything.

Do you create a random public/private keypair per session, or do you directly create per session symmetric keys?

The answer is both. It creates a session keypair with NaCl and sends it to the other peer, the other peer then uses that public key and their session secret key to generate a shared key used for symmetric encryption. (You do the same thing with their session public key and your session secret key and get the same key). That key is then used to encrypt everything sent via the connection.

Please rekey after a given time! Let's say after 2 hours or 500 text messages or 10MB of transferred data, depending on which happens first.

Yes, that's planned. How does rekeying every 2^16 packets sound? Personally I think that rekeying isn't that needed because if someone gets access to your machines ram while you are running Tox they can get all your messages from the message log of whatever client you are running. If someone has enough access to your system to obtain the session key then they don't even need it to know what you were doing with Tox.

But since it's not hard to implement and doesn't have any drawbacks I have no issues with implementing it.

[irungentoo]

I think he's speaking about deniability.

Toxcore doesn't sign anything.

Do you create a random public/private keypair per session, or do you directly create per session symmetric keys?

The answer is both. It creates a session keypair with NaCl and sends it to the other peer, the other peer then uses that public key and their session secret key to generate a shared key used for symmetric encryption. (You do the same thing with their session public key and your session secret key and get the same key). That key is then used to encrypt everything sent via the connection.

Please rekey after a given time! Let's say after 2 hours or 500 text messages or 10MB of transferred data, depending on which happens first.

Yes, that's planned. How does rekeying every 2^16 packets sound? Personally I think that rekeying isn't that needed because if someone gets access to your machines ram while you are running Tox they can get all your messages from the message log of whatever client you are running. If someone has enough access to your system to obtain the session key then they don't even need it to know what you were doing with Tox.

But since it's not hard to implement and doesn't have any drawbacks I have no issues with implementing it.

[codedust]

@aaannndddyyy

Toxcore doesn't sign anything.

To be more precise, toxcore uses the crypto_box method from the NaCl library for encryption:

The crypto_box function is not meant to provide non-repudiation. On the contrary: the crypto_box function guarantees repudiability. A receiver can freely modify a boxed message, and therefore cannot convince third parties that this particular message came from the sender. The sender and receiver are nevertheless protected against forgeries by other parties.
http://nacl.cr.yp.to/box.html

@irungentoo

The answer is both. It creates a session keypair with NaCl and sends it to the other peer

Hopefully, only the public key from that keypair is transferred. ;)

Personally I think that rekeying isn't that needed because if someone gets access to your machines ram while you are running Tox they can get all your messages from the message log of whatever client you are running.

The point is to make it even more difficult for an attacker (with a lot of computing power) who has no access to your machine to decrypt your whole communication during one session. Note that sessions can get quite long on mobile devices.

Anyone interested in this may read these two blog post from OWS explaining how (and why) they designed the protocol behind Textsecure:
https://whispersystems.org/blog/asynchronous-security/
https://whispersystems.org/blog/advanced-ratcheting/

[codedust]

@aaannndddyyy

Toxcore doesn't sign anything.

To be more precise, toxcore uses the crypto_box method from the NaCl library for encryption:

The crypto_box function is not meant to provide non-repudiation. On the contrary: the crypto_box function guarantees repudiability. A receiver can freely modify a boxed message, and therefore cannot convince third parties that this particular message came from the sender. The sender and receiver are nevertheless protected against forgeries by other parties.
http://nacl.cr.yp.to/box.html

@irungentoo

The answer is both. It creates a session keypair with NaCl and sends it to the other peer

Hopefully, only the public key from that keypair is transferred. ;)

Personally I think that rekeying isn't that needed because if someone gets access to your machines ram while you are running Tox they can get all your messages from the message log of whatever client you are running.

The point is to make it even more difficult for an attacker (with a lot of computing power) who has no access to your machine to decrypt your whole communication during one session. Note that sessions can get quite long on mobile devices.

Anyone interested in this may read these two blog post from OWS explaining how (and why) they designed the protocol behind Textsecure:
https://whispersystems.org/blog/asynchronous-security/
https://whispersystems.org/blog/advanced-ratcheting/

[aaannndddyyy]

2¹⁶ sounds a bit big, imho. You'd want to provide not that much of cipherdata for a given key to the cryptoanalyst.

And yes, the other issue above was about deniability, therefore, I wrote it is unrelated. I was not sure if you do it that way but already thought you might be doing it, so I didn't file a separate issue for it.

[aaannndddyyy]

2¹⁶ sounds a bit big, imho. You'd want to provide not that much of cipherdata for a given key to the cryptoanalyst.

And yes, the other issue above was about deniability, therefore, I wrote it is unrelated. I was not sure if you do it that way but already thought you might be doing it, so I didn't file a separate issue for it.

[dubslow]

That's 2^16 packets, and packets aren't very big. That's on the order of 64-128KiB.

[dubslow]

That's 2^16 packets, and packets aren't very big. That's on the order of 64-128KiB.

[aaannndddyyy]

2¹⁶*128KB is more than 8GB. Or do you mean, that it is a total of 128KB?
Remember: otr does that for every single message. I don't think that is a needed level, but 8GB might be a bit much.

[aaannndddyyy]

2¹⁶*128KB is more than 8GB. Or do you mean, that it is a total of 128KB?
Remember: otr does that for every single message. I don't think that is a needed level, but 8GB might be a bit much.

[dubslow]

One packet is typically on the order of a kilobyte, though my estimate ranges from 1-2 KiB per packet.

[dubslow]

One packet is typically on the order of a kilobyte, though my estimate ranges from 1-2 KiB per packet.

[aaannndddyyy]

ok, 128MB sounds much better already. that's still a LOT of text messges

[aaannndddyyy]

ok, 128MB sounds much better already. that's still a LOT of text messges

[aaannndddyyy]

2⁸ packets would be nice for text messages if one short text message corresponds to one packet. But that would be too foten often[edit] for you, I guess.

[aaannndddyyy]

2⁸ packets would be nice for text messages if one short text message corresponds to one packet. But that would be too foten often[edit] for you, I guess.

[irungentoo]

How about a time limit like every hour?

[irungentoo]

How about a time limit like every hour?

[aaannndddyyy]

I'm totally fine with either 2¹¹ packets or every hour or a combination thereof. Dunno about the other folks here. edit: in case of combination thereof, the exponent could even be slightly higher, namely 2¹² or 2¹³, IMHO. You could count packets and and time since rekey and if one reaches the limit it initiates rekeying and resets both counters.

[aaannndddyyy]

I'm totally fine with either 2¹¹ packets or every hour or a combination thereof. Dunno about the other folks here. edit: in case of combination thereof, the exponent could even be slightly higher, namely 2¹² or 2¹³, IMHO. You could count packets and and time since rekey and if one reaches the limit it initiates rekeying and resets both counters.

[codedust]

What do you think about implementing the ratchet protocol from Textsecure? It's not as trivial as simply changing the key after x packets but it would improve security even more.

[codedust]

What do you think about implementing the ratchet protocol from Textsecure? It's not as trivial as simply changing the key after x packets but it would improve security even more.

[irungentoo]

@codedust I think their protocol only works when the transport protocol delivers packets in order without loss. The Tox crypto is done at the level below the protocol that makes sure that data is delivered in order.

[irungentoo]

@codedust I think their protocol only works when the transport protocol delivers packets in order without loss. The Tox crypto is done at the level below the protocol that makes sure that data is delivered in order.

[aaannndddyyy]

I don't think, they require in-order delivery. Actually that's one thing they complained about in the silent circle ratched. What they have is a DH ratched combined with a hash ratched.
and to quote them "Nice properties like cryptographically-enforced message ordering and replay protection all come for free, without any complex record keeping required. The code is simpler, and the protocol security is more robust."

[aaannndddyyy]

I don't think, they require in-order delivery. Actually that's one thing they complained about in the silent circle ratched. What they have is a DH ratched combined with a hash ratched.
and to quote them "Nice properties like cryptographically-enforced message ordering and replay protection all come for free, without any complex record keeping required. The code is simpler, and the protocol security is more robust."

[aaannndddyyy]

that's what they say they do:

• Combine the forward-secrecy of symmetric-key updating with the "future-secrecy" of an OTR-like Diffie-Hellman ratchet.
  By "future-secrecy" we mean that a leak of keys to a passive eavesdropper will be healed by introducing new DH ratchet keys.
• Improve on OTR's future-secrecy with a "2-step" DH ratchet instead of "3-step".
  I.e. DH ratchet keys are used in a "send/receive" pattern, instead of "advertise/receive/send".
• Detect replay / reorder / deletion of messages.
• Allow decryption of out-of-order messages with minimal reduction in forward secrecy.
• Don't leak metadata in cleartext (such as identities or sequence numbers).

[aaannndddyyy]

that's what they say they do:

• Combine the forward-secrecy of symmetric-key updating with the "future-secrecy" of an OTR-like Diffie-Hellman ratchet.
  By "future-secrecy" we mean that a leak of keys to a passive eavesdropper will be healed by introducing new DH ratchet keys.
• Improve on OTR's future-secrecy with a "2-step" DH ratchet instead of "3-step".
  I.e. DH ratchet keys are used in a "send/receive" pattern, instead of "advertise/receive/send".
• Detect replay / reorder / deletion of messages.
• Allow decryption of out-of-order messages with minimal reduction in forward secrecy.
• Don't leak metadata in cleartext (such as identities or sequence numbers).

[jf99]

When you change keys often, watch out that you're not running out of entropy. Otherwise this practice might lower the security. To avoid this, you could take the old key, add some new random bits to it and use the hash of both as the new key. This way, the new key is never less secure (=less random) than the old one.

[jf99]

When you change keys often, watch out that you're not running out of entropy. Otherwise this practice might lower the security. To avoid this, you could take the old key, add some new random bits to it and use the hash of both as the new key. This way, the new key is never less secure (=less random) than the old one.

[aaannndddyyy]

axolotl also helps in that respect. it does not always do a new DH key exchange.
And yes, a good point @jf99. We wouln't wanna get insecure keys or block waiting for entropy.

[aaannndddyyy]

axolotl also helps in that respect. it does not always do a new DH key exchange.
And yes, a good point @jf99. We wouln't wanna get insecure keys or block waiting for entropy.

[codedust]

FYI: There is an Axolotl implementation in C out there: https://github.com/WhisperSystems/libaxolotl-c

[codedust]

FYI: There is an Axolotl implementation in C out there: https://github.com/WhisperSystems/libaxolotl-c

[aaannndddyyy]

It would be great if tox could use that.
Axolotl is one of the advantages signal has over tox. (the others are offline messages and lower ressource usage).
Axolotl also allows for encrypted offline messages once/if tox gets them, and effective authenticated group encryption via conference keys.
null

[aaannndddyyy]

It would be great if tox could use that.
Axolotl is one of the advantages signal has over tox. (the others are offline messages and lower ressource usage).
Axolotl also allows for encrypted offline messages once/if tox gets them, and effective authenticated group encryption via conference keys.
null