Fermilab Call for Codebreakers
http://www.symmetrymagazine.org/breaking/2008/05/15/code-crackers-wanted/ Though it now looks like they are well on their way to solving it, Fermilab requested help decoding a coded letter they received. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: blacklisting the bad ssh keys?
Ahh the irony, apparently Debian has implement just such a feature, but as patch to ssh within their distro: http://www.mail-archive.com/[EMAIL PROTECTED]/msg214853.html On Thu, May 22, 2008 at 11:19:05AM -0700, Abe Singer wrote: On Wed, May 14, 2008 at 07:52:58PM -0400, Steven M. Bellovin wrote: Given the published list of bad ssh keys due to the Debian mistake (see http://metasploit.com/users/hdm/tools/debian-openssl/), should sshd be updated to contain a blacklist of those keys? I suspect that a Bloom filter would be quite compact and efficient. As someone who is dealing with this operationally, we (SDSC) had already identified what Steve suggests as the desireable long-term solution. I would reword the requirement slightly to say that the capability of sshd should be to block use of any key specified by the adminstrator, not necessarily just the published blacklist. I think that's what Steve may have actually meant, but clarity is helpful. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [ROS] The perils of security tools
* Peter Gutmann: Debian seem to be particularly bad for not reporting changes to maintainers, This shouldn't be the case. There's a clear policy that non-packaging changes (basically, anything beyond trivial build fixes and pathname changes for FHS compliance) should be submitted upstream. I've got a few packages that are contained in a number of distros and I notice via occasional Google searches for semi-related items that I'm getting hits to CVS change logs for my code where someone is repeatedly re-applying some patch to every new version I release. If you name names, we can certainly fix that. I couldn't figure out what packages are affected on Debian's side. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [ROS] The perils of security tools
Florian Weimer wrote: * Ben Laurie: I must confess that I said that because I did not have the energy to figure out the other routes to adding entropy, such as adding an int (e.g. a PID, which I'm told still makes it in there). The PID dependency is there because of the need for fork support--obviously, the PRNG must return a different key stream in the parent and child process, but the two cannot communicate with each other. I'm fully aware why its there! I just wasn't sure (at the time) that this change didn't also remove it. -- http://www.apache-ssl.org/ben.html http://www.links.org/ 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: [ROS] The perils of security tools
* Ben Laurie: Jonathan S. Shapiro wrote: Ben: I'm idly curious. Was this exceptionally unusual case where use of uninitialized memory was valid properly commented in the code? It's mentioned in the manpage for a function that eventually calls the function that was (correctly) patched--through a function pointer. The incorrectly patched function looks somewhat parallel, but it's not. There is no local comment in the source code for this particular case of uninitialized memory access. Well. Kinda. It didn't really explain why: i=fread(buf,1,n,in); if (i = 0) break; /* even if n != i, use the full array */ RAND_add(buf,n,(double)i); There is in theory a second place where it might used an uninitialised buffer, but I think in practice that never happens. AFAIK, this piece of code is not really related and rarely used outside OpenSSL itself. And in the OpenSSL case, the fread call always overwrites the whole buffer, it seems. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [ROS] The perils of security tools
* Ben Laurie: I must confess that I said that because I did not have the energy to figure out the other routes to adding entropy, such as adding an int (e.g. a PID, which I'm told still makes it in there). The PID dependency is there because of the need for fork support--obviously, the PRNG must return a different key stream in the parent and child process, but the two cannot communicate with each other. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
