[Opendnssec-develop] signature verification

[Roland van Rijswijk]

Hi Roy,

Roy Arends wrote:
> Roland van Rijswijk wrote on 11/27/2009 03:42:03 PM:
>
> At the moment it is unknown if the bug is in softhsm/botan or the
> signer. The work-around is to verify signatures immediately in two
> places: softhsm/botan and the signer and when a signature fails, log it,
> regenerate it immediately, check it, etc.  

OK, I read in Matthijs report that it seemed to be in softHSM/Botan but
of course it might just as well be in the signer.

> We don't know where the bug is, as it might just as well be in
> opendnssec part, and I don't want to assume anything right now. The
> 'plan b' is the work-around above. That work-around guarantees that
> there will not be any false signatures due to this specific bug.

OK, but I'm sure you agree that can't be a permanent solution right? If
debugging shows that the problem is in the signer then this would block
release of a final 1.0 in my opinion; if - on the other hand - it turns
out to be a bug in either SoftHSM or Botan then I don't think this bug
should block release of OpenDNSSEC, right?

>> BTW, is it a reproducable bug -- i.e. will it consistently output a
>> wrong signature given the same input data or is the problem
>> intermittent? (the latter would be far worse than the former)
> 
> The latter. It only occurred once. On 2009-11-23 12:52:08. We haven't
> been able to reproduce it.

Hmmm... that's nasty.

> We're going to soak-test it, starting monday. Continuous signing loop on
> softhsm without the ods signer. Continuous signing loop on an sca6000
> using OpenDNSSEC.

OK, we're going to start test with the Safenet Luna HSM that I received
yesterday starting next Friday, so if it has still not been found by
then, let me know if we can assist with a different HSM brand.

> There are a few coincidences.
> 
> 1) The first 52 characters (40 bytes) of the bad signature are correct.
> The presentation format causes a wrap after 26 characters. So the first
> two lines of the presentation format are correct. This might be a
> complete coincidence, but worth checking out. (this is the signer part).
> 2) Additionally, 40 bytes is a multiple of 20 bytes, which is exactly
> the size of the output of SHA1. This is even more far fetched, but I'm
> just thinking out loud. (this is botan/softhsm).

Coincidence number 1 could be caused by some arcane bug in output code,
although one would expect it to be more consistent in that case.
Coincidence number 2 must be purely a coincidence. There is no relation
between the signature size and data and the hash size from the RSA
operation perspective; the signature creation data (= padding + algo-id
+ hash) is simply treated as an n-bit big integer (where n = modulus
length) so there should be no relation here...

Cheers,

Roland

-- 
-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl