-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Perfect Forward Secrecy #1254
Comments
How come? |
@srkunze because you could then prove that i said what i said. |
Perfect Forward Secrecy does not contradict message signing. You can have both. |
I think he's speaking about deniability. Toxcore doesn't sign anything.
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.
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. |
To be more precise, toxcore uses the crypto_box method from the NaCl library for encryption:
Hopefully, only the public key from that keypair is transferred. ;)
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: |
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. |
That's 2^16 packets, and packets aren't very big. That's on the order of 64-128KiB. |
2¹⁶*128KB is more than 8GB. Or do you mean, that it is a total of 128KB? |
One packet is typically on the order of a kilobyte, though my estimate ranges from 1-2 KiB per packet. |
ok, 128MB sounds much better already. that's still a LOT of text messges |
2⁸ packets would be nice for text messages if one short text message corresponds to one packet. But that would be too |
How about a time limit like every hour? |
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. |
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 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. |
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. |
that's what they say they do:
|
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. |
axolotl also helps in that respect. it does not always do a new DH key exchange. |
FYI: There is an Axolotl implementation in C out there: https://github.com/WhisperSystems/libaxolotl-c |
It would be great if tox could use that. |
Do you create a random public/private keypair per session, or do you directly create per session symmetric keys?
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.
The text was updated successfully, but these errors were encountered: