In cases where the RPC from acvptool to modulewrapper is expensive,
these iterated tests take excessive amounts of time. By moving the
inner loop into the module wrapper the number of round-trips is reduced
by 1000×.
Change-Id: Ic047db071239492e416a08cab60d6a7e2905e8dc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47364
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
It's defined as GCM without a plaintext input, so this is trivial.
Change-Id: Id430e998447e489c2bf2dd5c6541877870104ade
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46844
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Trusty requires its own trusted app to implement the ACVP modulewrapper
functionality for validation. Separate the frontend from the generic
functions that implement each algorithm.
Change-Id: I86802b66c627ce4f5b5ddd54555a386e8e993eed
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45604
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CMAC-AES isn't inside our FIPS module, it's only included in
modulewrapper in order to test acvptool. Mark it with a special tag to
avoid it appearing when dumping regcap JSON because NIST paperwork is
such that it's better not to ACVP test such code.
Change-Id: I0c6d3a38bce9bf5766b889677eb3f7de94262c24
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45465
Reviewed-by: David Benjamin <davidben@google.com>
This is only used for testing acvptool but, yea, |memcmp| doesn't return
a bool 😳
This wasn't noticed because "ver" mode was missing from the registration
and thus from the test vectors.
Change-Id: I181c9b66aea4032543d39ebcc8728a01e0f34f55
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45464
Commit-Queue: Adam Langley <alangley@gmail.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CMAC is not inside our FIPS module and we have ACVP support for it just
for testing (other modules need to validate CMAC). This change makes the
CMAC verify test an explicit action for the module wrapper so that a
verification function exposed by a FIPS module can be tested.
Change-Id: I3943bde175f2c1d62881002b4e12d7bca68a9018
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45264
Reviewed-by: David Benjamin <davidben@google.com>
Revision 1.0 is this test is reportedly no longer acceptable and we have
to use the “SSC” version now. The documentation for this test doesn't
mention that a “z” field is possible, but that's what the test vectors
from the demo server contain and, after guessing at the correct response
format, this makes the NIST server happy.
Change-Id: Ic63d9e19998dc015733d847cd0330a3af1d5e7e6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45224
Reviewed-by: David Benjamin <davidben@google.com>
The NIST production server doesn't like this.
Change-Id: I22ce31e822107f176eb97f7632ea2777c6ab4a44
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45184
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
A couple of processing errors crept in over time. Caught by the tests
in the next change.
Change-Id: I0caa478d3321cb8a1da1e61ddde16ba8db91eb35
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44745
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This involves adding a new function |DH_compute_key_hashed| that
combines the FFDH with the output hashing inside the FIPS module. This
new function uses the padded FFDH output, as newly specified in SP
800-56Ar3.
Change-Id: Iafcb7e276f16d39bf7d25d3b2f163b5cd6f67883
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44504
Reviewed-by: David Benjamin <davidben@google.com>
This change tweaks our ACVP config to better match what BoringCrypto
has previously tested with CAVP.
Change-Id: I7d7ce5153a3eb7355ae1516f06ff591ee2c9d902
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44385
Reviewed-by: David Benjamin <davidben@google.com>
The ACVP MCT tests involve a double loop where the inner loop iterates
1000 (AES) or 10000 (3DES) times. This change moves that inner loop
into the subprocess. This significantly reduces the amount of IPC
traffic at the cost of making the subprocesses more complex. The traffic
volume is unimportant when talking over a local pipe, but it's
significant when channels like serial links are used.
Change-Id: Ia9d51335f06b743791f7885d366c8fd2f0f7eaf6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43844
Commit-Queue: Adam Langley <alangley@gmail.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Use empty() over size() == 0, and don't export the IterateAES*
functions. (They return private types.)
Change-Id: I8a8f33a64e28cc2eab789563c6ba91afa6df87f9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43544
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I7636736752ac371fc8d86fbc6bf81ca797ac5092
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43127
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Due to a typo, if an unknown function was requested it was previously
ignored.
Change-Id: Id815c4b7e80d1452034b10bf9c7beb80a5ac3ed2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43125
Reviewed-by: David Benjamin <davidben@google.com>
Sending empty spans tripped up the code because it never considered
the iovec to have been sent. Instead, filter out empty iovecs in the
first place.
Change-Id: I48ea2a887ca64c73051346f3096735c30507525a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43124
Commit-Queue: Adam Langley <alangley@gmail.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>