Re: general defensive crypto coding principles
Paul Hoffman wrote: At 5:40 PM + 2/12/06, Ben Laurie wrote: It also defends against the MD5 crack, and is one of the recommended IETF solutions to hash problems. s/recommended/proposed/ The IETF has not recommended any solutions to hash problems. The sense of the room at the Hash BOF and the SAAG discussion at the Paris IETF meeting was that the IETF should *not* propose solutions to the problem. That is why the BOF did not turn into a Working Group and why there has been little discussion of the proposed solutions in the relevant IETF working groups. Agreed, I misspoke. I meant proposed and not thought to be a stupid idea. -- http://www.links.org/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
GnuTLS (libgrypt really) and Postfix
John Denker [EMAIL PROTECTED] writes: Werner Koch retorted: I disagree strongly here. Any code which detects an impossible state or an error clearly due to a programming error by the caller should die as soon as possible. That is a remarkably unprofessional suggestion. I hope the people who write software for autopilots, pacemakers, antilock brakes, etc. do not follow this suggestion. This just shows the dangers of over-generalization. Of course, we have to decide which is more important: integrity, or availability. I suspect that in the overwhelming majority (perhaps all) of the cases where libgcrypt is used, integrity is more important than availability. If that is true, well, if in doubt, it's better to fail closed than to fail open. You rightly points out that there are important applications where availability is more important than integrity. However, I suspect those cases are not too common when building Internet-connected desktop applications. I think the attitude that it's better to die than to risk letting an attacker take control of the crypto library is defensible, in many cases. Of course, it would be better for a crypto library to document this assumption explicitly than to leave it up to users to discover it the hard way, but I would not agree with the suggestion that this exit before failing open stance is always inappropriate. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
David Wagner wrote: This just shows the dangers of over-generalization. One could make an even stronger statement about the dangers of making assumptions that are not provably correct. Of course, we have to decide which is more important: integrity, or availability. That is a false dichotomy. I suspect that in the overwhelming majority (perhaps all) of the cases where libgcrypt is used, integrity is more important than availability. If that is true, well, if in doubt, it's better to fail closed than to fail open. Again: False dichotomy is a fallacy, and has been recognized for 2000 years as such. Showing that one extreme is bad does not prove that the opposite extreme is good. The whole point of my previous note was to argue for more nuanced handling. Progressing from one knee-jerk handing to a choice between two knee-jerk handlings is not much progress. I think the attitude that it's better to die than to risk letting an attacker take control of the crypto library is defensible, in many cases. Again, that's the wrong question; it's not an either/or proposition. We can agree that letting the attacker take control of the situation is a Bad Thing, but it is preposterous to think that exiting is provably correct in all situations where the library might be put to use. It is just plain arrogant for low-level code to arrogate to itself a decision that rightfully belongs to higher-level code. Werner Koch wrote in part: Sure, for many APIs it is posssible to return an error code but this requires that the caller properly checks error codes. We have all seen too many cases were return values are not checked and the process goes ahead assuming that everything went well That is narrowly true as stated, but it does not prove that exiting is the correct thing to do. That might lead to an argument in favor of exceptions instead of error codes, along the following lines: -- Naive code doesn't catch the exception. However (unlike returned error codes) this does not cause the exception to be lost. -- The exception percolates up the call-tree until it is caught by some non-naive code (if any). -- If all the code is naive, then the uncaught exception terminates the process ... to the delight of the exit on error faction. However (!!!) unlike a plain old exit, throwing an exception leaves the door open for non-naive code to implement a nuanced response to the exceptional condition. Again, enough false dichotomies already! Just because error codes are open to abuse doesn't mean exiting is the correct thing to do. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
Werner Koch [EMAIL PROTECTED] writes: On Sat, 11 Feb 2006 12:36:52 +0100, Simon Josefsson said: 1) It invoke exit, as you have noticed. While this only happen in extreme and fatal situations, and not during runtime, it is not that serious. Yet, I agree it is poor design to do this in a library. I disagree strongly here. Any code which detects an impossible state or an error clearly due to a programming error by the caller should die as soon as possible. If you try to resolve the problem by working around it will increase code complexity and thus error won't be detected. (Some systems might provide a failsafe mechanism at a top layer; e.g. by voting between independed developed code). That /dev/random doesn't exist seem like a quite possible state to me. The application would want to shut down gracefully when the library detect that condition. The application may be processing files in different threads. Further, a library is not in a good position to report errors. A users will sit there wondering why Postfix, or some other complex application died, without any clues. Returning an error and providing a foo_strerror() function at least make it possible to report a useful error to the user. I would agree if we are only talking about truly fatal cases, like asserts() to check explicit pre-conditions for a function, but I disagree when we move into the area if easily anticipated problems. However, looking at the code, it is possible for Postfix to handle this. They could have installed a log handler with libgcrypt, and make sure to shut down gracefully if the log level is FATAL. The recommendation to avoid GnuTLS because libgcrypt calls exit suggest that the Postfix developers didn't care to investigate how to use GnuTLS and libgcrypt properly. So I don't think there is any real reason to change code in libgcrypt here. Postfix could be changed, if they care about GnuTLS/libgcrypt. It is the same rationale why defining NDEBUG in production code is a Bad Thing. Agreed. 2) If used in a threaded environment, it wants to have access to thread primitives. The primary reason was for RNG pool locking (where it is critical), but I think the primitives are now used in other places too. GnuTLS is thread agnostic, so it can't initialize libgcrypt properly. Against our advise Nikos rejected to implement a proper initialization. Libraries and threading is actually a deep problem. It usually works well on GNU/Linux systems but this is more of coincidence than by design. We did quite some research on this and experimented with different ways of automagically initializing the thread primitives correctly; they all fail either at runtime or create headaches when trying to write proper build rules. The current approach is by far the most flexible and safest. But yes, the fact that one library needs an initialization can't be hidden from the application even if the application is using the lib only indirectly (Foo-OpenLDAP-GnuTLS-Libgcrypt). I'd say that the most flexible approach for a library is to write thread-safe code that doesn't need access to mutexes to work properly. Implementing the RNG functions like this is a challenge, and may require kernel-level support (see below), but giving up and requiring thread hooks seem sub-optimal. list. I think the Linux /dev/urandom implementation is sub-optimal. This is known since Ted Ts'o wrote /dev/random and justified by requirement of the Linux hackers to keep the memory use by a minimal Linux build low. That seem like a poor argument to me. It may be valid for embedded devices, but for most desktop PCs, Linux should provide a useful /dev/urandom. It seems that it would be possible to write a new /dev/*random implementation that is more useful by libgcrypt and other RNG libraries. Thanks, Simon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: general defensive crypto coding principles
Jack Lloyd [EMAIL PROTECTED] writes: On Fri, Feb 10, 2006 at 07:21:05PM +1300, Peter Gutmann wrote: Well, that's the exact problem that I pointed out in my previous message - in order to get this right, people have to read the mind of the paper author to divine their intent. Since the consumers of the material in the paper generally won't be expert cryptographers (or even inexpert cryptographers, they'll be programmers), the result is a disaster waiting to happen. I would expect that typically implementors would be following a published standard, which would (well, one would hope) have had expert cryptographers check it over sometime prior to publication Unfortunately that doesn't work in the real world for two reasons: 1. There are a great many special-case situations where no published protocol fits. As the author of a crypto toolkit, I could give you a list as long as your arm of user situations where no existing protocol can be applied (I'd prefer not to, because it's a lot of typing). The reason why existing protocols don't fit isn't because they're deficient in some way, but because there are so many specialised applications where security is needed that it isn't really possible to accomodate all of them in a single, or small set of, protocols - sometimes you have to do a custom design. 2. Published standards, at least IETF and ISO ones, don't include any rationale, and usually don't include implementation guidance either (this is a pet peeve of mine). Sometimes they don't even include critical security-related information. There was one wonderful example in IPsec where a major implementation got some feature that the spec never bothered to specify wrong. In the absence of any guidance in the spec, there was a 50:50 chance of doing it wrong, and this particular implementation happened to have the coin fall the wrong way when they were deciding on what to do. When asked about why the spec never specified how to handle this, one of its authors replied that this was a well known problem and everyone should know what to do. So implementors were expected to read the authors' minds to get it right. So saying it's a simple case of waving an expert cryptographer over the problem doesn't really work. There's a wonderful quote about this approach by Marv Schaefer, to get a truly secure system, you must ensure that it's designed and built by geniuses. Unfortunately, geniuses are in short supply. It's better to design a system that can be used by the average user than one that's brittle enough that only geniuses can safely employ it. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
