AES-XTS tweakValue's ending in FF inconsistent behaviour

[JonathanPlata]

AES-XTS TweakValue incrementation implementation and potential overflow issue or misunderstood implementation.
It appears that something funky is happening when tweakValues end in FF. In most cases, when incrementing the tweakValue
we increase the first byte, i.e. C8045F5CD2E19A2FBA4C6A667C09BA01 becomes C9045F5CD2E19A2FBA4C6A667C09BA01 and this produces the correct output.

Now to the issue: when the tweakValue ends in an FF byte we see curious behaviour.
A tweakValue of 5596EA2B811D0CC7AD7EBA441AE2EAFF incremented to 5696EA2B811D0CC7AD7EBA441AE2EAFF produces an incorrect answer according to the sample responses.

However, if you also increment the final FF byte as well (i.e. 5596EA2B811D0CC7AD7EBA441AE2EAFF increments to 5696EA2B811D0CC7AD7EBA441AE2EA00) produces the correct result. It's unclear to me if this is intended behaviour when it comes to tweakValue incrementation or potentially an issue with endianness and overflow detection.

Example:
Test session: 455845
vector set: 1955839
Test case: 158

Initial Tweakvalue: 5596EA2B811D0CC7AD7EBA441AE2EAFF

Resulting first data unit (this is correct according to the sample responses):
892485706A20A4A38B103F6DFEBFF3124918C7615F459767DFE170018F6135D758958B2B25D19FCD2B210AC9347191F0D98911353FC64D2C1CDEC86062477719D68A3E11C687C9BB3F1432A2DF3203D67D9CE4FBF4BB63FA0536C2DB841D051D6875E91EFD86E0A1FDDE8ACB88E20D4CE35252D9F0126FD93B61B22565A6F08247EE0B7254CA96B154C27AC86A64D6446FA3F5218CEBDE4B004D75E75B6D9AB621DA22D36327F8A8A7869DEB3C016BCD9A960F9FC74AF04A5EC2FA022325B5B3EBFCB423C89CEF129D78387786141E65E551B59E0BA520A4596C52C6204B14AFA56521BCB0FE0B613E2C357ECA97054BF382BAF56C4722D8B04DDD021EC2E89C9A59BC5F7D06D80240D6DF4A6FC3D8C987E9E61DBA0345FA415329F1A459145D9ED0106ED9E3834B43BBF231A7B10BCD4E109A3E955FF0568BCB5960EBF359D38598BCED2C8298A7980AE8A4E7165B89104E994D36604E7487070E5EF6FF3CCA2149CCC8DE5E8D6E6C101C95014A7847E5BAA6C12560955734D174227440AD7E04FE5580CB0A88E30062D9548AFBC2E2591D02828661D75B0A74C32B86D87C1BFE0A602AE3E4F37F11327904961E940AEF5E5E6D0A240C24F72F6B7B3A59F3D3796736E16A4AC43564A26D6A0C6FEB4C4F0FF07EC6D18B2F1412F4BE4405EB47B2EDA6D88BB0F40A8FBC04A8FF08CCB2CE4CA8F6B5E32D07969254695CBA6A09C71E16C42B11C704281EE71D3A0BE0212AE49C4411CFC228C7C5E9E57081590342A3B63D69A211541FB721FC28FE22B0ACC4F5DF38216BA8F0B1348577D713C515C8C121AD20DA09F02FD327B1BC12C98BD87165E295B8221E3DD583E4C1A98E640B4568CCA5108D92F58BABA0585388BF85C2EC305ACC639F0B78C6DF1EE18B517AC69D5C2EF729E9BE03275D2B88E1672E2EDC33098710D76FFA5EA4D85B7E9989AF4EE9FE1C6591EE79A904F89889EC600B04E99D49C0FBDA76A4486967026CE776F72F66DC4C0E51AA4CA2FAF2434F9678DC8383E585319E52C0DD0E145CAF43156E5004B518446398BC41D10785602A040EBB138D8CA4E95AE025CEAB32C686DED5C20D49E90D792AF2E481284993B21CB361D63DEA724AEC912D18F2618035BDC3171DD348A45D2BD5258670095FF714EFBE8F1BD7F73E50C44917C019E0502F668D0562A8C0A8FBE8C2DAA92901DC457FB7CE107A4D8905CDC95E7CB0320432B85F13DDF1A2F3E14FC40196F8CEAD79E249E08D32243F43B6D753DC725081E7B60A16D2607E72913D039718CC19462C49F2218AB8061E1F73CC032CC96C0A4513516E54D32746D30B3FC192FB882EB89C1CDCE2DCB74EB7472B811F600D1BB56D9FF7094F1D745D147877569994A1553AFE550A7156F4B4BFD178018EDD836475C18121D9BD2FC82673398D0917EFC733CF6F40170249B84E57BE35C841B79AEFC8B4092A3E55967FDC8F3F0D69A7B943A137468F002064526E048BA74C9D450C2741BD2A4802765E2A783F5C6A53EAD47F0ED659232CDCBFD41A6AB838B2A3971161CF906F1EEBC7F17A470804E16543F8CCB35DA5CDFB6DB78DE00C023DC7B240C348B7B138CCF6816A41EA9514F823EFB6D1AD1160C14AD8A2D380190BB968D6A5C2339687DF78F6E883454CA62994DE8B982D7AA33C87994B7A13D565AA15F473E41681326D9D5ED15533407C573F3657D6288B8E22595826ABC3E14B25F38F009845DBB5A6963D05540207FFD4ACB1790E47E2309A9D31F8E55A767FDC393969A0A42D0FA473AA7BD809D535A002947CA3EAF4B42A4307283B17547347B11EB49ADB486EEC933C633A2B08D2CA10556678DA33D375822DBE566363B877BC78439EA501715175129F9653F8DCF2BD43852449AA41D3675C487291961CFC04D4D16908E650D73A0C883373818D45D574ECEEB336B286AED5C3765C2163C8D5AB061D14F60CEA325BF93A44A5F54E09366A36F859143E5D1E3B2B781340F30F1A7D580875BCC4F5A325428655FDB1B0A93B8ADFCF96843BBBD04919FAF331882BDD65939993EEA3F840ABA0E211A13BB1EA0C86CB91F34B229CFE18484EA319839F591E091BCDA792B3F0F08B8AE3BEE033B47E2CB6E5BC6EE6194C39D3C3D810C7CAF3EBC50777305641431EBE5D3BDC8BCDA30C8FD9F6EB73A545DF1BFDF542AD5A97AD0B98C186A0B7AA2A59E051CEE07F929D9591498AC2DB2730BC3AAB0F2BF73F7CFFC4BC3CB50A8EAFD5F7C9CD77AC13534D07C2422FC02D9D16C2A60E74B616DDEE8BFF3846DD381A9917A54ABFA88FEB0060F27841C711654BE61762342A0A68422BC2BE18A9E0DAB54EDB54436F5999BD8821B02B8F5A884216A7C7CE4D49B0110E6A93DCA02725C9F6F3ADC94CA7DCB2AF465EA946A18B2CAB745256B0C9B552E979694BBCC6877309CE780579E293ED20E9D597BEE5BBBB224231F59AA4C78E627BD6AF0CC7EB15EB04BC0304C7AFA541B8D82D107D8FC3A1C5D62A490AB57354C53C3979E6DE51BAE31B9B07DFB1A12586B003F5205AB3F0D58DFC0F3A9C224A3FEE36E658802EFF1483A8B021982EC9C6664D7C3F85A048A5AF3268AD3D69CB3E9942D0E2A002CD7B3C377DE9C19096178FEEA5829242E9E285E145283EFCF69DF05820F04F8A128C1A97B8BDA9D649FB363E1AED6511398D05695AD40A8CB695AFFBB548FC91F6BBEC6A4E5BE15355ACB5203C719CDDEFD295B46D9C3C14955E5E87A55B6C0A47B203C6C72FD6B31661A16E2FB7C896A937A30B1AF8CD24812791355B62C71833918590E1637F229ED8B4301FFDDFAFE339EB1D0797D09B559C7C0449C09AB576E48A5FFD748F1E610B0B1D8CBB3CB32D558F21DEE3280E7A0DA500873B1E8F630AEBD6B118306B04FEF1170040581E923ED82105459C2D129

Updated tweakValue: 5696EA2B811D0CC7AD7EBA441AE2EAFF

Actual Result produced by iuT (using updated tweakValue: 5696EA2B811D0CC7AD7EBA441AE2EAFF)
77afb537bebf14faf2e900c3da7d32df2e8b424157bb347c0449bd1b3a7342eec5409227bbd80eb7a2c2b0e179303e3fec8b9873d63941b138c06845a9f88895502f0ef8139b2ea6adea77cb6fc8fae4e5d29068ddb916bdd73eedd67f5026ce63e9e31e372e6fc8e281c7cb87d4fa553ccbeae27e1466ee1a546d24922e2757738a9f1ebefdc1e0386003a70a1667a6364abca73c4167409de47f302fe9315ca7cd164568658117589c520060d956e4518faadf57e8e17785760cccb69f23cacdd04cdd803dba281bda281f66b622ca3b3275db01e09e2a7c6d24692ca1b7d2c988bdc1ea94cbff79b5b9504b2c4649c07599530559795833329964d8d242fe58cd177782bd344c0a8407cf4b6cd15db1042394e6ae213a68473a723ccb2d3a79cf3547ad02a0909089bf842565d7ff0facaebe4894eb933f363abbbe034c1cf74c8a65a11a789952f632311e1cea8f8837487180d1cfab80d88b0a68757d0e31747ecf6c7e42a9c68e91a0dd41bb330c23d494baeb3efe7146a9ba8780ab22fc97bb736123f7fcb46262fa6bed6ffa3a8883fccf32edfb0e68a2bd04c7add5c9808e46cc1dac1ef323a029ac01ed6d607e5d6cc1e3184785ea5203f6a1601dcd7f3a9915cf4273ad426b9943ae147e282ecbde1c9dc45fa2788917e3376758567913adb4fb3d23a671b6318ff079ae1ebd688e829992b3

Expected Resulting next data unit from the sample response: (using the tweakValue 5696EA2B811D0CC7AD7EBA441AE2EA00 produces this)

C742EFF79A677F303AD71655C67235A83310AA8CC8336DEBBC794D03D036503B798979E60F81745C93388AB844327DAD3B025FEA913576520766058D9EFEC5ABCD3C29A8FF66AA5720075929DF76D92B904370C628D5965DC0369BA68165B761B2478253B65BEB0D41D29DF487A0028E36FA113D0B11005F3450574CE5C41E403F81102AB45263C60191737BE443AE5728900DDD33797792B92DD75A6BCA42191F0DABD53E1CFEE62483B067663EF8CD2382F59509444444576030FF50F23143329E9C4616EA760B4BB188DB9D3A99848046DC15E00E6CD1D64516B21F2A73B1DFAD89FC01D19B7AB5EAE6FD8DABC12C641B8B3817CCAFC6489876E2012B869BB27EE9CF959A0CCDF5AE4B208F2628F30486E6A2268A24118F4800D3BA9A4C4C54EA9A125AEE843695E1B249F4175D9D66C634B91F029F56F84396A7D1ED9B18BC890F42EF20ACBAAAAA7F715F145F15F5494487CED4F89C278B8051E2C34241D5CD065DDB658A97E4A9329D1F9121E199220DD979588E68B178731BE46A597240F19FAB341B3C145E927712EE62D8DE59C59C6023284BE7753E1227EA15D92EB68ED1BA66BB0F3932A6B29579B18D53907F579DBDDED54620D67FE2A530006F077E2B4BC4C9C2786700EF868A7AF0AE308E12F07D402658AE088CEB717A30BD78C1E4BE4775FD0498A25BE047C04C8A5AB569CECC4745AA2C

To note, this implementation is producing correct output for all other test cases in these sessions by only increasing the initial byte, and only failing on testcases ending in FF.

[tsc-n]

We (NetApp) have also observed the same problem. Any tweak value ending in "FF" appears to require an "overflow" addition to "00" when updating the tweak for n_blocks > 1, where n_blocks = payloadLen / dataUnitLen. We believe that NIST intended to catch errors when updating initial tweaks of, for example: 0xffab987f...

[livebe01]

I'll take a look and let you know what I find. Thank you for providing the vsId!

[afazio2]

We observed a similar issue here: usnistgov/ACVP-Server#302.

[jbrock24]

Hi everyone, I have found the issue out and will be implementing a fix that will go out with the next release. Sorry for the inconvenience, and we really appreciate all the helpful info, thanks again. Once the release is out, we'll comment here that it's ready for testing. It will move to prod a week or two later.

[livebe01]

The fix for this is on Demo in release v1.1.0.33

[livebe01]

The fix for this is on Prod in release v1.1.0.33