Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate away from crypto-js to native support #13

Open
ben-ryder opened this issue Nov 7, 2023 · 1 comment
Open

Migrate away from crypto-js to native support #13

ben-ryder opened this issue Nov 7, 2023 · 1 comment
Assignees
Labels
improvement Improving an existing feature project/device

Comments

@ben-ryder
Copy link
Owner

MIgrate away from https://www.npmjs.com/package/crypto-js as its not longer maintained and isn't needed:

Nowadays, NodeJS and modern browsers have a native Crypto module. The latest version of CryptoJS already uses the native Crypto module for random number generation, since Math.random() is not crypto-safe. Further development of CryptoJS would result in it only being a wrapper of native Crypto. Therefore, development and maintenance has been discontinued, it is time to go for the native crypto module.

@ben-ryder ben-ryder self-assigned this Nov 7, 2023
@ben-ryder ben-ryder added improvement Improving an existing feature project/device labels Nov 7, 2023
@ben-ryder
Copy link
Owner Author

ben-ryder commented Nov 8, 2023

Features:

  • Generate random key to be used as vaultEncryptionKey which will be used to encrypt all vault content.
  • Let user enter userSecret (a password) which will be used to derive a profileEncryptionKey.
  • The profileEncryptionKey can be used to encrypt/decrypt the vaultEncryptionKey so it can be uploaded to the user's profile as profileEncryptionSecret.
  • Encrypt/decrypt vault content using vaultEncryptionKey
  • Persist vaultEncryptionKey or some way to derive/retrieve that key so users don't have to enter userSecret all the time? This could either involve persisting the key in device keyring, local storage of some kind (not secure?) or by only ever keeping vaultEncryptionKey in memory and requiring either the userSecret value to be supplied every time or maybe a different userPasscode which is more convenient for the user to enter?
  • Separating out vaultEncryptionKey and profileEncryptionKey allows future flexibility, as a user could change their passphrase without having to re-encrypt all vault data too.

Implementation Details (TO BE CONFIRMED):

  • Use SubtleCrypto API for cryptographic functions.
  • Use AES-GCM to encrypt vault content (256 bit key?)
  • Use generateKey to generate the vaultEncryptionKey
  • Use PBKDF2 to derive profileEncryptionKey from the users passphrase, by using importKey to first create an initial key based on the users passphrase then deriveKey to derive the profileEncryptionKey to be used from this initial key.
  • Use wrapKey/unwrapKey to create profileEncryptionSecret, with profileEncryptionKey wrapping vaultEncryptionKey?
  • Use a different iv and salt value for each encryption, and store these with the data.

@ben-ryder ben-ryder added this to the Initial Release milestone Nov 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improvement Improving an existing feature project/device
Projects
Status: Status/In progress
Development

No branches or pull requests

1 participant