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
As described in the README.md here, the way age-plugin-tkey (and tkey-device-x25519) currently deals with files encrypted for multiple identities might not be ideal. Here is the last paragraph from that section:
One can imagine another implementation where the TKey device app does not only do X25519
ECDH, but instead more of the age cryptography is run on it. The device app running on the TKey
could then receive the wrapped file-key along with all the recipients, and would try them one by
one until it successfully unwraps the file-key (or fails to). It would execute multiple ECDH, but
could be made to require touching only once for this whole operation.
The main rationale is to avoid having to touch the TKey multiple times when a file has been encrypted for multiple TKeys (each of which you may or may not be in possession of).
If this is workable, it would of course mean an entirely different TKey device app binary. As is the case with all changes to the device app binary, the identity will change, and all derived secret keys would change. So the new device app could not be used for decrypting files encrypted for a recipient bound to a TKey running the old device app.
If some way to overcome this practical problem is really needed, we could imagine ways to run both the old and the new device app in sequence, in order to re-encrypt the files.
Related are also the expected upcoming new revision of the TKey, which may change how device apps need to be implemented, and/or how the client application (like age-plugin-tkey) communicates with the device app. This may cause required changes to tkey-device-x25519 binary, even before we begin considering a rewrite outlined above.
The text was updated successfully, but these errors were encountered:
As described in the README.md here, the way age-plugin-tkey (and tkey-device-x25519) currently deals with files encrypted for multiple identities might not be ideal. Here is the last paragraph from that section:
The main rationale is to avoid having to touch the TKey multiple times when a file has been encrypted for multiple TKeys (each of which you may or may not be in possession of).
If this is workable, it would of course mean an entirely different TKey device app binary. As is the case with all changes to the device app binary, the identity will change, and all derived secret keys would change. So the new device app could not be used for decrypting files encrypted for a recipient bound to a TKey running the old device app.
If some way to overcome this practical problem is really needed, we could imagine ways to run both the old and the new device app in sequence, in order to re-encrypt the files.
Related are also the expected upcoming new revision of the TKey, which may change how device apps need to be implemented, and/or how the client application (like age-plugin-tkey) communicates with the device app. This may cause required changes to tkey-device-x25519 binary, even before we begin considering a rewrite outlined above.
The text was updated successfully, but these errors were encountered: