I have a requirement where in I get a HEX string which is 32 character long. I need to encrypt it with AES-128-ECB and get an Hex string with is again 32 character long.
I have been asked to convert the 32 char hex string to binary stream(to get 16 bytes of data) and then encrypt it using AES-ECB(to get 16 bytes of encrypted data) and then convert this 16 bytes of encrypted data to 32 char hex string.
I came across this article to achieve AES-ECB encryption.
https://www.ibm.com/developerworks/community/blogs/HermannSW/entry/gatewayscript_modules_aes?lang=en
Kindly let me know how to achieve this.
Other than the actual code you have the concept, for more detailed help you will need to make a best-effort attempt and add that code to the question along with error information and input/output test data (in hex).
Note that you need to ensure that padding is not added, some AES implementations add padding by default and will add a block of (PKCS#7) padding to data that is an exact multiple of the block size (16-bytes for AES).
Note: ECB mode, it is insecure when the key is used more than once and there is a similarity in the data. See ECB mode, scroll down to the Penguin.
Related
I would like to ask if there is a way to encrypt text (no matter how long it is) and ALWAYS get a fixed length decryption? I am not referring to hashing but to encryption/decryption.
Example:
Suppose that we want to encrypt (not hash) a text which is 60 characters long. The result will be a string which is 32 characters long. We can then decrypt the string to get the original text!
We now want to encrypt (not hash) a text which is 200 characters long. The result will be a string which is again 32 characters long. We can then decrypt the string to get the original text!
Is that somehow possible?
Thank you
As the comments indicate, this is impossible. For the underlying reason that this is impossible, see the Pigeonhole Principle. In your example, there are 256^200 inputs and 256^32 outputs. Therefore there must be at least 1 output that has more than 1 input, and therefore is impossible to reverse. Since the number of inputs is massively larger than the number of outputs (and in the general case, is unbounded), almost all cipher texts are necessarily impossible to decrypt.
I am reading up on AES, but most say it takes a Plain text of 128bits so it can be used in a 44 matrix each of 1 byte where the basic operations like sub byte, shift row, mix column, would be performed on them. Must the plain text be 128bits? according to this website which allows one to run AES online. I used a plain text "big" and it still got encrypted. the text big cannot fill the 44 matrix, so what happens to the remaining space in the matrix ?.
If you use a 'block' mode (ECB or CBC) then the plaintext needs to be padded out to a multiple of the block size (128 bits), generally with 0 bits (though other schemes can be used)
If you use a 'stream' mode (CFB, OFB, or CTR), there's no need to pad out the input -- it can be any length (in bits) and the resulting ciphertext will be the same length.
I have a question about aes keys.
I have a binary file which contains an aes256 key (32 bytes) at an unknown offset.
Would it be somehow possible to find this key in the file? Is it somehow possible to tell whether the next 32 bytes would be a valid aes key?
Thanks in advance
EDIT:
Thanks for all of your answers,
The key is stored in the file as normal bytes.
I finally managed to create a way to get it.
I basically filter out all strings, which actually made it work.
Thanks again
Well, yes and no. AES-256 keys should consist of just 32 bytes that are indistinguishable from random. Most files do not consist of just random bytes, so it could be possible t find a sequence that is most likely random, and this could be that key you are looking for. However, it might very well be that there are other random sequences in the file, or sequences that look like random but aren't random at all (such as the binary representation of the number Pi).
It may also be that you are unlucky and that the AES key doesn't look all that random. Or that the key is stored in hexadecimals (text) rather than binary byte values. Then there is the issue of finding the exact offset that might be the problem (is that initial byte with value 0x20 indicating the size of the AES key, a space character or part of the key value)?
Most files have a specific format, so you should first have a look at that. Just looking for random sequences may give you both false positives (rather likely) or false negatives (less likely). If you expect 64 bytes of randomness (two keys) then I suggest you search for that first, as it brings down the chance of false positives by a rather large amount.
No - unless you have a way to verify the key against a known plaintext/ciphertext pair - an AES key is not distinguishable from random noise. Any set of 16, 24 or 32 bytes is a valid AES key.
I have an API to call where I have to encrypt my data using RSA/ECB/PKCS1 Padding & AES/CBC/PKCS5PADDING.
Sample Data: {"KEY":"VALUE"}
Step.1:
I have to generate a random number of 16 digit. eg: '1234567890123456'
Step.2:
Do RSA/ECB/PKCS1Padding to random number and base64Encode the result. we get "encrypted_key"
Step.3:
Concatenate random number & data:
DATA = 1234567890123456{"KEY":"VALUE"}
Step.4:
Do AES/CBC/PKCS5Padding on DATA (from Step 3) using random number(1234567890123456) as KEY & Base64Encoded random number as IV. we get "ENCRYPTED_DATA"
So, for Step 1 I am using JSEncrypt javascript library.
for Step 4 I am using CrytoJS.AES.encrypt() function. I am pretty sure that my JSEncrypt function is running fine as the client is able to decrypt it but client is not able to decrypt my data. I feel that I am making a mistake while using CryptoJS.
Can someone guide me properly on how to use the library.
What I am doing is:
KEY = '1234567890123456'
IV = MTIzNDU2Nzg5MDEyMzQ1Ng== (result of btoa('1234567890123456') )
DATA = "1234567890123456{"KEY":"VAL"}"
cryptedData = Crypto.AES.encrypt(DATA, KEY, {iv: IV, mode: CryptoJS.mode.CBC,padding:CryptoJS.pad.Pkcs7})
I am told to use PKCS5Padding in AES/CBC Encryption ( Step 4 ) but it seems that AES does not support PKCS5Padding but PKCS7Padding.
I think I am making a mistake in the way I am passing KEY & IV to CryptoJS.
Any help will be greatly appreciated.
For the start lets see why are you doing the exercise. RSA is intended to encode only limited amout of data. So we use "hybrid encryption", where the data are encrypted using a symmetric cipher with a random key and the key itself is encrypted using RSA
Encryption works on binary data, to safely transmit binary data, the data are encoded to printable form (hex or base64)
Step.1: I have to generate a random number of 16 digit
What we see is 16 digits 0-9. That's not really safe. Generating 16 digits you will get a key of 10^16, which is equals of approx 2^53 (if I did the math wrong, please comment).
You need to generate 16 random bytes (digits 0-256 resulting in 2^128 key). That is your DEK (data encryption key).
You may encode the DEK to be in printable form, in hexadecimal encoding it will have 32 characters.
Step.2:
ok, you now get encrypted encoded_encryption_key
Step 3, Step 4
And here you should understand what are you doing.
encrypt DATA using DEK ( not encoded random number in binary form), you will get encrypted_data. You can encode the result to encoded_encrypted_data
concatenate the encrypted key and encrypted data. It. is up to you to choose if you encode it before or after encoding. I suggest you make concatenation of encoded_encryption_key and encoded_encrypted_data with some separator, because if RSA key length changes, the length of encoded_encryption_key changes too
Make sure to discuss with the client what format is expected exactly.
Notes:
IV needs to be 16 bytes long for AES and for CryptoJS I believe it needs to be Hex encoded, so using btoa may not be the best idea. I believe the CryptoJS just trims the value to 16 bytes, but formally it is not correct.
CBC cipher needs some sort of integrity check, I suggest to add some HMAC or signature to the result (otherwise someone could change the ciphertext without you being able to detect the tamper)
but it seems that AES does not support PKCS5Padding but PKCS7Padding.
Indeed AES supports Pkcs7. Pkcs5 is functionally the same, but defined on 64 blocks. The designation is still used in Java as heritage from DES encryption.
the password string is some kind of like that
MTY5LTYtNjEtMjAxLTkwLTE3MS05My0yMDAtMTMxLTE5Mi01My0xNjItMC0yMjAtMTgxLTIyNg==
I tried base 64 encoder and it gives me:
169-6-61-201-90-171-93-200-131-192-53-162-0-220-181-226
Looks like encode by ASCII Code
I put the numbers on ASCII code list gives me :
©=ÉZ«]ȃÀ5¢Üµâ
But this not the password that i looked.
Does anyone know the solution.
I am not an expert sorry for bad explaining.
The string contains 16 numbergroups and each number is between 0 and 255. So it looks like 16 bytes. And 16 bytes / 128 bits is the size of an md5 hash. So that would be my guess.
While a crypto hash function can't be easily reversed, there are online rainbowtable services which can revert them for short or common inputs. But if the programmer who wrote it did it right (used a salt and many iterations) they won't help.
I'd split it in 16 numbers, than convert these to a byte array of size 16, and then hexencode them, since that's the form most programs will accept. Edit: See Kenny's comment
And then search for some website which allows search in rainbow tables. And pray...