you're missing correct sig implementation. Both RSA and ECDSA have subtle issues that can lead to private key leakage (RSA-CRT bug, dup r)
-
-
Replying to @hanno @RichFelker
these are subtle issues that can't be seen with limited functional tests, but can be prevented with careful implementations
1 reply 0 retweets 0 likes -
Replying to @hanno
I was grouping this sort of thing as exfil, but thought it was practical to run tests for.
1 reply 0 retweets 0 likes -
Replying to @RichFelker
RSA-CRT bug means if one calculation goes wrong you leak a key. This may happen after 10 million sigs. or if the device is too hot. or...
1 reply 1 retweet 1 like -
Replying to @hanno @RichFelker
you can implement a countermeasure against that attack (verify sig before exposing), but you need to see the code to see if it's there
1 reply 0 retweets 0 likes -
Replying to @hanno
I guess this means the device you use the module with can guard against it, but loss of physical control could comprise key.
2 replies 0 retweets 0 likes -
Replying to @RichFelker @hanno
I wonder if any drivers/sw for usb crypto modules implement this protection.
1 reply 0 retweets 0 likes -
Replying to @RichFelker
that would be very wise. interesting thought, because there's no reason not to do this, you only need the sig and the public key for it.
1 reply 0 retweets 1 like -
Replying to @hanno
Further thought: is it still possible to exfil key via padding?
1 reply 0 retweets 0 likes -
Replying to @RichFelker
I'm not aware of any padding attacks that can leak keys. They usually only allow decrypting or signing with the key.
1 reply 0 retweets 0 likes
I mean if a malicious hardware module *wanted* to leak bits of the private key in ways its creator could recover.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.