profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/dchest/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Dmitry Chestnykh dchest Coding Robots Montenegro https://dchest.com Founder of @coding-robots. Invented "I Write Like". Previously created BlogJet (acquired) and StableLib. Interested in cryptography and perfect code.

dchest/captcha 1410

Go package captcha implements generation and verification of image and audio CAPTCHAs.

dchest/authcookie 112

[DEPRECATED] Go package authcookie implements creation and verification of signed authentication cookies.

dchest/blake2b 88

Go implementation of BLAKE2 (b) cryptographic hash function (optimized for 64-bit platforms).

dchest/blake2s-js 80

BLAKE2s cryptographic hash function in JavaScript

dchest/blake256 19

Go package blake256 implements BLAKE-256 and BLAKE-224 hash functions (SHA-3 finalist).

dchest/b2sum 14

Go implementation of b2sum utility to calculate BLAKE2 checksums (GitHub Mirror)

dchest/bcrypt_pbkdf 11

Go implementation of bcrypt_pbkdf(3) from OpenBSD

dchest/blake2s 11

Go implementation of BLAKE2 (s) cryptographic hash function (optimized for 32-bit platforms).

dchest/cache 11

Go package cache implements LRU (Least Recently Used) cache algorithm. [[ Deprecated, use https://github.com/dchest/lru ]]

dchest/blake512 8

Go package blake512 implements BLAKE-512 and BLAKE-384 hash functions (SHA-3 finalist).

pull request commentStableLib/stablelib

Update x25519.test.ts

Haha, thank you!

TJKoury

comment created time in 10 days

push eventStableLib/stablelib

TJKoury

commit sha d78e6a404cb6fdfd2aa6b6f61ad77ff91b722324

Update x25519.test.ts

view details

Dmitry Chestnykh

commit sha 4a78c3e664adcf62ed6b8c304c17de434c3b6d42

Merge pull request #40 from TJKoury/patch-1 Update x25519.test.ts

view details

push time in 10 days

PR merged StableLib/stablelib

Update x25519.test.ts
+1 -1

0 comment

1 changed file

TJKoury

pr closed time in 10 days

issue commentdchest/captcha

Add Letters

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.

alidehghan

comment created time in 15 days

issue commentStableLib/stablelib

Thoughts on Base32?

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

joshxyzhimself

comment created time in 20 days

push eventdchest/tweetnacl-js

Dmitry Chestnykh

commit sha 3389b7c9f00545e516a0fdafb324b7857cf1527d

README: update tweetnacl-js-sealed-box mention

view details

push time in a month

push eventdchest/tweetnacl-js

Dmitry Chestnykh

commit sha dbe15d39e10f29a298aa040aa05852d2150580e5

README: update the update

view details

push time in a month

push eventdchest/tweetnacl-js

Dmitry Chestnykh

commit sha 34350f3c042257752f07c61769d9170db9eac389

README: shorten audit quote and mention a bug since the audit

view details

push time in a month

push eventdchest/tweetnacl-js

Dmitry Chestnykh

commit sha 2f89e9a62abe80e138be11f3f7be6d8c289a84f7

README: add link to ed2curve

view details

push time in a month

push eventdchest/tweetnacl-js

Dmitry Chestnykh

commit sha 4938b349d4e79bf3158ea662adfff7ec1d46f56d

README: replace link to sealed boxes implementation The new one is maintained.

view details

push time in a month

issue commentdchest/captcha

How can i set png backgroun color ? Thanks

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.

olongfen

comment created time in a month

PR closed dchest/tweetnacl-js

Sealed Boxes
  • 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.
+83 -4

1 comment

3 changed files

CMEONE

pr closed time in a month

pull request commentdchest/tweetnacl-js

Sealed Boxes

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

comment created time in a month

issue commentdchest/tweetnacl-js

ed25519 decode / decompress

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.

1000i100

comment created time in a month

PR closed dchest/tweetnacl-js

Expose pack in nacl.lowlevel (resolves #214)
  • 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.
+9 -6

1 comment

5 changed files

CMEONE

pr closed time in 2 months

pull request commentdchest/tweetnacl-js

Expose pack in nacl.lowlevel (resolves #214)

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.

CMEONE

comment created time in 2 months

issue closeddchest/tweetnacl-js

Use box.keyPair for XEdDSA / VXEdDSA signatures?

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)?

closed time in 2 months

zbo14

issue commentdchest/tweetnacl-js

Use post-hash 64-bytes signing key with Ed25519 ?

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

Esya

comment created time in 2 months

issue commentdchest/tweetnacl-js

Please also export "pack" function in nacl.lowlevel

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

tetratorus

comment created time in 2 months

issue commentdchest/tweetnacl-js

Box keypair from seed?

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:

Screen Shot 2021-06-07 at 07 42 46

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.

Screen Shot 2021-06-07 at 07 48 21

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.

taoeffect

comment created time in 2 months

issue closeddchest/fast-sha256-js

Suggestion: input type check

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.

closed time in 2 months

blackjackshellac

issue commentdchest/fast-sha256-js

Suggestion: input type check

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.

blackjackshellac

comment created time in 2 months

pull request commentStableLib/stablelib

fix(random): hint bundler browser targets, webpack5

@jmrossy just released

zachferland

comment created time in 2 months

push eventStableLib/stablelib

Dmitry Chestnykh

commit sha 03dadf27703120d54e6be8436525228ee1c4299b

Publish - @stablelib/aead@1.0.1 - @stablelib/aes-kw@1.0.1 - @stablelib/aes@1.0.1 - @stablelib/base64@1.0.1 - @stablelib/benchmark@1.0.1 - @stablelib/binary@1.0.1 - @stablelib/blake2b@1.0.1 - @stablelib/blake2s@1.0.1 - @stablelib/blake2xs@1.0.1 - @stablelib/blockcipher@1.0.1 - @stablelib/bytereader@1.0.1 - @stablelib/bytes@1.0.1 - @stablelib/bytewriter@1.0.1 - @stablelib/cbor@1.0.1 - @stablelib/chacha-drbg@1.0.1 - @stablelib/chacha@1.0.1 - @stablelib/chacha20poly1305@1.0.1 - @stablelib/cmac@1.0.1 - @stablelib/constant-time@1.0.1 - @stablelib/ctr@1.0.1 - @stablelib/ed25519@1.0.2 - @stablelib/float@1.0.1 - @stablelib/gcm@1.0.1 - @stablelib/gf256@1.0.1 - @stablelib/halfsiphash@1.0.1 - @stablelib/hash@1.0.1 - @stablelib/hex@1.0.1 - @stablelib/hkdf@1.0.1 - @stablelib/hmac-drbg@1.0.1 - @stablelib/hmac@1.0.1 - @stablelib/int@1.0.1 - @stablelib/keyagreement@1.0.1 - @stablelib/nacl@1.0.2 - @stablelib/newhope@1.0.1 - @stablelib/pbkdf2@1.0.1 - @stablelib/poly1305@1.0.1 - @stablelib/random@1.0.1 - @stablelib/salsa20@1.0.2 - @stablelib/scrypt@1.0.1 - @stablelib/sha224@1.0.1 - @stablelib/sha256@1.0.1 - @stablelib/sha3@1.0.1 - @stablelib/sha384@1.0.1 - @stablelib/sha512@1.0.1 - @stablelib/sha512_256@1.0.1 - @stablelib/siv@1.0.1 - @stablelib/snappy@1.0.1 - @stablelib/tss@1.0.1 - @stablelib/utf8@1.0.1 - @stablelib/uuid@1.0.1 - @stablelib/wipe@1.0.1 - @stablelib/x25519@1.0.1 - @stablelib/xchacha20@1.0.1 - @stablelib/xchacha20poly1305@1.0.1 - @stablelib/xsalsa20@1.0.2

view details

push time in 2 months

push eventStableLib/stablelib

Dmitry Chestnykh

commit sha 14f9ef5ec1f3f2efce72f2fe9e70aaed4104189f

Update some dev dependencies

view details

push time in 2 months

pull request commentStableLib/stablelib

fix(random): hint bundler browser targets, webpack5

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

zachferland

comment created time in 3 months

push eventStableLib/stablelib

Zach Ferland

commit sha 42d2f2dd786a9953516fde6d316d36c11a3de84b

fix(random): hint bundler browser targets, webpack5

view details

Dmitry Chestnykh

commit sha 0123dfcb7baf54e0b4c481fdee33f4df3de53c7d

Merge pull request #30 from zachferland/fix/random/webpack5-errors fix(random): hint bundler browser targets, webpack5

view details

push time in 3 months

PR merged StableLib/stablelib

fix(random): hint bundler browser targets, webpack5

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

+3 -0

0 comment

1 changed file

zachferland

pr closed time in 3 months