Re: GnuTLS (libgrypt really) and Postfix
On Tue, Feb 14, 2006 at 01:00:33PM -0500, Steven M. Bellovin wrote: We all agree that critical errors like this should be caught; the only question is at what layer the action should take place. I'm an adherent to the Unix philosophy -- when a decision is made at a lower level, it takes away the ability of the higher level to do something different if appropriate, and this loss of flexibility is a bad thing. Thanks, this makes the point very clearly! Let me suggest a C-compatible possibility: pass an extra parameter to the library routines, specifying a procedure to call if serious errors occur. If that pointer is null, the library can abort. The pass-a-function pointer approach covers the simpler cases. Large utility libraries (OpenSSL, Kerberos, ...) sometimes have a tougher problem to solve. - The function needs error detail arguments so it can take the right actions. - Errors may need a classification system, so that new errors of the same type can be handled generically in legacy code as the library evolves. - The function needs an application context argument so it has access to the data it needs to take the right actions. So, the more sophisticated C-language designs (e.g. OpenSSL or Kerberos) include an error management API. These are clearly work-arounds for lack of real exceptions. They take care to design and implement, and it may be difficult or impractical to retrofit an existing design that did not pay the price from the start, but I find claims that the exit() approach is best *on architectural grounds* rather surprising... ERR_get_error(3)OpenSSL ERR_get_error(3) NAME ERR_get_error, ERR_peek_error, ERR_peek_last_error, ERR_get_error_line, ERR_peek_error_line, ERR_peek_last_error_line, ERR_get_error_line_data, ERR_peek_error_line_data, ERR_peek_last_error_line_data - obtain error code and data SYNOPSIS #include openssl/err.h unsigned long ERR_get_error(void); unsigned long ERR_peek_error(void); unsigned long ERR_peek_last_error(void); unsigned long ERR_get_error_line(const char **file, int *line); unsigned long ERR_peek_error_line(const char **file, int *line); unsigned long ERR_peek_last_error_line(const char **file, int *line); unsigned long ERR_get_error_line_data(const char **file, int *line, const char **data, int *flags); unsigned long ERR_peek_error_line_data(const char **file, int *line, const char **data, int *flags); unsigned long ERR_peek_last_error_line_data(const char **file, int *line , const char **data, int *flags); DESCRIPTION ERR_get_error() returns the earliest error code from the thread's error queue and removes the entry. This function can be called repeatedly until there are no more error codes to return. ERR_GET_LIB(3) OpenSSL ERR_GET_LIB(3) NAME ERR_GET_LIB, ERR_GET_FUNC, ERR_GET_REASON - get library, function and reason code SYNOPSIS #include openssl/err.h int ERR_GET_LIB(unsigned long e); int ERR_GET_FUNC(unsigned long e); int ERR_GET_REASON(unsigned long e); DESCRIPTION The error code returned by ERR_get_error() consists of a library num- ber, function code and reason code. ERR_GET_LIB(), ERR_GET_FUNC() and ERR_GET_REASON() can be used to extract these. The library number and function code describe where the error occurred, the reason code is the information about what went wrong. Each sub-library of OpenSSL has a unique library number; function and reason codes are unique within each sub-library. Note that different libraries may use the same value to signal different functions and rea- sons. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
James A. Donald wrote: The correct mechanism is exception handling. Yes, I reckon there is a pretty wide consensus that exceptions provide a satisfactory solution to the sort of problems being discussed in this thread. If caller has provided a mechanism to handle the failure, that mechanism should catch the library generated exception. If the caller has provided no such mechanism, his program should terminate ungracefully. OK ... although I wouldn't make a virtue of doing things ungracefully. Unfortunately, there is no very portable support for exception handling in C. There is however support in C++, Corn, D, Delphi, Objective-C, Java, Eiffel, Ocaml, Python, Common Lisp, SML, PHP and all .NET CLS-compliant languages. That raises the question of whether mission-critical applications should be written in C. It is straightforward but laborious to simulate exception-throwing in C: extern int errno; /* try some stuff */ if (errno) return; /* return immediately on any error */ /* try some more stuff */ if (errno) return; /* return immediately on any error */ et cetera. This is laborious and inelegant, but no more so than the other gajillion things you need to do to provide any semblance of security in C, such as computing the (N) argument to strncat(,,N). In particular, if-errno-return is often much preferable to some other tricks that have recently been suggested, such as raising SIGABRT or passing a pointer to a function to be called when exceptional conditions are detected. The reason is that throwing an exception _pops_ the stack until a catcher if found, whereas signals and function-calls just push deeper into the stack ... they allow you to regain some control, but they don't make it easy to regain control _at the right place_. For completeness, let me say again that _exit() is just an exception that is caught by the parent process. If you are ever forced to deal with a package that exits when it shouldn't, it is straightforward to create a wrapper that does a fork, calls the package, and collects the exit status. That is, rather than: rslt = nasty(a, b); /* might trash the whole process */ we have: rslt = forku(nasty, a, b);/* better */ if (errno) return; But of course I hope you never have to face such a problem. If at all possible, use a language that supports exceptions. Absent exception handling, mission critical tasks should have no exceptions, which is best accomplished by the die-on-error standard. No, that is not the best way nor even a good way, let alone a standard. Halt on error is a tool for achieving error free code. Error free code is in fact achievable for really crucial applications. The more crucial the application, the more reason to write code that halts on error. Halting on every exceptional condition is like amputating to cure every headache. Keep in mind Dykstra's dictum: testing can perhaps show the presence of bugs, but testing can never show the absence of bugs. Exit-on-error is a _problem amplifier_. It guarantees that small problems detected during testing will not go unnoticed. But this is a very long way from being a guarantee of error-free code. a) Remember Dykstra's dictum. b) If you knew the code was error free, then by the Red Queen's logic you wouldn't even need to check for errors, and there would be no need for exit statements. The contrapositive is that if you put checks in the code, you are implicitly admitting that your code might not be error free. And there's the rub: you cannot possibly prove that during deployment (as opposed to during testing) using a _problem amplifier_ won't make things worse rather than better. Whatever happened to doing what's best for the customer? Doing what's most convenient for the programmer during testing, while making things worse for the customer during deployment ... that seems remarkably unprofessional. Last but not least, I object (again!) to the false dichotomy, i.e. the allegation that exceptional conditions must either a) result in an abort, or b) go undetected. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
On Tue, 14 Feb 2006 13:00:33 -0500, Steven M Bellovin said: Let me suggest a C-compatible possibility: pass an extra parameter to the library routines, specifying a procedure to call if serious errors occur. If that pointer is null, the library can abort. I agree. However the case at hand is a bit different. I can't imagine how any application or upper layer will be able to recover from that error (ENOENT when opening /dev/random). Okay, the special file might just be missing and a mknod would fix that ;-). Is it the duty of an application to fix an incomplete installation - how long shall this be taken - this is not the Unix philosophy. Salam-Shalom, Werner - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
In message [EMAIL PROTECTED], Werner Koch writes: On Tue, 14 Feb 2006 13:00:33 -0500, Steven M Bellovin said: Let me suggest a C-compatible possibility: pass an extra parameter to the library routines, specifying a procedure to call if serious errors occur. If that pointer is null, the library can abort. I agree. However the case at hand is a bit different. I can't imagine how any application or upper layer will be able to recover from that error (ENOENT when opening /dev/random). Okay, the special file might just be missing and a mknod would fix that ;-). Is it the duty of an application to fix an incomplete installation - how long shall this be taken - this is not the Unix philosophy. It can take context-specific error recovery. Maybe that's greying out the encrypt button on a large GUI. Maybe it's paging the system administrator. It can run 'mknod' inside the appropriate chroot partition, much as /sbin/init on some systems creates /dev/console. It can symlink /dev/geigercounter to /dev/random. It can load the kernel module that implements /dev/random. It can do a lot of things that may be more appropriate than exiting. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Attack of the Teleclones
PHYSICS NEWS UPDATE The American Institute of Physics Bulletin of Physics News Number 765 February14, 2006 by Phillip F. Schewe, Ben Stein, and Davide Castelvecchi ATTACK OF THE TELECLONES: Should quantum cryptographers begin to worry? In contrast with everyday matter, quantum systems such as photons cannot be copied, at least not perfectly, according to the no-cloning theorem. Nonetheless, imperfect cloning is permitted, so long as Heisenberg's Uncertainty Principle remains inviolate. According to Heisenberg, measuring the position of a particle disturbs it, and limits the accuracy to which its complementary property (momentum) can be determined, making it impossible to reliably replicate the particle's complete set of properties. Now, quantum cloning has been combined with quantum teleportation in the first full experimental demonstration of telecloning by scientists at the University of Tokyo, the Japan Science and Technology Agency, and the University of York (contact Sam Braunstein, [EMAIL PROTECTED] and Akira Furusawa, [EMAIL PROTECTED]). In ideal teleportation, the original is destroyed and its exact properties are transmitted to a second, remote particle (Heisenberg does not apply because no definitive measurements are made on the original particle). In telecloning, the original is destroyed, and its properties are sent to not one but two remote particles, with the original's properties reconstructed to a maximum accuracy (fidelity) of less than 100%. (Heisenberg limits the ability to make clones as otherwise researchers could keep making copies of the original particle and learn everything about its state.) In their experiment, the researchers didn't just teleclone a single particle, but rather an entire beam of laser light. They transmitted the beam's electric field, specifically its amplitude and phase (but not its polarization) to two nearly identical beams at a remote location with 58% accuracy or fidelity (out of a theoretical limit of 66%). This remarkable feature of telecloning stems from the very magic of quantum mechanics: quantum entanglement. Telecloning stands apart from local cloning and from teleportation in requiring multipartite entanglement, a form of entanglement in which stricter correlations are required between the quantum particles or systems, in this case three beams of light. (An example of a multipartite entanglement is the GHZ state between three particles that was featured in Update 414.) In addition to representing a new quantum-information tool, telecloning may have an exotic application: tapping quantum cryptographic channels. Quantum cryptographic protocols are so secure that they may discover tapping. Nonetheless, with telecloning, the identity and location of the eavesdropper could be guaranteed uncompromised. (Koike et al., Physical Review Letters, 17 February 2006; for an earlier partial demonstration of telecloning, between an original photon and one clone at a remote location and another clone local to it, see Zhao et al., Phys Rev Lett, 13 July 2005) [...] *** PHYSICS NEWS UPDATE is a digest of physics news items arising from physics meetings, physics journals, newspapers and magazines, and other news sources. It is provided free of charge as a way of broadly disseminating information about physics and physicists. For that reason, you are free to post it, if you like, where others can read it, providing only that you credit AIP. Physics News Update appears approximately once a week. AUTO-SUBSCRIPTION OR DELETION: By using the expression subscribe physnews in your e-mail message, you will have automatically added the address from which your message was sent to the distribution list for Physics News Update. If you use the signoff physnews expression in your e-mail message, the address in your message header will be deleted from the distribution list. Please send your message to: [EMAIL PROTECTED] (Leave the Subject: line blank.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
-- John Denker wrote: Halting on every exceptional condition is like amputating to cure every headache. Keep in mind Dykstra's dictum: testing can perhaps show the presence of bugs, but testing can never show the absence of bugs. For truly critical applications, and I have written one such, there are better methods than testing. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG EQ0NuuGe3F81FVYLaVzuREVIM95sviNDw7cku0j6 4MEZw0qU0NMPYTNTSCMcjRi7wZSGRo06TUwlSmzr8 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: HDCP support in PCs is nonexistent now?
John Gilmore [EMAIL PROTECTED] writes: Despite a bunch of PC graphics chips and boards having announced HDCP support, according to the above article, it turns out that none of them will actually work. It looks like something slipped somewhere, and an extra crypto-key chip needed to be added to every existing board -- at manufacturing time. The extra item was just a little serial EEPROM with per-device keying/entitlement info. All the HDCP stuff (the challenge-response handshake over the DVI link and the actual content en/decryption and MAC'ing) are performed by the DVI controller chip using data from the external EEPROM. Since adding the EEPROM would have added a few tens of cents to the cost of the hardware (the hardware itself, the manufacturing cost, the cost of personalising and testing each EEPROM, and the fact all portions of the manufacturing process that come into contact with keys require special security measures), there was no clear idea when anyone could actually use it, and there would no doubt be interop problems once devices did hit the market, leading to product returns from dissatisfied customers, manufacturers skipped the cost and overhead of adding it. It makes sense really, why add something that's both completely useless to users and a potential liability to manufacturers? If I were creating the devices, I'd have done the same thing. It's like region coding in DVD players, you reduce cost and add value by *not* including it. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
On Tue, 14 Feb 2006 15:53:39 -0500, John Denker said: It is straightforward but laborious to simulate exception-throwing in C: extern int errno; /* try some stuff */ if (errno) return; /* return immediately on any error */ Except that this does not work. ERRNO gets set by most calls only on error so if everything went fine in the try ssome stuff you get random results. Shalom-Salam, Werner - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
the return of key escrow?
According to the BBC, the British government is talking to Microsoft about putting in a back door for the file encryption mechanisms. http://news.bbc.co.uk/1/hi/uk_politics/4713018.stm --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
Steven M. Bellovin wrote: In message [EMAIL PROTECTED], James A. Donald writes: -- Libgcrypt tries to minimize these coding errors; for example there are no error returns for the RNG - if one calls for 16 bytes of random one can be sure that the buffer is filled with 16 bytes of random. Now, if the environment is not okay and Libgcrypt can't produce that random - what shall we do else than abort the process. This way the errors will be detected before major harm might occur. I'm afraid I consider it instead a weakness in your API design that you have no way to indicate an error return from a function that may fail. The correct mechanism is exception handling. If caller has provided a mechanism to handle the failure, that mechanism should catch the library generated exception. If the caller has provided no such mechanism, his program should terminate ungracefully. Unfortunately, there is no very portable support for exception handling in C. There is however support in C++, Corn, D, Delphi, Objective-C, Java, Eiffel, Ocaml, Python, Common Lisp, SML, PHP and all .NET CLS-compliant languages. Absent exception handling, mission critical tasks should have no exceptions, which is best accomplished by the die-on-error standard. Precisely. I was preparing a post of my own, saying the same thing; you beat me to it. We all agree that critical errors like this should be caught; the only question is at what layer the action should take place. I'm an adherent to the Unix philosophy -- when a decision is made at a lower level, it takes away the ability of the higher level to do something different if appropriate, and this loss of flexibility is a bad thing. I have perhaps not been clear in some of my comments in this thread. I think there is a world of difference between critical errors and detecting internal inconsistency. In the case of inconsistency I claim that it is _never_ correct to continue running because every instruction executed is another potential hole for the attacker to use. Critical errors which do not indicate that something unexpected (as opposed to undesirable) has happened should, indeed, allow the caller to decide how they are handled. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
Werner Koch wrote: On Mon, 13 Feb 2006 03:07:26 -0500, John Denker said: Again, enough false dichotomies already! Just because error codes are open to abuse doesn't mean exiting is the correct thing to do. For Libgcrypt's usage patterns I am still convinced that it is the right decision. Then you should warn people that it is not safe to use in any high-privilege server application. cheers, DaveK -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
-- John Denker wrote: Whatever happened to doing what's best for the customer? Doing what's most convenient for the programmer during testing, while making things worse for the customer during deployment ... that seems remarkably unprofessional. It is usually better for the customer that the program does nothing, than that it does something unexpected. This is particularly true in mission critical applications, such as for example a pace maker. Would you rather have an inactive pacemaker, or pacemaker busily doing something unexpected? 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. Last but not least, I object (again!) to the false dichotomy, i.e. the allegation that exceptional conditions must either a) result in an abort, or b) go undetected. The correct solution to exceptional conditions is to use exceptions. This is not always practical or available, though it should be. The whole world should move to C++. If exceptions are not available, what then do we do? I say abort. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG yT/vxBNSRjFYGpU6iWTY1tvxDKTWkDa9wubFEmYD 40btwbJ8sjQGTu/vmkD4fjY1gud+1641iRf+Uq+Pb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
