Sealed Boxes

[CMEONE]

• Adds nacl.sealedbox(msg, nonce, publicKey) and nacl.sealedbox.open(msg, nonce, secretKey) to nacl.js and nacl-fast.js
• Adds the following constants to nacl.js and nacl-fast.js:

crypto_sealedbox_NONCEBYTES = crypto_secretbox_NONCEBYTES;
crypto_sealedbox_PUBLICKEYBYTES = 32;
crypto_sealedbox_SECRETKEYBYTES = 32;

nacl.lowlevel.crypto_sealedbox_NONCEBYTES = crypto_sealedbox_NONCEBYTES;
nacl.lowlevel.crypto_sealedbox_PUBLICKEYBYTES = crypto_sealedbox_PUBLICKEYBYTES;
nacl.lowlevel.crypto_sealedbox_SECRETKEYBYTES = crypto_sealedbox_SECRETKEYBYTES;

nacl.sealedbox.publicKeyLength = crypto_sealedbox_PUBLICKEYBYTES;
nacl.sealedbox.secretKeyLength = crypto_sealedbox_SECRETKEYBYTES;
nacl.sealedbox.nonceLength = crypto_sealedbox_NONCEBYTES;
nacl.sealedbox.overheadLength = nacl.box.overheadLength + crypto_sealedbox_PUBLICKEYBYTES;

• Adds checkSealedBoxLengths(sk, n, m) to check lengths of a secret key, nonce, and message for nacl.sealedbox.open to nacl.js and nacl-fast.js

Although there is a third-party library adding support for sealed boxes, there are a few reasons why I think it would be a good idea to include an implementation directly in TweetNaCl.js:

• Third-party library explicitly states that it is officially and completely unmaintained (no issues have been noticed by author since August 2019 with an ignored open issue), this is not great news for a cryptography library
• There is no flexibility in nonces with third-party library as it uses the exact libsodium specification. I currently do not see any reason to follow the nonce part of the specification because the nonce is deterministically generated (from the ephemeral public key and the recipient public key) and could just as well be a Uint8Array filled with 0s (see libsodium #630). It would be better to allow developers to choose the nonce directly for added flexibility, even though my implementation generates ephemeral keys within the scope of the function and zeroes out the secret key after boxing (low risk of reusing the ephemeral key).
• It would be incredibly useful to have sealed boxes as part of the official TweetNaCl.js library so that developers do not have to hunt down other libraries and so that companies do not have to add more dependencies to audit. The third-party library is not only just an extra dependency, it is not self-contained and relies on blakejs to generate the nonce (unnecessary as described above).

@dchest Please let me know if you plan to merge this PR. If so, I can write some test cases and add documentation to the README.md.

---

I dedicate any and all copyright interest in this software to the
public domain. I make this dedication for the benefit of the public at
large and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.

Anyone is free to copy, modify, publish, use, compile, sell, or
distribute this software, either in source code form or as a compiled
binary, for any purpose, commercial or non-commercial, and by any
means.

[dchest]

Sorry, the goal of this project is to be a JavaScript translation of TweetNaCl. There will be no new cryptographic features added. As you pointed out, sealed boxes can be easily supported via a third-party package. If you want to maintain one, I can replace the link in README.

[CMEONE]

Hello @dchest, apologies for the late reply. If you could please add the following libraries in the README, that would be greatly appreciated:

• tweetnacl-js-sealed-box — implementation of sealed boxes
• tEnvoy — object-oriented API and automatic encoding

Thanks so much!