Thank you so much for this extremely useful library. I'm not too "up" on C. Would you have any examples on encrypting a string that is longer than the N_BLOCK?

I have hit a stumbling block (no pun intended), and am trying multi-dimentional arrays to create blocks for encrypting/decrypting - I haven't gotten it working so am not even sure if plain and cipher will always be the same length.

Note that AES is a block hash, not suitable for encrypting bulk data simply by dividing the data into blocks and encrypting each one with the same key. That would open up all sorts of flaws and vulnerabilities. typically you use something like "cipher block chaining" or "random ctr-mode" that generate separate xor keys for each block of data, BASED on your AES key. Essentially you need a library like openSSL on top of AES before you have something more than a mathematical curiosity.

"bulk" means more than the native block size, in this case. For example, if you were to just run AES with your key on each block, an attacked could immediately tell whether both blocks were the same, which would be a terrible thing from a cryptographic point of view.Random-ctr mode consists of picking a random number (N) the same size as a block, and then running THAT through AES with your key to give you something to xor with the first 16 bytes, and then AES(N+1, k) to get something to xor with the second 16 bytes, and so on. (then you transmit N at the start of your message.) Aside from it being a bit tricky to generate 128bit random numbers, it should be TOO hard.

Thanks to robtillaart for putting me on the right track. Fundamental mistake on my part. When transferring string value to char array, I needed to size array to str.length() + 1 and also null terminate the final element.

Thank you so much for this extremely useful library. I'm not too "up" on C. Would you have any examples on encrypting a string that is longer than the N_BLOCK?

I have hit a stumbling block (no pun intended), and am trying multi-dimentional arrays to create blocks for encrypting/decrypting - I haven't gotten it working so am not even sure if plain and cipher will always be the same length.

Assuming you have padded your plaintext up to a whole number of blocks "blockcount", andassuming ciphertext is a byte array long enough for that amount of data, and that iv is a block'sworth of initialization vector, the encryption call is

I am new to this encryption and decryption stuff, so i was playing with this library to get a idea on how it works.

My questions is why does the decryption function require the original unencrpyted plain message? Should it not be requesting the key and the cypher to decrypt it?

If I encrpted a message on one arduino and sent the cypher to another arduino with the keys hard coded into each seperate program how would i decrpyt the message on the second arduino? I wouldn't want to send the plain text in the message because then it defeats the purpose of encrypting in the first place.

I am new to this encryption and decryption stuff, so i was playing with this library to get a idea on how it works.

My questions is why does the decryption function require the original unencrpyted plain message? Should it not be requesting the key and the cypher to decrypt it?

If I encrpted a message on one arduino and sent the cypher to another arduino with the keys hard coded into each seperate program how would i decrpyt the message on the second arduino? I wouldn't want to send the plain text in the message because then it defeats the purpose of encrypting in the first place.

I'll try explain some symmetric encryption AES concepts a little (I found this while googling an arduino AES library - thanks to the O.P. for his/her hard work!)

The password is the actual 'secret' that must never be disclosed to the public. The sender and receiver must know the password to encrypt and decrypt correctly.

The encryption will use the password to scramble "Hello World" into (example) "Um1nvnlmPP".But what happens if you want to send the same encrypted message again? The ciphertext will look exactly the same! This means the bad guys can do "Pattern analysis", not exactly figuring out exactly what's in your message, but they know the same message was sent.

An excellent example is here on Wikipedia:https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_codebook_.28ECB.29

Block based encryption breaks a message up into little "blocks of data" to encrypt. In the above link, you can clearly see why ECB is a very very bad thing if Initialization Vectors (IV) aren't used for EACH block. What's an IV?

The IV is purely random data that is used WITH your password to encrypt the data. The IV does not need to be kept private, it is often sent with the encrypted message, eg:Plaintext: "Hello World"Password: "Hunter2"IV: (randomly generated) "aabbaabbaa"The complete message: "[aabbaabbaa][mnmnmnmnmn]"

So the encrypted message that anyone can see contains the IV in plain text. The IV does not need to be kept secret, only the password since it's not easy to crack the encryption without the password. The decrypter takes the IV, the user supplied password and attempts to decrypt the ciphertext

See the ciphertext is always different, even if the same password is used because the IV is always different. This is only one step of preventing the bad guys identifying the contents of your message.

CBC is a little different. CBC uses a little bit of encrypted data from the previous block to encrypt the next block. The first block still needs the IV to be random. CBC has a smaller data size for a lot of blocks since a single IV can be used for a lot of blocks, while ECB can have only one IV for the lot, to prevent pattern matching as per the wikipedia article, better security would necessitate it should have a unique IV per block.