A processor that can do a DES round in 1 clock
I've seen this quite some time in the past, it wasn't for public disclosure. Periodically I've looked for a copy on the internet. This is from Strech Inc., their Software Configurable Processor. http://www.pdcl.eng.wayne.edu/msp6/MSP6_Workshop_Keynote_2004_POSTING.pdf The stuff on DES encryption starts on page 44. The processor is based on a Tensilica Xtensa processor, which can be customized. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
Werner Koch wrote: 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. Quite so. 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). But this is not why: if you attempt to fix impossible states, the problem is that you cannot know why (by definition) the code is in the state you are trying to fix, or what else might be broken. Continuing to run is giving the attacker the option to make good on his exploit. Sure, for many APIs it is posssible to return an error code but this requires that the caller properly checks error codes. Again, this it not the issue. If you continue to run code you are running it against an unknown state of the code and data. You are allowing more leeway for exploits. This is true even if the code is just printing a warning (don't forget that to print a warning you must typically execute a substantial body of library and system code). We have all seen too many cases were return values are not checked and the process goes ahead assuming that everything went well - this might be okay for games but definitely not for cryptographic applications. 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 environemnt 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. It is the same rationale why defining NDEBUG in production code is a Bad Thing. I agree. Cheers, Ben. -- http://www.links.org/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Nonrepudiation - in some sense
Victor Duchovni wrote: On Fri, Feb 10, 2006 at 07:49:59PM +, Ben Laurie wrote: Secondly, obviously, you can only decrypt SSL if you have the private key, so presumably this is referring only to incoming SSL connections. And only if EDH (or more generally all PFS) ciphers are disabled. This is AFAIK common with HTTP servers, but the majority of TLS capable MTAs negotiate EDH ciphers. You refer, of course, to the case where you are trying to decrypt a sniffed conversation. Gotta be careful with the trimming of messages! -- http://www.links.org/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: general defensive crypto coding principles
Travis H. wrote: On 2/8/06, Jack Lloyd [EMAIL PROTECTED] wrote: An obvious example occurs when using a deterministic authentication scheme like HMAC - an attacker can with high probability detect duplicate plaintexts by looking for identical tags. I think though that the solution is fairly simple; prepend a block-length random IV to the message and to the output of HMAC. In fact, I've wondered if doing this on all hashes might be a good defensive programming idea. It seems to defend against attacks of the sort which /etc/passwd was subject (dictionary cracking) in much the same way that salt did*, and against guessing the plaintext for short plaintexts even when the language is unknown. It also defends against the MD5 crack, and is one of the recommended IETF solutions to hash problems. -- http://www.links.org/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
On Sun, 12 Feb 2006 13:46:05 -0500, John Denker said: That is a remarkably unprofessional suggestion. I hope the people who write software for autopilots, pacemakers, antilock brakes, etc. do not follow this suggestion. Thus my remark about a independend failsafe system. I strongly hope that for life critical systems nobody even things about throwing in a bunch of general purpose libraries and declares the task as done. Fortunately these systems have resource constraints so that such a solution won't come to mind anyway. First of all, impossible is the wrong word. If the condition s,impossible,not foreseen/tested/coded by the developer, previous tick's tasks are finished. What do you do, exit? If Yes. And one of the concurrent running system will take over. In 1969 this system used to be Armstrong, though. There are other stories like this, including funny (?) stories of what happens if exceptions are not handled so well. Terminating a process is a well handled exception. Think of hardware failure; continue while knowing that tehre is something really weird going on?? More generally: library routines should never exit. They almost If you are thinking of exit please mentally translate this to assert. Still believing one should never call assert(0) in a library? Nitpickers note: I can imagine a situation where the stack is so messed up that you can't thrown an exception or even return from Die as soon as you can; kill (getpid(),SIGKILL) might even be justified in such a situation. Try to make an attackers life as hard as possible. Yes, for life critical systems an attack scenario might be different to judge and thus the design needs to be different. Obviously I agree with Ben that that there is no way to know the current state if something went wrong in unexpected ways. Shalom-Salam, Werner - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
Werner Koch wrote: 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. :-) Then what was EINVAL invented for? 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 - this might be okay for games but definitely not for cryptographic applications. Really it's never ok for anything, not even games, and any program that fails to check error return values is simply not properly coded, full stop. But abort()-ing in a library is also a big problem, because it takes control away from the main executable. That can be a massive security vulnerability on Windows. If you can get a SYSTEM-level service that listens on a well known pipe or LPC port to abort(), you can often steal it's pipe or port and escalate your privileges It would be far preferable for the service to remain running in a main loop that ends up operating as ... ... receive request from client ... fail to service it because libgcrypt returns errors.. return error to caller ... rather than for it to abort. 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 environemnt 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. It is the same rationale why defining NDEBUG in production code is a Bad Thing. Perhaps libgcrypt could call abort in debug builds and return error codes in production builds? cheers, DaveK -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: general defensive crypto coding principles
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. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
