Haha, thank you!

It was made purposely to have only digits for good international support. You'll have to rewrite some parts of generation to include letters, and also add them to the font.

Agree, base32 would be great to have. Not sure when I'll have time to implement it, though.

It is not configurable. You can try cloning the repo and modifying the code. In general, I recommend that you just set a proper background color for your web page.

• 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.

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.

To be fair, I would like to avoid exposing internals at all — they are mostly translated from the C code without proper JS conventions, and require a lot of care to use correctly; they should have a properly designed API. I wanted to eventually remove all .lowlevel stuff, but since people already started building on top of it, it will break third-party packages. This is why I'd prefer if forked this code to add features they desire, it's small enough and not changing frequently.

• Exposes pack in nacl.lowlevel in both nacl.js and nacl-fast.js
• Updates nacl.min.js and nacl-fast.min.js
• Resolves issue #214

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.

Thank you for your contribution, however there's no need for a PR for such a small change. I regenerate the minified versions myself anyway for security reasons, and adding a few exported functions is easy for me to do, once the original issue has use case that's not covered by the current API.

I'm guessing this functionality is outside the scope of the package. Still wondering how one would go about doing this (mb requires other packages)?

I had a quick look at the paper. It says:

We work with the extended private key (64-byte􏰂) k in Ed25519, instead of the original 32-byte key k. All extended keys have the bits set and cleared exactly as specified in [5]. Signing and verifying procedures remain the same as in Section III-B. However, some Ed25519 libraries have a signing function that takes the 32-byte 􏰂k and expands it for every signing, while other libraries sign using the extended 64-bit k. Due to the way child Ed25519 keys are derived, they will not have the 32- byte master secret key. We note that the NaCl library [3] provides the necessary interface to the extended private key.

TweetNaCl.js indeed can use the extended 64-byte private key (nacl.sign.keyPair.fromSecretKey).

Will nacl.sign.keyPair.fromSeed work for your purpose?

These APIs are indeed confusing, but basically what sign.keyPair.fromSeed does is it allows you to replace nacl's internal randombytes(32) with your own 32 bytes, which it then uses for the secret key and computes the corresponding public key:

The problem with the signing secret key (due to NaCl design) is that it contains both this 32-byte seed and also 32-byte public key concatenated with it (can't see it in the screenshot). What sign.keyPair.fromSecretKey does is that it takes these 64 bytes and just extracts the public key from it, creating a suitable JS object.

box.keyPair doesn't have .fromSeed because .fromSecretKey already serves the same purpose: box's secret key is just 32 random bytes. That is, .fromSeed would be the same as .fromSecretKey.

To summarize, if you need to get a key pair from your own 32 random or derived bytes, use: nacl.box.fromSecretKey and nacl.sign.fromSeed. If you need to get the original key pair from the secret key (32 bytes for box and 64 bytes for sign), use nacl.box.fromSecretKey and nacl.sign.fromSecretKey.

Note that box (x25519) and sign (ed25519) use different curve representations, so their keys are not compatible with each other. You can however re-use a sign key pair for box if you convert it with https://github.com/dchest/ed2curve-js.

I wonder if an input type check, say in Hash.prototype.update(data), would be appropriate for idiots like me who just assume that a string is fine :)

    Hash.prototype.update = function (data, dataLength) {
        if (typeof data === "string") {
          throw new Error("Input data should be Uint8Array");
        }

I got much better results when I converted my strings to Uint8Array after noticing that my result was different than that produced by sha256sum at the command line.

I initially wanted to add such type checks, like in https://github.com/dchest/tweetnacl-js/blob/master/nacl.js#L949 but decided against that for speed, simplicity, and due to the rise of such things as TypeScript and IDEs that check types.

@jmrossy just released

Sorry for the wait, it's merged now. Thank you for your contribution! I'll release the updated version soon.

webpack5 no longer by default polyfills node libs like crypto, so by default build/bundle fails when consuming lib https://webpack.js.org/blog/2020-10-10-webpack-5-release/#automatic-nodejs-polyfills-removed

noticed already split by node/browser for runtime, this just hints to bundlers (webpack5) for browser targets that its safe to not include crypto and wont complain at build

probably helpful having similar changes in other packages here as well, but currently only needed random for now