Why do age encrypted files not support modification?

[adamlamar]

The spec clearly states:

The payload MUST NOT be modified without re-encrypting it as a new file with a fresh nonce.

Can someone explain why the payload cannot be modified? I am aware that reuse of a given key and nonce pair could result in various cryptographic attacks. If an implementation could guarantee nonces were not reused, would modifying the payload be acceptable?

[alerque]

This is not related to age, it is just a math problem. If you re-use the same encryption parameters to encrypt different payloads an attacker can use the differences in encryption to learn things about the private encryption parameters. You must decrypt, modify the payload* then re-encrypt from scratch with refreshed parameters. What is needed varies between encryption systems, in age's case you can re-use the private key file but you must start a fresh encryption from scratch with a new nonce. This logic is for roughly the same reason in the case of a one-time-pad encryption you must use a new random pad for each message, you can never re-use the pad. If you read about why that is you'll understand why age must have a new nonce for each payload and encryption operation.

[adamlamar]

Thanks for the reply! I understand that nonce reuse with a given key can be catastrophic. I'm not trying to argue that point, or say that its not true. 100% agree with the problems you've laid out.

However I'm not referring to the 16-byte nonce in the payload key, but rather the 12-byte nonce in each chunk.

What I'm asking is - if we could guarantee nonces were not reused when modifying the payload, could this be secure? To be clear, I'm suggesting a new implementation with a different filesystem-like interface would do this, not the current age CLI tools.

To further explain what I mean, consider the following scenario:

A new payload is written that fits in exactly 3 chunks. That should be 3*64KiB. The nonces for that payload will be 0, 1, 2. The last payload will have the 12th byte set to 1 to signal the end of the chunk list.

Now the user wants to extend the size of an existing payload without re-encrypting. They append exactly 64KiB without changing any of the previous contents. As I understand it, there are two operations that need to occur:

1. The 12th byte in the 3rd chunk nonce needs to be changed from 1 to 0. Since the last byte is also part of the nonce, the 3rd 64KiB chunk needs to be decrypted and encrypted with the new nonce.
2. The 4th chunk needs to be written with a nonce of 3 (one more than the previous last chunk), and sets the 12th byte to 1

At no point was a nonce ever reused. Besides the modification of the 12th byte, this mirrors what happens when the payload was streamed originally. AFAICT, whether the payload was written in 3 chunks with a later 4th append, or originally written with 4 chunks, the overall set of cryptographic parameters is identical.

Does that make sense?