Can you brake this?
github.com
github.com
What is your attack model?
As Bruce Schneier said, "There are two types of encryption: one that will prevent your sister from reading your diary and one that will prevent your government.”
For example, do you consider timing attacks as a vulnerability?
What is your user model? As written, your code requires the user to peer into the implementation. For example, Cape.h exposes the "swap(a,b)" and "MAX_LENGTH" macros, which may collide with user code.
You also have a "char result[MAX_LENGTH]" but 'result' is filled by user-specified data. Hence, unless the API user does a check against MAX_LENGTH, this can cause a buffer overflow.
If the encryption strength is 0, which is documented as a possible input value, then the "% _encryption_strength" is undefined. Quoting from the spec:
> the binary % operator yields the remainder from the division of the first expression by the second. If the second operand of / or % is zero the behavior is undefined
I don't think that can be so easily fixed.
Again, unless you are an expert, do not write your own crypto system and try to encourage others to use it. Even for experts it's hard work.
Just because you or random strangers on the internet can't break it in 5 minutes of side project, doesn't mean it's not breakable.
Arduino has 16mhz. On your phone you could have enough computational power to break every type of encryption made by an AVR in a timeframe near to a second. I you want to crypt something with Arduino really in a difficult way the procedure could last hours if not days (something can be made in less then a second on a smartphone).
So in any case an Arduino compatible system is not secure because of its lack of computational power.
That's all well and fine. My statement was conjunctive, "... and try to encourage others to use it." You README implies that others should use it. I'm saying that you need big huge warnings that try to keep people away.
You say the Arduino lacks computational power. DES ran on 1970s era hardware. I ran it on a 4.77 MHz 8088. Even that weak cryptosystem cannot be brute forced "in a timeframe near to a second" by a smartphone.
Searching now, http://crypto.stackexchange.com/questions/12891/aes-algorith... gives links to 6 different projects that have implemented AES-256. Including implementations "that run directly on the 16 MHz Arduino [and] can encrypt approximately 1 block per millisecond, roughly 32 000 bytes/sec".
Your "initialisation_vector" is simply derived from system time, not exported (so how is anyone supposed to use it decrypt?) and not even properly used as far as I can tell.