Support whole file integrity check

[rimrim]

In AesGcmHkdfStreaming.java, we can verify the integrity of the segments individually but we cannot verify the integrity of the file as a whole: header || seg1 || seg2 || ... || seg_n. An integrity attack could be using a segment from another file to replace a segment of that file, assuming that the attacker can obtain 2 files encrypted by the same key.
I would suggest having a mode where we can check this as well, for example, a file can look like header || seg1 || seg2 || ... || seg_n || footer. Where footer is the collection of all the GCM integrity tags of the segments, and also being authenticated, so footer might look like: IV_f || tag1 || tag2 || ... || tag_n || tag_footer.
Now, if one wants to verify the integrity of the file, he collects the gcm tags from the segments and computes a tag to compare with tag_footer, this can only be done if he is the owner of the file with the proper key.

[thaidn]

@bleichen

[thaidn]

In AesGcmHkdfStreaming.java, we can verify the integrity of the segments individually but we cannot verify the integrity of the file as a whole: header || seg1 || seg2 || ... || seg_n. An integrity attack could be using a segment from another file to replace a segment of that file, assuming that the attacker can obtain 2 files encrypted by the same key.

Each file is encrypted with a unique key derived from the master key and the salt in the file header. The salt is not authenticated, thus an attacker can copy file 1's salt to file 2, and copy file 1's segments to overwrite file 2's segments. There are two scenarios:

1/ The attacker copies the whole file. They basically change the file path. This could be an issue if users don't authenticate the file path. At the API level, StreamingAead however doesn't know if users are going to encrypt a file or just a stream. So it seems that there's a disconnection between what we offer and what users might be expecting, and that could lead to potential misuses. We can address this by introducing an API for file encryption in which the file path is used as the additional associated data, but there's a concern that it would break when the file path changes (i.e., people making copies of their data).

2/ Assuming that file_1 and file_2 are encrypted with the same key and chunk size. The attacker overwrites file_1's salt with file_2's salt and overwrite file_1's segment 1 with file_2's segment 1. This is similar to scenario #1 in which the only information that the attacker did actually change is the file path.

I would suggest having a mode where we can check this as well, for example, a file can look like header || seg1 || seg2 || ... || seg_n || footer. Where footer is the collection of all the GCM integrity tags of the segments, and also being authenticated, so footer might look like: IV_f || tag1 || tag2 || ... || tag_n || tag_footer.
Now, if one wants to verify the integrity of the file, he collects the gcm tags from the segments and computes a tag to compare with tag_footer, this can only be done if he is the owner of the file with the proper key.

Because of the above observation this is not necessary because segments cannot be actually copied.

I'm going to close this issue, please reopen if you disagree with the assessment or if you have any other suggestions.

Thanks!