Re: [PATCH] AES counter mode non-zero counter offset

[Matt Piotrowski]

Stephen Sprunk wrote:

> If we document that *num must always be zero on first use (not sure
> how I can assert() that), is there any bug that needs fixing?

Yes, the sample code I included in a previous post demonstrates the bug 
despite num being zero on first use.


Matt



__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [PATCH] AES counter mode non-zero counter offset

[Richard Levitte - VMS Whacker]

In message <[EMAIL PROTECTED]> on Tue, 30 Jul 2002 16:18:07 
PDT, Matt Piotrowski <[EMAIL PROTECTED]> said:

matt.piotrowski> "num" could point to a value out of that range if it
matt.piotrowski> is not initialized before the first call to
matt.piotrowski> AES_ctr128_encrypt().  The fix for this is to clearly
matt.piotrowski> document that the value "num" points to is both an
matt.piotrowski> input and an output.  

Just as for the DES OFB and CFB modes, num must be initialized to 0 by
the user.  You're perfectly correct that we need to document the AES
functions, thanks for the reminder.

matt.piotrowski> However, this range of values really has no bearing
matt.piotrowski> on the bug.  The bug exists for all non-zero values.

I completely agree, now that you pointed out what you meant (sorry for
missing it).  However, your patch worries me, because it potentially
can mean that AES in counter mode goes half as fast in case encryption
is done in chunks close to AES_BLOCK_SIZE in size (because counter
will be encrypted twice for each increment).  I'd much prefer to have
a relevant portion of tmp saved somewhere (just like OFB mode, but
that one has an ivec to count on for that :-/).  A possibility is to
set up an vector of AES_BLOCK_SIZE bytes in AES_KEY, specifically to
be used for such purposes (actually, it could be used directly as
tmp).  It can be considered a hack, but will do the job, and more
efficiently for the worst case.

Comments?

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [PATCH] AES counter mode non-zero counter offset

[Matt Piotrowski]

On Tuesday 30 July 2002 02:54 pm, Richard Levitte - VMS Whacker wrote:

> How could num (or n, inside AES_ctr128_encrypt() ever have a value
> that isn't between 0 (included) and AES_BLOCK_SIZE (excluded), unless
> you do something stupid with num between calls?  Make note of the
> following statement:
>
>   n = (n+1) % AES_BLOCK_SIZE;

"num" could point to a value out of that range if it is not initialized before 
the first call to AES_ctr128_encrypt().  The fix for this is to clearly 
document that the value "num" points to is both an input and an output.  
However, this range of values really has no bearing on the bug.  The bug 
exists for all non-zero values.

> That program prints "success" on my system (a Pentium running Debian
> GNU/Linux).

Yes, I apologize for that.  I just ran the program on a system other than my 
own and it printed "success".  The reason it prints "success" is that the 
stack happens to be preserved between calls to AES_ctr128_encrypt().  I have 
included a new version below which makes a call to a function which mirrors 
AES_ctr128_encrypt()'s stack usage.  This should illustrate the problem.


Matt

#include 
#include 
#include 

#define KEY_LENGTH 16
#define TEXT_LENGTH 36
#define COUNTER_LENGTH 16

void mirror(const unsigned char *in, unsigned char *out,
const unsigned long length, const AES_KEY *key,
unsigned char *counter, unsigned int *num) {

unsigned int n;
unsigned long l=length;
unsigned char tmp[AES_BLOCK_SIZE];

memset(tmp, 0xFF, AES_BLOCK_SIZE);
}

int main(void)
{
unsigned char key[KEY_LENGTH + 1] = "9dfe5ea4c3f84ae3";
unsigned char plaintext1[(TEXT_LENGTH / 2) + 1] = "123456789012345678";
unsigned char plaintext2[(TEXT_LENGTH / 2) + 1] = "876543210987654321";
unsigned char ciphertext[TEXT_LENGTH + 1];
unsigned char plaintext[TEXT_LENGTH + 1];
unsigned char ecounter[COUNTER_LENGTH + 1] = "6543210987654321";
unsigned char dcounter[COUNTER_LENGTH + 1] = "6543210987654321";
AES_KEY k;
int num;
int retval;


retval = AES_set_encrypt_key(key, strlen(key) * 8, &k);
if (retval < 0) {
printf("couldn't set encrypt key: %d\n", retval);
return -1;
}

num = 0;
AES_ctr128_encrypt(plaintext1, ciphertext, strlen(plaintext1), 
   &k, ecounter, &num);

mirror(NULL, NULL, 0, NULL, NULL, NULL);

AES_ctr128_encrypt(plaintext2, ciphertext + strlen(plaintext1),
   strlen(plaintext2), &k, ecounter, &num);

num = 0;
AES_ctr128_encrypt(ciphertext, plaintext,
   strlen(plaintext1) + strlen(plaintext2),
   &k, dcounter, &num);

retval = strncmp(plaintext, plaintext1, strlen(plaintext1));
if (retval != 0) {
printf("error\n");
return -1;
}
retval = strncmp(plaintext + strlen(plaintext1), plaintext2, 
 strlen(plaintext2));
if (retval != 0) {
printf("error\n");
return -1;
}

printf("success\n");

return 0;
}

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [PATCH] AES counter mode non-zero counter offset

[Michael Sierchio]

Richard Levitte - VMS Whacker wrote:

> How could num (or n, inside AES_ctr128_encrypt() ever have a value
> that isn't between 0 (included) and AES_BLOCK_SIZE (excluded),

It's even smaller than that.  CTR mode is defined as a BIG-ENDIAN
128-bit number (AES only has one block size) 0 <= n <= 2^64-1

Chances are you don't want to abuse this -- this mode has not been
studied as much, and it's a good idea to produce considerably less
stream than allowed with a single key.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [PATCH] AES counter mode non-zero counter offset

[Richard Levitte - VMS Whacker]

In message <[EMAIL PROTECTED]> on Tue, 30 Jul 2002 14:04:21 
PDT, Matt Piotrowski <[EMAIL PROTECTED]> said:

matt.piotrowski> I think there's a bug in the AES counter mode
matt.piotrowski> implementation: if you pass a non-zero counter offset
matt.piotrowski> to AES_ctr128_encrypt() (through the "num" argument),
matt.piotrowski> this function will access unitialized data in "tmp".

How could num (or n, inside AES_ctr128_encrypt() ever have a value
that isn't between 0 (included) and AES_BLOCK_SIZE (excluded), unless
you do something stupid with num between calls?  Make note of the
following statement:

n = (n+1) % AES_BLOCK_SIZE;

matt.piotrowski> I'm not sure if this function is intended to provide
matt.piotrowski> stream-like services, but if it is, then I have test
matt.piotrowski> code which demonstrates the bug and a patch that
matt.piotrowski> fixes it.  I have included both below.

That program prints "success" on my system (a Pentium running Debian
GNU/Linux).

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
\  SWEDEN   \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]