Extensions were a poorly conceived concept
TotalTechGeek opened this issue · 4 comments
The current system for extensions is poorly conceived. They can be stripped from the file undetected.
I should modify the scheme to include the extensions in the authenticated payload, but this will prove slightly difficult as some of the extensions could potentially rely upon an HMAC of the payload (like a signature extension).
A potential solution to force the extensions to compute a separate hmac for what was previously considered the payload.
Extensions are not currently in use though, so the damage is non-existent.
Another option is to compute hmac(key, extensions || hmac(key, payload)) to use for the file's encryption.
This option is efficient but reduces the overall entropy fed into the underlying hash function. This is probably not an issue, but it's not ideal.
In my eyes, it is far better to commit to separating the responsibility of the extensions from the overall encryption scheme.
I think computing a hash/hmac for the file separately for the extension will lead to the best design.
Update:
The current solution to this issue is to move all of the extensions into the encrypted & authenticated payload. Tweaks to this payload will not go undetected.
Extensions will not be allowed to share information with the outside encryption scheme, thus, if the extension wants to utilize information about the file, the extension must compute that information for itself prior to being consumed.
Asymmetric authentication will compute a hash of the file and sign it.
Symmetric authentication will compute an hmac for the file, using the provided symmetric key.
Extensions were revised. This issue is now fixed.