# @ibgib/encrypt-gib changelog

_note: as you implement features/fixes/etc., please document them here under the "Working Version" section. These will be moved to a concrete version number during the next publish._

## Working Version

## 0.3.1
* fix: updated helper-gib fundamental non-breaking `hash` and `getUUID` changes
  * This change is non-breaking in terms of contract surface, but big enough of
    a change that I bumped the minor version.
  * This includes a security bug where `getUUID` was ignoring `seedSize` and
    hard-coding this at 16. This "should" not be a huge deal, especially since
    encrypt-gib has no users (none that I know of anyway), and this is only used
    in generating salts when none are explicitly provided. But this hard-coded
    the entropy for any uuid created at 122 bits, which isn't terrible, but it
    isn't that great in terms of PQC. So encrypt-gib defaults to a seed size of
    1024, and this was getting _completely_ ignored.
    * Since this only was used in generating default salts, decryption is
      unaffected since the salt is generated in the encryption phase only.
  * I only have run the quick tests, which are all passing, though I did add the
    mitigation tests to the "quick" set, so it takes about a minute now on my
    old laptop. Ah, constraints create great art and all that BS.
  * Here is the changelog from helper-gib v0.0.37:
  ---
  * fix: `getUUID` implementation entropy seedSize and perf
    * For the fix, for some reason, `seedSize` was being ignored (??) and all
      uuid's were using 16: `crypto.getRandomValues(new Uint8Array(16));`.
      * This is crazy and I don't remember doing it, but there it is.
      * This hard-coded the entropy at 120 bits, which isn't terrible
        but downstream encrypt-gib passing in seedSize of 1024 was completely
        ignored and losing entropy for PQC, which really should have had 256 bits.
        (1024 is probably overkill)
    * For the perf, in addition to using the new `hash` function implementation,
      we now use `crypto.randomUUID` for `seedSize` of 16 or less instead of
      manually allocating via `getRandomValues`.
      * This makes regular uuid's used as nonces for uniqueness in ibgibs
        significantly faster. This is the most common use, and the least stringent
        on security requirements, taking 68% of the time (47% increase in perf) on
        initial benchmarks.
    * Added `test speed of different implementations` respec to
      utils-helper.respec.mts, which naively benchmarks different seed sizes over
      a large number of iterations in a tight loop. These yield expected results:
      ```
      [speedTest][undefined]: 1.370s
      [speedTest][0]: 1.046s
      [speedTest][8]: 1.017s
      [speedTest][16]: 1.018s
      [speedTest][17]: 1.264s
      [speedTest][32]: 1.354s
      [speedTest][1024]: 2.521s
      ```
      * `undefined` through 16 `seedSize` being equal-ish time (all using
        `crypto.randomUUID`)
      * a jump at 17 where we switch to the slower, higher-entropy
        `getRandomValues` algorithm
      * a clear increase as `seedSize` increases, with a significant jump at
        seedSize 1024.
    * passes all unit/regression tests in entire monorepo
  * perf: `hash` implementation improvements
    * `hash` - uses a pre-computed lookup table for all 256 possible byte hex
      combinations instead of converting to an array and doing custom
      `asArray.map(b => b.toString(16).padStart(2, '0')).join('');`
    * `getUUID` -
    * passes all unit/regression tests in entire monorepo
  ---
* meta: added [AES_AND_BYTE_VAR_IMPLEMENTATION.md](libs\encrypt-gib\docs\AES_AND_BYTE_VAR_IMPLEMENTATION.md)
  * Had a discussion with the Google AI mode agent after `hash` and `getUUID`
    optimizations, and we discussed a "drop-in" Byte-Variant encrypt-gib
    algorithm overhaul. I stubbed this implementation file for when we add AES
    and the ability to dual-encrypt (or n-encrypt if we go that far). Basically,
    the "Byte Variant" uses byte arrays instead of string concatenation all over
    the place, which would increase runtime perf at the cost of
    readability/complexity (encrypt-gib's main selling point). Read the md file
    for more details.
* chore: centralized build orchestration
  * migrated build, clean, and test logic to the root `@ibgib/build-gib` orchestrator.
  * pruned legacy `package.json` scripts and archived them in `docs/ARCHIVE_SCRIPTS.md`.
  * updated `prepare:publish` to use the centralized build engine.
  * documented the new **Monorepo Build Policy** in the README.

## 0.2.35
* meta: respec-gib testing migration
  * migrated specialized `quick` and `stress` test runners to use the centralized `RespecNodeRunner` in `@ibgib/helper-gib`.
  * utilized `respecFileRegExp` and `lookForExtraRespec` runner options to maintain specialized test scopes.

## 0.2.32

* correcting bare imports in all libs/apps
* updated helper-gib, ts-gib and encrypt-gib.

# 0.2.20

* refactor: changed rli to use helper-gib `buildArgInfos` fn

# 0.2.19

* refactor: moved some rli code to helper-gib
  * updated helper-gib
* refactor: use helper-gib `extractErrorMsg` in catch blocks

# 0.2.18

* meta: readme

# 0.2.17

* refactor: multipass section to block
  * many various renames, including types, constants, variables,
    and file names/paths.
    * made backwards compatible fwiw
    * changed in readme and opportunity.
    * changed existing *.encrypt-gib
  * tested regression for gather.encrypt-gib again.
  * quick tests all pass. also, did quite awhile of stress test but
    ultimately need to do another full stress test.
  * also tweaked refactor for stream to stream-mode in paths.

# 0.2.16

* refactor: renamed temporary "legacy" name to "stream"
  * the original implementation does act as a stream cipher, even though
    it does not operate at a binary level. So "stream" seems to be more
    descriptive than "legacy".

# 0.2.15

* refactor: round function
  * I condensed each different implementation of the round function
    within encrypt and decrypt functions, both in legacy (stream) and
    multipass modes.
  * all tests passing for quick (not heavy stress tests yet though)
  * tested manually for regression also with gather.encrypt-gib and
    foo.encrypt-gib
  * adjusted README to reflect changes.
* meta: removed cruft
  * lots of cruft removal
  * did NOT remove unused logging, as those still are useful to uncomment
    * but dangerous if they get into production...
    * waffling on this a bit, but low priority since no one else uses this
      lib.
* meta: README warning
  * added a bolded warning at the top of the readme that describes the
    experimental nature of the lib.

# 0.2.14

* added multipass mode walkthrough section in the readme to contrast with
  the default cipher stream mode.
  * stubbed verbose logalot tracing throughout multipass mode for the
    walkthrough, but commented all out.
* request line interface (RLI) parameters added to expose more available
  parameters.
  * `initialRecursions`, `hashAlgorithm`, `saltSrategy`, etc.

# 0.2.0/1

* multipass mitigation against short-circuit brute force attacks.

# 0.1.7

* changed unit testing to use respec-gib inside helper-gib.

# 0.1.4/5

* changed npm package to scoped name @ibgib/encrypt-gib
* simplified isomorphic crypto
  * removed all aspects of `set_target.sh` hack
    * deleted .browser/.node src and tsconfigs
    * changed scripts in package.json
  * changed from mocha to jasmine
    * removed all aspects of mocha
    * added jasmine config for both node and browser
    * aligned package.json, tsconfigs, gitignore, npmignore files with other ibgib packages
      * currently reorg/refactoring ibgib packages

# 0.1.0

* changed `initialRecursions` to use 20000 default iterations.

# 0.0.6/7/8

* Added SHA-512 hashing.
  * Set default hashing to use this in `constants.ts`.

# 0.0.1

* Basic encrypt functionality

# notes

* this package is now isomorphic and the following note is no longer accurate. deprecated, so keeping the note here for now.
* ~~I'm publishing two versions of this lib at a time. **USUALLY** the odd number is the node version (because that is how I run `npm test`), and the higher even number is the browser target.~~
  * ~~Sometimes three build versions in a row will be the same to resynchronize.~~
    * ~~(I tried publishing node last, in case someone downloads and npm test doesn't run, but nobody is going to use this anyway so I'm going back to node odd, browser even)~~