0
$\begingroup$

The use case is: I need to encrypt data such that only my own private key can be used to decrypt it, from a machine that only knows my public key.

I'd prefer not to have to create and keep track of a sender key pair in addition to my own key pair. I understand that by setting the sender private key to "1" I will not be able to properly authenticate the sender of the message as being myself, but I am happy to accept that.

Related question 1: If a proper sender key pair was used (using a random private key rather than a "1" private key), can the encrypted message be decrypted using only the sender's private key and knowledge of my public key? Edit: Clarification: The receiver (me) would be told the public key of the sender key pair. The crux of the question was about whether if the encrypted message, the sender private key and my public key were all known, could the message be decrypted without my private key?

Related question 2: Is it OK to use the same key pair for both the sender and recipient when using the Box? This would mean a third party can authenticate the message as being encrypted by me, using only the public key.

Improve this question
$\endgroup$
2
  • $\begingroup$ Don't do it you use a foolproof,state of the art high level crypto facility, the least you can do is to satisfy all of its requirements. There is really no difference to store 40 instead of 20 bytes on either side of the connection. $\endgroup$
    – eckes
    May 4, 2017 at 8:24
  • $\begingroup$ Related: Questions about the NaCL crypto library on stackoverflow $\endgroup$
    – CodesInChaos
    May 4, 2017 at 8:49

1 Answer 1

Reset to default
4
$\begingroup$

It is possible to decrypt the message using either the receiver's private key together with the sender's public key or using the sender's private key together with the receiver's public key. This means that if either private key is public, you end up with a completely broken system.

What you should do instead, is generating an ephemeral key-pair for the sender and sending the public part of it alongside the message. This essentially turns crypto_box into ECIES.

Using the same keypair for both sender and receiver is possible in principle, but silly, because then you end up with symmetric authenticated encryption and you should use the cheaper crypto_secretbox function instead.

Note that you need to know the shared key to verify, which at the same time allows forgeries. So this is typically only a workable solution if you have at most two parties. When you need a party who can verify but not sign, you should use a signature scheme instead. NaCl includes Ed25519.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Thank you, fantastic answer. I'll implement your suggestion. ECIES is exactly what I need to do. $\endgroup$
    – knaccc
    May 4, 2017 at 10:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.