test(encryption): add backwards-compatibility-test for encrypt/decrypt

[legobeat]

Encryption in this library is historically using tweetnacl and tweetnacl-util as encryption libraries. tweetnacl-util was replaced with @scure/base in #358 and tweetnacl is also due for removal.

This adds a snapshot of encryption.ts as test-legacy-encryption.ts, and adds compatibility tests in both directions to ensure that new versions of the code can decrypt messages produced by the old version and vice-versa.

It does this by wrapping the entire existing encryption-test-suite and injecting the functions under test.

---

Note for reviewers: Most of the diff in encryption.test.ts is indentation, which can be ignored by git diff -w).

[socket-security]

New dependencies detected. Learn more about Socket for GitHub ↗︎

Package	New capabilities	Transitives	Size	Publisher
npm/[email protected]	None	0	8.14 kB	dchest

View full report↗︎

[mcmire]

I'm curious whether it would be obvious that are we are running these tests with different inputs, or even why we are doing so. What are your thoughts on using describe to organize/describe the different invocations? I'm thinking an arrangement that looks something like this:

describe('encryption', () => {
  describe('using modern encryption and decryption APIs', () => {
    run({
      decrypt,
      decryptSafely,
      encrypt,
      encryptSafely,
      getEncryptionPublicKey,
    });
  });

  describe('using legacy encryption API', () => {
    run({
      decrypt,
      decryptSafely,
      encrypt: legacyEncrypt,
      encryptSafely: legacyEncryptSafely,
      getEncryptionPublicKey: legacyGetEncryptionPublicKey,
    });
  });

  describe('using legacy decryption API', () => {
    run({
      decrypt: legacyDecrypt,
      decryptSafely: legacyDecryptSafely,
      encrypt,
      encryptSafely,
      getEncryptionPublicKey,
    });
  });
});

Note that this would mean removing the describe('encryption', ...) from run.