[Cryptography] Vulnerability of RSA vs. DLP to single-bit faults

[Jerry Leichter]

On Nov 7, 2014, at 1:54 PM, Michael Kjörling <michael at kjorling.se> wrote:
...However, I think the above sequence
> ...However, I think the above sequence potentially misses one failure case, namely the stuck bits case which I mentioned in my previous email in this thread.
> 
> Thankfully, stuck bits is fairly easy to protect against, since (and
> especially with the above) you can likely assume non-intelligence. A
> trivial way of checking this might be to on key storage normalize the
> actual key data to some known format (this could be as simple as an
> ASCII base-10 digits representation of the parameters in a fixed
> order), compute a checksum over that data, and store that checksum
> along with the stored (encrypted, marshalled, whatever strikes your
> fancy) key material. As a final step before using the loaded key
> material for crypto, normalize the key material that is about to be
> used into the same format, compute the checksum over that, and compare
> it to the stored checksum. In other words, true _end to end_
> verification that the key material is what was originally generated or
> at least stored. If they differ, then bail out with a prominent error
> message.
So if the original checksum function was C(x), you've replaced it by C(ASCII(x)), where ASCII(x) converts x into a series of decimal digits.  Why is that a better checksum than C() was?  If the answer is that C(0) = 0 so it's vulnerable to "stuck at 0" faults, then you're simply saying that C was a bad checksum (for this purpose) to begin with.  Why not choose a better one in some disciplined way, rather using the arbitrary technique?

                                                        -- Jerry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20141107/483b103f/attachment.bin>