i am generating *.reg file using code which will have some important data. and user will save this into registry.
upon application launch i am getting the values from registry and performing some validation..
but the problem is that in registry and in *.reg file the information are stored in plain text.
how can i create encrypted *.reg file first.
then in application start. how to decrypt the value(encrypted) from registry..
i read some articles. but they are related to encryption/decryption of file.
here i am working with "*.reg" file and Registry itself
If your program is the only one that is reading the values from the registry you can save them encrypted and decrypt them on every use.
This way the exported .reg file is going to contain encrypted data too.
If there are other programs using the data you must ensure they can access and understand the information they need.
Sorry Mohsan, that's the wrong way. d. showed the right way.
Just imagine if you encrypt a .reg file. What should happen afterwards?? You'll like to import it into the registry, but before you can you have to decrypt it and so just plain text comes into registry which can be read be everyone.
So don't encrypt your key or value names. Encrypt the content of your values within the registry. So your program can read it in, decrypt it and work with it. Here is an example:
[HKLM\Key\SubKey\SubSubKey\etc]
#=""
"Password"="KALSDJLSIWNKLDNISNDLKWDNLAW"
So you program opens the key, reads the value and computes the decrypt algorithm on that value, resolving it to: 'My Secret Password'
What's the point? Anyone can just use a tool like Regmon to find out what values you set anyway.
You should instead just encrypt the values and decrypt them when your application reads them (that is assuming your app the only one accessing that data). Keep in mind, though, that you'd have to store the decryption key somewhere in your executable which opens up a whole other can of worms.
You wont be able to transparently encrypt the registry.
I would look at either public/private key or symmetric key encryption methods.
Here is a quick project to use RSA:
http://www.codeproject.com/KB/security/RSACryptoPad.aspx
Storing your keys in a resource is probably the best way to protect the contents, but be warned: If you store both the Key and the Cyphertext on the same system (eg, in your program and in the registry) there is no way to fully prevent the owner of the system from reading the Plaintext.
Related
Is there a way to sign binary files? I'd like to sign my zip files to protect them from modification (to prevent installation of malicious software).
Signing XML is rather easy, but I'm not so sure about binary files. Is this even possible? All I can find about that matter is code signing (which is not what I want). There is no use in buying expensive certificates, it's just to ensure that update files aren't modified when they get installed.
I figure I have to work like that: Hashing the file, generating a key pair (probably using the hash for it) and then append the signature bytes to the file.
Vice versa, reading the signature bytes and verifying the hash against the public key of the signature.
But I don't think it's that simple. Do I have to consider certain things (like with XML that you need to canonicalize)?
I do not necessarily need code, but some detailed explanation about the process (any resources that explain that thoroughly would be okay as well).
When working with arbitrary binary files you can't modify their content so if you want to sign them you need to use a separate external file that contains the hash of the file you want to sign and also signs itself to prevent itself from being modified.
You then read this separate file, verify its personal signature, then verify the hash of each file it lists in its contents. You can use Catalog Files built in to windows (using MakeCat and SignTool to create them) or create your own following the same process.
Because you are only distributing updates, and if you are allowed to assume that the program loading the updates has not been modified, you don't need to "buy" a certificate. You could create your own "private CA", distribute that CA's certificate inside the updater, then use that Private CA's certificate to validate the catalog file.
I'm not sure what you mean as "binary file", but if you talk about PE format (Windows binary executable) you can generate own signature (encrypted hash) and put it inside of PE file in the same place as Windows authenticode certificate goes. Here is an open source tool to make such modifications:
http://blog.didierstevens.com/programs/disitool/
I create my file using File.WriteAllBytes(). Byte[] that is passed to File.WriteAllBytes() is encrypted by algorithm of my own. You need password that was used when file was encrypted (user of the program knows the password) to decrypt it. But when some file is opened by my program using File.ReadAllBytes() there are 3 situations:
File that is being opened is my program's file and user knows the password to open it.
File that is being opened is my program's file but user doesn't know the password to open it.
File that is being opened is not my program's file.
First one is easy to handle. 2nd and 3rd are same for my program because my program doesn't know the difference between encrypted byte[] and byte[] of some random file.
How do I differ these situations? I was thinking of adding some sequence of bytes to the end or beginning of byte[] before passing it to File.WriteAllBytes(). Is that safe? How do modern programs differ their files from other files?
You can give your file some structure before encryption, and check that the structure is there after decryption. If the structure is not there, it's not your file.
For example, you could compute a check sum, and store it in the first few bytes prior to the "payload" block of data. Encrypt the check sum along with the rest of the file.
When you decrypt, take the payload content, and compute its check sum again. Compare the stored result to the computed result to see if the two match. If they don't match, it's not your file. If they do match, very good chances are that it is your file.
This is not the only approach - the structure could be anything you wish, from placing a special sequence of bytes at a specific place to using a specific strict format (e.g. an XML) for your content, and then validating this format after the decryption.
[the file is] encrypted by algorithm of my own.
Be very careful with security through obscurity: coming up with an algorithm that is cryptographically secure is an extremely hard task.
Many many file format use "Magic numbers" in front of the file to determine their types. Use the first ... 4 bytes, write a custom sequence it it then read it when you load the file.
I have an application, its Name and Logo can changed directly from a TXT and a PNG file in the same directory.
I want to give the user the ability to change the Logo and Text File from another application that does the following :
Takes the Logo.png , Name.txt file paths and the directory of my Software then encrypt these two files and put them in the Directory of the Software
In the other hand. The software will Decrypt these two files and write them to Hard Disk to temp directory then use them to display the name and the logo.
I searched for the simplest and easiest way to encrypt a file and i found :
From the MSDN :
File.Encrypt():
Encrypts a file so that only the account used to encrypt the file can decrypt it.
Could someone please tell me what does it mean "only the account used to encrypt a file can decrypt it"
What about encrypting the application from Computer1 by Application1 then the file will be decrypted by Computer2 in Application2
Will the encryption work correctly ?
Edit:The purpose why I need to encrypt these two files is to avoid users from directly change the Logo and the Name of Application from the directory
This will encrypt the file, but not as you expect - and almost certainly not such that it can be decrypted by another application/user on a different computer.
The Encrypt method basically just toggles a feature of the underlying NTFS driver to encrypt the specified file on the file system itself. The nice feature is that it (typically) provides seamless file encryption for the user, but it isn't really portable encryption. It is the same as opening the file properties, clicking the advanced button and selecting the "Encrypt" checkbox.
More information on the encrypting feature of NTFS can be be found here: http://technet.microsoft.com/en-us/library/bb457116.aspx
No. You should use a proper encryption method such as those in System.Security.Cryptography namespace. There is a stream implementation for this, too, called CryptoStream, which you may wrap a FileStream with for encrypting files with.
This is related to Windows' EFS.
You can try it from Windows Explorer by right-clicking on the file, Properties, Advanced, Encrypt contents. The file data is automatically decrypted/encrypted on the fly as your app accesses it. But if another user logs in the machine and copies the file it will appear encrypted since the encryption is based on a user token.
This is may or may not be what you want and that depends on your intended use of that feature. If you don't want the user to be able to modify the data outside your app it won't be enough.
how can we encrypt an executeable file using c# and make that encrypted file still executeable without using extra file for decryption?
mean the decryption methods shuold be inside file.
how can i write something like that with c# language?
thanks in adavance
Storing encrypted data on clients machine and having it decrypt automatically means that you will have to store decryption key on that machine as well. This means that you can't effectively protect data and provide it to user. Such encryption is only used to slow down user from tampering with the data as time is needed to recover decryption key and algorithm.
If you want to encrypt code of the executable itself, to prevent user from tampering with it, this is a very very complex topic. It's only matter of persistence and time. You will not get an answer to such question in one StackOverflow post. You'll have to study PE and .NET file formats, operating system internals regarding executable loader as well as mscor*.
If you need to store some data
choose some encryption algorithm and encrypt your data into a file (see this question)
add encrypted file to your c# project as embedded resourse
in runtime access this file (see this question) and decrypt it (already discussed in first point)
For privacy reasons, I want to prevent my users from posting unencrypted files to my ftp site.
It is company policy that all data exchanges of sensitive data be encrypted with PGP.
I'd like to setup a program to monitor the ftp folders and whenever a new file is placed there, verify that it is in fact encrypted.
I can't just rely on the file extension because in some cases, our trading partners require a specific filename that doesn't have a .PGP on the end.
Is there a library or another method I can use to verify that a given file is encrypted?
I'm using C# and .NET on a windows platform.
You can easily detect the text mode PGP files. They start with
-----BEGIN PGP MESSAGE-----
Version: GnuPG v2.0.11 (GNU/Linux)
and end with
-----END PGP MESSAGE-----
This is of course not a sure way but good enough to prevent accidental unencrypted uploads.
I have do idea how the binary format looks like. You can try using "gpg -d " with an empty password and if it fails with "decrypt_message failed" then it is not a correct file. If it fails with bad key it is a PGP file. This is not a really good idea because the messages can change in the future.
You have to come with an heuristic approach to knowing if the file is encrypted or not. Usually, encrypted files tend to have a near random distribution of bytes. So if you read the stream of bytes, and bucket-count each byte, the distribution should be even, ie, there should be nearly as many 00h as AAh or FFh or 78h or etc (two hex values represent a byte) for each encrypted files.
Bad news is almost all compressed files (jpg, mp3, zip,...) also have this pattern of random bytes. Also, being an heuristical test, some encrypted files will fail, and some unencrypted files will be approved.