* Make doc clearer on getCrossSigningKeyId
I was trying to work out why this was being used in a check. It
turns out it only returns the key ID if the private part is stored
locally, which seems very much non-obvious.
* Better doc
* Formatting & clarity
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
---------
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Add CryptoApi. encryptToDeviceMessages
Deprecate Crypto. encryptAndSendToDevices and MatrixClient. encryptAndSendToDevices
* Overload MatrixClient. encryptAndSendToDevices instead of deprecating
* Revert "Overload MatrixClient. encryptAndSendToDevices instead of deprecating"
This reverts commit 6a0d8e26385c34d40e8c2ed1e34cb5119c12456c.
* Feedback from code review
* Use temporary pre-release build of @matrix-org/matrix-sdk-crypto-wasm
* Deduplicate user IDs
* Test for RustCrypto implementation
* Use ensureSessionsForUsers()
* Encrypt to-device messages in parallel
* Use release version of matrix-sdk-crypto-wasm
* Upgrade matrix-sdk-crypto-wasm to v8
* Sync with develop
* Add test for olmlib CryptoApi
* Fix link
* Feedback from review
* Move libolm implementation to better place in file
* FIx doc
* Integration test
* Make sure test device is known to client
* Feedback from review
* Move used Crypto event into crypto api
* Use new crypto events in rust crypto
* Remove `WillUpdateDevices` event from CryptoApi
* Use new crypto events in old crypto events
* Compute type of CryptoEvent enum
* Rename CryptoEvent and CryptoEventHandlerMap as legacy
* - Rename `RustCryptoEvent` as `CryptoEvent`
- Declare `CryptoEventHandlerMap` into the crypto api
* Add `WillUpdateDevices` back to new crypto events to avoid circular imports between old crypto and the cryto api
* Extends old crypto handler map with the new crypto map
* Review fixes
* Add more explicit documentations
Currently the crypto-api hierarchy is exposed only as a `Crypto` namespace
under the "matrix" entrypoint in the documentation.
This isn't really right: it's meant to be a separate entrypoint (in the same
way as `types`, `testing` and `utils` are). This PR fixes that problem.
* Move `SecretEncryptedPayload` in `src/utils/@types`
* Move `encryptAES` to a dedicated file. Moved in a utils folder.
* Move `deriveKeys` to a dedicated file in order to share it
* Move `decryptAES` to a dedicated file. Moved in a utils folder.
* Move `calculateKeyCheck` to a dedicated file. Moved in a utils folder.
* Remove AES functions in `aes.ts` and export new ones for backward compatibility
* Update import to use new functions
* Add `src/utils` entrypoint in `README.md`
* - Rename `SecretEncryptedPayload` to `AESEncryptedSecretStoragePayload`.
- Move into `src/@types`
* Move `calculateKeyCheck` into `secret-storage.ts`.
* Move `deriveKeys` into `src/utils/internal` folder.
* - Rename `encryptAES` on `encryptAESSecretStorageItem`
- Change named export by default export
* - Rename `decryptAES` on `decryptAESSecretStorageItem`
- Change named export by default export
* Update documentation
* Update `decryptAESSecretStorageItem` doc
* Add lnk to spec for `calculateKeyCheck`
* Fix downstream tests
* crypto: configure key sharing strategy based on deviceIsolationMode
fix eslint import error
cryptoMode was renamed to deviceIsolationMode
post rebase fix: Device Isolation mode name changes
* Fix outdated docs referring to old cryptomode
* code review: better comment for globalBlacklistUnverifiedDevices option
* RoomEncryptor: Use appropriate default for getBlacklistUnverifiedDevices
* do not provide a default value for DeviceIsolationMode for encryption
* Update src/rust-crypto/RoomEncryptor.ts
---------
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Implement `UserVerificationStatus.needsUserApproval`
Expose the `identityNeedsUserApproval` flag from the rust crypto crate.
* Add CryptoApi.pinCurrentUserIdentity
Expose `pinCurrentMasterKey` from the rust crypto api.
* Test data: add second cross-signing key for Bob
* Add tests for verification status
* Element-R: Don't mark QR code verification as done too soon
The rust crypto sdk doesn't actually finish QR code verification until the
`m.key.verification.done` is received, so make sure we don't tell the
application it is done before that happens.
Fixes https://github.com/vector-im/element-web/issues/26293
* ignore fallback line
* Revert unnecessary changes
Can't get the coverage high enough on this and it's not needed.
* Refactor key backup recovery to prepare for rust
* rust backup restore support
* Move export out of old crypto to api with re-export
* extract base64 utility
* add tests for base64 util
* more efficient regex
* fix typo
* Support for showing QR codes
* Emit `VerificationRequestEvent.Change` events when the verifier changes
* Minor integ test tweaks
* Handle transitions from QR code display to SAS
* Fix naming
* Add a test for `ShowQrCodeCallbacks.cancel`
* Offer `m.qr_code.scan.v1` verification method by default
Normally, the application specifies the supported verification methods when
creating the MatrixClient (and matrix-react-sdk does so). If the application
leaves it unset, then the idea is that the js-sdk offers all known verification
methods.
However, by default, the rust-sdk doesn't specify `m.qr_code.scan.v1`. So
basically, we need to set our own list of supported methods, rather than
relying on the rust-sdk's defaults.
* Factor out base class from `RustSASVerifier`
* Implement QR code scanning
* Update src/rust-crypto/verification.ts
* integ tests: factor out some utility methods
* Add `VerificationRequest.startVerification` to replace `beginKeyVerification`
The rust SDK ties together creating the verifier and sending the
`m.key.verification.start` message, so we need to combine
`.beginKeyVerification` and `.verify`.
* add some unit tests
* add a test for incoming verification requests
* Move `VerificationRequestEvent` to crypto-api
* Move `VerificationPhase` to `crypto-api`
* Define `VerificationRequest` interface
* Implement `canAcceptVerificationRequest`
* Move IReciprocateQr to `crypto-api` and rename
* Move ISasEvent to `crypto-api`, and rename
... and add some ✨comments✨
* Combine QrCodeEvent, SasEvent and VerificationEvent together
... as a precursor to extracting a single `Verifier` interface for `SAS` and `ReciprocateQRCode`.
`enum`s are slightly magical things that have both a type and a value, so we
have to re-export their backwards-compatibility fudges twice.
* Update src/crypto/verification/Base.ts
Florian Duros