Long term public key encryption?

[nazar-pc]

Here is the quote from the spec:

If we are announcing ourselves we must put our real long term public key in the packet and encrypt it with our long term private key. This is so the peer we are announcing ourselves to can be sure that we actually own that public key.

Shouldn't it be and sign it with our long term private key instead?

[GrayHatter]

No, that decision was made to reduce the API usage from NaCl. Encrypting it offers a similar level of proof.

[nazar-pc]

OK, so effectively it is used with the same goal as signature. Don't you think this can be added to the spec in order to avoid some confusion? It seems important to me that this decision was dictated by implementation.

[nurupo]

Saying that it's signing might also be confusing. See, Tox heavily relies on NaCl/sodium crypto library, to the point that you can't change the underlying crypto without breaking Tox protocol. NaCl library provides both encryption and signing functionality, with just one caveat -- you can't you your encryption keypair for signing, the signing operations require you to generate a special signing keypair, the encryption keypair won't do it. So while saying "and sign it with our long term private key" is the correct conceptual idea of what is happening, in the actually what is happening is that you encrypt rather than sign. When @irungentoo was writing the spec he was pretty much going all over the toxcore implementation (the spec was written after the implementation), writing out what the implementation is doing exactly with all the nitty-gritty details, instead of writing a conceptual specification of a Tox protocol. Due to this, it's probably better just to clarify the intention in the following sentence, e.g. "the encryption here is used as a signature -- to prove that we actually own the private key", which, now that I read your quote, is already done with

This is so the peer we are announcing ourselves to can be sure that we actually own that public key.

[nurupo]

So, to answer your question

Shouldn't it be and sign it with our long term private key instead?

No, it shouldn't.

[nazar-pc]

Understood, thanks for the clarification!

[nurupo]

OK, so effectively it is used with the same goal as signature. Don't you think this can be added to the spec in order to avoid some confusion? It seems important to me that this decision was dictated by implementation.

That ^ might be a good idea @iphydf @robinlinden. A person not familiar with NaCl encryption/signing details would probably go "well, that was a runabout way of saying 'signing'" when reading the spec, just like @nazar-pc did.

[nurupo]

Opened just so that we don't forget about this. I kind of expect either @iphydf or @robinlinden to add this to the spec, instead of opening a PR for this myself.