HSMSigner: Use pre-hashing #548
Conversation
jku
force-pushed
the
softhsm-automation
branch
2 times, most recently
from
85adbc3 to
c1aff18
Compare
|
I just tested the speed differences and the pre-hashing is so much faster that I'll expand this PR: let's pre-hash everything instead of just softhsm payloads |
jku
changed the title
Two benefits: * It's faster: devices like Yubikeys don't like being fed massive payloads. signing time for 100MB payload goes from 29 secs to 0.4 secs on my USB A hardware key * Testing becomes simpler: SoftHSM only supports pre-hashing so the tests needed a mock patch to handle that specifically. This is a bit of a pain for applications. So: * Use PyKCS11.CKM_ECDSA mechanism for both supported schemes * Hash the payload according to scheme, and feed HW the hash instead of the full payload * Remove the test patching
|
The potential impact of this is that we now expect hardware to support the pre-hashing mechanism whereas before we expected the hardware to support the two other mechanisms... I don't think we have a lot of insight into what actual devices out there support: Yubikey at least works both ways. |
Given the insight we have, this is is definitely an improvement. If we learn later that we need a fallback in either direction, we can start asking the devices for the mechanism they support and handle appropriately. |
This PR was previously only for SoftHSM, I have extended it so all signing now uses pre-hashing
Two benefits:
payloads. signing time for 100MB payload goes from 29 secs to
0.4 secs on my USB A hardware key
tests needed a mock patch to handle that specifically. This is a
bit of a pain for applications.
So:
of the full payload