enter name here

Yeah that response also didn't age well... there was little precedent (if any) in FDE products at the time I just wonder what precedents were available of using weak Kuznyechik sh_t cipher in FDE that prompted VeraCrypt devs to implement it. The only justification that seems plausible is that it is a russian govt backdoor. You just look like a fool. Yeah insults are the main arguments of a person that surely deems themselves as "intelligent", and superior 😂 You could just say that stream cipher is...

Yeah that response also didn't age well... The ChaCha20+Poly1305 is in very widespread use. cryptsetup, the Linux FDE tool does support ChaCha20. https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMCrypt SSH supports it. root@debian:~# ssh -V OpenSSH_10.0p2 Debian-7+deb13u4, OpenSSL 3.5.6 7 Apr 2026 root@debian:~# ssh -Q cipher | grep chacha chacha20-poly1305@openssh.com there was little precedent (if any) in FDE products at the time I just wonder what precedents were available of using weak Kuznyechik...

Yeah that response also didn't age well... The ChaCha20+Poly1305 is in very widespread use. cryptsetup, the Linux FDE tool does support ChaCha20. https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMCrypt SSH supports it. root@debian:~# ssh -V OpenSSH_10.0p2 Debian-7+deb13u4, OpenSSL 3.5.6 7 Apr 2026 root@debian:~# ssh -Q cipher | grep chacha chacha20-poly1305@openssh.com there was little precedent (if any) in FDE products at the time I just wonder what precedents were available of using weak Kuznyechik...

Maybe we could then take an opportunity to merge the work done by 7-Zip ZStandard fork. There are great encoders there - for example the underappreciated Brotli, with crazy results with compression or decompression time to compression ratio - it's been selected as a new compression algorithm for PDF, for example. https://pdfa.org/brotli-compression-coming-to-pdf/ Brotli is also supported as the compression for HTML traffic for a long time. It doesn't beat LZMA2 in terms of compression ratio, but...

Maybe we could then take an opportunity to merge the work done by 7-Zip ZStandard fork. There are great encoders there - for example the underappreciated Brotli, with crazy results with compression or decompression time to compression ratio - it's been selected as a new compression algorithm for PDF, for example. https://pdfa.org/brotli-compression-coming-to-pdf/ It doesn't beat LZMA2 in terms of compression ratio, but it's good to have a choice. And there are those venerable LZ4 and ZStandard for...

Zstandard and LZ4 would be fine. Lizard looks like a kid with hydrocephalus. It has crazy slow compression speeds, so I could as well use Zstandard instead of it and have better speeds/compression ratios. LZ4 is to be the fastest of them all. So there could be like 3 "engines" - 7zip native LZMA as it is, then an option to choose Zstandard for more flexible scenarios, and LZ4 for the fast archiving/unarchiving for scenarios requiring extreme speeds. I agree this should resemble Tino's 7zip-zstd....

About "Tools / Delete Temporary Files..." I think the original requestor mentioned WinRAR's "Wipe temporary files", i.e. overwriting ALL THEIR CONTENTS with 0 bytes or random bytes before deleting the file. That makes sense if added/extracted files were sensitive to not unwillingly leak their contents to random places of the disk. It can be a problem on SSD, though, because of their wear-leveling algorithms (if you overwrite a file, it can actually not be overwritten in place, but the zero/random...

Maybe you can integrate the following solution to have the ability of ZSTD and LZ4 compression within .7z archives? https://github.com/mcmilk/7-Zip-zstd Thanks in advance!