Re: [PATCH 1/1]: CTR mode implementation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>> > I suggest that you make these parameters to your CTR template.
>> > So instead of requesting for "ctr(aes)", you could request for
>> > "ctr(aes, 4, 8)" where 4 is the length of the nonce in the
>> > counter block and 8 is the length of the IV.  The counter
>> > itself would then be calculated as block_size - 4 - 8.
>> > 
>> Ok, pretty much had this coded up when it dawned on me
>> maybe I should include the nonce as parameter too.
>> Whenever you use ctr, it is a given you need the nonce.
>> Couldn't the user of the api, separate the nonce from 
>> the key and pass it in the template? It would solve
>> my problem about sometimes the keylen is bigger than 
>> max-key-length for the algorithm with the additional bytes 
>> for nonce. So, I could pass in ctr(aes, nonce, noncesize, ivsize).
>> Let me know if this sounds ok or did I miss something important?
>
>It would be awkward to have the actual nonce as a parameter
>because for IPsec at least it's negotiated through the same
>process as the encryption key.
>
>More importantly, for the same "ctr(aes, 4, 8)" tuple, there
>are many users (each SA would need two) while for if you
>include the actual nonce then each tuple would be used by just
>one SA.

Ahhhhh, ok. Yes, you are right.

I have another question regarding this change to using a tuple.
The size of my counter is now, csize = blocksize - (noncesize + ivsize).
rfc 3686 (CTR-AES for ESP) states in section 4, that the counter
portion of the counter block be a 32-bit big endian. To keep
code endian-neutral as I can, would it be appropriate if I only did
this when my csize is 2, 4 or 8 bytes so I can easily use be16_to_cpu(), 
be32_to_cpu() and be64_to_cpu() respectively? And for all other 
sizes for csize, don't worry about this "endian" requirement, just store as is. 
Does it matter that I store the 32 bits as big endian?

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

[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux