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?
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 ?
#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.
Any information regarding the above is really appreciable.
BR,
SriSowj
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ciao
Stephan
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?
In CTR mode nonce and counters plays a significant role while
performing encryption or decryption? ,So I am trying to understand
these aspect from linux kernel driver aspects where crypto H/W engine
is 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
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 ?
BR,
Srisowj
On Sat, Apr 11, 2015 at 2:21 AM, Stephan Mueller <[email protected]> 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 [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> --
> Ciao
> Stephan
sri sowj <[email protected]> wrote:
> 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
Not what you asked for, but in case it is useful here is the counter
management code from a version of the random(4) driver that
I am working on:
/*****************************************************************
* 128-bit counter to mix in when hashing
****************************************************************/
static u32 iter_count = 0 ;
static spinlock_t counter_lock ;
/*
* constants are from SHA-1
* ones in counter[] are used only once, in initialisation
* then random data is mixed in there
*/
#define COUNTER_DELTA 0x67452301
static u32 counter[] = {0xEFCDAB89, 0x98BADCFE, 0x10325476, 0xC3D2E1F0} ;
/*
* Code is based on my own work in the Enchilada cipher:
* https://aezoo.compute.dtu.dk/doku.php?id=enchilada
*
* Mix operations so Hamming weight changes more than for a simple
* counter. This may not be strictly necessary, but a simple counter
* can be considered safe only if you trust the crypto completely.
* Low Hamming weight differences in inputs do allow some attacks on
* block ciphers or hashes and the high bits of a large counter that
* is only incremented do not change for aeons.
*
* The extra code here is cheap insurance.
* Somewhat nonlinear since it uses +, XOR and rotation.
*
* For discussion, see mailing list thread starting at:
* http://www.metzdowd.com/pipermail/cryptography/2014-May/021345.html
*/
static void count(void)
{
spin_lock( &counter_lock ) ;
/*
* Limit the switch to < 256 cases
* should work with any CPU & compiler
*
* Five constants used, all primes
* roughly evenly spaced, around 50, 100, 150, 200, 250
*/
switch( iter_count ) {
/*
* mix three array elements
* each element is used twice
* once on left, once on right
* pattern is circular
*/
case 47:
counter[1] += counter[2] ;
break ;
case 101:
counter[2] += counter[3] ;
break ;
case 197:
counter[3] += counter[1] ;
break ;
/*
* inject counter[0] into that loop
* loop and counter[0] use +=
* so use ^= here
*/
case 149:
counter[1] ^= counter[0] ;
break ;
/*
* restart loop
* include a rotation for nonlinearity
*/
case 251:
counter[0] = ROTL( counter[0], 5) ;
iter_count = -1 ;
break ;
/*
* for 247 out of every 252 iterations
* the switch does nothing
*/
default:
break ;
}
/*
* counter[0] is almost purely a counter
* uses += instead of ++ to change Hamming weight more
* nothing above affects it, except the rotation
*/
counter[0] += COUNTER_DELTA ;
iter_count++ ;
spin_unlock( &counter_lock ) ;
}
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 <[email protected]>
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 [email protected]
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> > --
> > Ciao
> > Stephan
--
Ciao
Stephan