Show HN: Simple Image encrypt/decrypt using Python
uniqueuid 2021-08-18 12:37:25 +0000 UTC [ - ]
Neat.
I've used nacl and its python bindings in the past, which were pretty easy to use for asymmetric scenarios [1].
Is there anything particularly special about this project?
pavlovskyi 2021-08-18 12:52:51 +0000 UTC [ - ]
I think that there is not. It was created for specific purposes at one project when I have to be aware of store images in specific path because of security reasons. At this moment it was clearly one simple way to crypt dataset with without any information loss. (data was further used to feed neural network architecture).
ryan-duve 2021-08-18 11:27:39 +0000 UTC [ - ]
Very cool. It would be neat if you had a MWE included so we could see an actual image get encrypted and decrypted in the README. I find sections like that, sometimes titled "Quick Start", the most instructive way to learn about the functionality of a new library at a glance.
pavlovskyi 2021-08-18 11:48:19 +0000 UTC [ - ]
Yes, that is true. The entry threshold to this kind of projects without well defined Readme section becomes really high.
tyingq 2021-08-18 13:35:21 +0000 UTC [ - ]
Is there more context as to why something custom was desired here? Gpg, for example, can do symmetric AES256 as a "one liner". Not criticizing, just curious.
pavlovskyi 2021-08-18 13:54:57 +0000 UTC [ - ]
As I understand it properly, there was need to develop some solution with some limited technological stack.
28194608 2021-08-18 14:15:53 +0000 UTC [ - ]
It would be great if the secret_key goes through a time consuming hashing algorithm like bcrypt.
metalliqaz 2021-08-18 13:35:26 +0000 UTC [ - ]
Is there a use case that would make this preferable to storing images (and other data) on an encrypted disk?
LinuxBender 2021-08-19 14:11:31 +0000 UTC [ - ]
One use case would be if and end-user wanted the files encrypted in a way that the systems admin can't see the content. This is the model NextCloud uses.
pavlovskyi 2021-08-18 13:56:34 +0000 UTC [ - ]
I think that it can be used in situation when you cannot reach an encrypted disk and have to move about in closed space.
BugsJustFindMe 2021-08-18 14:46:55 +0000 UTC [ - ]
And by "I think you should do" what I mean is "IO encryption already exists so you shouldn't need to do anything" (see https://developers.google.com/tink/encrypt-large-files-or-da... for one example). But if you really like making things yourself, it would be very easy to just not use PIL and numpy and read blocks from a stream into a small R/W buffer.
1) Encryption has nothing to do with images. If you encrypt arbitrary data from the file system then you don't need PIL or numpy.
2) Right now if your decompressed image doesn't fit in RAM, then your code dies horribly.
Using the same system interfaces and same encryption without the reliance on numpy or PIL, you could accomplish the same feat but safer, faster, and more universally en/decrypting raw data from a chunked IO stream instead of treating images as special somehow. It will work against all files and will never overflow available resources. PIL can't even decode all image formats.
Leave the image decoding part to the code that actually does something with images.
dominik-2020 2021-08-18 14:52:52 +0000 UTC [ - ]