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')
Related
I have some encrypted data, which is encrypted using rc2-64-cbc NO PADDING. I am able to decrypt fine.
The issue : Even if the encrypted content is encrypted with wrong key my decryption doesn't error out, instead it decrypts to some garbage value, as its rc2 and no padding I believe.
I tried from openssl Linux command prompt and my C/C++ program(using EVP_* API calls).
Is there any openssl option/way to detect this the wrong key used ? ( command line or EVP_* C/C++ API calls)
Unless some form of authentication was added to the encrypted data there is no way to know for certain. The best is to look for decrypted that "makes sense", the decrypted data will either be correct or appear as a sequence of bytes that can not be distinguished from random bytes.
Assuming no authentication was added to the message possible methods include:
There is some know correct bytes at a known location in the message, this is known as a crib, an example is in WWII German weather reports began with predictable text.
Make a test of the randomness.
If the data is text check for invalid characters such as 0x00 - 0x1f.
Think of other tests that apply to your data.
You can take the plain text, calculate the checksum and then encrypt both. Once you decrypt the cipher text (even with a wrong key), try calculating the checksum again for the deciphered text and I am sure it will fail.
I have a tcl/tk based tool, which uses network password for authentication. Issue is that, it is saving password in the logs/history. So objective is to encrypt the password.
I tried to use aes package. But at the very beginning aes::init asks for keydata and initialization vector (16 byte). So how to generate IV and keydata. Is is some Random number? I am a novice in encryption algorithms.
If you have the password in the logs/history, why not fix the bug of logging/storing it in the first place?
Otherwise there are distinct things you might want:
A password hashing scheme like PBKDF2, bcrypt, argon2 etc. to store a password in a safe way and compare some user input to it. This is typically the case when you need to implement some kind of authentication with passwords on the server side.
A password encryption and protection scheme like AES. You need a password to authenticate to some service automatically, and it requires some form of cleartext password.
You have some secret data and need to securly store it to in non cleartext form.
If you have case 1, don't use the aespackage, it is the wrong tool for the job. If you have case 2, the aes package might help you, but you just exchanged the problem of keeping the password secret with the other problem of keeping the key secret (not a huge win). So the only viable case where aes is an option might be 3.
Lets assume you need to store some secret data in a reversible way, e.g. case 3 from above.
AES has a few possible modes of operation, common ones you might see are ECB, CBC, OFB, GCM, CTR. The Tcllib package just supports ECB and CBC, and only CBC (which is the default) is really an option to use.
Visit Wikipedia for an example why you should never use ECB mode.
Now back to your actual question:
Initialization Vector (IV)
This is a random value you pick for each encryption, it is not secret, you can just publish it together with the encrypted data. Picking a random IV helps to make two encrypted blocks differ, even if you use the same key and cleartext.
Secret Key
This is also a random value, but you must keep it secret, as it can be used for encryption and decryption. You often have the same key for multiple encryptions.
Where to get good randomness?
If you are on Linux, BSD or other unixoid systems just read bytes from /dev/urandom or use a wrapper for getrandom(). Do NOT use Tcls expr {rand()} or similar pseudorandom number generators (PRNG). On Windows TWAPI and the CryptGenRandom function would be the best idea, but sadly there is no Tcl high level wrapper included.
Is that enough?
Depends. If you just want to hide a bit of plaintext from cursory looks, maybe. If you have attackers manipulating your data or actively trying to hack your system, less so. Plain AES-CBC has a lot of things you can do wrong, and even experts did wrong (read about SSL/TLS 1.0 problems with AES-CBC).
Final words: If you are a novice in encryption algorithms, be sure you understand what you want and need to protect, there are a lot of pitfalls.
If I read the Tcler's Wiki page on aes, I see that I encrypt by doing this:
package require aes
set plaintext "Some super-secret bytes!"
set key "abcd1234dcba4321"; # 16 bytes
set encrypted [aes::aes -dir encrypt -key $key $plaintext]
and I decrypt by doing:
# Assuming the code above was run...
set decrypted [aes::aes -dir decrypt -key $key $encrypted]
Note that the decrypted text has NUL (zero) bytes added on the end (8 of them in this example) because the encryption algorithm always works on blocks of 16 bytes, and if you're working with non-ASCII text then encoding convertto and encoding convertfrom might be necessary.
You don't need to use aes::init directly unless you are doing large-scale streaming encryption. Your use case doesn't sound like it needs that sort of thing. (The key data is your “secret”, and the initialisation vector is something standardised that usually you don't need to set.)
Right now, this is what I am doing:
1. SHA-1 a password like "pass123", use the first 32 characters of the hexadecimal decoding for the key
2. Encrypt with AES-256 with just whatever the default parameters are
^Is that secure enough?
I need my application to encrypt data with a password, and securely. There are too many different things that come up when I google this and some things that I don't understand about it too. I am asking this as a general question, not any specific coding language (though I'm planning on using this with Java and with iOS).
So now that I am trying to do this more properly, please follow what I have in mind:
Input is a password such as "pass123" and the data is
what I want to encrypt such as "The bank account is 038414838 and the pin is 5931"
Use PBKDF2 to derive a key from the password. Parameters:
1000 iterations
length of 256bits
Salt - this one confuses me because I am not sure where to get the salt from, do I just make one up? As in, all my encryptions would always use the salt "F" for example (since apparently salts are 8bits which is just one character)
Now I take this key, and do I hash it?? Should I use something like SHA-256? Is that secure? And what is HMAC? Should I use that?
Note: Do I need to perform both steps 2 and 3 or is just one or the other okay?
Okay now I have the 256-bit key to do the encryption with. So I perform the encryption using AES, but here's yet another confusing part (the parameters).
I'm not really sure what are the different "modes" to use, apparently there's like CBC and EBC and a bunch of others
I also am not sure about the "Initialization Vector," do I just make one up and always use that one?
And then what about other options, what is PKCS7Padding?
For your initial points:
Using hexadecimals clearly splits the key size in half. Basically, you are using AES-128 security wise. Not that that is bad, but you might also go for AES-128 and use 16 bytes.
SHA-1 is relatively safe for key derivation, but it shouldn't be used directly because of the existence/creation of rainbow tables. For this you need a function like PBKDF2 which uses an iteration count and salt.
As for the solution:
You should not encrypt PIN's if that can be avoided. Please make sure your passwords are safe enough, allow pass phrases.
Create a random number per password and save the salt (16 bytes) with the output of PBKDF2. The salt does not have to be secret, although you might want to include a system secret to add some extra security. The salt and password are hashed, so they may have any length to be compatible with PBKDF2.
No, you just save the secret generated by the PBKDF2, let the PBKDF2 generate more data when required.
Never use ECB (not EBC). Use CBC as minimum. Note that CBC encryption does not provide integrity checking (somebody might change the cipher text and you might never know it) or authenticity. For that, you might want to add an additional MAC, HMAC or use an encryption mode such as GCM. PKCS7Padding (identical to PKCS5Padding in most occurences) is a simple method of adding bogus data to get N * [blocksize] bytes, required by block wise encryption.
Don't forget to prepend a (random) IV to your cipher text in case you reuse your encryption keys. An IV is similar to a salt, but should be exactly [blocksize] bytes (16 for AES).
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.
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