summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/dsa/dsa_gen.c
diff options
context:
space:
mode:
authortb <>2025-02-08 10:12:00 +0000
committertb <>2025-02-08 10:12:00 +0000
commit6c52bae3df522ccb0c1f2d5138b4c0c6bad8152c (patch)
treea2c0f3c491127e4eb760af97a3fc828a3b541fe1 /src/lib/libcrypto/dsa/dsa_gen.c
parente5c3598995f7ea0447aa4041ff08a6e099042a22 (diff)
downloadopenbsd-6c52bae3df522ccb0c1f2d5138b4c0c6bad8152c.tar.gz
openbsd-6c52bae3df522ccb0c1f2d5138b4c0c6bad8152c.tar.bz2
openbsd-6c52bae3df522ccb0c1f2d5138b4c0c6bad8152c.zip
Cache CRLs in issuer cache
The issuer cache holds a pair of SHA-512 of parent and child cert plus the result of the signature verification. Since CRLs also have a cached hash of their DER, we can easily add them to the same cache. This way we also avoid the cost of repeated signature verification for CRLs. For ordinary workloads the cache is larger than necessary and it won't currently take up more space than ~8M anyway, so the cost of doing this is negligible. For applications like rpki-client where the same (CA, CRL) pair is used to verify multiple EE certs, the gain is significant. In fact, the current worst case is a single pair being used for > 50k EE certs, responsible for about 20-25% of the total runtime of an ordinary rpki-client run if a hw-accelerated version of SHA-2 is available and even more if it isn't. In both cases the cost of processing of this pair is reduced by more than an order of magnitude. The implementation is a translation of x509_verify_parent_signature() to the case of CRLs and is entirely trivial thanks to the cache's design. Found while investigating a performance bottleneck found by job tested by job ok beck
Diffstat (limited to 'src/lib/libcrypto/dsa/dsa_gen.c')
0 files changed, 0 insertions, 0 deletions