Are highly compressed files with AES 256 password more secure with EOS ARK ZIP, or P7ZIP, or otherwise?

General system Applications
1

Hi friends. When I was using Windows, I used 7-zip to securely password-zip my files with AES 256 in 7z format.

I abandoned Windows and now only use EOS KDE. I found that the only way to compress with a password was to use the ZIP format that KDE’s ARK brings, since the other formats do not allow me to compress with a password. I also installed p7zip and it can be used from ARK, and this one also allows me to use password.

I would like to know the following things, if possible:

  • Is ARK ZIP (default) with AES 256 password, or P7ZIP (.7z) with AES 256 password more secure?

  • Does a maximally compressed file with a password become more secure than an uncompressed file with a password?

  • I have heard that some “7-zip” in the ARCH and AUR repository (and in most repositories) are versions made by third parties, or closed source, or that they are outdated. Also, some of these versions should not be used because they do not save some user permissions in Linux (I don’t know what this is, but it worries me and I would like to avoid these versions if possible, since I have read many people saying this on reddit and other forums).

  • If ZIP is better than 7Z, there is no problem because I already have it installed, and I will continue using it. But if you confirm that 7Z is better, which one should I install? Many appear in the ARCH repository, and many more appear in the AUR repository. Some with the “file manager” tag and others with the “file compressor” tag. I don’t know which one works with Linux permissions, it is free source and up to date.

  • Is there a more secure method to compress files with a password? AES 256 is the best known I think, but I would like to know if there is something more secure for compressing files, although I think this is the best known. I’m looking for something with a GUI since I use the terminal for everything else, but creating files and compressing files I prefer a GUI like ARK’s (or similar, in case you tell me there is something better).

Sorry for so much text, and thanks in advance for your time and help, friends.

image
image614×713 46.9 KB

2

7zip is better than zip.

1 Like
3

About the same, i would think.
7zip has better compression rate on most file types though, in case you need it.

No, why would it be?
They’re encrypted exactly the same way.

Yes:

  1. In case you can use password that is not one you should manually enter or remember with your own brain - use KeePassXC password generator with 128 length and all Character types enabled.

  2. Wrap it around another encryption layer like an onion, for example use gpg on top of that archive.

    gpg -c --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-count 65536 --no-symkey-cache --batch --pinentry-mode loopback --passphrase-file "PASSWORD_2.txt" -o "OUTPUT.7z.gpg" "INPUT.7z"

    Obviously before using it wherever you need to use it…always check if that layered sandwich can actually unpack with your password(s) :upside_down_face:

3 Likes
4

I am sure there are good GUI tools, but the CLI tools for this are very simple.

To compress a directory called “foo” into a tarball:

tar czf foo.tar.gz foo

This basically breaks down like this:

tar [options] [name of the archive you are creating] [file or directory you are compressing]

The example command creates a compressed archive named “foo.tar.gz” from the directory foo.

Encrypt the archive using GnuPG:

gpg -c foo.tar.gz

This generates an encrypted file named “foo.tar.gz.gpg.” It will prompt you to create a password for the encryption when you run it.

gpg -c takes arguments if you want to use an encryption algorithm other than AES-256, however if you just leave off the argument it will default to AES-256. I personally have not found any compelling reason to use another algorithm.

Later, to restore the directory, you basically do it in reverse. Decrypt the archive:

gpg -o foo.tar.gz -d foo.tar.gz.gpg

Again, it will prompt you to put in the password when you run it.

“-o” is the file you are outputting and “-d” is the file you are decrypting. This example produces a decrypted archive named “foo.tar.gz.”

Extract the archive:

tar xzf foo.tar.gz

This restores the “foo” directory.

If you want, you could turn these commands into a simple script, and then add the script as a custom “open with” entry in Dolphin’s right-click context menu.

That way you could do it right in your GUI file manager by right-clicking on the file or directory you want to compress and encrypt. Perhaps this would allow you to preserve the workflow you had for this process when you were using Windows.

3 Likes
5

You can use the -a/–auto-compress option, which use the compression tool according to the extension of the archive name.

tar -caf foo.tar.gz foo

I don’t think AES-256 is the default algo for gpg, my Thunar custom action looks like this ;

gpg -c --s2k-cipher-algo AES256 %f
6

Just try it, and see for yourself. :wink:

7

Looks you are right.

Encrypt with a symmetric cipher using a passphrase. The default symmetric cipher used is AES-128, but may be chosen with the –cipher-algo option.

https://man.archlinux.org/man/gpg.1#c

8

I noticed that too; the man page is actually incorrect on this one. :face_with_hand_over_mouth:

1 Like
9

Until now, I had put no more trust in any other man but the man :wink:

Seems I need to reconsider :sweat_smile:

10

Usually the man pages are the source of truth!

They changed the default encryption algorithm for GnuPG quite a few years ago but never updated the man page. See also this comment:

11

I doubt that I used the cipher option for nothing :grinning:, let’s see :

gpg -c -vv test.txt

gpg: using cipher AES.CFB

It seems AES is 128 bit from what I found.

edit: I just modified my gpg.conf, added this :

cipher-algo AES256

now it will be the default cipher.

12

Seems so. :grinning:

No harm to specify the algorithm anyway; it doesn’t hurt anything. If you are using it in a script or something I think it is a good practice to specify the algorithm so an upstream change can’t modify the behavior of your script.

Anyone using Arch Linux or EdeavourOS does not need to make any changes; AES-256 has been the default for GnuPG for years now.

13

If gpg with no option encrypt with AES instead of AES256, there’s something wrong with my system.

14

Perhaps you have modified that file in the past for some other purpose.

This is the behavior I get on the back of a recent Arch install, without modifying any gpg configs or otherwise changing any gpg-related settings:

❯ echo "Hello world" > hello.txt

❯ gpg -c -vv hello.txt 
gpg: enabled compatibility flags:
gpg: pinentry launched (5884 gtk2 1.2.1 /dev/pts/0 foot :0 20620/1000/5 1000/1000 0)
gpg: using cipher AES256.CFB
gpg: writing to 'hello.txt.gpg'

❯ gpg -d -vv hello.txt.gpg 
gpg: enabled compatibility flags:
# off=0 ctb=8c tag=3 hlen=2 plen=13
:symkey enc packet: version 4, cipher 9, aead 0, s2k 3, hash 8
	salt F314A23830942488, count 65011712 (255)
gpg: AES256.CFB encrypted data
# off=15 ctb=d2 tag=18 hlen=2 plen=72 new-ctb
:encrypted data packet:
	length: 72
	mdc_method: 2
gpg: encrypted with 1 passphrase
gpg: public key encrypted data: good DEK
# off=36 ctb=a3 tag=8 hlen=1 plen=0 indeterminate
:compressed packet: algo=1
# off=38 ctb=ac tag=11 hlen=2 plen=27
:literal data packet:
	mode b (62), created 1711201246, name="hello.txt",
	raw data: 12 bytes
gpg: original file name='hello.txt'
Hello world
gpg: decryption okay
1 Like
15

Thanks friends, according to that article, p7zip from the arch repository is more secure than zip when it comes to encrypting files with a password.

But can it give me some kind of problems, corrupted files or something like that? I have read in this reddit thread that it does not save the permissions, only Zip or Tar do it:

https://www.reddit.com/r/archlinux/comments/r5r3ns/will_arch_replace_p7zip_with_normal_7zip/

What kind of problems can I get using p7zip (arch repository), when saving important files with a password?

Thanks friend, but I made a mistake. I meant “p7zip” from the arch repository, not “7zip” or “7-zip” from the aur repository.

I have read in some reddit threads that p7zip, 7zip and 7-zip have some problems with permissions and Linux files. Do you know exactly what kinds of problems I can have when compressing linux files with p7zip?

I mean, I don’t know if I should use p7zip from arch, or 7zip and 7-zip from aur, or another package.

The thread I’m talking about is this one, although I’ve read this elsewhere and I’m confused:

https://www.reddit.com/r/archlinux/comments/r5r3ns/will_arch_replace_p7zip_with_normal_7zip/

16

No i don’t know, i’ve just tested ark 7zip with few of my scripts, it saved and unpacked both user:group and file permissions just fine as they were originally.

Just test it for your case, you can verify it with checksums

1 Like