I am using RNCryptor to encrypt/decrypt (AES256) files for an Objective C project.
I would like my app to ask for a password if the chosen file is encrypted (say, with AES256) or to open it directly if it isn't. Is there a way of recognizing if a given file is encrypted?
Related
I am doing this small university project, where I have to create a console-based text editor with some features, and making files password protected is one of them. As I said, it's a university project for an introductory OOP course, so it doesn't need to be the most secure thing on planet. I am planning to use a simple Caesar cipher to encrypt my file.
The only problem is the password. I'll use the password as the encryption key and it will work, but the problem is handling the case where the password is wrong. If no checks are placed then it would just show gibberish, but I want to make it so that it displays a message in case of a wrong password.
The idea I have come up with is to somehow store the hash of the unencrypted file in that text file (but it shouldn't show that hash when I open the file up with notepad) and after decrypting with the provided password, I can just hash the contents and check if it matches with the hidden hash stored in that file. Is it possible?
I am using Windows, by the way, and portability is not an issue.
In general, you can't theoretically design a data format where nothing but plain text is a valid subset of it, but there can also be metadata (hash or something else). Just think about it: how do you store something other than text (i. e. metadata) in a file where every single byte is to be interpreted as text?
That said, there are some tricks to hide the metadata in plain sight. With Unicode, the palette of tricks is wider. For example, you can use spacelike characters to encode metadata or indicate metadata presence in the way that the user won't notice. Consider Unicode BOM. It's the "zero-length space" character. Won't be seen in Notepad, serves as metadata. You could so something similar.
They already mentioned alternative data streams. While one of those could work to keep the metadata, an alternative data stream doesn't survive archival, e-mailing, uploading to Google Drive/OneDrive/Dropbox, copying with a program that is not aware of it, or copying to a filesystem that doesn't support it (e. g. a CD or a flash drive with FAT).
Using fstream, what file type would you recommend that I can read and write to for save files? I'm attempting to make a program where the user enters a username and a password and it'll output it to a file. I'd like a filetype that isn't very easy for the user to edit. (so not a .txt or .ini)
Thanks in advance
fstream doesn't really have a sense of a "file format" outside of being in text mode vs pure binary mode (there are some nuances with newlines for example). You would typically use some sort of intermediate library to generate or directly write XML files, JSON files, INI files, etc. SQLite is a popular library/format to store database tables in a file. Mozilla Firefox uses it for their bookmarks and history for example.
What you're talking about is security through obscurity. By using using some sort of encoding, perhaps ultimately binary so it wouldn't even be printable at all without a hex editor, it would obscure things a bit. If you used encryption it wouldn't be readable until decrypted, but you could always reverse engineer the program to determine the encryption/decryption keys and algorithms.
The most secure option is to not store the password at all, but a hash of the password. This means that even with reverse engineering the program, you wouldn't be able to directly extract the stored password. Instead, whenever the user attempted to enter a password, it would compare use the same hashing algorithm and compare the results.
This doesn't always work though, because sometimes you are storing the password to submit to a 3rd party, in which case you do have to ultimately recover the stored password into plaintext for transmitting to the 3rd party.
I hope this gives you some ideas!
I am new to the security stuff. Is there any way to encrypt and decrypt a security key with the same encryption key?
The real use case is:
Got a security key (32-char), need to hard-coded it into C++ code. But I don't want to have it plain text in C++.
So I choose a password (like 8-char long), pass this to a hash function, like SHA2 and get a 128 bytes hash.
Encrypt the 128 bytes hash with my security key, and save that output encrypted string to C++ code.
When use using the application:
Prompt for password (8-char).
My application take the password and generate the hash through SHA2
Decrypt the encrypted string with the SHA2 hash to get the original security key (32-char).
Since the design has to put the security code in C++, we wanted to find out a way to secure it. With the above mechanism, we are putting the original code in C++ directly.
Can I put text string (serving as password) and binary data (an image file actually) together and encrypt them and then save into new a file. To view the image, first, check if password matches, if yes, read the binary data and save as image. I have to use C++.
Very new to C++. Is that technically possible? Can someone give me some ideas how to start?
If you want it to be actually secure, use somebody else's implementation of an encryption algorithm. What you're looking for is a symmetric key encryption algorithm, such as AES. You'd use the password to encrypt the image, not save the password, and then the password would decrypt said image.
And, as luck would have it, somebody else asked about using AES to encrypt and decrypt things in C and C++ here.
I'm writing a program that asks the user for a username and password. I also want to be able to save this information if they so choose, but I don't want to have my program create a simple plain text file that anyone can open. How can I have my c++ program write to an encrypted file and be able to access it when the program is launched later?
Try libgcrypt. For this sort of task, the key (generated from the user's password), will have to be entered every time. You don't want to save the key right next to the encrypted data.
You could also try some scripting with pgp or gpg, if you want to tackle it at a higher level.