
Can you brake this? - gioscarab
https://github.com/gioblu/Cape
======
gioscarab
[https://github.com/gioblu/Cape](https://github.com/gioblu/Cape) This is an
encryption library I wrote. I think this is the best place to try to find
someone able to find some vulnerability in my encryption algorithm. So good
luck :)

~~~
dalke
In general, do not write your own crypto system unless you are a crypto
expert. The rule is to not suggest people use your system until you are an
expert.

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

~~~
gioscarab
Thank you so much for your feedback I will soon fix this issues you have
found.

~~~
dalke
The major issue I found is that you wrote your own crypto system without
developing a security model and without explaining why well-known and well-
tested crypto methods aren't appropriate.

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.

~~~
gioscarab
I think that who is interested in crypto analysis like me, should try simple
approaches like this one to learn and be aware of the rules of cryptoanalysis.

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.

~~~
dalke
> should try simple approaches

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...](http://crypto.stackexchange.com/questions/12891/aes-algorithm-
processing-time-in-arduino-vs-raspberry-pi) 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".

------
amenghra
yes

