@vit alors c’est plus subtil que ça et pourtant très important selon le cas d’usage. En effet signer une correspondance privée peut s’avérer dangereux pour l’utilisateur final :
Imaginons que j’écrive dans une correspondance privée des choses que je ne pourrais pas écrire publiquement pour X raisons, j’aurais de grave problèmes si j’écrivais cela publiquement.
Et bien la personne avec qui je communique peut me faire chanter en me menaçant de dévoiler publiquement ce que je lui est écrit.
C’est la raison pour laquelle la crypto_box de NaCl n’utilise pas la signature mais un autre procédé nommé “authentification par clé publique” que je nomme perso “authentification privée” (je trouve que c’est plus clair).
Le destinataire du message a toujours la preuve que le message proviens bien de l’expéditeur, mais pour vérifier cette preuve il a besoin de sa clé privée. Il ne peut donc pas prouver au monde extérieur que l’expéditeur lui a envoyé ce message.
Mieux encore, si le destinataire décide de dévoiler sa clé privée, cela ne permettra toujours pas de prouver au monde extérieur que c’est l’expéditeur qui lui a envoyé ce message, car la preuve a pu être générée par le destinataire directement.
Lorsque tu déchiffre le message avec NaCl, NaCl vérifie déjà la preuve d’authenticité, si elle est invalide NaCl retourne une erreur. Donc si tu récupère bien le message déchiffré tu est déjà certain que le message proviens bien de l’expéditeur, dans le cas d’'usage “correspondance privée entre humains”, ajouter un procédé de signature est inutile et dangereux.
Il serait préférable pour l’utilisateur final que Cesium+ ne signe pas les messages privés (qui sont déjà authentifiés par NaCl donc ça n’apporte rien à l’utilisateur a part le risque de chantage).
@kimamila @vit Je vous invite a méditer ce post de D. J. Bernstein, le mathématicien cryptologue qui a inventé l’algo Salsa20 et qui a participé a la conception du process crypto_box de NaCl :
Anyone can verify a public-key signature.
This is the whole point of public-key signatures. Verification isn’t
limited to the people who can create signatures.
This is, however, a useless feature for private email. Sometimes it’s
downright dangerous.
In contrast, with public-key authenticators, verification is limited to
the sender and the receiver. The receiver can’t convince anyone else
that the message was created by the sender; the receiver could have
computed the same authenticator.
What is a public-key authenticator? It’s a secret-key authenticator,
with a key derived from g^xy, where g^x and g^y are the public keys of
the sender and the receiver.
If you were already planning to encrypt the message, using another key
derived from g^xy, then you don’t have to do any extra public-key work.
A secret-key authenticator is easier to implement than a public-key
signature, and it takes less CPU time to compute.