>On Fri, Oct 19, 2007 at 10:29:32PM +0000, Joy Latten wrote: >> >> I think the change to CTR would be simple. >> If noncesize + ivsize == blocksize, then use >> entire counterblock as counter and pass to >> ctr_inc_quad(). Currently, we just fail >> if noncesize + ivsize == blocksize. > >How about adding an explicit counter size parameter? > >So intead of ctr(aes,4,8) for the standard IPsec CTR we'd have >ctr(aes,4,8,4). Then GCM can just use ctr(aes,4,12,4). GCM begins encryption with the counter at 2. CTR initializes its counter with 1 to begin encryption. GCM then uses counter set to 1, to create authentication tag. It must do encryption first though because the encrypted data is passed in to create authentication tag. Encrypting with counter initialized at 2 doesn't quite fit into CTR... The only resolution I can readily think of is to allow the user to pass in the counter. It could be part of the IV. Thus GCM could pass in IV || 0^31 || 1 to CTR for encryption. It would then later pass in IV || 0^32 to create authentication tag. So, if noncesize + ivsize == blocksize, do not initialize a CTR counter. Instead, use "countersize" bytes from end of IV as counter to be incremented. So ctr(aes,0,16,4) would indicate to use last 4 bytes of IV for counter. Does this seem ok? Would there be some concern of user initializing counter, because it could be initialized to a high number... then counter could rapidly rollover? Would this be a problem? If so, then we could use entire counterblock for counter in this instance and not allow user to specify countersize... Regards, Joy - To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
