3 ms·

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

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 11y ago
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 11y ago
  Thank you so much for your feedback I will soon fix this issues you have found.
  - dalke 11y ago
    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 11y ago
      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 11y ago
        > 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-algorithm-processing-time-in-arduino-vs-raspberry-pi 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".
detaro 11y ago
Why would you argue that your library is secure? Since it seems to be based on RC4, what is done to protect against the known weaknesses of RC4? (And why did you pick RC4 as a base, despite it's known weaknesses, especially at the start of the cipherstream?) 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.
- gioscarab 11y ago
  The initialization vector is exported in the last character of the string and so who will decrypt will be able to get back the correct message.

dalke 11y ago

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 11y ago
Thank you so much for your feedback I will soon fix this issues you have found.
- dalke 11y ago
  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 11y ago
    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 11y ago
      > 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-algorithm-processing-time-in-arduino-vs-raspberry-pi 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".

detaro 11y ago

Why would you argue that your library is secure? Since it seems to be based on RC4, what is done to protect against the known weaknesses of RC4? (And why did you pick RC4 as a base, despite it's known weaknesses, especially at the start of the cipherstream?) 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.

gioscarab 11y ago
The initialization vector is exported in the last character of the string and so who will decrypt will be able to get back the correct message.