How to Encrypt/Decrypt byte array using AesManaged class in Windows Phone 8? I'm trying to encrypt 16 bit data, but observed that after encryption the data size is getting changed to 256bits?
There is a Padding (you can't turn it off) and Aes is a block cipher with 128bits blocks. You can see some example usage here: real aes sample
Related
I have a version of AES algorithm with 128bits in plaintext, now i want to change this version to 32bits in plaintext . How can i do this, please ?
That's part of my code when i send data to core AES, i send 128bits to encrypt and i check if the result is true.
apb_write(x"e2bec16b",AES_CMD_ADDR_DATAIN_0);
apb_write(x"969f402e",AES_CMD_ADDR_DATAIN_1);
apb_write(x"117e3de9",AES_CMD_ADDR_DATAIN_2);
apb_write(x"2a179373",AES_CMD_ADDR_DATAIN_3);
apb_write(x"80000005",AES_CMD_ADDR_CONTROL); --confige AES with mode (CBC)
apb_write(x"acab4976",AES_CMD_ADDR_DATAOUT_0);
apb_write(x"46b21981",AES_CMD_ADDR_DATAOUT_1);
apb_write(x"9b8ee9ce",AES_CMD_ADDR_DATAOUT_2);
apb_write(x"7d19e912",AES_CMD_ADDR_DATAOUT_3);
The question : how i can send just 32bits and check , after, send 32bits and check ....?
how i can do this ?
AES is as far as I know only defined for blocks of 128 bits.
If you want to encrypt blocks of 32 bits, you'd need to pad your plain text (with for example 0's) until you reach 128 bits. Then, if you want to decrypt it, just decrypt it normally and after the decryption chop off the last (or first, depending which side you padded) 96 (128 - 32) bits.
I'm replacing PKCS7Padding padding with PKCS5Padding for my AES encryptions.
Can I use PKCS5Padding padding algorithm while decryption for already encrypted data using PKCS7Padding?
I tried using a sample program on local and somehow it works and didn't give any error. Just want to ensure if we need any sort of Migration for all the existing records.
For all the existing records, Do I need to decrypt first using PKCS7Padding and then again encrypt using PKCS5Padding and store it back in the DB?
You may check the following post https://crypto.stackexchange.com/questions/9043/what-is-the-difference-between-pkcs5-padding-and-pkcs7-padding
PKCS5 and PKCS7 are effectively the same by algorithm, just PKCS5 is defined on 8 byte block (64 bit). Therefore cipher AES/.../PKCS5Padding is formally incorrect designation, effectively PKCS7 is used.
Do I need to decrypt first using PKCS7Padding and then again encrypt using PKCS5Padding and store it back in the DB?
No, just to change the padding you don't need to do anything
Hi i have created an RSA encryption using Java that so far only encrypts and decrypts BigIntegers and would like to make it so that it can also do the same for other characters, i have a feeling that i would have to convert everything into Ascii (if this is even possible) to then encrypt but no idea how.
i would have to convert everything into Ascii
consider encryption as converting a byte array to a different byte array (even BigInt is represented as a byte array)
Still I see several issues:
You are implementing your own textbook RSA (no padding, no mitigation for side-channel attacks) and this approach is really really not secure. It's ok to do it for learning purposes (even I'd object) , but not for any real life secure encryption.
RSA is secure (when used properly) to encrypt a fixed block of data. If you want to use RSA to encrypt data of any length, you may use hybrid encryption (use symmetric encryption with a random key to encrypt data and RSA to encrypt the key)
you may have a look at my blog for that
https://gusto77.wordpress.com/2017/10/30/encryption-reference-project/
I have an existing set of Python code that uses the primitive (textbook) RSA encryption mechanism to encrypt small pieces of data. Specifically, the python code loads a public key into variable publickey and then encrypts this data using the following code:
ciphertext = publickey.encrypt(plaintext,None)
Yes I have read the disclaimer that "this function performs the plain, primitive RSA encryption (textbook). In real applications, you always need to use proper cryptographic padding,..." Unfortunately, I cannot change this code at the present time, so I am stuck with using this "textbook" encrypt command.
Note that even though this command does not use any padding scheme, it still seems to be able to encrypt any (appropriately small) amount of plaintext. In other words, the plaintext can be any length up to whatever limit is imposed by RSA.
Now however, I want to use the OPENSSL C library in an IOS app to do an identical RSA encryption. I cannot figure out how to do the exact same thing that the python function is doing. OPENSSL has a method RSA_public_encrypt where you pass in the size of the plaintext, the plaintext itself, an RSA object pointer which contains public key information, and the RSA padding mechanism. To replicate what python is doing in the crypto library, I thought I could use RSA_NO_PADDING as the padding mechanism. The problem is that OPENSSL states in their documentation that if you use RSA_NO_PADDING, then the length of the plaintext to encrypt must be EXACTLY equal to a certain value: RSA_Size(rsa) where rsa is a pointer to the RSA object passed in (the object that contains the public key).
In other words, the python crypto library seems to be able to encrypt variable length plaintext with no padding, but OPENSSL requires plaintext to be fixed length. So what exactly is the python crypto library doing to handle the variable size of the plaintext, and is there any way I can replicate this in OPENSSL?
If you look at the documentation for RSA_NO_PADDING, they explain:
This mode should only be used to implement cryptographically sound
padding modes in the application code. Encrypting user data directly
with RSA is insecure.
In other words, RSA_NO_PADDING is for cases where you're going to handle padding on your own, so OpenSSL expects an input of the proper size. It doesn't mean "textbook RSA".
Is there a compelling reason you can't change the python code? Textbook RSA is insecure and you're taking a great risk by using it.
My device doesn't support full 3DES (EDE). How can I emulate one using standard DES? Encryption mode is CBC.
You start by picking three independent DES keys which are not related to each other in any way.
You will want to put DES into ECB mode, not CBC mode. You also need to ensure that each encryption and decryption operation is done only on 64-bit blocks and nothing more or less. Padding schemes and the likes will cause a vulnerability in the implementation and will lead to the discovery of the block content via brute force faster than a brute force against each key.
Using the first key, encrypt your plaintext. Using the second key, decrypt that value. Using the third key, encrypt the value for your full block. It looks like this:
Encrypt(k3, Decrypt(k2, Encrypt(k1, plaintext)))
Decryption is the other way around and looks like this:
Decrypt(k1, Encrypt(k2, Decrypt(k3, ciphertext)))
When you encrypt your blocks with 3DES you then need to apply your mode of operation like CBC or CTR and apply padding if needed.
Be careful.
Block mode encryption
What you do is that you split the key of size 128 bit (16 byte) or 168 bit (24 byte) in two or three pieces respectively. So for a 16 byte key K you would have two keys Ka and Kb, and for a 24 byte key you would have Ka, Kb and Kc. DES ABC keys have an effective strength of about 112 bits, DES ABA keys have an effective strength of about 80 bits.
To encrypt a single block of 8 bytes (the block size of both DES and 3DES) you would perform the following cryptographic operation: Cn = E(Ka, D(Kb, E(Kc, Mn))) where Mn is the n'th block of the plain text message and Cn the n'th block of the cipher text. If you don't have a Kc then you may use Ka (DES ABC key vs DES ABA key).
For this you need a single block DES encrypt, which is identical to a single block encrypt in ECB mode, or a single block encrypt with CBC and an IV consisting of 8 bytes valued 00h.
CBC
So that's the block encryption sorted, now you need some kind of encryption mode and padding mode. I'll explain CBC mode encryption here, ECB should not be used for encryption non-random data.
With CBC mode encryption you XOR a vector to the plain text. The vector is normally just the output of the last DESede encrypted block. As you don't have any preceding cipher text, you need to create the first vector yourself using random data. This vector is called the initialization vector or IV. See wikipedia for a clear picture.
Padding
Block cipher modes only allow full blocks of plain text to be encrypted. So you would need some kind of padding scheme. Although there are many padding modes, PKCS#5 padding is used most of the time. You should pad the plain text like this: pad with bytes valued 0Xh, where X is the number of padding bytes required to create a full block. X should be between 1 and 8: in other words, PKCS#5 padding is always used; this makes it possible to distinquish the padding bytes from the plain text.
If you use padding in an online protocol then you need to protect against padding oracle attacks. In this case it is highly recommended to use some form of integrity checks, e.g. by adding a HMAC over the cipher text using a separate key.
3DES is just DES used three times on the plaintext:
ciphertext = E_K3(D_K2(E_K1(plaintext)))
plaintext = D_K1(E_K2(D_K3(ciphertext)))
E_Kn = Encryption with Key number n.
D_Kn = Decryption with Key number n.
So you can easily "emulate" 3DES with just DES.
In CBC mode you'll need an IV to start with and then XOR the next plaintext block with the previous ciphertext block. If your device doesn't support CBC then this too is easily "emulated".