Add Xchacha20 algorithm

[fzxx]

I submitted this to the official 7-zip team, but haven't received any response. Would this project welcome such a contribution? If so, I would be happy to submit it here.
https://github.com/fzxx/7zip-XChaCha20

[sebres]

FWIW, a short explanation what is XChaCha20

XChaCha20 is a highly secure, fast stream cipher. It is an extended-nonce variant of the widely popular ChaCha20 algorithm.

Core Features:

• Key Size: uses a strong 256-bit key for data encryption
• Extended Nonce: uses a 192-bit random number (nonce) instead of the standard 96 bits
• Collision-Free: the large nonce allows you to safely generate random nonces without reusing them
• High Performance: runs extremely fast in software without requiring specialized CPU hardware
• Side-Channel Resistance: immune to cache-timing attacks by design
• Built-in Counter Mode: ChaCha20 is internally designed like a counter (CTR) mode
• No Padding Needed: because it is a stream cipher, ChaCha20 can encrypt data of any arbitrary length down to the exact byte. It never requires padding, unlike AES-CBC which requires data to be a multiple of 16 bytes.
• Direct random access: due to CTR ChaCha20 is excellent for direct random access.

[mcmilk]

@fzxx - this looks like a cool addition to 7-Zip. Can you rebase the whole thing a bit and add copyright and/or source statements into the source files?

If you want, you can create a PR for this.

[fzxx]

@fzxx - this looks like a cool addition to 7-Zip. Can you rebase the whole thing a bit and add copyright and/or source statements into the source files?

If you want, you can create a PR for this.

I'm adding cascade modes (AES+XChaCha20-Poly1305, AES+XChaCha20+Ascon); will consolidate everything and migrate it to this project once completed.

[sebres]

I hope the cascade becomes optional, wouldn't it?
Just because by cascade we'd get the potential for security increase in opposite to performance degradation. Since the former is purely hypothetic (e. g. in theoretic case if one algorithm becomes compromised or gets a mathematic weakness somedays), whether the latter is completely real from scratch (because would significantly reduce throughput and drain battery life or CPU resources faster than with single algorithm).

[fzxx]

I hope the cascade becomes optional, wouldn't it? Just because by cascade we'd get the potential for security increase in opposite to performance degradation. Since the former is purely hypothetic (e. g. in theoretic case if one algorithm becomes compromised or gets a mathematic weakness somedays), whether the latter is completely real from scratch (because would significantly reduce throughput and drain battery life or CPU resources faster than with single algorithm).

Of course it's optional. Currently I'm designing a cascaded key derivation scheme, and the encryption algorithms have already been implemented. Three differently structured algorithms ensure high security.

[sebres]

Further in #505, thus closed here.