Thought on sender signature

[rayc345]

Hello all.
When age is used to encrypt file to be sent/stored via untrusted web servers, it's meaningful for the encrypted to be signed, or this encrypted file may be replaced.
Currently, a send tool such as rsign2 should be used. But the UX is not good by using two different tools, especially when you encrypt with PIV card but cannot use PIV for signing. Also, encrypt then sign or sign then encrypt are not good.

I think it's better to integrate signing and encryption for better UX and higher security by adding a new signature file. For example, the encrypted output of is text.txt.age.

Add a text.txt.age_sign file, it has two parts, part 1 is HMAC_SHA256(AEAD_enc_Key, publickey). The AEAD symmetric encryption key and the signing public key is used to compute a authentication tag.
Part 2 of this file is the signature of text.txt.age and part 1 as a whole.

The signature verification not only just verifies part 2 but also should verify part 1, and check if the public key for signing is the one used for HMAC.

The text.txt.age is the output of current age, and its security is not discussed here since it's been analyzed by a lot of people. We only consider the file text.txt.age_sign.
Since both text.txt.age and part 1 of text.txt.age_sign are used for signature generation, so everything is protected. Recipents and attackers cannot modify encrypted data, recipent info, etc.

As for the signature problem where the signature can be replaced by someone else, an attcker who knows the public key of recipents cannot change the file, because the attacker does not know AEAD symmetric encryption key, the HMAC cannot be correct. Recipents can generate new HMAC and resigning, but I think it's okay. Recipents can resend the file to someone else as long as the signature does not correspondent to the original sender.

Using this method, the problem 'attacker can strip your signature, replace it with their own' cannot happen. The multiple recipent issue should not exist, too. Because the header is covered by signature of original sender.
Also, maximium compatibility is obtained, since it does not break the file format of the encrypted output.

I want to know if this design is good ? I want to develop a helper tool to generate this signature file and supports PIV tokens. I want folks to help check if my thoughts are good. Thanks a lot!