TW

@darkk please have a look at #8903. `buzhash64` is not using AES, so likely not that cryptographically strong, but using a 64bit hash was suggested by one of these recent...

I added optional support for encrypting the rolling hash value before the chunking decision is made. About 7x slower when enabled.

## "Chunking Attacks on File Backup Services using Content-Defined Chunking" - section 3.2: N (window length) has a default size of 4095, but is **not** "hard-coded", can be set via...

Yes, these "chunker attack" defenses don't solve the problem of fingerprinting sets of (un-chunked) small files - but we already have obfuscation for these (and also for chunked bigger files)....

The new "buzhash64" chunker is now released in 2.0.0b18 in its basic form: - algorithm very similar to the old "buzhash", but computing 64bit hash values - the buzhash64 table...

@darkk Not sure if that should be default, can you start a github discussion about it? Doesn't really fit into the "new chunker" issue.

As a workaround, `borg transfer --dry-run --list ...` can also be used (if looking at the old repo's archives was desired in a transfer context).

Maybe let rather me fix that, it can get rather complicated while working with the 2 flavours of borg repos and the related code. Maybe we don't even need this...

@RogerHaase ok. they point was mainly having > 1 person there with admin capabilities (does not require translating). @UlrichB22 Maybe you?

@sebix I accepted your join request now, sorry for the delay and thanks for helping! One of the active devs here needs to push updated i18n files now and then...