0

I have this Objective-c Code that Converts a NSData to AES256, recently I discovered that the maximum number of password is 32 bytes:

- (NSData *)AES256EncryptWithKey:(NSString *)key {
    // 'key' should be 32 bytes for AES256, will be null-padded otherwise
    char keyPtr[kCCKeySizeAES256+1]; // room for terminator (unused)
    bzero(keyPtr, sizeof(keyPtr)); // fill with zeroes (for padding)

    // fetch key data
    [key getCString:keyPtr maxLength:sizeof(keyPtr) encoding:NSUTF8StringEncoding];

    NSUInteger dataLength = [self length];

    //See the doc: For block ciphers, the output size will always be less than or
    //equal to the input size plus the size of one block.
    //That's why we need to add the size of one block here
    size_t bufferSize = dataLength + kCCBlockSizeAES128;
    void *buffer = malloc(bufferSize);

    size_t numBytesEncrypted = 0;
    CCCryptorStatus cryptStatus = CCCrypt(kCCEncrypt, kCCAlgorithmAES128, kCCOptionPKCS7Padding,
                                          keyPtr, kCCKeySizeAES256,
                                          NULL /* initialization vector (optional) */,
                                          [self bytes], dataLength, /* input */
                                          buffer, bufferSize, /* output */
                                          &numBytesEncrypted);
    if (cryptStatus == kCCSuccess) {
        //the returned NSData takes ownership of the buffer and will free it on deallocation
        return [NSData dataWithBytesNoCopy:buffer length:numBytesEncrypted];
    }

    free(buffer); //free the buffer;
    return nil;
}

- (NSData *)AES256DecryptWithKey:(NSString *)key {
    // 'key' should be 32 bytes for AES256, will be null-padded otherwise
    char keyPtr[kCCKeySizeAES256+1]; // room for terminator (unused)
    bzero(keyPtr, sizeof(keyPtr)); // fill with zeroes (for padding)

    // fetch key data
    [key getCString:keyPtr maxLength:sizeof(keyPtr) encoding:NSUTF8StringEncoding];

    NSUInteger dataLength = [self length];

    //See the doc: For block ciphers, the output size will always be less than or
    //equal to the input size plus the size of one block.
    //That's why we need to add the size of one block here
    size_t bufferSize = dataLength + kCCBlockSizeAES128;
    void *buffer = malloc(bufferSize);

    size_t numBytesDecrypted = 0;
    CCCryptorStatus cryptStatus = CCCrypt(kCCDecrypt, kCCAlgorithmAES128, kCCOptionPKCS7Padding,
                                          keyPtr, kCCKeySizeAES256,
                                          NULL /* initialization vector (optional) */,
                                          [self bytes], dataLength, /* input */
                                          buffer, bufferSize, /* output */
                                          &numBytesDecrypted);

    if (cryptStatus == kCCSuccess) {
        //the returned NSData takes ownership of the buffer and will free it on deallocation
        return [NSData dataWithBytesNoCopy:buffer length:numBytesDecrypted];
    }

    free(buffer); //free the buffer;
    return nil;
}

I wonder if it is possible to find some way to increase these bytes? Causing the password to be larger than 32 digits, it is possible?

LettersBa
  • 747
  • 1
  • 8
  • 27

2 Answers2

3
  1. A byte is not a digit.

  2. 256-bit keys are well beyond brute force cracking.

  3. Do not use a password for the encryption key. If you need to use a password use a Password Key Derivation Function such as PBKDF2 to create a secure encryption key from the password. The password can be of any length and the PBKDF2 function will generate a secure encryption key of the correct length. Specify an iteration count of > 10K.

  4. Getting CCCrypt to work is the trivial part of creating a secure encryption scheme.

  5. Consider using RNcryptor, it will handle these details and more.

  6. You will need to handle the security of the password/key, that is not easy.

zaph
  • 111,848
  • 21
  • 189
  • 228
2

AES doesn't use a password, but a key. AES-256 for example is only defined for a 256-bit key (32 bytes). You can of course use password-based derivation functions to derive a key from a password.

Popular choices are PBKDF2, bcrypt and scrypt (with increasing slowness - the slower the better). They are essentially hash functions that take an arbitrary binary string and give a (variable) fixed output.

A good value for PBKDF2 is 86,000 iterations. Also, use a random salt. You can then generate enough output for the key and IV.

CBC mode (which is the default for CCCrypt) is not semantically secure if used with a static IV such as the all zeros IV in your code. Use at least CBC mode with a random IV or even better an authenticated mode like GCM or EAX. If an authenticated mode is not available, you need to apply a message authentication code to your ciphertext (encrypt-then-MAC) in case your system is vulnerable to a random oracle attack.

Community
  • 1
  • 1
Artjom B.
  • 61,146
  • 24
  • 125
  • 222
  • Sure, I've linked PBKDF2. Use more than 1000 iterations and a salt. – Artjom B. May 02 '15 at 23:41
  • Other question: If I prefer to not use this salt, Only create a AES256 with my code with 32 bytes? The file is secure too? – LettersBa May 02 '15 at 23:42
  • 1
    That depends on your password and how much entropy it has. If it is low on entropy, meanings it appears in a dictionary or is a common password, then this is not at all secure. It can be easily brute-forced. – Artjom B. May 02 '15 at 23:45
  • I use this code to convert a zip file into AES256 file and I save it with objective-c, and send for e-mail (is a backup file). If one user get this file he will try to decrypt right? What are the chances he can decrypt and know that the file is nothing more than a .zip file? Second, he can open a file type NSData without the ios? – LettersBa May 02 '15 at 23:51
  • 2
    As I said, that depends on the password and how easily guessable it is. – Artjom B. May 03 '15 at 00:04
  • Well The mode ECB that I'm using is not segure, I find this project https://github.com/Gurpartap/AESCrypt-ObjC, It use CBC you recommend me to use this project? – LettersBa May 03 '15 at 00:26
  • No, I wouldn't recommend it, because it uses a fixed IV. Normally, you would generate a random IV and use it for encryption. Then you can prepend it to the ciphertext so that you can use the same IV for decryption. – Artjom B. May 03 '15 at 00:35
  • 1
    Look at this -> https://github.com/RNCryptor/RNCryptor, Simple, use CBC, and random IV, I use this – LettersBa May 03 '15 at 01:38
  • 1
    RNCryptor is good and currently maintained. How are you going to maintain and transfer the encryption key? – zaph May 03 '15 at 04:06
  • @LettersBa Yes, RNCryptor looks very good, since it uses a random IV *and* supports encrypt-then-MAC. – Artjom B. May 03 '15 at 07:49
  • And if you run into trouble you can ask here since Rob Napier is active on SO as well :) – Maarten Bodewes May 03 '15 at 11:24
  • @ArtjomB. Note that the CCCrypt default mode is CBC, not ECB. – zaph May 03 '15 at 11:29
  • @Zaph I see. So it means that the IV is all zeros for the above code? – Artjom B. May 03 '15 at 13:02
  • Yes the iv is all zeros. While I would not recommend that it is still far above ECB. An aside: The problem with your solution is that there is no way a developer inexperienced in cryptography will be able to successfully implement it due to a basic lack of crypto knowledge and if attempted will most likely end up with an insecure mess—yes, that is depressing. Thus I suggest RNcryptor as their best hope. – zaph May 03 '15 at 16:42
  • @Zaph I agree. It's rather hard to implement all of this on their own. I still think that knowing those intricasies will be more rewarding in the long run than simply saying that solves all your problems. Additionally, I haven't worked with obj-c or RNcryptor, so it would be quite strange if I would recommend it. That's why I upvoted your answer. OP is welcome to accept yours. I won't hold a grudge. I promise :) – Artjom B. May 03 '15 at 16:58
  • 1
    I don't disagree with your answer, it is all good. It is all complicated as well. I agree knowledge is rewarding if for no other reason that to make developers understand that it is not as easy as a password and AES. A better link is https://github.com/RNCryptor this provides information on the availability in 10+ language/platform combinations. I continually see inter-platform/language issues and this helps alleviate the interoperability problems. I have never used RNCryptor but might if I needed to implement the capabilities it supports, well tested code would trump my new code. – zaph May 03 '15 at 17:09