Thank you for your reply.

All test vector in  are 
byte-aligned . I've tested these vectors locally, and they're all pass. But 
it doesn't have a non-byte-aligned vector like datalen=250bit in  We 
can found non-byte-aligned vector in
.  All byte-aligned vector in
pass, but all non-byte-aligned vector are fail.

在2021年5月20日星期四 UTC+8 下午1:07:48<Jeffrey Walton> 写道:

> On Thursday, May 20, 2021 at 12:38:14 AM UTC-4 Jeffrey Walton wrote:
>> On Wednesday, May 19, 2021 at 11:53:54 PM UTC-4 wrote:
>>> I intend to use Crypto++  XTS-AES for encrypting data.  I tested XTS-AES 
>>> with the following NIST vector and got an unexpected 
>>> CT= 54a8629d76db46d0c516fca52c9c903baa3a635ddd56f09760f63252c8b46140 .   
>>> I call the following function:
>>> XTS_Mode< AES >::Encryption e;
>>> e.SetKeyWithIV(in_key, KeySize, in_iv, IVSize);
>>>     StringSource(in_plain_txt,svSize(plain_txt, 1),true, 
>>> new StreamTransformationFilter(e,
>>> new StringSink(cipher),
>>>                 StreamTransformationFilter::NO_PADDING
>>> ) // StreamTransformationFilter
>>> ); // StringSource
>>> My questions:
>>>    - Does  Crypto++  XTS-AES  not support non-byte aligned data 
>>>    encryption and decryption
>> XTS mode should support non-aligned data. For SSE, it uses _mm_loadu_si128 
>> and _mm_storeu_si128, which are unaligned loads and stores. The class 
>> also uses 'GetWord<word64>(false, LITTLE_ENDIAN_ORDER, ...)' and 
>> 'PutWord<word64>(false, LITTLE_ENDIAN_ORDER, ...)'. The 'false' says the 
>> data is not aligned, so a memcpy is used. Also see 
>> We've seen some trouble with bad code generation when two pointers happen 
>> to be the same in strcipher.cpp. But I don't believe XTS uses it. Also see 
> Something else that might be a factor... The head notes in xts.h (
> says:
>     /// \details XTS mode is a wide block mode defined by IEEE 
> P1619-2008. NIST 
>     /// SP-800-38E approves the mode for storage devices citing IEEE 
> 1619-2007. 
>     /// IEEE 1619-2007 provides both a reference implementation and test 
> vectors. 
>     /// The IEEE reference implementation fails to arrive at the expected 
> result
>     /// for some test vectors.
> That's a bad sign :(
> I keep the programs that are used to generate test vectors so we can 
> always establish provenance if needed. The program is located in one of my 
> testing GitHubs. For XTS, it is located at 
> The test vectors we use are located at 
> Looking through the test vector, it looks like we use both the XTS test 
> vectors, the XTS reference implementation and Botan. Botan is Jack Lloyd's 
> Botan (, and we use to to add 
> additional test vectors when we feel there are gaps.
> Jeff

You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To view this discussion on the web visit

Reply via email to