cal integration#36
Closed
jkoenig134 wants to merge 32 commits into
Closed
Conversation
* feat!: rust-crypto backed secret key handles and secret key handle deriviation This commit adds wrappers around rust-crypto KeyHandle with similar api to the existing libsodium CryptoSecretKey. BREAKING CHANGES: Added a few encryption algorithms that rust-crypto supports. Co-authored-by: Mark Beck <67227500+mark-beck@users.noreply.github.com> Co-authored-by: ngussek <45964639+ngussek@users.noreply.github.com> * fix!: missing crypto algorithms in crypto validation BREAKING CHANGES: Added more crypto algorithms to crypto validation. Some functions might succeed where they intentionally failed beforehand (`checkEncryptionAlgorithm`). * fix: accidental version downgrade of bt-runner and package version * remove: coverage test Remove coverage test via nyc, due to not functioning anymore. * refactor!: refactor of method names in crypto-layer/encryption Methods names and docs where adapted to fit code style guide lines. Changed docs to be less descriptive of what happens. Removed methods that where not used. * refactor!: adapted some function names to fit the style guide, rewrote some methods docs * refactor!: removed some unused methods, refactored util method names and refactored crypt derivation handle to use key spec and kdf of cal * removed!: unused default key spec from cal util * docs: minor improvements regarding docs in crypto layer providers * removed: lodash as unneeded * tests: added serialization and deserialization tests for CryptoSecretKeyHandle * test: CryptoSecretKeyHandle * fix: eslint not linting test-crypto-layer * tests: fixed eslint errros, added a constant for specifying the provider to use, added some documentation * tests: fixed failing parameterized tests and renamed them to fit naming style of allready existing tests * fix: bad validation in crypto secret key handle * fix: key spec not object error on derive key from base * docs: rephrased docs regarding custom validation * refactor: move crypto secret key handle key spec verification to post from * tests: moved crypto encryption tests into own module * tests: added tests to crypto encryption handle derived from crypto encryption tests, added test to check copmliance with libsodium implementation * tests: fixed some legacy tests not using new validation functions, grouped some promises * tests: fix missing lint:tsc check for tsconfig of test-crypto-layer * remove: superfluous lodash types dependency * fix: implicit soft failures in many CryptoLayerProviders functions Many checks used implicit type conversions and did not throw an error, but rather pretended that said keys do not exist. * feat: added context to errors originating from cal, added try catch and new error code for cal derivation * fix: problems that came up in pr * remove: superfluous tsconfig * refactor: move key spec check of crypto secret key handle to preFrom * fix: issues with CryptoLayerProviders * feat: implemented abstract base key handle and deriviates * feat: added generate key handle methods for new explicit key handles, updated rs-crypto-types * feat: change derive key handle to new explicit key handle classes * fix: accidental private api of derive key handle, missing exports in index * feat: conversion to libsodium key for key handle * feat: add conversion function to crypto secret key from portable key handle * test: added explicit key handle validation * test: added new non_exportable functionality of key handle to parameterized test util * fix: remove type intersection for generate key handle methods, update derive tests to use new key handle types * test: add check for instance in derive * test: fixed all other tests * refactor!: crypto layer config to use rust crypto api for per provider level configuration * chore: add validator * chore: add validation test * chore: key validation * docs: added comments regarding phantom markers in base key handle derived classes * removed: superfluous check in base key handle pre from * feat: argon2 option conversion in crypto layer utils * style: return early in conversion method * refactor!: crypto derivation handle derive key from password to use ts-crypto types * tests: refactored tests to use new api, added key handle derivation from password tests * test: fix derivation tests using a too small salt * test: test derive fails on too amall salt, expose derive key handle from password parameter interface * style: remove parameter unpacking in arguments of derive key handle from password method * refactor!: conversion methods in crypto encryption handle use crypto hash algorithm * chore: version bump * chore: version alpha * chore: fix alpha * chore: audit fix --------- Co-authored-by: Mark Beck <67227500+mark-beck@users.noreply.github.com> Co-authored-by: ngussek <45964639+ngussek@users.noreply.github.com> Co-authored-by: Mark Beck <mark-beck@web.de> Co-authored-by: Thomas Steinmetz <thomas.steinmetz@js-soft.com>
* chore: remove strange cspell file * test: combine cal and normal tests * chore: update scripts * chore: update configs * fix: use lockfile from main * chore: npm i * chore: prettier * fix: eslint * fix: imports * chore: remove strange run
…#40) * removed!: keySpec from BaseKeyHandle Removed `KeySpec` from BaseKeyHandle as there is currently no use in sync context. * refactor!: derived key handles are not serializable Refactored *Derived variant of key handles to not use BaseKeyHandle anymore, but rather a DerivedBaseKeyHandle that does not support serialization. The need stems from derived key handles being ephemeral. If they are being dropped, they do not exist anymore. Hence deserializing ephemeral key handles does not make sense and will result in an error. * refactor!: move construction method of key handles to CryptoEncryptionHandle * fix: from methods of key handles wrongly inferring BaseKeyHandle * refactor: remove unused type and useless comments * refactor: create nonce takes a provider identifier * removed: importable base key handle abstraction
…special recursive config
This commit removes the ability to create arbitrary providers inside ts-crypto in favor of exactly one hardware provider and one software provider if possile (or other security levels). There is a new function for the first time creation of these providers, which returns on success a config, which can be used to load exactly the same providers again. Said config is recursive and represents not only the provider to be inititialized, but also the provider that is depended on. The ability to create multiple providers of the same security level or the same provider with different storage config, was removed due to missing scopes of keys in ts-crypto in this regard. BREAKING CHANGES: removed initCryptoLayerProviders and CryptoLayerConfig
Test provider creation via mocks. Fixed loading of provider not using security methods. Moved types and interfaces of provider initialization to separate source file.
Add storage security config for android provider
…e initialized / provider init config This config needs to be deserialized before any provider is initialized, thus if key handle was part of this config, there'd be an error at that moment as the key handle cannot be loaded.
Due to all relevant providers supporting AES GCM and due to AES CBC being less secure than GCM, CBC was removed.
…ialization functions Als refactored method for inserting providers into the global provider map, to make more sense.
While crypto layer does have the option for the use of ChaCha20-Poly1305, no provider supports said algorithm. Meanwhile libsodium does support ChaCha20, but XChaCha20 is allready in use in TS-Crypto.
See nmshd/rust-crypto#167 for the reason regarding the override of tmp.
jkoenig134
commented
Aug 21, 2025
The override stems from the transitive and abandoned dependency external-editor depending on an insecure version of the tmp package. The override is not necessary anymore, as the developer of inquierer that depended on external-editor took up development on said project and updated inquirer to use said updated project.
Contributor
Author
|
@stnmtz will reopen it |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.