AES 256 Encryption with PyCrypto using CBC mode - any weaknesses?

Question

I have the following python script to encrypt/decrypt data using AES 256, could you please tell me if there's anything in the code that may make the encryption weak or if there's anything that I've not taken account of for AES 256 encryption using CBC mode? I've tested the script and it works fine, it is encrypting and decrypting data but just wanted a second opinion. Thanks.

    from Crypto.Cipher import AES
    from Crypto import Random

    BLOCK_SIZE = 32

    INTERRUPT = u'\u0001'

    PAD = u'\u0000'

    def AddPadding(data, interrupt, pad, block_size):
        new_data = ''.join([data, interrupt])
        new_data_len = len(new_data)
        remaining_len = block_size - new_data_len
        to_pad_len = remaining_len % block_size
        pad_string = pad * to_pad_len
        return ''.join([new_data, pad_string])

    def StripPadding(data, interrupt, pad):
        return data.rstrip(pad).rstrip(interrupt)

    SECRET_KEY = Random.new().read(32)

    IV = Random.new().read(16)

    cipher_for_encryption = AES.new(SECRET_KEY, AES.MODE_CBC, IV)
    cipher_for_decryption = AES.new(SECRET_KEY, AES.MODE_CBC, IV)

    def EncryptWithAES(encrypt_cipher, plaintext_data):
        plaintext_padded = AddPadding(plaintext_data, INTERRUPT, PAD, BLOCK_SIZE)
        encrypted = encrypt_cipher.encrypt(plaintext_padded)
        return encrypted

    def DecryptWithAES(decrypt_cipher, encrypted_data):
        decoded_encrypted_data = encrypted_data
        decrypted_data = decrypt_cipher.decrypt(decoded_encrypted_data)
        return StripPadding(decrypted_data, INTERRUPT, PAD)

    our_data_to_encrypt = u'abc11100000'
    encrypted_data = EncryptWithAES(cipher_for_encryption, our_data_to_encrypt)
    print ('Encrypted string:', encrypted_data)

    decrypted_data = DecryptWithAES(cipher_for_decryption, encrypted_data)
    print ('Decrypted string:', decrypted_data)

Answer 1

I've seen the code posted on the internet. There are - in principle - not too many things wrong with it, but there is no need to invent your own padding. Furthermore, I don't see why the first padding character is called INTERRUPT. I presume that INTERRUPT and PAD is handled as a single byte (I'm not a Python expert).

The most common padding is PKCS#5 padding. It consists of N bytes with the value of the number of padding bytes. The padding used here looks more like 'ISO' padding, which consists of a single bit set to 1 to distinguish it from the data and other padding bits, and the rest is zero's. That would be code point \u0080 in code.

So the encryption (which can provide confidentiality of data) seems to be used correctly. It depends on the use case if you also need integrity protection and/or authentication, e.g. by using a MAC or HMAC. Of course, no legal guarantees or anything provided.