Are there any AES test vectors for encrypting/decrypting plaintexts of arbitrary lengths?
All I could find was test vectors for plaintexts which lengths were multiples of 16 bytes...
I need it to validate my internal padding function (PKCS#7) in an AES implementation
Thanks!
no, there are most likely no specific AES test vectors with other length than the AES blocklength ...
but since you want to test a PKCS7 implementation, what do you want with AES test vectors anyways?
AES handles blocks ... 128 bit at a time ... when you have a working AES implemtation, you are safe to assume that DEC(ENC(DATA,K),K) = DATA ...
so all you need to test is if your padding function produces the same output as a PKCS7 reference implementation whithout any cipher behind it ... AES has nothing to do with your problem
Related
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.
I am working on encryption & decryption of data using AES-CCM.
While studying AES, I came across a word called S-Box.
What is S-Box, and the relationship with AES? How can it be calculated? Is it depends on symmetric key or not?
How will cypher text be generated in AES-CCM 128 bit?
The S-Boxes are a system that is used in symmetric cryptographic algorithms to substitute and obscure the relationship between the key and the text that you want to cypher.
You can see more in this article. Here, you have a part:
There are different types of cyphers according to their design [68]. One of these is the Substitution–PermutationNetwork (SPN) that generates the ciphered text by applying substitution and permutation rounds to the original text and the symmetric key to create confusion. To do this, it must be used the Substitution boxes (S-boxes) and Permutation boxes (P-boxes). The S-boxes substitute one-to-one the bits of a block of the input text in the round with bits of the output text. This output is taken as an input in the P-boxes and then it permutes all the bits that will be used as S-box input in the next round.
As #CGG said, S-boxes are a component of a Substitution-Permutation Network. The Wikipedia entry has good diagrams which will help explain how they work.
Think of an S-box as a simple substitution cipher -- A=1, B=2, etc. In an SPN, you run input through an S-box to substitute new values, then you run that result through a P-box (permutation) to distribute the modified bits out to as many S-boxes as possible. This loop repeats to spread the changes throughout the entire cipher text.
In general, an S-box replaces the input bits with an identical number of output bits. This exchange should be 1:1 to provide invertibility (i.e. you must be able to reverse the operation in order to decrypt), should employ the avalanche effect (so changing 1 bit of input changes about half the output bits), and should depend on every bit of input.
How can I decrypt a random block of encrypted data using aes-cbc?
First information:
AES has a block size of 128-bits. So when you say "AES-128" the assumption is a key size of 128-bits and "AES-256" the assumption is a key size of 256-bits.
CBC mode requires an iv. The iv is used for the first block, each other block use the value of the previous block in a similar way. See Cipher Block Chaining (CBC).
Decryption must be done on a block boundary. The first block will use the iv, subsequent blocks will use the value of the previous encrypted block essentially for it's iv. Thus decryption can start from other than the beginning of the encrypted data.
An assumption on my part is that gpg and openssl place the iv preceding the encrypted data, that is usual procedure but this is a guess by me but may be more complicated (I am to lazy to look that up). This would explain why decryption from the first block would work and not from other starting locations.
For more information study the available documentation.
There is a good online AES calculator provided by Cryptomathic.
With info in zaph's answer I was able to do it in python like this:
from os import urandom
from Crypto.Cipher import AES
import hashlib
IV = urandom(16)
aes = AES.new(hashlib.sha256(b'123').digest(), AES.MODE_CBC, IV)
T='1234567890'*160
C=aes.encrypt(T)
# Now if we make a new aes instance with IV we will be able to decrypt first block:
aes = AES.new(hashlib.sha256(b'123').digest(), AES.MODE_CBC, IV)
aes.decrypt(q[:16]) # It returns b'1234567890123456'
# But if we need to decrypt block 4 we need to instanciate aes with contents of block 3 as iv parameter:
aes = AES.new(hashlib.sha256(b'123').digest(), AES.MODE_CBC, q[48:64])
aes.decrypt(q[64:80]) # It returns b'5678901234567890'
So to sum it up if you want to decrypt some encrypted text using aes-cbc from block n to block m for example (which is bytes n×16 to m×16), you need data from block n-1 (bytes (n-1)×16 to (n×16)-1) as IV to start decryption on block n. This way you can decrypt any chunk of data even though you don't have access to whole data except for its first block (first 16 bytes).
Can anyone suggest the pattern of Initialization vector for AES 128.
Can we include characters in IV or we have to include only numbers for it?
The IV depends on the cipher mode. But for AES with CTR, CBC, and some other modes, use 16 bytes chosen by a cryptographic random number generator.
Do you know of any other ciphers that performs like the ROT47 family?
My major requirement is that it'd be keyless.
Sounds like you might be looking for some "classical cryptography" solutions.
SUBSTITUTION CIPHERS are encodings where one character is substituted with another. E.g. A->Y, B->Q, C->P, and so on. The "Caesar Cipher" is a special case where the order is preserved, and the "key" is the offset. In the rot13/47 case, the "key" is 13 or 47, respectively, though it could be something like 3 (A->D, B->E, C->F, ...).
TRANSPOSITION CIPHERS are ones that don't substitute letters, but ones that rearrange letters in a pre-defined way. For example:
CRYPTOGRAPHY
may be written as
C Y T G A H
R P O R P Y
So the ciphered output is created by reading the two lines left to right
CYTGAHRPORPY
Another property of rot13/47 is that it's REVERSABLE:
encode(encode(plaintext)) == plaintext
If this is the property you want, you could simply XOR the message with a known (previously decided) XOR value. Then, XOR-ing the ciphertext with the same value will return the original plaintext. An example of this would be the memfrob function, which just XORs a buffer with the binary representation of the number 42.
You also might check out other forms of ENCODINGS, such as Base64 if that's closer to what you're looking for.
!! Disclaimer - if you have data that you're actually trying to protect from anyone, don't use any of these methods. While entertaining, all of these methods are trivial to break.