Discussion/remarks on the file format

[peter021]

Header
Compared to this https://docs.cryptomator.org/en/latest/security/architecture/ and this https://www.aescrypt.com/aes_file_format.html the header format feels a bit sparse. I'd expect a nonce, a salt, a date, a GUID-identifier, an IV, a 64k-block-count, maybe a filename.
Header MAC
Why are you using an empty salt? Not using a salt means that the key is heavily dependant on the password, which means that the keys will not change from file to file. Using a random salt ensures that all files gets a unique key.
Also, why are you using a fixed info-field? And a short one at that. The info-field is also meant to be the rainbow table protection and using just "header" may not cut it. I'd recommend putting a SHA256 of the whole header in there.
The X25519 recipient type
Why would you use a base 32 encoding for key material? No human is going to be handling this? It is unclear to me as to how the motivation behind Bech2 applies to this use case.
X25519 recipient stanza
"A new ephemeral secret MUST be generated for each stanza and each file."
Isn't this why you want to use asymmetric encryption - so that you don't have to exchange keys every now and then? Don't you think key rotation is something "age" has to provide, and the X25519 keys are only used to wrap unique session/block keys.
"where the ChaCha20-Poly1305 nonce is fixed as 12 0x00 bytes."
Why would you use all zeros?
The rest of the encryption stuff is beyond me, and I hope someone else reviews this part.

[FiloSottile]

Hi! You seem to be conflating at various points the key material and operations involved in the individual file, and the wrapping keys derived from asymmetric keys or passwords (which do have a salt). I recommend trying to encrypt a few files and dissecting them to understand the spec better.

[FiloSottile]

The documentation is up to date. I don't think your interpretation is correct, for example the scrypt section clearly explains the use of a random salt.

[peter021]

Oh, sorry I wasn't clear. The bold lines in ny text was an attempt to point to sections I was having questions about.
In this document: https://github.com/C2SP/C2SP/blob/main/age.md
It is indicated that the header MAC isn't using a salt. The message authentication code is keyed and to improve security of the key and to generate different signatures on each run a random salt is required. Yes, I can see I was less than clear in my text, but my question stands.
I know the info field is about add more entropy to the key and therefore my opinion stands that a fixed info field that states "header" is a bit weak.

[FiloSottile]

The fixed header string is for domain separation, not entropy. Salting is necessary when bruteforce is a concern, to force attackers to attack each hash separately (which is why we use it for the user passphrase in scrypt). When the key material is high-entropy (such as the randomly generated 128-bit file key), salting is unnecessary, as bruteforce is not a concern.

[peter021]

...depending on user customs and intended threat model...
Well, it was nice talking to you. I hope you have a wonderful new year!

[FiloSottile]

Have a happy new year, and thank you for being nice even if we ultimately didn't converge :)