Why not AES-GCM?

[chaxor]

It is claimed here that AES-256-CTR with Poly1305-AES is used for encryption.

Why is this used rather than AES-GCM? My understanding is that AES-GCM is CTR, but improved and more secure against some attacks.
Poly1305 has some advantages, but seem to be nullified with the dependence on AES-NI equipment already depended upon for AES-CTR.
If AES-GCM already has so many (very well founded, and secure under heavy scrutiny) implementations, why change it to something that is much less known, or 'home-rolled'?

Why this choice?

[intgr]

Note that the repository format of Rustic is fully dictated by Restic, the original implementation which Rustic is compatible with. https://github.com/restic/restic/blob/master/doc/design.rst#keys-encryption-and-mac

If your question is "why" it was designed like this, you should ask Restic.

[aawsome]

In addition to @intgr : Yes, in principle it would be not too hard to add additional encryptions and we could even do it such that in runtime rustic can use the crypto needed for each repository. But still in this case we would work with a repository which cannot be used by restic as restic does only support this one crypto.

We see it as a huge benefit in terms of data integrity that a rustic repository can always be read by restic - and vice versa. But still, if anyone comes up with a PR adding support for other crypto, we will add this extra possibility to rustic - and hope restic would follow as it does with other improvements rustic is offering ;-)