1

I have this little piece of code for encrypting:

typedef unsigned char byte;

int encrypt(char *filename) {

    byte key[ 16 ];
    int i;
    memset( key, 0x00, 16);

    for(i=0;i<=sizeof(*key);i++){ 
    key[i]=(byte)(std::rand() % 256);
    }

    auto enc = new ECB_Mode<AES>::Encryption(key, sizeof(key));
}

Is there a method to crack or decrypt a piece of encrypted text encrypted with this function?

closed as off-topic by schroeder Jan 28 at 9:26

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "This question does not appear to be about Information security within the scope defined in the help center." – schroeder
If this question can be reworded to fit the rules in the help center, please edit the question.

  • Why is filename not used inside the encrypt function? Please, provide the entire function – Mr. E Mar 3 '17 at 18:20
  • 1
    Assuming this code were changed to actually encrypt 'a piece of text', the biggest problem is you set only 2 bytes of key, which is very easy to bruteforce even without cracking the probably-weak RNG per akg answer. Conversely if you had coded what you apparently intended, it would have an overrun possibly leading to destroying your data. If you want to program security-critical code in C++, a good start would be programing in C++ correctly. – dave_thompson_085 Mar 4 '17 at 15:19
1

The first problem I see is that you use a standard random function instead of a cryptographic random. I don't see how you seeded that, but if it is srand(time(0)) then it can probably be cracked.

However AES ECB mode is still AES. If you have only 1 block of ciphertext it is ok. If you have lots of texts then probably one will still be unable to crack it, the problem with ECB mode is that 2 blocks of the same plaintext will have the same ciphertext block too. So it really depends on the text you want to encrypt and the attacker's knowledge of the original plaintext. What you see on Wikipedia is a picture encoded where there are lots of similar blocks. All the white blocks will be similar, all the black blocks will be similar and so on and so forth.

  • This is trivially cracked if an attacker can inject contents for you to encrypt before something sensitive. – Stephen Touset Mar 4 '17 at 2:18
  • 1
    If you are referring to a en.wikipedia.org/wiki/Known-plaintext_attack - to which AES is resistant, no you can't derive the key thus can't crack the other unknown parts. Could you elaborate? – akg Mar 4 '17 at 2:50
  • 1
    ECB is not resistant to an adaptive chosen-plaintext attack. Imagine Alice has a block of sensitive data, and Eve can inject her own plaintext before it gets encrypted. Eve gets Alice to encrypt a block of 31 NULs followed by a NUL, followed by the secret data. Repeat with 32 NULs followed by \x01. Repeatd, followed by \x02. Repeat for all until \xff. Now Eve has a lookup table for every possible value of the last byte. Ask Alice to encrypt 31 NULs, followed by the secret data. – Stephen Touset Mar 4 '17 at 3:19
  • 1
    The last byte of the block will be the first byte of the secret data. And it will be one of the 256 values you have a lookup table for. Repeat until you have an entire block of data. – Stephen Touset Mar 4 '17 at 3:20
  • Yes, that attack exists, but doesn't apply for this scenario. You need an oracle for that to work. Technically you are right (iff you can inject content before the plaintext), because 1 byte of the plaintext can still be decrypted and that is a piece of the data, but practically infeasible. – akg Mar 4 '17 at 3:33

Not the answer you're looking for? Browse other questions tagged or ask your own question.