Re: Counter Size in CTR mode for AES Driver

[Stephan Mueller <smueller@chronox.de>]

Am Samstag, 11. April 2015, 09:07:35 schrieb sri sowj:

Hi sri,

> Hi Stephen,
> 
> Thanks a million for the information provided. I really appreciate
> your time and efforts.
> 
> In CTR mode counter size is not fixed , it varies based on
> requirements like for rfc 3686 its size is 4 bytes, for other "CTR
> Mode" operations it is 8/16 bytes. So how does linux crypto HW drivers
> like nx-aes-ctr.c or omap-aes.c etc handles these variations?

Without having looked at those implementations, I guess that they simply 
implement ctr(aes). That means that they simply have a counter value of 128 
bit (to match the requirement that the IV must be block size). Then they 
simply increment them.

Now, the logic of the kernel crypto API kicks in: there is the rfc3686 
template in ctr.c. Thus, when you use rfc3686(ctr(aes)), you get that 
particular logic where the counter is interpreted in a special way and thus 
set up accordingly.

Now, the rfc3686 now provides a very particular interpretation of the IV -- 
i.e. this one initializes it as needed (in .fact, it uses seqiv as initialized 
in  crypto_rfc3686_alloc). After creating the IV based on a particular 
requirement, this template simply invokes ctr(aes) which simply increments the 
given IV/counter value. Then at some point, rfc3686 takes over again where the 
IV is again massaged as needed.

As we have segiv, the full power of rfc3686 can only be used by the caller 
when using the skcipher_givcrypt_* APi from include/crypto/skcipher.h. For an 
example, check the esp_output function that uses the AEAD version of the 
givcrypt API. I drew a picture in [1] that illustrates the structure a bit 
more.

[1] http://www.chronox.de/crypto-API/ch02s07.html

(the rfc3686 is logically very similar)

> 
> In CTR mode nonce and counters plays a significant role while

Before continuing, you need to detach yourself from thinking of the counter 
value in form of 4/8/16 byte nonces or other values. The "raw" counter is 
blocksize, period. Now, some code may get an initial value of 4/8/16 bytes (or 
whatever size). Now, that implementation must do its magic to transform that 
input into block size before performing the CTR operation with the underlying 
block cipher.

> performing encryption or decryption? ,So I am trying to understand
> these aspect from linux kernel driver aspects where crypto H/W engine
> is present.

The crypto HW implementations may or may not implement the specialities 
mentioned above. That is the true power of the crypto API: every part 
inside/outside the parantheses can be implemented in independent components or 
in joint components. The kernel crypto API selects the right implementation 
based on the cra_priority.

For example, the rfc4106 template has the same issue for GCM as rfc3686 for 
the CTR mode. And rfc4106 is implemented in the HW implementation for AES-NI 
(see arch/x86/crypto/aesni_intel-glue.c) as well as in pure C (see gcm.c). 
Other HW implementations of AES or GCM may not implement rfc4106 -- they would 
use the C version as fallback (the API does that transparently based on the 
cra_priority and registered implementations). So, there is a full freedom 
available what HW can implement or wants to provide as usually there is always 
a software "fallback" present.
> 
> from the user it might be possible to get request consisting the
> counter size of 4 or 8 or 16 bytes.There has to be a way to deal these

The user can never request sizes of a counter used for encryptions. All 
implementations will eventually align the initial counter values (which may be 
given by the caller) to a blocksize boundary. Otherwise, the math will not 
work. Thus a caller may provide some initial value (depending on the chosen 
implementation) which is then somehow padded/aligned/massaged to block size.

> variations from linux kernel crypto subsystem , but i am finding
> little hard time to understand this.
> 
> Just to give a thought, is it possible  to find size of these fields
> like nonce or counter from IV size ?

Either I do not understand this remark, our based on the description above, 
you see that this question is not applicable.
> 
> BR,
> Srisowj
> 
> On Sat, Apr 11, 2015 at 2:21 AM, Stephan Mueller <smueller@chronox.de> 
wrote:
> > Am Samstag, 11. April 2015, 00:30:30 schrieb sri sowj:
> > 
> > Hi sri,
> > 
> >> Hi All,
> >> 
> >> I have seen multiple open source drivers for AES(CTR) mode for
> >> different Crypto Hardware Engines, I was not really sure on
> >> countersize,nonce etc.
> >> Please can any one provide some info on the following
> >> 
> >> #1:How does AES driver identifies the counter size during the CTR mode
> >> of operation?
> > 
> > I am not sure about the question, but the block chaining mode is
> > orthogonal to the block cipher.
> > 
> > Thus, the block cipher does not need to know of the counter size of CTR.
> > That applies to any block chaining mode.
> > 
> >> looks like AES in CTR mode supports "countersize" of multiple lengths as
> > 
> > below:
> >> >>1: First is a counter which is made up of a nonce and counter. The
> >> >>nonce
> >> >>is random, and the remaining bytes are counter bytes (which are
> >> >>incremented).
> >>  
> >>  For example, a 16 byte block cipher might use the high 8 bytes as a
> >> 
> >> nonce, and the low 8 bytes as a counter.
> >> 
> >> >>2: Second is a counter block, where all bytes are counter bytes and can
> >> >>be
> >> >>incremented as carries are generated.
> >>  
> >>  For example, in a 16 byte block cipher, all 16 bytes are counter bytes
> >> 
> >> #2: Does Linux Kernel Crypto subsystem increments the counter value
> >> for every block of input or is it needs tp be taken care by Kernel
> >> Driver for the respective Crypto H/W ?
> > 
> > This depends on your choice -- the kernel crypto API provides crypto_inc()
> > for the increment, it provides the ctr template to wrap a block chaining
> > mode. The kernel crypto API does not restrict, it enables you.
> > 
> >> #3:counters and nonces are something which will be extracted from the
> >> IV i.e., IV = nonce + counter
> >> Note if "l" is length of IV then first "l/2" is length of nonce and
> >> next "l/2" is length of counter.
> > 
> > What you describe may be on e convention. But the ctr.c template
> > initializes the counter value to 0 during init time. So, you see that
> > there is no hard fact. The counter is in fact just an IV.
> > 
> >> Any information regarding the above is really appreciable.
> >> 
> >> BR,
> >> SriSowj
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-crypto"
> >> in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> > --
> > Ciao
> > Stephan


-- 
Ciao
Stephan