You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, age-plugin-trezor assumes (without checking) the identity-v1 state machine (it should actually verify, and close if an unsupported state machine is passed).
The recipient-v1 state machine is used during encryption, and is an alternative to generating a recipient id. Instead, the plugin receives an identity, and dynamically generates and applies the matching recipient id, or any other encryption method of choice, to the file key.
This method carries a security advantage: An identity file, if generated without the recipient id comments, is simply a link back to the plugin (plus derivation path), and is therefore perfectly secure even if it leaks. The recipient id, on the other hand, can be used to "forge" an encrypted file, that cannot be set apart from files encrypted by the user, unless using a third-party authenticity signature/verification solution.
In addition to implementing the protocol, generating an identity file should, by default, be done without generating the recipient id (also allows doing it without a device connection), so it, by default, generates a "secure" identity file that is safe to leak. An option should exist for generating the recipient id, for when it is specifically intended to share the recipient id with another person (e.g. to receive a file encrypted).
The text was updated successfully, but these errors were encountered:
Currently,
age-plugin-trezor
assumes (without checking) theidentity-v1
state machine (it should actually verify, and close if an unsupported state machine is passed).The
recipient-v1
state machine is used during encryption, and is an alternative to generating a recipient id. Instead, the plugin receives an identity, and dynamically generates and applies the matching recipient id, or any other encryption method of choice, to the file key.This method carries a security advantage: An identity file, if generated without the recipient id comments, is simply a link back to the plugin (plus derivation path), and is therefore perfectly secure even if it leaks. The recipient id, on the other hand, can be used to "forge" an encrypted file, that cannot be set apart from files encrypted by the user, unless using a third-party authenticity signature/verification solution.
In addition to implementing the protocol, generating an identity file should, by default, be done without generating the recipient id (also allows doing it without a device connection), so it, by default, generates a "secure" identity file that is safe to leak. An option should exist for generating the recipient id, for when it is specifically intended to share the recipient id with another person (e.g. to receive a file encrypted).
The text was updated successfully, but these errors were encountered: