> In the function private_AES_set_decrypt_key, in aes_core.c, it inverts > the order of the round keys before applying the MixColumn transform from > low to high (excluding low and high, order doesn’t really matter as each > transformation is dependent only on the item in question). Then > AES_decrypt applies the round keys from low to high on the input. > > It seems to me that you will get the same result if you do away with the > inversion of the round keys, apply the MixColumn transform (excluding > low and high) and then AES_decrypt applies the round keys from high to > low on the input. > > Using this method would therefore save the amount (pretty small) of cpu > time used to invert the round keys, with no apparent penalty, assuming > looping backwards costs the same as looping forwards.
Well, you'll have to calculate address of the last round key in the schedule. This introduces dependency on load of number of rounds. I mean contemporary processors look ahead and in this context can start pulling key schedule elements in advance. But with the dependency pre-load will have to be postponed and might be late, which would result in delay upon entry into the loop. I mean there is no penalty with backward looping per se, there is penalty with setting up backward loop. In *this* context that is. > Is there something functionally wrong with my hypothesis? No, not outcome-wise. > If not, is > there something wrong security-wise, e.g. will the different cpu time > cause a vulnerability (it seems that currently one can theoretically > tell the difference between an encryption and a decryption based on cpu > usage, but I don’t know if that is a real problem)? There is no security value in order in which key schedule elements are addressed. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
