Develop a Photo viewer, with GPG encryption built in

Development Code
1

Google Photos supposedly encrypts all of your pictures, Android is supposed to be encrypted 1-by-1 ? if I am to understand what they are doing correctly. Of course creating an encrypted Luks container in your system would suffice for this, but would require mounting > unmounting the container.

Creating a 7z archive would also do, but the larger the archive, the longer it would take to decrypt.

What if an app could simply encrypt > decrypt your pictures when you need to view them? Not sure there is any thing like this that I am aware of.

I thought GPG would be the most practical, since you can store your key in a password manager safely or have it in your keyring where ever Linux has it.

These are ideas I have had for a while, and have come from a recent project to archive about 30yrs of pictures. I wrote a simple bash script to do this while logging the passwords, archive info into a .log file.

#!/bin/bash

# Rename files
for pattern in "s/,/_/g" "s/ /_/g" "s/_-_/_/g" "s/__/_/g"; do
    prename "$pattern" *
done

seq=42600
echo 'dir,prefix,seq,archive,password' >> "/home/<User>/log.csv"

for dir in *; do
    prefix=$(head -c 9 <(tr -dc '0-9' < /dev/urandom))  # generate random 6-digit prefix
    pw64=$(head -c 64 <(tr -dc '[:alnum:]' < /dev/urandom))  # generate random 64-char alphanumeric string
    ((seq+=1))
    archive=$(printf "${prefix}_archive_%04d" "$seq")  # name of archive
    7za a -t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=off -p"$pw64" -mhe=on "$archive.7z" "$dir"
    echo "$dir,$prefix,$seq,$archive,$pw64" >> "/home/<User>/log.csv"
done

Over 2 thousand archives were created in the process, and was good for storing. The .log file relevant information was easily stored in a password manager like keepassXC for safe keeping and backup.

This is great for full archives, but very time consuming to extract and view. During holidays or gatherings, to have to decrypt > extract > view and then repeat when done is impractical.

Convenience over Security? Maybe we don’t have to compromise this time. . .
If every image was done individually, it would lessen the time to decrypt>view done !

I’m open to ideas and have some time before i layout everything. I want to keep things simple. I want to pursue the GPG keys since Public/Private keys can open this up to sharing easily as well.

Suggestions…

Thanks

1 Like
2

Ente has been recommended to me in another forum

1 Like
3

I see they are basically like MEGA, where the pictures are E2E. Mega has had a built in Photo Gallery and video viewer for several years now too. I’ve had a grandfather 50GB storage with them since 2013-ish. . . While interesting suggestion, It would not solve the encryption at rest locally, or offer up a Self-Hosted solution for your library.

I thought more about it last night and having the app deployable in a Linode droplet would go a long way as well for those seeking control over their content.

Thanks for the recommendation !

4

Just remember about things like preview or thumbnail which can reveal the encrypted photo in an undesirable way.

1 Like
5

Yeah, I’m still looking into how to handle or exclude the ability to preview. I’m gonna look over those repos, and come up with a flow chart or something to post potential compromise or what the direction of the tool is. It does have to be Privacy first though. . .

Thanks for the repos !

1 Like
6

LUKS layers encryption at the block device level, I think file system level schemes deserve a mention too, like eCryptfs which used to be in broad use in Ubuntu systems. There’s also the cross-platform EncFS (haven’t used), and at least one FUSE implementation floating around that uses gpg (haven’t used either).

The reason I mention these more generic approaches is they are more useful. Since once your photo viewer is done, maybe you have some video and audio to securely store too. And eventually maybe a few important openoffice documents too.

eCryptfs and friends, or your own FUSE based implementation, don’t look all that different from building encryption into a photo viewer or other app, it’s just the code lives in a different place in your stack and is available to be run by any program that can do filesystem calls.

1 Like
7

giphy

I had thought of creating a container and mounting for LUKS encryption to open/close when needed. Still on the table, but not as likely as per file encryption.

Exactly ! My main focus is the Photo viewer right now, but you are absolutely correct as anything can be encrypted by the app and potentially be a part of a stack. Email archives ( or ones you are currently writing. . . :wink: ) Documents, Health records, Audio/Video.