File and folder encryption application

I am looking for a file and folder encryption application. FileVault is not the answer. I want to be able to encrypt sensitive data files (like tax returns, medical info, etc.) and keep them encrypted until I need to work with them again. DiskUtility is not the answer for hundreds of files.

I had been using goSecure. It did everything I needed. However, it is flaky under Mojave and does not work under Big Sur. It has been abandoned by its author.

I switched to FileWard. It too does everything I need. It works under Mojave but is not fully compatible with Big Sur. Its author does not respond to queries.

Do you have any suggestions?

The most successful DIY approach for you may be creating encrypted containers (volumes) for related groups of files. This eliminates the need for individually encrypting every file or folder. The unlocked and mounted volume contents behave as any other files or folders. Dismounting the volume removes access to the contained files and folders.

This has the advantage of being transparent to backups of the dmg file as well as some device independence – an encrypted dmg may be opened identically within various versions of macOS and on different drives on different machines. No application-specific processes are required. No third-party software is required.

2 Likes

Best idea I’ve got is to make an encrypted disk image for the files and folders…and then mount it and put in the password when needed. You could store it in the keychain so it would auto mount if you are logged in but would still be unavailable for anybody else…or else just input the password every time you need it.

I have used encrypted disk images for my secure files and it works great. I keep the passwords in 1Password. Pro is that the dmg is great to transfer and/or backup to other hard drives; Con for me is that you are limited to the disk image size which means as the file grows you may have to create another dmg with more room and transfer the files.

Another vote for using an encrypted disk image, with the added tip that creating a “sparse image” will allow it to expand in size automatically.

1 Like

I’m not on a Mac at the moment…but I think you can still make sparse image files with a maximum size that only expand from minimal size as needed.

1 Like

That’s what I do. I typically create a 100MB sparse image. The files I put in it don’t come close to that size, but this gives me enough headroom to not have to worry about the image filling up, and making it sparse means it won’t consume 100MB, but only the amount actually needed to hold the content.

1 Like

In my uneducated and unscientific experience, a sparse image rarely decreases in size, even if files are removed.

I have had sparse images get close enough to the maximum size (that probably meant the size was about 60% of the max) that I created new (larger) sparse images, copied the contents from the old to the new, and deleted the old. As far as I can recall, every time the size of the new sparse image was significantly smaller than the size of the old sparse image.

None of this is meant to detract from the recommendations to use encrypted sparse images, which I happily continue to do.

That’s true, and it seems to be the nature of most sparse data structures. With these structures, it is far easier to allocate new data blocks than it is to declare a block empty and remove it.

I remember asking about this on a VirtualBox support forum. VirtualBox also has support for sparse disk images. I asked why the image files never shrink, even when you configure them as emulated SSDs (where TRIM should be able to tell the image-management code when blocks are garbage and can be removed).

The answer I got was that it would require quite a bit of data shuffling in the file in order to make this actually work, which would significantly slow down the emulated storage device.

I still think it would be useful, even if it can only be done when the image is off-line (e.g. when it is not mounted), but I don’t think anyone thinks it is worth the effort.

I might agree with that thought. Any change is an opportunity to introduce a bug, while creating a new sparse image and copying everything to it every few years has worked for me and has been fairly painless.

Has anyone had issues with disk images becoming corrupt?

I used to do this sort of thing (storing different projects on disk images to keep them more organized), but it was a long time ago. One reason I stopped was that I ran into times where the OS would tell me a disk image was corrupt and wouldn’t open. This might have been due to OS upgrades and trying to open an image I hadn’t opened in a while, so it could have been an OS compatibility problem. But unlike regular files, if an encrypted disk image won’t open, the data is toast. (At least with regular files you might only lose one file or be able to extract partial data from a file.)

The second reason I stopped using disk images is I started using syncing services like Dropbox so that my projects were on multiple devices and every tiny change to a file in a disk image required the entire disk image to by synced, which wasted a lot of bandwidth and was slow.

I’m just curious if either of these are still problems today.

There is another variation called a sparse bundle. This article explains its pros and cons:
https://eclecticlight.co/2020/04/27/sparse-bundles-what-they-are-and-how-to-work-around-their-bugs/

Thank you all for your responses.
It seems to me that using encrypted volumes is like trying to fit a square plug into a round hole. I have about 200 encrypted files/folders. Their content is important to me. I cannot chance losing them to corrupt volumes. I would like Apple to step up and release a supported file and folder application. Until then, I am going to do two things. Firstly, I will store the data in the Tresorit secure cloud. Secondly, I will migrate each of my encrypted files and folders to .7Z archived, compressed, and encrypted files and folders. I will use the Keka app.

Just a technical question, does compression add another layer where a process can get corrupted or are certain types of compression more stable? Does some compression happen automatically with certain encryption?

This is the perfect argument for regularly scheduled multiple backups. Multiple backups can provide spatial diversity (multiple drives and off-site backups).

Every once in a while, I have had to restore a clients dmg file. Usually to correct a user error; rarely to replace a corrupted volume. Sometime restoration is from a Time Machine backup, sometimes from CCC backup. Both are satisfactory.

I encourage use of a Safe Deposit Box for off-site storage of backups. Access to and subscriptions for Safe Deposit Boxes are generally easier and more reliable than cloud backups.

1 Like

This can be done with .sparseimage and .sparsebundle files using the hdiutil command line tool and the compact verb.

compact image [options]
            scans the bands of a sparse (SPARSE or SPARSEBUNDLE) disk
            image containing an APFS or HFS+ filesystem, removing those
            parts of the image which are no longer being used by the
            filesystem.

Also explained on the old Mac OS X Hints site:

http://hints.macworld.com/article.php?story=20040625012304236

For a GUI to do this, see Howard Oakley’s utility Spundle:

That was one of the reasons the .sparsebundle format was created: It is actually a folder with lots of individual files called ‘bands’, all of which are only a few MB in size. A change to the disk image should only affect a handful of bands, so syncing should be quick. This is compared with the .sparseimage format where an image with 10GB of data on it will be a single ~10GB file.

Overall, this still seems like a lot of hassle to me compared with simply encrypting the whole disk (but I know you said you didn’t want to use File Vault).

1 Like

Thanks. I didn’t know about that. For my use-cases, the disk images are relatively short lived (typically getting deleted once I come home from the trip where I was using the disk image), but for images that are used for an extended period of time, this will be quite useful.

1 Like

There’s Gnu Privacy Guard (GnuPG), which is based on OpenPGP. There’s a front-end for the Mac called GPG Suite, which is available at gpgtools.org. I’ve never used these tools, but it sounds like they would do what you want.

I have used an encrypted disk image on Macs for many years for precisely this purpose (confidential/private document filing). I have had one instance of corruption, the file would not open. However, I have multiple backups, including Time Machine and cloud storage, so nothing was lost.

For extra security I password protect the most valuable files but this opens up a separate topic as I have been unable to find out whether password protection in Office for Mac encrypts the file or just requires a password to open. Anyone know?

I’m pretty sure the file is encrypted.

Microsoft Office XML documents (.docx, .xlsx and .pptx) are zip files. You can actually view the contents using standard zip tools. For example:

$ zipinfo foo.docx 
Archive:  foo.docx
Zip file size: 17020 bytes, number of entries: 11
-rw----     4.5 fat     1312 b- defS 80-Jan-01 00:00 [Content_Types].xml
-rw----     4.5 fat      590 b- defS 80-Jan-01 00:00 _rels/.rels
-rw----     4.5 fat      817 b- defS 80-Jan-01 00:00 word/_rels/document.xml.rels
-rw----     4.5 fat    99738 b- defS 80-Jan-01 00:00 word/document.xml
-rw----     4.5 fat     8393 b- defS 80-Jan-01 00:00 word/theme/theme1.xml
-rw----     4.5 fat     2865 b- defS 80-Jan-01 00:00 word/settings.xml
-rw----     4.5 fat      753 b- defS 80-Jan-01 00:00 docProps/core.xml
-rw----     4.5 fat     1683 b- defS 80-Jan-01 00:00 word/fontTable.xml
-rw----     4.5 fat      655 b- defS 80-Jan-01 00:00 word/webSettings.xml
-rw----     4.5 fat    31420 b- defS 80-Jan-01 00:00 word/styles.xml
-rw----     4.5 fat      993 b- defS 80-Jan-01 00:00 docProps/app.xml
11 files, 149219 bytes uncompressed, 13932 bytes compressed:  90.7%

If you try the same with a password protected document, the zip tools fail:

$ zipinfo bar.docx
Archive:  bar.docx
[bar.docx]
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
zipinfo:  cannot find zipfile directory in one of bar.docx or
          bar.docx.zip, and cannot find bar.docx.ZIP, period.

I don’t know what Microsoft is doing, but I think it is reasonable to assume that it is still a zip file, but one that they encrypted after creation.

It is not encrypted using the Zip’s own encryption, because the zipinfo tool would show the table of contents for such an archive, only requiring a password to extract the contained files.

1 Like