Re: [ROS] The perils of security tools
On Tue, 13 May 2008 12:10:16 -0400 Jonathan S. Shapiro [EMAIL PROTECTED] wrote: Ben's points are well taken, but there is one *small* piece of this where I have some sympathy for the Debian folks: What can we learn from this? Firstly, vendors should not be fixing problems (or, really, anything) in open source packages by patching them locally - they should contribute their patches upstream to the package maintainers. The response times from package maintainers -- even the good ones like the OpenSSL team -- are not always fast enough. Sometimes, vendors don't have a choice. There is a catch-22 on both sides of this coin. I was going to post something similar. I maintain several pkgsrc packages (http://www.pkgsrc.org); while most upstream maintainers are happy to receive bug fixes, others range from indifferent to downright hostile. For example, I once reported a portability bug to a developer: POSIX standards *require* that a certain system call reject out-of-range arguments, and NetBSD enforces that check. The Linux kernel (or rather, the kernel of that time; I haven't rechecked lately) did not. Fine -- a minor standards issue with Linux. But the application I was adding to pkgsrc relied on the Linux behavior and the developer angrily rejected my fix -- the standard was stupid, and he saw no reason to change his code to conform. Usually, though, indifference is a bigger problem. The NetBSD internal developers' mailing list has seen numerous complaints about *major* package developers ignoring portability and correctness fixes. If it isn't Linux and it isn't Windows, it doesn't matter, it seems. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The perils of security tools
On Tue, May 13, 2008 at 02:10:45PM +0100, Ben Laurie wrote:
[Moderator's note: A quick reminder: please use ASCII except if you
need Unicode to spell your name right. Microsoft's proprietary quote
marks are not a standard and don't look right on non-Microsoft
displays. I edited them out of this by hand. --Perry]
Debian have a stunning example of how blindly fixing problems pointed
out by security tools can be disastrous.
Upstream authors can take defensive measures against ill-advised
patches of this sort. For a while, distributions were in the habit
of Patching the code that Postfix uses to learn the its own hostname.
Invariably, they botched it. The code now reads:
/* get_hostname - look up my host name */
const char *get_hostname(void)
{
charnamebuf[MAXHOSTNAMELEN + 1];
/*
* The gethostname() call is not (or not yet) in ANSI or POSIX, but it is
* part of the socket interface library. We avoid the more politically-
* correct uname() routine because that has no portable way of dealing
* with long (FQDN) hostnames.
*
* DO NOT CALL GETHOSTBYNAME FROM THIS FUNCTION. IT BREAKS MAILDIR DELIVERY
* AND OTHER THINGS WHEN THE MACHINE NAME IS NOT FOUND IN /ETC/HOSTS OR
* CAUSES PROCESSES TO HANG WHEN THE NETWORK IS DISCONNECTED.
*
* POSTFIX NO LONGER NEEDS A FULLY QUALIFIED HOSTNAME. INSTEAD POSTFIX WILL
* USE A DEFAULT DOMAIN NAME LOCALDOMAIN.
*/
if (my_host_name == 0) {
/* DO NOT CALL GETHOSTBYNAME FROM THIS FUNCTION */
if (gethostname(namebuf, sizeof(namebuf)) 0)
msg_fatal(gethostname: %m);
namebuf[MAXHOSTNAMELEN] = 0;
/* DO NOT CALL GETHOSTBYNAME FROM THIS FUNCTION */
if (valid_hostname(namebuf, DO_GRIPE) == 0)
msg_fatal(unable to use my own hostname);
/* DO NOT CALL GETHOSTBYNAME FROM THIS FUNCTION */
my_host_name = mystrdup(namebuf);
}
return (my_host_name);
}
The addition of /* DO NOT CALL GETHOSTBYNAME FROM THIS FUNCTION */
every couple of lines appears to have solved the problem: it deliberately
breaks all prior patches (context diff overlaps), and strongly signals
that the code must not be messed with.
--
Viktor.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [ROS] The perils of security tools
Steven M. Bellovin wrote: On Tue, 13 May 2008 14:10:45 +0100 Ben Laurie [EMAIL PROTECTED] wrote: Debian have a stunning example of how blindly fixing problems pointed out by security tools can be disastrous. I've blogged about it here: http://www.links.org/?p=327 Vendors Are Bad For Security I?ve ranted about this at length before, I?m sure - even in print, in O?Reily?s Open Sources 2. But now Debian have proved me right (again) beyond my wildest expectations. Two years ago, they ?fixed? a ?problem? in OpenSSL reported by valgrind[1] by removing any possibility of adding any entropy to OpenSSL?s pool of randomness[2]. The result of this is that for the last two years (from Debian?s ?Edgy? release until now), anyone doing pretty much any crypto on Debian (and hence Ubuntu) has been using easily guessable keys. This includes SSH keys, SSL keys and OpenVPN keys. [2] Valgrind tracks the use of uninitialised memory. Usually it is bad to have any kind of dependency on uninitialised memory, but OpenSSL happens to include a rare case when its OK, or even a good idea: its randomness pool. Adding uninitialised memory to it can do no harm and might do some good, which is why we do it. It does cause irritating errors from some kinds of debugging tools, though, including valgrind and Purify. For that reason, we do have a flag (PURIFY) that removes the offending code. However, the Debian maintainers, instead of tracking down the source of the uninitialised memory instead chose to remove any possibility of adding memory to the pool at all. Clearly they had not understood the bug before fixing it. Ben: I haven't looked at the actual code in question -- are you saying that the *only* way to add more entropy is via this pool of uninitialized memory? No. That would be fantastically stupid. If so, is there any support in the relevant standards that dictate that this memory MUST NOT be cleared? I was thinking of things like SELinux, which may (or may not) clear memory areas before handing it to an application. --Steve Bellovin, http://www.cs.columbia.edu/~smb -- 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
On Tue, 13 May 2008 23:00:57 +0100 Ben Laurie [EMAIL PROTECTED] wrote: Steven M. Bellovin wrote: On Tue, 13 May 2008 14:10:45 +0100 Ben Laurie [EMAIL PROTECTED] wrote: Debian have a stunning example of how blindly fixing problems pointed out by security tools can be disastrous. I've blogged about it here: http://www.links.org/?p=327 Vendors Are Bad For Security I?ve ranted about this at length before, I?m sure - even in print, in O?Reily?s Open Sources 2. But now Debian have proved me right (again) beyond my wildest expectations. Two years ago, they ?fixed? a ?problem? in OpenSSL reported by valgrind[1] by removing any possibility of adding any entropy to OpenSSL?s pool of randomness[2]. The result of this is that for the last two years (from Debian?s ?Edgy? release until now), anyone doing pretty much any crypto on Debian (and hence Ubuntu) has been using easily guessable keys. This includes SSH keys, SSL keys and OpenVPN keys. [2] Valgrind tracks the use of uninitialised memory. Usually it is bad to have any kind of dependency on uninitialised memory, but OpenSSL happens to include a rare case when its OK, or even a good idea: its randomness pool. Adding uninitialised memory to it can do no harm and might do some good, which is why we do it. It does cause irritating errors from some kinds of debugging tools, though, including valgrind and Purify. For that reason, we do have a flag (PURIFY) that removes the offending code. However, the Debian maintainers, instead of tracking down the source of the uninitialised memory instead chose to remove any possibility of adding memory to the pool at all. Clearly they had not understood the bug before fixing it. Ben: I haven't looked at the actual code in question -- are you saying that the *only* way to add more entropy is via this pool of uninitialized memory? No. That would be fantastically stupid. So why are are the keys so guessable? Or did they delete other code? --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [ROS] The perils of security tools
Steven M. Bellovin wrote: On Tue, 13 May 2008 23:00:57 +0100 Ben Laurie [EMAIL PROTECTED] wrote: Steven M. Bellovin wrote: On Tue, 13 May 2008 14:10:45 +0100 Ben Laurie [EMAIL PROTECTED] wrote: Debian have a stunning example of how blindly fixing problems pointed out by security tools can be disastrous. I've blogged about it here: http://www.links.org/?p=327 Vendors Are Bad For Security I?ve ranted about this at length before, I?m sure - even in print, in O?Reily?s Open Sources 2. But now Debian have proved me right (again) beyond my wildest expectations. Two years ago, they ?fixed? a ?problem? in OpenSSL reported by valgrind[1] by removing any possibility of adding any entropy to OpenSSL?s pool of randomness[2]. The result of this is that for the last two years (from Debian?s ?Edgy? release until now), anyone doing pretty much any crypto on Debian (and hence Ubuntu) has been using easily guessable keys. This includes SSH keys, SSL keys and OpenVPN keys. [2] Valgrind tracks the use of uninitialised memory. Usually it is bad to have any kind of dependency on uninitialised memory, but OpenSSL happens to include a rare case when its OK, or even a good idea: its randomness pool. Adding uninitialised memory to it can do no harm and might do some good, which is why we do it. It does cause irritating errors from some kinds of debugging tools, though, including valgrind and Purify. For that reason, we do have a flag (PURIFY) that removes the offending code. However, the Debian maintainers, instead of tracking down the source of the uninitialised memory instead chose to remove any possibility of adding memory to the pool at all. Clearly they had not understood the bug before fixing it. Ben: I haven't looked at the actual code in question -- are you saying that the *only* way to add more entropy is via this pool of uninitialized memory? No. That would be fantastically stupid. So why are are the keys so guessable? Or did they delete other code? However, the Debian maintainers, instead of tracking down the source of the uninitialised memory instead chose to remove any possibility of adding memory to the pool at all. -- 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
Steven M. Bellovin wrote: On Tue, 13 May 2008 23:27:52 +0100 Ben Laurie [EMAIL PROTECTED] wrote: Ben: I haven't looked at the actual code in question -- are you saying that the *only* way to add more entropy is via this pool of uninitialized memory? No. That would be fantastically stupid. So why are are the keys so guessable? Or did they delete other code? However, the Debian maintainers, instead of tracking down the source of the uninitialised memory instead chose to remove any possibility of adding memory to the pool at all. Ah -- you wrote adding memory rather than adding entropy, which I found ambiguous. 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). -- 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 [EMAIL PROTECTED] writes: 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). So just to clarify, does the Debian patch only remove the ability to add uninitialised memory (which will be all-zeroes anyway on an OS with proper resource controls) or does it remove the ability to add any entropy at all? The advisory makes it sound like it's the latter. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [ROS] The perils of security tools
Peter Gutmann wrote: Ben Laurie [EMAIL PROTECTED] writes: 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). So just to clarify, does the Debian patch only remove the ability to add uninitialised memory (which will be all-zeroes anyway on an OS with proper resource controls) or does it remove the ability to add any entropy at all? The advisory makes it sound like it's the latter. Indeed, it is the latter. -- 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: The perils of security tools
On Tue, 13 May 2008, Ben Laurie wrote: Had Debian done this in this case, we (the OpenSSL Team) would have fallen about laughing I think we all should not miss this ROTFL experience: Original code (see ssleay_rand_add) http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=140view=markup, the patch http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141view=diffr1=141r2=140p1=openssl/trunk/rand/md_rand.cp2=/openssl/trunk/rand/md_rand.c and the end result http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141view=markup -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [ROS] The perils of security tools
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? 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. I'd note that ISO/IEC 9899 says the result of doing this is undefined, so I am inclined to remove it from future releases. -- 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
Jonathan S. Shapiro wrote: On Wed, 2008-05-14 at 10:34 +0100, Ben Laurie wrote: 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? Well. Kinda. It didn't really explain why... Then you got what you deserved. _I_ didn't get anything. And _I_ didn't deserve anything: I did not write the code. -- 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]
blacklisting the bad ssh keys?
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. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Call for papers for the Security in Storage Workshop 2008, due May 30th
The 5th international Security in Storage Workshop (SISW) http://ieeeia.org/sisw/2008/ will be held on Sept 25th, 2008 in conjunction with MSST 2008 http://storageconference.org/2008/ and theKey Management Summit 2008. http://www.keymanagementsummit.com/2008/ Prospective participants should submit either a full paper (not to exceed 12 single-spaced pages) for a paper presentation to be published in the proceedings or can submit a short abstract suggesting alternative presentation forms, discussion items, or panel topics. Please submit papers to James Hughes ([EMAIL PROTECTED]) by May 30th. Thanks Jim Hughes - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The perils of security tools
Paul Hoffman wrote: I'm confused about two statements here: At 2:10 PM +0100 5/13/08, Ben Laurie wrote: The result of this is that for the last two years (from Debian's Edgy release until now), anyone doing pretty much any crypto on Debian (and hence Ubuntu) has been using easily guessable keys. This includes SSH keys, SSL keys and OpenVPN keys. . . . [2] Valgrind tracks the use of uninitialised memory. Usually it is bad to have any kind of dependency on uninitialised memory, but OpenSSL happens to include a rare case when its OK, or even a good idea: its randomness pool. Adding uninitialised memory to it can do no harm and might do some good, which is why we do it. It does cause irritating errors from some kinds of debugging tools, though, including valgrind and Purify. For that reason, we do have a flag (PURIFY) that removes the offending code. However, the Debian maintainers, instead of tracking down the source of the uninitialised memory instead chose to remove any possibility of adding memory to the pool at all. Clearly they had not understood the bug before fixing it. The second bit makes it sound like the stuff that the Debian folks blindly removed was one, possibly-useful addition to the entropy pool. The first bit makes it sound like the stuff was absolutely critical to the entropy of produced keys. Which one is correct? They removed _all_ entropy addition to the pool, with the exception of the PID, which is mixed in at a lower level. -- 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: The perils of security tools
At 10:25 AM +0100 5/15/08, Ben Laurie wrote: Paul Hoffman wrote: I'm confused about two statements here: At 2:10 PM +0100 5/13/08, Ben Laurie wrote: The result of this is that for the last two years (from Debian's Edgy release until now), anyone doing pretty much any crypto on Debian (and hence Ubuntu) has been using easily guessable keys. This includes SSH keys, SSL keys and OpenVPN keys. . . . [2] Valgrind tracks the use of uninitialised memory. Usually it is bad to have any kind of dependency on uninitialised memory, but OpenSSL happens to include a rare case when its OK, or even a good idea: its randomness pool. Adding uninitialised memory to it can do no harm and might do some good, which is why we do it. It does cause irritating errors from some kinds of debugging tools, though, including valgrind and Purify. For that reason, we do have a flag (PURIFY) that removes the offending code. However, the Debian maintainers, instead of tracking down the source of the uninitialised memory instead chose to remove any possibility of adding memory to the pool at all. Clearly they had not understood the bug before fixing it. The second bit makes it sound like the stuff that the Debian folks blindly removed was one, possibly-useful addition to the entropy pool. The first bit makes it sound like the stuff was absolutely critical to the entropy of produced keys. Which one is correct? They removed _all_ entropy addition to the pool, with the exception of the PID, which is mixed in at a lower level. I take it that these are not 128-bit, non-monotonic PIDs. :-) The bigger picture is that distributions who are doing local mods should really have an ongoing conversation with the software's developers. Even if the developers don't want to talk to you, a one-way conversation of we're doing this, we're doing that could be useful. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The perils of security tools
Paul Hoffman wrote: At 10:25 AM +0100 5/15/08, Ben Laurie wrote: Paul Hoffman wrote: I'm confused about two statements here: At 2:10 PM +0100 5/13/08, Ben Laurie wrote: The result of this is that for the last two years (from Debian's Edgy release until now), anyone doing pretty much any crypto on Debian (and hence Ubuntu) has been using easily guessable keys. This includes SSH keys, SSL keys and OpenVPN keys. . . . [2] Valgrind tracks the use of uninitialised memory. Usually it is bad to have any kind of dependency on uninitialised memory, but OpenSSL happens to include a rare case when its OK, or even a good idea: its randomness pool. Adding uninitialised memory to it can do no harm and might do some good, which is why we do it. It does cause irritating errors from some kinds of debugging tools, though, including valgrind and Purify. For that reason, we do have a flag (PURIFY) that removes the offending code. However, the Debian maintainers, instead of tracking down the source of the uninitialised memory instead chose to remove any possibility of adding memory to the pool at all. Clearly they had not understood the bug before fixing it. The second bit makes it sound like the stuff that the Debian folks blindly removed was one, possibly-useful addition to the entropy pool. The first bit makes it sound like the stuff was absolutely critical to the entropy of produced keys. Which one is correct? They removed _all_ entropy addition to the pool, with the exception of the PID, which is mixed in at a lower level. I take it that these are not 128-bit, non-monotonic PIDs. :-) The bigger picture is that distributions who are doing local mods should really have an ongoing conversation with the software's developers. Even if the developers don't want to talk to you, a one-way conversation of we're doing this, we're doing that could be useful. That doesn't scale very well, though - which is why my position is that they should avoid local mods. -- 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]
Question re Turing test and image recognition
Hi gang, In looking at captchas that have been broken via software it dawned on me that the amount of mental processing involved is actually very little. I'm interested in what the current state of image recognition via software of things like knowing the difference between a monkey and a cat or a child laughing or just happy and the degree of reliability of the differentiation. I've done a bit of looking around and don't find much. Does anyone have knowledge of or a pointer to someone who might know where to look about this? Thanks, Allen - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The perils of security tools
Ben Laurie alerts us to the recent bug in Debian distributions of OpenSSL which caused the RNG to have almost no entropy. The distribution mistakenly commented out the call that added seeding and most other sources of entropy to the RNG state. This is requiring many keys to be re-issued. One of the more unfortunate aspects of this bug is that it affects not only keys generated on systems with the weak RNG, but also even securely generated DSA keys, if the keys were used for signing on systems with the bug. DSA keys are vulnerable to weak RNGs not only at keygen time but at any later time that signatures are created. This causes those keys to be far more vulnerable to problems in RNGs. The reason is the DSA signature equation sk - xr = h, where h is the message hash, r and s are signature components, x is the private key, and k is a random value chosen uniquely per message. If k is guessable, as potentially was the case with this recent bug, then x can be deduced since the other values are typically sent in the clear. A simple trick can be used to help immunize DSA signatures against these kinds of failures. I first learned of this idea many years ago from Phil Zimmermann, and a varient has been used for a long time in PGP and probably other code, but aparently not OpenSSL. The idea is to base the random k not just on the output of your RNG, but also on the private key x. Something like: k = hash (x, rng()). Of course it is still necessary that k be uniformly distributed mod q (the DSA subgroup prime order), so this can't be just a straight hash. It might be a separate PRNG instance which gets seeded with the data values shown. But the idea is to mix in the secret key value, x, in addition to data from the RNG. In this way, if the rng data is predictable but the secret key is unknown, k should still be unguessable. And if your mixing function is good then this should not leak any information about x, especially in the usual case where the rng is of good quality. A variant on this idea protects against a separate problem, where k is unguessable but somehow the same k value is used for two separate signatures. This again lets the attacker deduce x because he will observe two instances of the DSA signature equation above, with all values known except k and x, and since k is the same, this is two equations with two unknowns and allows recovering both values. To immunize against this failure, include the message hash h in the mixing function that generates k: k = hash (x, h, rng()). Now, if the RNG does produce identical output, h will typically differ among signatures, again producing unique and unguessable k values. And if h is the same for two messages in this form, k will be the same, but then r and s will be the same as well, and the second signature will be an exact match of the first and not leak new information. I think these techniques are widely known among implementors but I did not see them in HAC so I thought it was worth reminding the community here. OpenSSL is such a widely used crypto library that it would be especially valuable for it to consider incorporating these mechanisms. It would have saved some considerable pain as administrators who use OpenSSH (which depends on OpenSSL) DSA keys now are forced to consider whether they may be vulnerable to the bug even if their primary servers were not exposed to it, since any client out there may have generated insecure signatures and inadvertantly revealed secret keys. Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Call for presentations: Cryptographic e-voting systems for the IACR
The International Association for Cryptologic Research (http://www.iacr.org/ ) is seeking presentations and demos of e-voting systems. For its next meeting in August-17, 2008 (in Santa-Barbara, CA, USA), the IACR board would like to invite presentations and demos of cryptographic e-voting systems that are open source and freely available for all. For more information see http://www.iacr.org/elections/cfp.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The perils of security tools
More interesting threadage about the issue here: http://taint.org/2008/05/13/153959a.html, particularly in the comments. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Exploiting network card firmware
I didn't see Ben forward this himself, but it's definitely relevant to the discussion of malware hiding in hardware: Without needlessly boring everyone with the various steps allow me to share an interesting observation: drivers often assume the hardware is misbehaved but never malicious. It is fascinating to discover what can be done by making the hardware malicious. [...] 3) from 1 2 above, after about two years, I've reached my goal of writing a totally transparent firewall bypass engine for those firewalls which are PC-based: you simply overwrite the firmware in both NICs and then perform PCI-to-PCI transfers between the two cards for suitably formatted IP packets (modern NICs have IP offload engines in hardware and therefore can trigger on incoming and outgoing packets). The Jedi Packet Trick (sorry, couldn't resist) fools, amongst others, CheckPoint FW-1, Linux-based Strongwall, etc. This is of course obvious as none of them check PCI-to-PCI transfers, 4) I have extended the technique to provide VM escape support: one writes packets from a bridged guest into the network which initiates the NIC firmware update, updates the firmware and then the NIC firmware is used to inject code into the underlying VM host. The requirement to write to the network is then dropped as all that is required is the pivoting in the NIC firmware. http://www.links.org/?p=330 -- - Adam ** Expert Technical Project and Business Management System Performance Analysis and Architecture ** [ http://www.adamfields.com ] [ http://www.morningside-analytics.com ] .. Latest Venture [ http://www.confabb.com ] Founder [ http://www.aquick.org/blog ] Blog [ http://www.adamfields.com/resume.html ].. Experience [ http://www.flickr.com/photos/fields ] ... Photos [ http://www.aquicki.com/wiki ].Wiki - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Bletchley Park museum in financial trouble
A wonderful place. I hope it manages to pull through. http://resources.zdnet.co.uk/articles/imagegallery/0,102003,39415278,00.htm?r=234 -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: blacklisting the bad ssh keys?
At Wed, 14 May 2008 19:52:58 -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. I've been having a similar thought. This also probably applies to SSL keys, given the rather lack attitude that most clients have about checking CRLS. -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Bletchley Park museum in financial trouble
Perry E. Metzger wrote: A wonderful place. I hope it manages to pull through. http://resources.zdnet.co.uk/articles/imagegallery/0,102003,39415278,00.htm?r=234 There is a mechanism whereby US donors can send tax deductible donations to the trust. Go to http://www.cafamerica.org and search for the Codes and Ciphers Heritage Trust. I helped them rebuild Colossus a couple of years ago, and have just donated some more (thanks, Perry). Note, though, minimum donation is $500. Greg. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Question re Turing test and image recognition
Check out http://www.numenta.com/ . They have an SDK that you d/l and play with it. saqib http://doctrina.wordpress.com/ On Fri, May 16, 2008 at 8:36 AM, Allen [EMAIL PROTECTED] wrote: Hi gang, In looking at captchas that have been broken via software it dawned on me that the amount of mental processing involved is actually very little. I'm interested in what the current state of image recognition via software of things like knowing the difference between a monkey and a cat or a child laughing or just happy and the degree of reliability of the differentiation. I've done a bit of looking around and don't find much. Does anyone have knowledge of or a pointer to someone who might know where to look about this? Thanks, Allen - 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: blacklisting the bad ssh keys?
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]
Re: blacklisting the bad ssh keys?
On Wed, May 14, 2008 at 7:52 PM, Steven M. Bellovin [EMAIL PROTECTED] 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. Debian has two packages, one call openssh-blacklist (1024 DSA and 2048 bit keys RSA keys) ~4MB, and an unstable package openssh-blacklist-extra for non-default key sizes sizes that are simple lists of blacklisted keys. current source: http://ftp.debian.org/debian/pool/main/o/openssh-blacklist/openssh-blacklist_0.3.tar.gz from the README: - The blacklists are separate by architecture, type, and bit size. The contents are ordered by process pid, starting at PID 1 and ending at PID 32767. While generating entries, each possible process ID must be used. To help automate this, LD_PRELOAD is used to override the getpid() libc function. See generate-blacklist.sh for details. Note that the list is architecture-specific. - -Michael - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
