What is the best way to encrypt a value in INI file?
Using Encryption/Decryption key??
For what purpose? Security?
If you are trying to (e.g.) encrypt a plaintext password you should probably use some implementation of PKI. Remember though, that then key management becomes your problem. Just encrypting the value is not a panacea because the ini file is most likely on the local host's file system, presumably the same place you'll have to store your key pair. You've simply abstracted the problem down a layer. They won't be able to read your encrypted password directly, but if they can find the place you store your key pair they can decrypt it themselves.
To what effect? What are you trying to protect or obfuscate?
You could use one of the many two-way key encryption algorithms available for all platforms... But ask yourself why you're doing it in the first place. If you're trying to make something hack-proof, encrypting ini strings probably isn't going to get you that far because as soon as you decrypt the ini, the string is in memory. And the key to decrypt will be in your program. Childsplay to hack out.
If you just want to stop people editing a setting easily, don't put it in an ini. Choose a binary format that the user will have a hard time editing.
For personal scripts where I have an email password, I use
TinyEncryption.
I will put the passkey in the code itself. This prevents a casual snooper from just browsing through and picking up an email password.
The code is pretty simple too. Here it is in Python.
import random
import base64
def tinycode(key, text, reverse=False):
"(de)crypt stuff"
rand = random.Random(key).randrange
if reverse:
text = base64.b64decode(text)
text = ''.join([chr(ord(elem)^rand(256)) for elem in text])
if not reverse:
text = base64.b64encode(text)
return text
For more enhanced security, I use PGP, but you then have to prompt for a passkey. There's no setup that's perfect, it depends on what your needs are.
You could use any standard encryption algorithm with a key, and perhaps prefix the value with some random padding before encrypting.
However where do you plan to store that key then? Or are you going to get the user to enter a password and derive a key from that? If not then it would be fairly pointless to encrypt the value.
Do you need to decrypt it too? If not you can just salt and hash it.
If you do want to decrypt it, then Id say you should specify the language as well perhaps.
MD5 hash
Then you compare hash("password") with the ini_file.password hash
Related
Using PHP mcrypt_encrypt, text 'I am secret text' using tripledes, key 'xICbEwgvNMv7yyXIB4xbRUXxaGf4wnpP', Mode CBC, NoPadding, Base64, IV 'MDAwMA=='.
result:7lctMAo8uH/XRlbD82Yjclg2AT4EoR9+
-- or you can use any online tool to encrypt using these settings
Using CF encrypt, text 'I am secret text' using tripledes (DESEDE), key 'xICbEwgvNMv7yyXIB4xbRUXxaGf4wnpP', Mode ECB, NoPadding, Base64.
encrypt( 'I am secret text','xICbEwgvNMv7yyXIB4xbRUXxaGf4wnpP','DESEDE/CBC/NoPadding', 'Base64', ToBase64('0000'))
result: 1K1LPndpIEVLL6cNBMxCXw==
The result from CF seems will never match the output form another tool. Resulting in never being able to use CF decrypt on encrypted data sent to CF for processing. I have tried various combinations and algorithms.
why you ask do i want to do this?
Someone that is sending us sensitive information decided they want it extra secure.
Yes communicating over https.
The text is within a json file.
No, I do not feel like creating our own or using a third party tool to encrypt/decrypt on each of or ends.
Using encrypted text sent from outside CF within decrypt function over and over and over and over again with various algorithms and modes.
Using basic AES we often get message of "Given final block not properly padded. Such issues can arise if a bad key is used during decryption." when trying to decrypt.
Yes we are using same key and modes, etc., on both ends.
I am completely flexible on the algorithm and mode. I would just love to see one of them work.
Thanks #Topaco
using ToBase64() around the key solved the issue.
Decrypt( encryptedMsg, ToBase64(key), "AES/ECB/PKCS7Padding", 'Hex')
I'm trying to figure something out. I have a legacy system in place and I'm not using all of it. There are business reasons why we use things this way.
Some fields in the system get encrypted by a piece of middleware that I ultimately would like to replace. I can't replace this part of the system because I can't decrypt the values properly.
For example I have a field that contains the word:
ferret
This is encrypted and becomes:
^ADFJBLFOHLOJFNHHKFJLHFJNPCJFJCPFBAPEKDKM
The words
wellington boot
becomes
^KOKFDEJPAAPFJHPOIGOICOAHKFLNFHMIOJNHAAHF
I can see the unencrypted data and I can see the resulting encrypted data but I am trying to find what algorithm was used to turn the field value into the encrypted versions. The main reason for this is that I have a requirement to massively increase the number of fields that contain the encrypted data but at the moment I can't because I cannot replace the existing encryption mechanism because I don't know what was used to encrypt the data.
There is simply too much data in the system to go through and load up each record and make a note of the unecrypted data so I can make a new encryption mechanism.
If I knew how the existing data was encrypted I could use the same method to encrypt my new fields. The system encrypts certain fields only and my extension to the system needs to encrypt others using the same method.
How can I do this? Is it even possible to find out how the data was encrypted and what method was used?
It is SHA1, translated into A for 0, B for 1, C for 2, etc. For example, your "wellington boot" example has the SHA1 hash of "aea5349f00f..." which is clearly "KOKFDEJPAAP..."
So you can just use SHA1 and do the same translation to continue the pattern.
To check this, try the phrase "test phrase" - the SHA1 of this is "ab8f37d89b1154ba18c78a7e4b8eef2acdfec1eb", which becomes "KLIPDHNIJL..." in your system.
I need to save the password to database.I get confused in encryption,hash using sha-256 ,salt generation method .If any one explains the basic concept behind this then it will be helpful
The follow is a very basic explanation, anyway...
Encryption is a reversible method to crypt the data. So if you have "password" a encryption method convert it into (for example) "ufmehlejw" and then you are able to get again "password".
An hash function (one of them is the sha-256) is a function that once it's used on a string you have no way to recover the original string.
A salt is a string which usually prorammers (and not only, of course) use to mix the given password. It's usually randomly generated. A salt is used to extend the original data before using an hash function. The goal of the salt is to avoid attackers to discover the original password of a user from a stolen hash using rainbow tables.
In short:
Encryption is a process with an inverse. In other words: If I encrypt some text, there is a process which is able to convert the new text back to the original, called decryption.
Hashing is fundamentally different from encryption, because it does not have such a process. What a hash is meant to do is provide you with a result, which is unique for that given input text (well, almost unique, let's keep it at unique). This way, people can verify if two input texts were equal, without knowing what the actual input text was. So, if people get their hands on your hashed password, they still cannot decrypt it. SHA is a family of methods which provide hashing.
Salts and Peppers are merely additional techniques to hashing, which describe the process of adding something before and after the input text before hashing. This improves the difficulty of brute-force cracking of hashes back to text.
Brute force cracking means simply trying all possible inputs (aa, ab, ac, etc...) and see if you can generate a hash which matches the hash you have gotten via hacking some website or whatever. You can find more on that here: https://security.stackexchange.com/questions/3272/password-hashing-add-salt-pepper-or-is-salt-enough
I'm learning to do proper crytographic implementations, and I thought as an exercise I would create an encrypted text editor.
My first attempt used a SHA-512 hash of a user-provided password as the key, and it functioned just fine. Though I was storing the IV in the header of the file, unprotected and that had me worried.
Then I read on stackoverflow that I should be using SecretKeyFactory (I'm using Java) to do PBE, and now I additionally need to provide a salt. So now I'm storing the salt in the header as well, but that would seem to ruin the whole purpose of having a salt. So how is this supposed to work? When I have Alice pick a password for her file when she saves, am I supposed to say "Here, memorize this random number along with your password."? I would like for the resulting file to be able to be e-mailed to Bob, so the salt can't be stored locally.
As my app stands, the IV and salt are out in the open. I would like for my user to only have to know the password when they send their file to Bob while remaining cryptographically secure, but I can't find any examples of how this is done.
Thanks for any help!
It is safe to store an IV along with the data, that is how IVs are used. Your method is ok, pick a block cipher, use cipher block chaining and an IV, and you're away.
There are many ways to create a key and iv from a passphrase, but one of the more common ones involves HMAC with SHA-1, in an algorithm that takes some salt and other things into account, to build a sufficiently bit-mixed key and iv.
The technical standard is the PKCS#5 v2.0 PBKDF2 algorithm, to which OpenSSL implements a C interface to a method that can do this, but as far as I know, no command line method.
After studying CryptoChefs homepage about "fullbit encryption" (Vollbit Verschlüsselung), I just wondered if there has already been an analysis on how this algorithm works.
I believe he just xors some file with another file, maybe multiple times, but maybe someone still knows what he really does.
I think its no that easy as chefin says, because he claims it works with a passphrase to generate the keyfile.
So, if the software exists, it will be flawed, because a keyfile for XOR generated by a passphrase will contain redundancies. just think of the easiest way to generate a keyfile from a password:
passwordpasswordpassword
Now you can just split the ciphertext in three blocks (each with the length of the password) and XOR two of them together to get the password.
Of course, there are more sophisticated algorithms for generating keyfiles from a password, but none of them will have the OTP-Feature of "nobody can decrypt it without the pad", because the pad depends on the passphrase and cannot have more entropy than the passphrase itself.
Sorry, but it works "perfect". But thats normal, as he only create a onetimepad encryption. If you use random numbers (and thats why he speak about 256bit key) and generate a file as big as the file you want to encrypt, simple xor multiple times is enough.
But this is old and everyone know it is not usefull. How do you store a 2Mbyte File you need to decrypt your 2Mbyte Dokument. Use a Stick? Why not put the file on the stick itself? It is just a little harder for decrypting, as you need 2 components you have to find first.