| Commit message (Collapse) | Author | Files | Lines |
|
A Certificate is a pair of an RSAPublicKey and a particular hash. So v1
and v3 differ in the hash algorithm (SHA-1 vs SHA-256), similarly for
v2 and v4.
In verifier testcases, we used to load v1/v2 keys with an explicit
argument of "sha256" to test the v3/v4 keys. This CL switches to loading
v3/v4 keys directly and lets load_keys() to handle that, which is the
actual flow we use in practice.
Also remove the "fallback to v1 key" in the testcases, which is not the
actual behavior.
Bug: 30415901
Test: Run the verifier_test component test on device.
Change-Id: I3a2baa64826f1b6c4c367a560090df384c4521bb
|
|
This changes the verification code in bootable/recovery to use
BoringSSL instead of mincrypt.
Cherry-pick of 452df6d99c81c4eeee3d2c7b2171901e8b7bc54a, with
merge conflict resolution, extra logging in verifier.cpp, and
an increase in the hash chunk size from 4KiB to 1MiB.
Bug: http://b/28135231
Change-Id: I1ed7efd52223dd6f6a4629cad187cbc383d5aa84
|
|
This changes the verification code in bootable/recovery to use
BoringSSL instead of mincrypt.
Change-Id: I37b37d84b22e81c32ac180cd1240c02150ddf3a7
|
|
Bug: 27135282
Change-Id: If53682b591397ddfdb84860a3779b612904d4489
|
|
Bug: 26962907
Change-Id: I5f80636af1740badeff7d08193f08e23f4e4fee1
|