Re: Design choice in LTC

On Sep 4, 7:52 am, Noob <r...@xxxxxxxxx> wrote:
How do you qualify a signature failure, if it is not an error?

The document could have been modified. So it's still a valid
signature but not for that document. An error is more like you ran
out of ram, the padding was wrong, etc.

How do you handle the case (err == 0 && res != 1) ?

Depends on the application. In my cases I handle err != 0 as a fatal
error (usually because you ran out of ram or have malformed inputs),
and res != 1 as a soft error (because the user may have specified the
wrong message to verify) both with different messages to the user.

Please correct me if I'm wrong. A signature failure could only occur if the
owner of the private key signed the wrong document? An attacker cannot generate
a wrong signature, only an invalid signature?

I'll gladly correct you since you are in fact wrong. An attacker
could shove any matter of data your way. RSA signatures are just
arbitrary byte sequences until you perform the public operation, then
you have to check for padding.

It's no more correct or wrong than merging it into an error condition,
it just happens to be the style I chose at the time.

I did not write "incorrect" or "wrong".
I said unintuitive and error-prone (and not consistent).

With what though? It's consistent with my other PK APIs inside the
library. And in fact in the 8 years the projects have been around
you're the first person to complain that the two-fold channel is hard
to use.

Do you dispute that it is unintuitive and error-prone, considering that the
other functions only return an error code?

Other functions don't really have the ability to successfully compute
the wrong data though.

If you could do it over again today, would you still use two distinct variables,
or would you add an extra error code?

I did do it over again. The company I work at has a library similar
to LTC that has the exact same style API. None of our customers have
complained about it.

I'm not disputing that you could just return CRYPT_SIGNATURE_MISMATCH
or something similar. I am disputing that that's better. To me
return codes other than CRYPT_OK really mean something is wrong with
the environment, whereas the additional channel of the status allows
more logical processing. So now you do

err = rsa_verify_hash(...)
if (err != OK) { error(); }
if (!stat) { signature_failed(); }

The equivalent in your preferred style would be

if (err == CRYPT_SIGNATURE_MISMATCH) {
signature_failed();
} else if (err != OK) {
error();
}

It's just as complicated.

Finally, the library is public domain, you're at liberty to modify and
redistribute as you see fit. So stop bitching at me about the API and
go fix it yourself.

Tom
.

Relevant Pages

  • Re: RSA on 8bit micro
    ... No hardware multiplier. ... 768 bytes of contiguous, aligned XDATA RAM ... bytes of stack, including return address ... Runtime is nearly halved using e=2 (Rabin signature, ...
    (comp.arch.embedded)
  • Re: RSA on 8bit micro
    ... I have 32K ROM and 1K RAM. ... I need to implement 1024 bit RSA encryption ... If your application is DEcryption, or signature GENERATION, ... 68HC11: execution time 0.49 s ...
    (comp.arch.embedded)
  • Re: Design choice in LTC
    ... signature but not for that document. ... out of ram, the padding was wrong, etc. ... because the file I intend to write already exists? ... Success at one ...
    (sci.crypt)
  • Re: patch/option to wipe memory at boot?
    ... to test whether they go away when the RAM is properly initialized. ... which are untouched since boot (hence the 0xdeadbeef signature). ... Boot memtest86 for a little while before booting the kernel? ...
    (Linux-Kernel)
  • patch/option to wipe memory at boot?
    ... Is there a patch or a boot option or something which wipes all ... to test whether they go away when the RAM is properly initialized. ... which are untouched since boot (hence the 0xdeadbeef signature). ...
    (Linux-Kernel)
Quantcast