Re: Design choice in LTC
- From: Tom St Denis <tom@xxxxxxx>
- Date: Fri, 4 Sep 2009 07:28:40 -0700 (PDT)
On Sep 4, 9:46 am, Noob <r...@xxxxxxxxx> wrote:
In my humble opinion, any outcome that does not allow one to proceed normally
might be considered an "error".
Which is good for you. Except LTC wasn't written for just YOUR
application in mind.
Thus, valid signature for the wrong document = error.
Which is an application context. There are conceivable instances
where you'd want your application to continue working even after an
invalid signature is found, whereas you'd like to abort if it fails to
compute the result.
NB: you did use "error" in both circumstances ;-)
In my application, both cases are fatal.
Well congrats for your application.
Consistent with the general design goal.
The documentation states:
"In general, the API is very simple to memorize and use. Most of the
functions return either void or int. Functions that return int will
return CRYPT_OK if the function was successful, or one of the many
error codes if it failed."
Ya, it SUCCESSFULLY COMPUTED THAT THE SIGNATURE IS INVALID.
Think of say an MPEG encoder where you have a target bitrate, so you
try one q value, then it SUCCESSFULLY ENCODES THE FRAME but fails to
meet the bitrate. So you have to retry. That's the same sort of
err != OK means it failed to even compute whether the signature
matches or not because the program is in a faulty state [out of
memory, invalid inputs, etc]. Wheras err == OK and stat == 0 means it
successfully computed that the signature is not valid.
It's all a matter of style.
I did not write "hard to use".
I wrote unintuitive and error-prone (and not consistent).
Is there a glitch in the matrix?
error prone would imply hard to use. Stop being obtuse.
Other functions don't really have the ability to successfully compute
the wrong data though.
I don't understand what you mean.
AES either computes the correct output or fails. It can't
successfully compute the wrong ciphertext.
The function takes a sig and a binary blob, and returns "success" if the sig is
correct for the blob. It seems natural to expect it to return different shades
of "fail" when the signature is not correct, for whatever reason.
It's all a matter of style. To me if the padding is correct then the
operation was a success, even if the hash doesn't match (that would
imply stat == 0).
I am not "complaining". I am merely discussing.
You're asserting your style is superior while dismissing any rational
comments I make out of hand because YOUR application demands a certain
behaviour. To me that's whining.
If you were this arsed about it you could just write a wrapper around
it to return your desired error code.
Except in my case, a verification failure is fatal, so I write
err = rsa_verify_hash(...)
if (err) return err;
/* normal code path */
Yeah, that's YOUR case.
I have. Thanks again for the software.
You're most welcome.
So stop bitching at me about the API and go fix it yourself.
Good ol' Tom. Always finishing with a kind word :-)
Mamma always taught me never to suffer any fools. :-)
If you think the API is that bad, go fix it yourself. I wrote LTC as
a LIBRARY not as an APPLICATION so it had to have broad appeal. Which
mean more parameters than some would like, for instance, my PKCS #8
encryptor I wrote has 14 parameters. But from that single function it
supports all of PKCS #5 v1 and v2 under PKCS #8, etc...
The idea is people would write wrappers around the god awful functions
and reduce their complexity based on choices made in the context of
the end user application. For example, I have example macros to
perform "default" AES encryption with PKCS #8 where the macro only
takes 5 parameters.
- Prev by Date: Re: Design choice in LTC
- Next by Date: XOR-decryption...
- Previous by thread: Re: Design choice in LTC
- Next by thread: Re: Design choice in LTC