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.
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 have short messages (<=256bit) that need to be encrypted and published as a (HTTP URL) QR code, along with the public key(s). Because of the QR requirement the result should also stay 256bits long - with the scheme, servername, and base64 encoding the resulting URL already has quite a length, and so the QR becomes "too" big easily.
RSA is out of the question for that key size.
libsodium provides crypto_box functions using ED25519; but for these I need to transport the nonce (24 bytes) as well, and the result is eg. 48 bytes - this makes the QR code already a bit unwieldy.
Furthermore, using one (constant) key pair and another randomly generated per message means the random key needs to be embedded as well, enlarging the result
Using a single key pair doesn't work - If I encrypt with sec1 and pub1, I need to publish exactly these values for decrypting too.
So I'm pondering using plain, raw ED25519 en- and decryption. Are there any pitfalls like with RSA (padding, bad keys (like pub exp 3)) that I need to look out for?
My plan would be to take the input, do an SHA256 of it, use the hash value to pad the input to 256 bits, and then do a plain ED25519 encryption. (I'll prepend a key marker to the result to make key rotation possible.)
What can go wrong? After all, all the complexity in libsodium has to have a reason, right?
Thanks a lot for any help!
i need to write an encrypted text to a file and then subsequently read the file and decrypt the text. i wanted to use authenticated encryption with openssl evp with ccm, but ccm produces a tag which later must be used to decrypt the text.
the question is - how to store this tag and reuse it across file reads in an isolated pc env (no internet)?
i'm new to encryption, but already appending the tag to the encrypted text before writing to the file and then ignoring the tag bytes when decrypting, kinda smells of bad approach. any hints how to solve this? i cannot ask the user to provide a password before writing/reading the text. the environment is not highly security-sensitive
The tag, frankly, is the point of CCM (or GCM). You can
Delay writing to a file until it's calculated, prepend the tag and nonce (on decrypt, read tag, read nonce, decrypt rest).
Write the nonce, then the ciphertext, then the tag. Recover appropriately
Write the nonce and/or tag to a separate file.
Any of the above, but with more structure than concatenation (e.g. a DER SEQUENCE)
If you're using CCM or GCM you MUST use a different nonce every time you use the same key. Failure to do so can lead to key compromise. (And there's no "well, I know that, but it doesn't matter in this case..." because today's intentionally sloppy code is tomorrow's multi-million dollar bug once it gets copied (as a reference example) to another location).
It is quite common to have nonce, ciphertext, and tag (and "additional data") transmitted in the same message, such as in TLS and IPSEC.
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.)
I am Implementing the AES128 bit encryption/Decryption in iOS application for sending/receiving data from .net server, I almost done but during unit testing I got some issue in encryption string, some encrypted string are not similar as on .net server, Can say 98 percent strings are correct at both side but issue comes in 2 percent strings , when I match the both side encrypted string then found at iOS end generated string is little short and .net end it is long string. One more thing i found the iOS string is the substring of .net string. When i tried to decrypt the iOS generated encrypted string, it is not decrypted showing null but when I try to decrypt the .net server generated encrypted string (it was larger than the iOS) I am able to se the decrypted string.
Using the same KEY(16 character long at server and iOS end).
could you please suggest the solution or where I am wrong .
Thanks a lot to all.
Original string: "custId=10&mode=1"
KEY= "PasswordPassword"
at iOS encrypted string:
r51TbJpBLYDkcPC+Ei6Rmg==
at .net encrpted string:
r51TbJpBLYDkcPC+Ei6RmtY2fuzv3RsHzsXt/RpFxAs=
padding for encryption = kCCOptionPKCS7Padding;
I followed this tutorial.
http://automagical.rationalmind.net/2009/02/12/aes-interoperability-between-net-and-iphone/
A similar question found on CryptoSE
My Version TL;DR
Essentially .net and iOS both have different implementations, and since the guide you are following is from 2009 I would expect that it is rather out of date by now given there have been at least 1 major revision bump in each of the platforms since then.
Original Answer Gives the following answer:
I can immediately think of four reasons:
They're both not using AES256. I see in the Obj-C document a direct statement that they are using AES256 (unless you deliberately change it), I don't see any statement in the Visual Basic document that says what key size they're using (unless that's what they mean by "Block Bits").
Different keys. AES256 takes a key of 256 bits; there's no standard method to take a five character string and convert that into a 256 bit value. Now, there are a lot of possible methods; there's no particular assurance that they both use the same one.
Different modes of operation. The AES block cipher takes 128-bit values, and translates that into 128-bit values. However, not all our messages can fit into 128 bits, and in addition, sometimes there are other things we'd like to do other than message encryption. A Mode of Operation is a method that takes a block cipher, and uses it as a tool to perform some more generally useful function (such as encrypting a much longer message). There are a number of standard modes of operations, the Obj-C document states that it is using CBC mode; the Visual Basic document has scary sounding words which might be a garbled explination of CBC mode.
IVs. Some modes of operation (such as CBC mode) have the encryptor select an "Initialization Vector" randomly; that can be translated along with the encrypted message (because the decryptor will need that value). One of the things that this Initialization Vector does if you encrypt the message a second time, the second ciphertext will not resemble the first ciphertext at all; that way, someone listening will not be able to deduce that you've just repeated a message. The Obj-C document specifically says that it will pick a random IV (unless to tell give it one yourself).
As you can see, there are a bunch of reasons why the two ciphertexts may be different. One thing you can try: hand the ciphertext from one to the other, and ask them to decrypt it; if they can, you can be pretty sure that both sides are doing basically the same thing.
As you can see, there are a bunch of reasons why the two ciphertexts may be different. One thing you can try: hand the ciphertext from one to the other, and ask them to decrypt it; if they can, you can be pretty sure that both sides are doing basically the same thing.