Open cptwunderlich opened 9 years ago
The block size (plaintext/ciphertext bit-length) of AES-256 is still 128. The 256 denotes only its key size. So the code shouldn't need significant modification except replacing AES-128 by AES-256. I am not 100% sure though. I may check it thoroughly once I have time later.
I know this thread is a bit old, but zhuzhuor is right. The gf function and the block size remain the same whatever the key length. I patched the implementation to support AES192/256. The only change is in aes_gcm.py, in the function change_key():
` def change_key(self, master_key): if (len(master_key)*8 not in (128, 192, 256)): raise InvalidInputException("valid AES key must be 128, 192 or 256 bit long")
self.__master_key = master_key
self.__aes_ecb = AES.new(self.__master_key, AES.MODE_ECB)
self.__auth_key = bytes_to_long(self.__aes_ecb.encrypt(b'\x00' * 16))
# precompute the table for multiplication in finite field
table = [] # for 8-bit
for i in range(16):
row = []
for j in range(256):
row.append(gf_2_128_mul(self.__auth_key, j << (8 * i)))
table.append(tuple(row))
self.__pre_table = tuple(table)
self.prev_init_value = None # reset`
Note that the master key is now passed as a byte array instead of an int, which I personally find easier. Using this I was able to successfully run some test vectors from the NIST CAVP test suite (http://csrc.nist.gov/groups/STM/cavp/block-cipher-modes.html#gcm-gmac).
I can do a pull request and patch it if someone is still interested.
What would be necessary to add support for AES-256? Am I correctly assuming, that it's mostly about creating an equivalent function for "gf_2_128_mul"? I don't really understand the maths behind it well enough to touch it...