Hello all,
I am making a password manager with an AES library. I'm using this example to help me learn how to use it:
#include "AESLib.h"
void setup() {
Serial.begin(9600);
uint8_t key[] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
char data[] = "4567890127apple()*&^634777"; //origanally only 16 chars
aes128_enc_single(key, data);
Serial.print("encrypted:");
for (byte i=0; i<16; i++) {
Serial.print(data[i]&0xFF,HEX);
Serial.print(" ");
}
Serial.println();
aes128_dec_single(key, data);
Serial.print("decrypted:");
Serial.println(data);
}
void loop() {
// put your main code here, to run repeatedly:
}
You may notice my comment near the top. In experimentation, I decided to add more characters into the data to be encrypted. Here's the thing, it worked ( I think ) fine.
Here's where I got confused. The brief library instructions told me that I needed to add padding to the data before encryption to make a total char number of a multiple of 16.
By not padding, am I risking security?
Thank you!
-Englishscone
Englishscone:
Here's where I got confused. The brief library instructions told me that I needed to add padding to the data before encryption to make a total char number of a multiple of 16.
By not padding, am I risking security?
So, why would you not follow the advise of the documentation?
gfvalvo:
So, why would you not follow the advise of the documentation?
I think I will be able to add padding, I just wanted to understand how great the risk was. If I need to pad, I think am going to try to split the over 16 char data into cycles, and take the remainder and add padding chars until it hits 16.
You could also just look in the source code. From AESLib.c:
// encrypt single 128bit block. data is assumed to be 16 uint8_t's
// key and iv are assumed to be both 128bit thus 16 uint8_t's
void aes128_enc_single(const uint8_t* key, void* data){
aes128_ctx_t ctx;
aes128_init(key, &ctx);
aes128_enc(data, &ctx);
}
So, that function encodes 16 bytes of data. No more, no less. If you print out your char array after encryption, I imagine anything after the first 16 bytes will remain unencrypted.
gfvalvo:
You could also just look in the source code. From AESLib.c:
// encrypt single 128bit block. data is assumed to be 16 uint8_t's
// key and iv are assumed to be both 128bit thus 16 uint8_t's
void aes128_enc_single(const uint8_t* key, void* data){
aes128_ctx_t ctx;
aes128_init(key, &ctx);
aes128_enc(data, &ctx);
}
So, that function encodes 16 bytes of data. No more, no less. If you print out your char array after encryption, I imagine anything after the first 16 bytes will remain unencrypted.
When I run the code, this is what appears:
encrypted:50 4C 96 E3 B7 5 43 1F 94 96 B7 99 40 91 55 BE
decrypted:4567890127apple()*&^634777
Perhaps the function is creating extra zero values to encrypt the remainder?
You're only printing the first 16 bytes of the "encrypted" data array. It's actually 26 bytes long (not counting the terminating '\0'). The last 10 bytes are not effect by the encryption or decryption, they are untouched. You would see that if you printed the whole array. That's why they appear "decrypted" in the last print, but they were never encrypted.
Englishscone:
By not padding, am I risking security?
Presumably you see some advantage by not using padding.
How much security are you prepared to risk in order to have that advantage?
You have not told us what you are trying to protect.
...R
Robin2:
Presumably you see some advantage by not using padding.
How much security are you prepared to risk in order to have that advantage?
You have not told us what you are trying to protect.
...R
Hmm I see. So I will be encrypting separate passwords, which means I do need to add padding. Should my idea from post #2 work?
Englishscone:
Hmm I see. So I will be encrypting separate passwords, which means I do need to add padding. Should my idea from post #2 work?
I don't see that as an answer to my comment in Reply #6
And a lot depends on what the passwords are protecting.
It would probably be better to use a hash for passwords so they cannot be decrypted - but then there is also the important question of where, in the chain of communication, the password changes from plain text to encrypted text.
...R