FinalCrypt 2.7.2 now has a Legacy / RAW encryption mode. A mode that disables the default MAC Mode (Message Authentication Code Mode). This is handy to remove any MAC traces off encrypted files and also to raw (visual) binary data analyze encrypted files. Beware of course MAC Mode and Non MAC Mode encrypted files are not compatible. Non MAC Mode does not allow to re-encrypt encrypted files that contain a message authentication code, protecting the user. MAC Mode does allow encrypting of encrypted files without message authentication code as there is no way to distinct between any raw encrypted file and any other unknown binary data formatted file. Now you can easily do things like testing encryption with different types of (key) files and do a bitmapped visual data analysis (see picture attached). NON OTP encryption with a GnuPG public key has 52 times more compressed data spectrum than FinalCrypt and even 1.6 times more data compression than the original. It almost looks like an obscured compression format. I must admit that AES-256-CBC encryption had a similar data spectrum to FinalCrypt's OTP encryption (and yes i did use an OTP key as big as the original (bmp image) file). I can imagine if you have a small key then the data spectrum will also be smaller, unless you would use very CPU costly multi-round encryption like AES does, which makes it much slower, which isn't necessary with OTP encryption.
GnuPG has 11 different algos to choose from, 7 hash functions and four options of compression. (Including: none) I assume you used standard settings? What are they? Say it in comparisons. https://en.wikipedia.org/wiki/GNU_Privacy_Guard Not like you have an option. And this is an issue... why? As I said above, in GnuPG you can choose from three compression algos or save it uncompressed. I guess you didn't chose uncompressed. Remember: You are not promoting a program that has the option of different ecryption algos. So you HAVE to compare to other algos and not to other programs. Logically.
The main purpose was to demonstrate what you can do with FinalCrypt's Non MAC (RAW) Mode, but apart from that you are right and i admit i was impressed with AES-256-CBC's data spectrum coming off such a small AES key, except for it's "multi-round" performance decrease disadvantage to achieve such a wide data spectrum / wide spread random noise generation.
I am taking a step back, reflecting and spectating over what I did and what I do, and I found that I was rude and condescending towards you. I am sorry for that. I know how it feels when people don't acknowledge what you accomplished. This was not my intention. Please, forgive me. I feel at some point I lost a connection. There's always a person on the other side of the screen. I tend to forget that and hurtle logic at people, stepping on feelings. I beg you to also take a step back once and to do the same. Reflect about your ingrown opinions about AES and other typical crypto. See your creation from an outside point-of-view. What it is to us and why. Why we think AES is fine and what the laws of physic have to do with it. This way you may understand us better. Anyway. I wanted to ask if that image comparison is a function of your program or if not, how you did it. I came up with the PGM format, but it's only for greyscale images. What else is true binary?
That's okay @__Nikopol. It wasn't rude enough for forgiveness, but indeed it was a bit personal, but that can happen when you can't get through to someone and frustration takes over. We all get emotional sometimes, which also demonstrates how important things are to us. When someone is right then someone is right and i respect that. You were right with most of your (logical) observations. In all honesty I don't trust asymmetric cryptography, as keys are recognisable and therefor collectable by big brother and besides that some other suspicions come to mind against the design of asymmetric cryptography, yet I don't think symmetric cryptography is perfect either. I don't mind being called a conspiracy theorist after having seen some undeniable documentaries on civil intelligence collaborations worldwide on PRISM, Bullrun, Xkeyscore etc. Of course i do understand it's for the war on terror, but governments also abuse their privacy invasion powers for capitalistic purposes also causing many suicidal deaths swiped under the rug. About FinalCrypt's Disabled MAC Mode... I copied a BMP image and encrypted the copy (with FinalCrypt's Non MAC Mode) and after encrypting it, restoring it's original 56 bytes metadata header (from the original image into the encrypted image) and called it mypicture.bmp.bit.bmp. Then it will simply be shown by your default BMP imageviewer. With GIMP you can do a histogram and some other analysis on it. FinalCrypt's Non MAC Mode (RAW / Legacy Mode) button is positioned at the lower right part of the interface and has to be enabled first with a double click, before it can then be toggled on to: "Disabled MAC Mode". This is just to protect regular users from accidentally enabling disabled MAC Mode. One more click takes it out of disabled MAC Mode and locks / disables the button again. Restoring the BMP metadata header to an encrypted bmp file is simply done as follows (on Linux): dd if=mypicture_copy.bmp of=mypicture.bmp.bit bs=54 count=1 conv=notrunc FinalCrypt has a command line interface too, which is even more flexible than the GUI and you can automate the whole process (on Linux): Code: cp mypicture.bmp mypicture_copy.bmp # Just making sure you have a copy of the original before it is encrypted java -cp FinalCrypt.jar rdj.CLUI --create-keyfile -K mykeyfile.dat -S $((1024**2*100)) # Create 100 MiB OTP key file. Also interesting is using another image as your encryption key in FinalCrypt java -cp FinalCrypt.jar rdj.CLUI --disable-MAC --encrypt -k mykeyfile.dat -t mypicture.bmp # Encrypt the image. Normally you would NOT use --disable-MAC dd if=mypicture_copy.bmp of=mypicture.bmp.bit bs=54 count=1 conv=notrunc # Restoring the original BMP metadata header mv mypicture.bmp.bit mypicture.bmp.bit.bmp gimp mypicture.bmp.bit.bmp # Opening image with the GIMP # Decrypting wouldn't be necessary for the purpose of this experiment, but would go as follows: Code: mv mypicture.bmp.bit.bmp mypicture.bmp.bit # Non MAC Mode just swaps extensions with every encryption round, unlike MAC Mode which controllable adds the .bit in --encrypt mode en removes the .bit in --decrypt mode java -cp FinalCrypt.jar rdj.CLUI --disable-MAC --encrypt -k mykeyfile.dat -t mypicture.bmp.bit # Encrypt (actually) decrypt the image, but in NON MAC Mode there is no way FinalCrypt can know the target is already encrypted. Normally you would use --decrypt in the default MAC Mode dd if=mypicture_copy.bmp of=mypicture.bmp bs=54 count=1 conv=notrunc # Restoring the original BMP metadata header and the original picture is restored again. I tested the above script successfully. You can also download the jar file and rename it from FinalCrypt_Z.jar to FinalCrypt.jar for convenience. Using the jar package, make sure you install a downloaded jre/jdk or higher from java.com and make a symlink like: Code: sudo rm /usr/bin/java; sudo /home/ron/jdk1.8.0_171/bin/java /usr/bin/ You can even use the bytecode version that comes with the "native" FinalCrypt package, which is just here: /opt/FinalCrypt/app/FinalCrypt.jar The FinalCrypt (GUI) Log will also tell you where it is installed. Lots of ways to Rome.
This is cool, but is it a good representation of any cryptographically important feature? I played around with it. It's fun to make pictures using the inherent flaw of the crypto. Source images either used as file-to-encrypt or as key-file: Combinations (See filename): Combining Rainbow either with Stripes or with Black creates the same, simply inverted image for some reason:
With an actual picture: (CC-BY-NC-ND by me) Combinations (Again see filename): And again using Stripes or Black just inverts the picture for some reason. EDIT: Of course, using actual random data, we get a random picture:
After using it for a while here are some thoughts about the program: - It is 193 MB on the disk. WHY?!?! Because Java is bad. It could easily be a 5 MB single exe without installation. - The GUI is OK in design, but bad in responsiveness (Probably Javas fault) and visual appeal. Also the changes I do to the columns in the file explorer are not saved and after every encryption reset. That's annoying. - No warning about using unsafe key files, like I did. It should be very bright, flashy and big. may add more later
Interesting results, such visual results is what fascinated me too about the Non MAC Mode. A long time ago I decided I wanted to invest in solely cross platform programming as writing / porting it to different platforms is a daunting task. Further I don't like the file manager panes (old Java JFileChooser Swing objects) either and that will change soon being replaced by the newer JavaFX FileChooser objects, simplifying the interface with a tiny bit more abstraction and some 3D animations. The FinalCrypt jar file (requires a separate JVM) is only about 300 KB. In terms of responsiveness perhaps there is a thing or two I can do to improve. Non the less FinalCrypt does authenticate all files in it's target, regardless whether target select represents 100,000 files hidden in sub-directories. This is why step 1 is selecting the target first and then the key as only then the recursive inventory commences. I'm using SSD drives so I'm not really experiencing unresponsiveness. About key usage, FinalCrypt will increasingly urge users to use OTP keys and maybe come up with a random quality testing feature, but that's for a little later perhaps. I appreciate you giving FinalCrypt a test-spin and some valuable feedback. Thanks Nikopol.
Forgot to mention... trying to use a keyfile with byte values hollding 0's (or 0,0,0 bytes in a key file that actually is a bitmap image) would not have any 1 bits in the keyfile bytes to XOR the corresponding data bytes being encrypted, which would mean no encryption at all, which is why i invert the key byte (from 0 to 255). So litterally with FinalCrypt there can't be no encryption, even if the key contains bytes holding 0 values. Better to invert the key bytes (and therefor also the corresponding data bytes) than no encryption at all.
How to encrypt files with FinalCrypt If you're looking for an encryption tool that offers a unique approach and a well-designed GUI, FinalCrypt might be just the tool March 21, 2019 https://www.techrepublic.com/article/how-to-encrypt-files-with-finalcrypt/
Thank you Mood. http://www.finalcrypt.org/ v4.0.3 now includes Voice Guidance and a Star Trek Sound Scheme.
Created a Cyber Security News Page https://www.finalcrypt.org/news.php Many changes happened after v5.0.0 But Mood's links (above) are sufficient
On 3 February 2025 FinalCrypt was security audited by ChatGPT AI Security Analyst. Read the FinalCrypt Security Whitepaper here: HTML / https://www.finalcrypt.org/finalcrypt_security_whitepaper.pdf
