The OpenSSL implementation passes the NIST XTS compliance tests ?

XTS was designed to do in-place encryption of blocks of data. (disk encryption etc).

Feature rather than bug ?

Pete



-----owner-openssl-...@openssl.org wrote: -----
To: "openssl-dev@openssl.org" <openssl-dev@openssl.org>
From: "Greg Bryant (grbryant)"
Sent by: owner-openssl-...@openssl.org
Date: 04/26/2013 11:32PM
Subject: AES-XTS mode doesn't chain between successive calls to EVP_CipherUpdate?

I sent this to openssl-users a couple of days ago, but haven’t gotten a reponse. Perhaps it’s more of a “dev” question:

 

Looking at the xts128.c code, it looks like the “tweak” is recalculated from scratch every time CRYPTO_xts128_encrypt() is called:

 

memcpy(tweak.c, iv, 16);

 

                (*ctx->block2)(tweak.c,tweak.c,ctx->key2);

 

It seems like this would break the chaining between successive calls to EVP_CipherUpdate, requiring that the plaintext be encrypted in its entirety with one call to EVP_CipherUpdate. Other chaining modes preserve the chaining state in the context (CTR mode, for example, saves the ctr in “IVEC”). There’s nothing in the XTS context structure that would preserve the “tweak”, though.

 

Am I missing where this chaining occurs? Or is this a bug? Or is it a requirement that XTS mode only use a single call to EVP_CipherUpdate per data stream? (which seems to violate the definition of EVP_CipherUpdate.)

 

I saw this in openssl-1.0.1, but I’ve checked that the relevant code in openssl-1.0.1e is no different.

 

thanks,

 

Greg Bryant

Technical Leader

Cisco Systems, Inc.

______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org

Reply via email to