RSA DecryptionPrimitive Sp800-56Br2 Vectors, expected and generated plaintext mismatch

[prashantawde]

environment Demo

testSessionId 376767

vsId 1527529

Algorithm registration [ { "acvVersion": "1.0" }, { "isSample": true, "algorithms": [ { "algorithm": "RSA", "mode": "decryptionPrimitive", "revision": "Sp800-56Br2", "keyFormat": [ "standard", "crt" ], "modulus": [ 2048, 3072, 4096 ] } ] } ]

Endpoint in which the error is experienced acvts.nist.gov:443

Expected behavior We have generated a set of test vectors from the ACVP server for the Demo environment and run them through our in-house harnesses to test the client's application. The majority of the "plaintext" generated by the client's application is as per the expected results. But we got a failure for a few test vectors. While observing closely we have seen the following finding,

Case 1: tcId 8, 18

"Expected plaintext" and "generated plaintext" is the same, the only difference is "Expected plaintext" is prepended with "00".

Here expected plaintext is "0095410A501C3F92059DAB8E293D5B021AAF2E5E61E649EFD4BA9665F8956BFBB2721C39B4A0496195C8D4BF70655D7020442A21E3198F677186C209C4F1596005CC53242AB4A6D43189C9A34A5F12DC940833A7D7A14C101731CA1C9CADEED7D9820F5EB38827F280F54A58DF3D9DF43E968142048704848151C786B7F08389EF38DBB09CB4EF84B514F1725D326D0C874806E3054755D0365C161B1E3BC7C691B9F24254C82EC030A86A3936C05A85C07A2D46D1EC01299CE4CC3301230F7D8BA0A5D0760E3B3FE2892187698C28DADAC15907406AEB0FAF55B0AB1F0E52BEF338FFD60A87A82C5E69EA9A74F594F90E338D5478207969191137270ED9AD8E2C"

and generate plaintext is "95410A501C3F92059DAB8E293D5B021AAF2E5E61E649EFD4BA9665F8956BFBB2721C39B4A0496195C8D4BF70655D7020442A21E3198F677186C209C4F1596005CC53242AB4A6D43189C9A34A5F12DC940833A7D7A14C101731CA1C9CADEED7D9820F5EB38827F280F54A58DF3D9DF43E968142048704848151C786B7F08389EF38DBB09CB4EF84B514F1725D326D0C874806E3054755D0365C161B1E3BC7C691B9F24254C82EC030A86A3936C05A85C07A2D46D1EC01299CE4CC3301230F7D8BA0A5D0760E3B3FE2892187698C28DADAC15907406AEB0FAF55B0AB1F0E52BEF338FFD60A87A82C5E69EA9A74F594F90E338D5478207969191137270ED9AD8E2C"

"Expected plaintext" is prepended by "00", it seems two additional bytes were added here, it also results in the total length of the "Expected plaintext" to "4112" bits, which is not aligned with the requirement of "4096" bits. however, "generated plaintext" is having "4096" bits length.

Case 2: tcId 6, 7

Here we are suspecting the length of the input value "d" which turns out to be "4080" instead of "4096", which results in wrong and different plaintext generation while running it through the client's application.

{ "tcId": 6, "ct": "94B8E39B6A4695DECFC11A858F51D301FC12155834B476326ED26866179462F196A51F40A9923B218E21220222B5EFE7EFE9500D69FEA6B3F88C2DA6682400F1C43C3B7F38C3EA4C1F7F56DA686FBE9C78D08A1885262DD125580394DF5BA0E5FC8A71E15168B77A01D63497CFCB0CFB200D010809FD7B361D8DE8F03DEC22541626A6746ADFA97AD99416015D4B5E0D49408002AFB70BA3FFDCC0FBE2900E17D791E32ED9553CA00FB1C014A17B13DE88CA814B04FAE5F9557FCAA780B82B99A9B77C702AE6D7CA8C84FC94B16023CA8441B30D2AB7CF53010D14B120C8250C457175C445971F3CD7AC02D34EE7076930EB6FA5C5710B1E7CC1074A22AF778F", "p": "FB567CA4DA04AAAD7E4741BACC61C03810B817DCC4E9A5D4102E3931A2B9D6727662B4809E2649BFD2C8E37BB21BEC8CC2928307C14A0DAFD71ACA23C37C7562C2F3D6B9ED83CA93C0D826D2997CEFDB51FCAE181C99664D1BA20469BA0997F89B7CF7A1F63E8970AA9FA027972952DB83842C5B7510DEB995CDF777F3753361", "q": "FF06A24AEC604F0D5EB7E761B70DA3E0F7451F949C86594065C0704B1895BBCBBF38FF246E41B993AE8226C6E8FB5FBF005B05E53E2EF2FF2B108BA5F4FD90847ECF5C16CDA43CFD2B5DC28F858450F1656549A91A399B1C4FCDC9AA3EE4F17111AB4B39ECC42449051F1FD94A42CCF4BACA89E56FA130C90848DBF2EE411D4B", "d": "7A75688D24D287D91EF62683EE124D62DE5334B82EC1483CFCE3021B588F29ECFA07257A7DA0FB57F0930FD4A77A664DBA93A4DA425871AC8E4E192A13157F7D73961A857F286FA754F01946B0A6EF5D19CF5FEC922E9B9C5C0E445C4F31D00EDEF52A7E8F86FD5DA5BE4F80849B5079FD4D47DA4D02743797AF0E31736E23E47187FD231A902D8849BD645021E1301A5CE78B82512DD48914785B6ECCFE0A75A7C25E3FF45CA55099627AF852710CDC8C014CD8E83DA74C2D8EE8939839EFD88194009620D5998AEA7E8F92AF4DB26E28CADBD26DA4FA11349D4B005F8B43DE37FEE94553A22FEA1E005802FAFEB37A0BB1B8E5D93B8410C42742E57C8427" },

           {
              "tcId": 7,
              "ct": "89E3FA378B4D4BBA8F36E9E25569E91811D57ABF515989F4F970CED84FE8449E2ABC151BAD26649F4BC14E69E11F039BCEB13CBDF3093D9EFFA75DEFED977BDE9FCB015904B8C94D936EC88EF8889B575FBB6FCAC7E46A2C1619D37674F70E144F47F17D7763573E7B03A15D3653B8D31ED1E7FBABCA25914879BC5BF6455135CCFFE1B05BB92946B71B94EC75B2A5D275CABBC52CDA1330F84C37A0A90E5910F01710DC252D9DD99713D6BFFA1DDE7F1966694F55414CDDDB06DEF893C05A8DDA8F0A5332BF38DF1A100679B7EF37D645CA60049B339FFA6B439B5E0DB7EA9D8C8DAE32F4234A7A6A0583F53BB7207765ECAF7D5DE61B88C2FF777D3AA3E49E",
              "p": "C0BC3EBE748C529FC07916D89BF31BC41A11A4E7FC83D7C404CC5C9B8A7910228715038B4DAEE3A9DEE77AF24FA347BEF17C22B4AA31D6C4478C6D583630863A6B657BE2B10C403CC54E19D3471E50712492CB11B47C8703F7B5978EEBA9F8F7BAC2119F146B50BC8DD6303135CE79DF1A59012E2841FD7D05904E02C9CE13F5",
              "q": "DAFF0F302D5A94F1F36244AB1F68AC7ED8DB765E4E9A909F85C82E636985880A75F23A5CB948FEFCD58E10195DD968D5D71F7DC54AB931145BC8782C576A80037CA184883D849E55A1C1177FAFEB68FDF485CDEA8904ABFA7A78E0579DA0BEED0EBF05C5D65D5AA50906CAF6B4AC8D3C2016CC15578FC381665BE5982AA75C6B",
              "d": "1A2C3C0D798CE11AE4AEA948BA77237903E2FB3112F2E66D02DA3C629B3FA4195B784B52124C1F984D8F693243AC00D4577919030001FC8E47E290E8AFB50C2E4FB87485166184FA890BA9D3EA816B2C0BFF31829BFE5AC1E6E81C375137941A15799CD1FE019CB3F762B525C6E8F55A5F0D19B6C7E1F4BFA9C300E01C865409AFDC8613C030DF840610B2947EC7A68E1FDDACD4F5FF0408FD2F8F21D06BD3104B8EC97DE6ECF0570FD6EB2145EF205AF664F3447261B82710B92066C82553ABF1412DE7E21CB0086B567AEE3C162332A40CF6E69961885387A0FDB0D4498F5F25FDFCFE7B3CDAB285DF24EEAD6FE3AACF2C4FAAA63DFA2DD92069CE29BC63"
           },

both "d" values turn out to be "4080" bits in length.

Vector with proper results:

{ "tcId": 5, "ct": "19397BD9A0A0ACF4F74F3B68E0E26FB073649FC1CDDB846198C8B9CAB3A6FB2C57AC94782BB6D2174EBC2AFC4FD732D8F752588CAC6DADADB2A68F72B7FBB1214B8B4013BA6702CBF04C2F7A893708273B71C564C847B897BF4FE02E82C3637E36B33457FF6E49BDB620D465056DFC92D511351B79E7D57FE340810424B9ECC4B134E786C9DD39718D3E4C9DC79CD8415305E86E8815B31E3AFE3539DFD6FC03BE9B01DDAE5098BE7FBD312C06107D197960DB21BDAB60B21296D7629CB92EBE6A52AE45B552A22E26A519E9C8C5B41160D2F20E9567556CE1B630507FBE6399A6F9F2BA21DEEB6C6F70881317426943E656200052D5B75D0DD023A1BE119FAF", "p": "EC383EFA7587352086D68674647D10F90F8907D33D53AC213D66BEC436FD2585B274FE74E0FDD6933C79442BCF65C72AE281228E47094FEBAC1FF84B1A719ACA0256DA2CA8F27B32174FDC8C3F594035B1D936D0C727DB8CA0A7675B2FEDE219068384109A79041852EAB52395EF92137A2739FD8BA04D876774A5AD0BCD1DCD", "q": "D894EDFEE958D7EFDC0E570C89E0B68616CCC1ADC9F4BD63104E2F9D985FAAFC282C59D39E1240431998134452FC69ED14F4E7B2AC00A132678B112A9BF088EF53AA08F2CECB7BFD7E6EAE6B2624EF2278CB8E204FFEA6311F289E1A10BFB1C7043A69421EE1B8A21536B05332C15A06A521E94DB88C29BCEC27D4866D91342F", "d": "1CC668EB6BB9E27B4FED22D83534353A54686DF60BB1C9A169736E38EFDEF74EB7AC3F98DBF9725B4F5C7AE42982DA1140DAE25DF00695F1F3FBB7A1C2B41E75B055AB2106BFC3CA4697FFD1F26C490EAC1CD71AD75D22A95AE2274654CBC0A93ADB1465F6A7BAE0EA459714625CAFEEADD747DA6BA6DE281D9FEDBE3D94A7481FC95214F14BBAAB6CF1AE64586A6EDE6D093EB39D3954B146A8C60A761717E176DDAA640D08BA28C27303100A1C0A72F748047B7D59D1ADC110B084BF0C7B57B1B6292BBFA0782188E554CB3730E359A1CCA94ACFB9E1FD2B8ADB3342541BEF38A15348C40A4C7335A53072DF8DFEBBC05D803593DBCB6785B379346A270BD5" },

Here "d" value turns out to be "4096" bits in length.

your guidance will be helpful here, to use any workaround or to fix this problem.

Additional context Referred documentation: https://pages.nist.gov/ACVP/draft-celi-acvp-rsa.html

[jbrock24]

@prashantawde I'll take a look at this and get back to you.

[jbrock24]

@prashantawde Thanks for making us aware of this bug. I've found the issue and resolved it. I am currently implementing other changes into this algo as a HOTFIX, and it will be released as a part of that. In the mean time, you can safely remove the added empty byte to continue with your testing. When the HOTFIX is released, I will respond here and let you know and close the thread. Thanks again!

[ehanson12]

@jbrock24 is there an ETA for the hotfix? Is removing the extra byte a valid technique for official runs with production vectors?

[jbrock24]

@ehanson12 It's currently set for review this week, the code is done and just needs last testing. It should be out shortly after that with the next patch. The extra byte removal will not need to be removed by the user after this update as I've fixed it. This algo isn't in production yet, and will not be for a bit of time after it's released to demo for testing. Once it's been used enough and we are confident it's working properly for the population, we will officially unlock it on Production.

[prashantawde]

Thanks for the updates @jbrock24

[ehanson12]

Thank You @jbrock24