On Thu, Feb 16, 2006 at 09:36:16AM +1000, James A. Donald wrote: > In the case in question, going bad means that the program appears to > be encrypting data, but is NOT encrypting data, or is only trivially > encrypting data. This is far worse for the customer than an > encryption program that simply aborts. >
Who said the program's primary function is data security? The program may be handling entirely public data, available from multiple sources. One of the sources may offer "opportunistic" encrypt, which though potentially useful, is inessential and mostly "does no harm". It takes hubris for libgrypt to *assume* that is functions are essential. The dichotomy between pretending to encrypt data and exiting is false. It is plainly correct to not encrypt any data and say so (return errors from the encryption API). I'm outta here. I did not expect any controversy on this point, and don't expect views to shift dramatically. If the developers were open to the issue, the request might have been fruitful. If they dig in their heels, I am free to use other libraries. -- /"\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAIL Morgan Stanley confidentiality or privilege, and use is prohibited. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]