Re: Keysigning @ CFP2003
On Mon, 24 Mar 2003, Ian Grigg wrote: > I must be out of touch - since when did > PGP key signing require a photo id? It does not. It is improper for a key-signing organizer to dictate signing policy to individuals. When I wrote the Efficient Group Key Signing Method paper[1], I specifically omitted identity verification steps, since it is no one's business but the holder of the key (and those who trust that key as an introducer) what information the holder requires before signing. Incidentally, the GnuPG FAQ perpetuates this fallacy, so Doug is probably not to blame for this mistake. There are better ways of determining identity, and one of the benefits of PGP is that we aren't locked in to a strict, rigid model of how trust is to be assigned. Convincing people that [easily forged] government IDs are sufficient to verify identity is a dangerous practice. A better thing to do is to announce in the key-signing notice that individuals may want to bring government ID in the case that someone attending will require it to satisfy his signing policy -- rather than dictating signing policy to your participants. --Len. [1] http://sion.quickie.net/keysigning.txt - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Obituary for Janis Jagars (Disastry)
Janis Jagars, known to many people on the Internet by his handle Disastry, was a prolific programmer who made numerous valuable contributions to the Internet. I am afraid I cannot do his memory justice, having known him only a short number of years and only through his work on privacy enhancing programs, but he earned my respect and appreciation for his achievements in that area. I first "met" Janis Jagars while I was employed by PGP Security. In preparation for the release of PGP 7, I located and contacted the people responsible for other implementations of OpenPGP, in order to set up interop testing. Janis was working on updating the DOS-aware PGP 2.6.3i program to work with modern implementations of PGP. His work on that program, and his presence in the IETF OpenPGP working group, helped to smooth over a number of PGP compatibility problems. On the PGP newsgroups and mailing lists, Janis helped many new PGP users get started using email encryption, and tirelessly answered support questions for privacy-related programs. To my knowledge, Janis operated the only anonymous remailer to exist in Latvia. Janis was, by the original definition, a true Cypherpunk. He believed that privacy was a right that must not be denied to Internet users, and he wrote code to help ensure that it could not be. When he needed a way to easily send encrypted email through Netscape, he wrote a plugin. When he wanted a way to mount PGPdisk volumes under Linux, he wrote a conversion tool. When Windows users wanted a pre-compiled version GnuPG, Janis gave them one. Janis understood that the fight for Internet privacy must take place at the hands of programmers, and he rose to the challenge of bring useful privacy-enhancing programs into existence, and into the hands of the public. Immediately after the terrorist attacks in September, 2001, I took over maintenance of the Mixmaster anonymous remailer project. Mixmaster had been unmaintained for over a year, and needed serious work. I was delighted when I received email from Janis, offering his help. Over the next year, entirely of his own initiative, Janis ported Mixmaster's server functionality to Windows, brought Mixmaster's OpenPGP support from an unstable "alpha" state to a solid, usable feature set, and established himself as an invaluable member of the Mixmaster development team. The upcoming Mixmaster 3.0 release features a number of crucial improvements which would not have happened had it not been for Janis's involvement. My last communication with Janis was on October 11th of last year. He had planned a vacation in Nepal, and expected to return a month later. When he did not return, we feared the worst. Sadly, it turns out that our fears were true: On October 31, while descending from Lobuche summit, Janis fell 250m, and did not survive. I am dedicating this year's CodeCon conference to Janis's memory. Janis will be missed, but his contributions will still be appreciated and utilized. It is my hope that Janis's work will serve as an example for other like-minded programmers, who chose to give their time and code in the name of free speech and privacy. Len Sassaman 13 February 2003 San Francisco, CA -- Janis's home page may be viewed here: http://web.archive.org/web/20010927055328/disastry.dhs.org/ News of his accident can be found here: http://www.vertikalex.lv/minisurvey/Discussion/ShowMessage.asp?ID=4703 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
CodeCon Registration Deadline Approaching
CodeCon is fast approaching, and there are only three days left to register online for CodeCon at the reduced rate. CodeCon 2.0 is the premier event in 2003 for the P2P, Cypherpunk, and network/security application developer community. It is a workshop for developers of real-world applications with working code and active development projects. Last year, presentations at CodeCon included the Peek-A-Booty anti-censorship application, the Invisible IRC Project, the CryptoMail web-based email encryption project, and the file-distribution application BitTorrent. Some of this year's highlights include Mixminion, a next-generation anonymous remailer; Alluvium, Internet Radio software exempt from current RIAA webcasting royalties; and GNU Radio, an open source software defined radio application. CodeCon registration is $95; a $15 discount is available for attendees who register online prior to February 15th. CodeCon 2.0 will be held February 22-24, noon-6pm, at Club NV (525 Howard Street) in San Francisco. For more information, please visit http://www.codecon.info. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Keep it secret, stupid!
On Sun, 26 Jan 2003, Matt Blaze wrote: > The tragic part is that there are alternatives. There are several > lock designs that turn out to resist this threat, including master > rings and bicentric locks. While these designs aren't perfect, they I think it is worth pointing out that, while master ring systems (and master-keyed systems with false steps added) resist the attack Matt describes, they often make the task of picking the lock (on a case by case basis) easier. That needs to be considered when designing a physical security plan. One may wish to key locks of particular importance separately from the master ring system if entry by picking is a concern. (There are some master-key systems, like the one made by Corbin, that require pin rotation at the proper time to unlock the secondary sheer line. And, as Matt mentioned, bicentric cylinders avoid this problem completely. Cost may be a major concern with these solutions, though.) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [IP] Master Key Copying Revealed (Matt Blaze of ATT Labs)
On Sat, 25 Jan 2003, Pete Chown wrote: > Len Sassaman wrote: > > > Most of the time, the lock is not the weakest point of attack. > > Isn't this like saying that cryptography isn't important, because most > real world attacks aren't cipher breaks? No. It's similar to arguing against a system because it uses 56 bit DES, but missing the fact that the cryptosystem isn't actually encrypting the plaintext at all. > Also, if you pick the lock, potentially no one will know that you > gained access. An ordinary burglar can just break a window, but > someone with a more subtle reason for wanting to gain access may not > want to. There are many, many entrance techniques which do not cause any physical damage whatsoever, which also do not require direct manipulation of the pin tumbler mechanism. > If I wanted to make a building physically secure, my instinct would be > to use electronic locks. While attacks on, say, an iButton are probably > possible, it seems to me that it must be an order of magnitude more > difficult than attacking a mechanical lock. Again, you're missing the weakest point of attack. *Ignore* the actual lock. It doesn't matter if you have an iButton or an ASSA or a Kwikset if the door is secured with an improperly installed spring-latch mechanism, and it can be opened with a shim. Only after you get the rest of the physical security aspects addressed should you spend time thinking about the lock, because it takes a lot more time, effort, or talent to attack a lock than it does to jimmy a latch. I would say that 60 percent of the doors I have stood before in my life, I could have opened with items I carry in my pocket on a daily basis. Another ten percent would have required picking. The world of physical security doesn't rely on "security through obscurity." It relies on security through illusion. > Now, I'm not an expert on locks, so firstly am I right? If so, does > this mean that high security mechanical locks will gradually disappear? Nearly all installed locks do nothing more than keep honest people honest. I don't see this changing anytime soon. I used to jump up and down about physical security problems when I encountered them, until I learned that people generally don't want to hear if they have security problems -- they just want to think they are safe. One of my previous employers was a web hosting company, who had a locked data center. On my second day working for them, I pointed out that I could open the door to their datacenter with a credit card. They didn't believe me. I demonstrated. Did they thank me for this bit of information? Nope. I was nearly fired. If you have to sign an NDA before you visit a company's colocation facility, ask yourself what it is you are about to see that would do damage to the company if you spoke about it. Locked cages? Look at the raised floors. None of these problems even come close to the issues of lost keys and overly helpful employees, though. Criminals have been using social engineering techniques to get into locked buildings for as long as there have been locked buildings. My comments in this thread have never been intended to criticize Matt for publishing his paper. In fact, I hope I've praised it. I just don't think that it will affect the status quo. --Len. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [IP] Master Key Copying Revealed (Matt Blaze of ATT Labs)
On Sat, 25 Jan 2003, Sampo Syreeni wrote: > Sure. But trying those combinations out can be automated -- I don't think > the kind of automatic lock pickers one sees in current action movies are > *entirely* fictional. I've never encountered an automatic key combination decoder, but it would presumably be possible to build for a lot of locks. Most automatic lock picks are variations on the snap-gun design, however, which is an entirely different approach to lock picking. (Think of when you hit a cue-ball with a pool cue, and it hits the target ball. The cue ball stops moving, and the target ball speeds off. That's the principal behind a snap-gun: the snap-gun is the cue, the bottom pin is the cue-ball, and the top pin is your target. You use the snap-gun to strike all the pins at once. The top pins fly up past the sheer line, the bottom pin stays below it, and deft use of a tension wrench lets you turn the cylinder at just the right moment.) > Rotational shear dictates that the key channel of every normal lock must > have a certain minimum cross-section, given a material for the key. If you > think about how long a lock cylinder can be in common applications, one > has a whole lot of room for all sorts of mechanics within the space > alloted for the key in a working lock. It might even be the length of the > cylinder is strictly limited by rotational shear concerns. My first take > on designing an automated probe would simply be to apply rotational noise > to the lock, record the vibration coming back, while sliding a probe > through the cylinder. When each disc/pin is pushed into the free position, > one would expect it to be exceedingly difficult to hide changes such a > match will cause in the response of the signal chain. I have met people who can decode a lock's pin combination by feel, so what you are describing is almost certainly possible. > >If you have a location which is secured in such a manner that the lock's > >security is of concern, you should look into a lock such as Medeco, which > >employs a number of security features which resist these attacks. (Angled > >cuts, restricted key blanks, etc.) > > I would equate the latter with both security-thru-obscurity, and purely > legislative approaches to security. That is, I wouldn't lay a lot of > weight on them. The former, that I've already found a minor complication. It's not exactly security-through-obscurity. The blank's cuts are known -- but in order to make blanks of your own, you have to go through a lot of effort. It's a protection based on increasing the work an attacker needs to do to succeed. > That's the spirit. I wouldn't exactly go with the live stuff, but > otherwise crickets sound simply nutritious. Not to mention delicious, > after having been dipped in honey. ;) Now, there's another yummy idea. > It might well be you have to get acquainted with'em crickets. Well, here's the deal. If Matt decides he really wants to see me feast on crickets, I'll send him a box locked with a Medeco lock that has two possible change keys (they aren't really master/change in this scenario). I'll give him one of the change keys. If he shows up at DEFCON[*] with the other change key, without disassembling the lock or the box, I'll publicly "eat my words." I'm betting my dignity on the assumption that Matt has better things to do. :) --Len. [*] Insects have a history of being eaten by people when The Shmoo Group gathers at DEFCON. It's as good a place as any. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [IP] Master Key Copying Revealed (Matt Blaze of ATT Labs)
On Fri, 24 Jan 2003, Matt Blaze wrote: > Len, > > We're probably getting a bit into the depths of the details for this > (cryptography-oriented) list, so I'll certainly understand if Perry doesn't > forward this on. Ditto. Time for a "lockpunks@" list? =) > It surely would be possible to have a Medeco-type design using > different rotations for the change and master by cutting new holes/grooves > in the bottom pin. I've not seen that on any of the Biaxial pins > I've looked at, and the Medeco pinning kits I've seen seem to have > such pins in them (maybe they sell them only to certain customers? In > any case, such a kit would have to be very large indeed). I was trying to draw this in ASCII-art, and failing. Looks like Derek had the same problem. In any case, you'll typically find the more complex pin combinations in installations where you need a large amount of change keys on the same master key. It's more work to design a master-key system when you add in these additional variables, so some locksmiths probably won't do it unless they have to. > But even if they did, you'd still be able to straightforwardly do the > attack, consuming up to 3 (in the standard design) or 6 (in the Biaxial > design) blanks per pin (at each rotation/offset). I'm forgetting off the top of my head how many pins a Medeco Biaxial has -- it's 7, right? That would mean in the worse case you would need to try 42 different key blanks. And filing a Biaxial is probably not feasible, so you would need the machine. I'm just not convinced this would ever be done. The time and effort involved would almost certainly make this a less efficient attack than others. > Some of the "restricted" Medeco blanks are in fact readily available; others > aren't but can be modified from available blanks, and still others > seem to require extensive milling or casting. Medeco has a number of different blanks for a number of different security models. The restricted ones are either "Card restricted", where you can go to a Medeco authorised locksmith and present your signature card to have the key duplicated; "Contract restricted" where your key is using a blank that is tied to a specific locksmith (or specific to your organization), and you must deal with that locksmith only; and "Factory restricted", where Medeco itself does duplication, and the key blanks are not released outside of the factory. The last two require the same signature card/ID authorization as well. Sure, you could mill or cast your own blanks to beat the factory controls. That is surely a waste of time, since either there are going to be easier ways to gain access without attacking the lock directly, or the lock will be using dummy-stepping if not on a master-ring system, because the locksmith has considered this attack. --Len. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [IP] Master Key Copying Revealed (Matt Blaze of ATT Labs)
On Fri, 24 Jan 2003, Matt Blaze wrote: > I have no particular interest in seeing you eat crickets (and before > I went veggie I've eaten a few myself; taste like whatever they're > cooked in), but I've done it on Medecos; it's no problem. Well, unfortunately I specified "live", which probably precludes the cooking bit. Hmm. Cricket fondue, perhaps. > The angles will be the same on the master as the change key; only the > cut depth will differ. That isn't necessarily the case. High-security Medecos can have multiple valid pin rotation positions -- the pin's angled surface doesn't need to be flush with the key. This allows much larger number of possible pin combinations, and I think it would make your attack infeasible in practice (particularly since the attacker presumably doesn't know if there are dummy steps added, or if the key is part of a master-ring system. That's a lot of work to do only to find out the attack wouldn't have worked in the first place.) > If you have a code cutter at the oracle lock it's no different from > doing the attack regular locks, except that Medeco's MACS restrictions > mean you have to be careful about whether you use the change depth or > previously learned master depth at the positions adjacent to the > position under test. That would certainly be true. > If you're using a file at the oracle lock, just use a code machine to > pre-cut a #1 cut at the right angle at each position; the sharp angle > actually makes filing a bit easier than on locks with a standard cut. > I recommend a light garlic sauce. *grin* Have you found a source for the factory-controlled Medeco key blanks? --Len. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [IP] Master Key Copying Revealed (Matt Blaze of ATT Labs)
On 24 Jan 2003, David Wagner wrote: > If those locksmiths didn't publish the vulnerability, phooey on them. > Matt Blaze deserves full credit for being the first to publish. I'm fairly certain this has been published in locksmithing journals previously, though I would have to do some digging to prove that. > What good is it to know about a vulnerability if you never warn the > users and never fix the weakness? It is the prevailing opinion in the physical security space that users are not the best qualified to judge their own threat models. Whether or not this is correct could be up for debate, but trying to force high-security locks on someone who doesn't need it is viewed with the same sort of disdain that you might have for a company trying to sell Tempest-shielding to a small business owners. The actual lock is very rarely the point of least resistance for an attack. [These and other weaknesses are, in fact, addressed in a number of high-security locks. Most users won't want to pay for them.] > In scientific research, we credit the first person to publish new > knowledge. Sure, maybe you've invented a cure for cancer ... but if > you don't tell anyone, you don't get the credit, and you haven't done > much good for the world. > > I think, on balance, Matt Blaze's paper seems likely to be beneficial > for users of locks. It helps us more accurately evaluate our own > security and be smarter about how we select physical security defenses. > That seems likely to lead to greater security for all of us in the end. > We should be grateful to Blaze for publishing, not dismissive. Matt's paper is beneficial to fledgling locksmiths, but I'm uncertain if it will have any effect on users. Perhaps I'm cynical. Here's a story you might find interesting. A few years ago, a certain employee of a Silicon Valley company with which both you and Matt may be familiar asked me to evaluate the physical defenses of one of their facilities. The goal was to see how close I could get to the center of the building. They had a magnetically-sealed front door, a hand geometry scanner on one inner door, iButton access on another, and fairly secure physical lock cylinders. I was able to get inside with nothing more than a coat hanger, credit card, and a pen knife. This is the reality of physical security. Designing a burglar-proof installation is tricky business, and using secure locks is usually the least of the problem. A user who needs full security should be engaging a qualified physical security specialist to do the design and installation, and a security professional who knows how to address all the other potential attacks will surely be aware of key decoding techniques, and how to defend against them. Matt's technique is clever, and I am impressed that he came up with it on his own. His paper is well-written, and explains a lot about master-keyed systems in general. People interested in becoming locksmiths or entering the physical security business will definitely want to read it. I don't think it is going to significantly increase security in the real world, however. --Len. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [IP] Master Key Copying Revealed (Matt Blaze of ATT Labs)
On Fri, 24 Jan 2003, Arnold G. Reinhold wrote: > If all the master cuts are higher than the change cuts, I believe you > can carry out Len's procedure with a single blank. You start with the > master key and file it down one pin position at a time until it > becomes the change key. If that were the case, sure. However, you usually can't know that the master key sheer line is higher than the change key, so this doesn't work in practice. > The apparently common restrictions on where the master cuts can be > relative to the change cuts would seem to severely limit the number > of possible master keys for any given lock style. Note that these aren't actually direct restrictions on where the master key sheer line is in relation to the change key sheer line, but instead restrictions on the height difference between a given pin and the pins adjacent to it. This has the side-effect of limiting where the master key sheer line is in respect to the change sheer line, because both of these must be within the allowed distance of steps between pins. (This is a purely physical limitation. If you had pins that were of drastically different heights next to each other, key insertion would be extremely difficult or impossible.) > It might well be possible to construct a priori a set of all possible > master keys for a given lock style. This would make such systems > vulnerable to someone who lacks even a change key. Heck, it's possible to construct a set of all possible *keys* for a given lock. Even with the optimizations of knowing which pin combinations are physically impossible to use, however, this is still a lot of combinations. > A careful lock picker could also deduce a lot of information on where > the master cuts are. Yes. A very talented locksmith could decode a pin combination on a lock using special lock-picking tools, such as a feeler. However, in nearly all real-world scenarios, this would not make sense. Most of the time, the lock is not the weakest point of attack. Attacking the lock in this manner is analogous to breaking a crypto-system by attacking the cipher. Usually, other parts of the implementation are much weaker. (And, in the case of a legitimate entry by a locksmith, destroying the lock by drilling or other means would probably be cheaper than the labor costs.) If you have a location which is secured in such a manner that the lock's security is of concern, you should look into a lock such as Medeco, which employs a number of security features which resist these attacks. (Angled cuts, restricted key blanks, etc.) (On another list, I joked that if Matt could get his technique to work on a Medeco master-keyed system by July, I'd eat a pound of live crickets at DEFCON. I'll hold myself to that.) --Len. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [IP] Master Key Copying Revealed (Matt Blaze of ATT Labs)
On Thu, 23 Jan 2003, Matt Blaze wrote: > A brief summary is available on my web page at > http://www.crypto.com/masterkey.html > with links to the full (4MB) paper. > > Note that this is a bit slashdotted at the moment... This is a rather clever technique for discovering the second key of a dual-keyed lock; however, it wasn't previously unknown. I do give Matt a lot of credit for having come up with it independently, though I think it is worth pointing out that any good locksmith would already have been aware of this. It was described to me in 1997, when I first started working with locksmithing, as a way of determining a given lock's change key knowing only the master key (and having access to the lock, but not the ability or desire to disassemble it.) Using this to find a change key when you have a master key isn't nearly as interesting from the point of view of an attacker, but is the more common use of this technique in the locksmithing field. The fact that AT&T couldn't find much public mention of this technique isn't surprising. Locksmithing is a more secretive discipline than cryptography. Locksmiths generally don't discuss the plethora of ways to defeat standard physical security techniques with the general public. Sometimes I think they understand the issue of threat-models better than cryptographers do. They certainly understand that the public doesn't understand. --Len. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
CodeCon presentations announced and registration open
CodeCon 2.0 is the premier event in 2003 for the P2P, Cypherpunk, and network/security application developer community. It is a workshop for developers of real-world applications with working code and active development projects. CodeCon registration is $95; a $15 discount is available for attendees who register online prior to February 15th. CodeCon 2.0 will be held February 22-24, noon-6pm, at Club NV (525 Howard Street) in San Francisco. http://www.codecon.info Presentations will include: * Advogato - Good metadata, even when under attack, based on a trust metric * Alluvium - p2p media streaming for low-bandwidth broadcasters * Bayonne - Telephony application services for freely licensed operating systems * Cryptopy - pure Python crypto * DeepGreen - Agent Oriented investment analysis designed to be self-funding * GNU radio - Hacking the RF Spectrum with Free Software and Hardware * HOTorNOT - A working example of well-designed website user interface * Hydan - Steganographically conceal a message into an executable application * Khashmir - A distributed hash table library upon which applications can be built * Mixminion - A next-generation anonymous remailer * Neurogrid - Decentralized Fuzzy Meta-Data Search * OpenRatings - An open source professor ratings engine * Paketto Keiretsu - Interesting and Useful Techniques for TCP/IP Networking * YouServ - A communal web-hosting system for the masses * A panel on future directions in version control - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: PGPfreeware 8.0: Not so good news for crypto newcomers
On Mon, 9 Dec 2002, Peter Gutmann wrote: > "Richard Johnson" <[EMAIL PROTECTED]> writes: > > >To my dismay, the developers of gnupg chose to embed the command line > >processing deep in their software, making doing a proper library-supported > >GUI more difficult. This was the same mistake that made PGP 2 such a bear to > >port, etc. I wish I had the time or skill to fix that, but the reality is I > >simply don't have either. > > There are other PGP libraries available. The Veridis Filecrypt SDK, > http://www.veridis.com/products/FileCryptSDK/fcsdk.asp, is a commercial > offering which uses the OpenPGP format, A warning about Filecrypt SDK -- A few months ago, I was doing OpenPGP interop testing between Mixmaster and some other 2440 implementations, including PGP, GnuPG, Hushmail, and Zendit. In the course of this testing, I discovered that Zendit, which is based on Veridis's SDK, had a rather alarming bug: it had no concept of subkey binding signatures (it neither generated them, nor did it verify them.) The implications here are obvious. I didn't do any further investigation of this bug, since I found far too many other interop/usability flaws in Zendit to justify continuing to worry about it, and I don't know of anyone else using FileCrypt. Consequently, I don't know if this was a Zendit-specific bug or a problem with FileCrypt. I notified both the Zendit and Veridis people about this problem. I haven't heard from either if this has been fixed. --Len. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
CodeCon 2003 Call for Papers
CodeCon 2.0 February 22-24, 2003 Club NV San Francisco CA, USA www.codecon.info Call For Papers CodeCon is the premier showcase of active hacker projects. It is an excellent opportunity for developers to demonstrate their work, and for coding hackers to find out about what's going on in their community. All presentations must be accompanied by functional applications, ideally open source. Presenters must be one of the active developers of the code in question. We emphasize that demonstrations be of *working* code, and reproducible by other people. Throughout the event, we will have several kiosks and local servers available for demonstration purposes. CodeCon strongly encourages presenters from non-commercial and academic backgrounds to attend for the purposes of collaboration and the sharing of knowledge by providing free registration to workshop presenters and discounted registration to full-time students. We hereby solicit papers and demonstrations. * Papers and proposals due: December 15, 2002 * Authors notified: January 1, 2003 * Demonstration materials due: January 15, 2003 The focus of CodeCon is on working applications which: * enhance individual power and liberty * can be discussed freely, either by virtue of being open source or having a published protocol, and preferably free of intellectual property restrictions * are generally useful, either directly to a large number of users, or as an example of technology applicable to a larger audience * demonstrate novelty in technical approaches, security assumptions, and end-user functionality Possible topics include, but are by no means restricted to: * development tools - languages, debuggers, version control * file sharing systems - swarming distribution, distributed search * community-based web sites - forums, weblogs, personals * security products - mail encryption, intrusion detection, firewalls Presentations will be a 45 minutes long, with 15 minutes allocated for Q&A. Overruns will be truncated. Submission details: Submissions are being accepted immediately. Acceptance dates are September 1, November 1, and December 15. On each acceptance date, submissions will be either accepted, rejected, or deferred to the next acceptance date. The conference language is English. All submissions should be accompanied by source code or an application. When possible, we would prefer that the application be available for interactive use during the workshop, either on a presenter-provided demonstration machine or one of the conference kiosks. Ideally, demonstrations should be usable by attendees with 802.11b connected devices either via a web interface, or locally on Windows, UNIX-like, or MacOS platforms. Cross-platform applications are most desirable. Please not that our venue is 21+. To submit, send mail to [EMAIL PROTECTED] including the following information: * Project name * url of project home page * tagline - one sentence or less summing up what the project does * names of presenter(s) and urls of their home pages, if they have any * one-paragraph bios of presenters (optional) * project history, no more than a few sentences * what will be done in the project demo * major achievement(s) so far * claim(s) to fame, if any * future plans Conference Producers and co-chairs: Bram Cohen, Len Sassaman Program Committee: * Tina Bird, Counterpane * Bram Cohen, BitTorrent * Roger Dingledine, The Free Haven Project * Jered Floyd, Permabit * Paul Holman, The Shmoo Group * Ben Laurie, The Apache Foundation * Don Marti, Linux Journal * Jordan Ritter, Cloudmark * Len Sassaman, Nomen Abditum Services * Rodney Thayer, The Tillerman Group * Jamie Zawinski, DNA Lounge Sponsorship: If your organization is interested in sponsoring CodeCon, we would love to hear from you. In particular, we are looking for sponsors for social meals and parties on any of the three days of the conference, as well as sponsors of the conference as a whole, prizes or awards for quality presentations, scholarships for qualified applicants, and assistance with transportation or accommodation for presenters with limited resources. If you might be interested in sponsoring any of these aspects, please contact the conference organizers at [EMAIL PROTECTED] Press policy: CodeCon strives to be a conference for developers, with strong audience participation. As such, we need to limit the number of complimentary passes for non-developer attendees. Press passes are limited to one pass per publication, and must be approved prior to the registration deadline (to be announced later). If you are a member of the press, and interested in covering CodeCon, please contact us early by sending email to [EMAIL PROTECTED] Members of the press who do not receive press-passes are welcome to participate as regular conference attendees. Questions: If you have questi
Re: 1024-bit RSA keys in danger of compromise
I've posted my thoughts about Bernstein's paper to the NANOG list, so I won't recap them here. I do want to make one point that people seem to be ignoring, however, and it has to do with the section of Lucky's message that I have quoted below. There are several significant applications in wide-spread use currently that do not have any mechanism for the user or administrator to specify a minimum public key algorithm bit size. Additionally, Verisign appears to not have a policy against signing ridiculously small RSA keys -- I've been told that they signed a 384 bit key in the past year. If you're interested, buy the Netcraft SSL survey results and see how many 512 bit RSA keys are being used now. On the client side, Internet browsers should have a mechanism for specifying the minimum key size that a user is willing to accept to secure his TLS/SSL connection. Not offering this as a standard feature, with sane defaults, is downright negligent. Both Netscape/Mozilla and Microsoft appear guilty of this. Likewise, I cannot find any way of configuring sshd (in any version of SSH/OpenSSH server software) to deny users' public key based authentication based on insufficient key size. Either I have to turn off public key authentication and rely on passwords, or allow users to use factorable keys. This needs to be fixed, immediately, and documented properly. The feasibility of factoring 1024 bit keys, while a very serious issue that needs to be examined, seems almost irrelevant if software users cannot specify a lower limit on public key bit sizes in their applications. --Len. On Sat, 23 Mar 2002, Lucky Green wrote: > Coincidentally, the day before the panel, Nicko van Someren announced at > the FC02 rump session that his team had built software which can factor > 512-bit RSA keys in 6 weeks using only hardware they already had in the > office. > > A very interesting result, indeed. (While 512-bit keys had been broken > before, the feasibility of factoring 512-bit keys on just the computers > sitting around an office was news at least to me). - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NAI puts PGP into Maintenance
On Thu, 28 Feb 2002, R. A. Hettinga wrote: > Dear Valued Customer, [...] > > The PGP technology and source code will remain under the control and > ownership of Network Associates. Other products that utilize this > encryption technology will remain a part of Network AssociatesÂ’ > current product portfolio and they will continue to be developed in > order to meet the security needs of both new and existing Network > Associates customers. These products currently include McAfee > E-Business Server, McAfee Desktop Firewall and McAfee VPN Client. This explains a few things. When I first saw the announcement that NAI was selling PGP, I was very surprised at what they were selling and not selling. PGP used to be an "all-in-one" crypto solution, which included things like a disk encryption program, an IPSEC implementation, and recently a personal firewall in addition to the PGP mail and file encryption we're used to. It appeared from the original announcement that NAI wasn't going to be selling some of the more interesting chunks of the product, such as the IPSEC utility, the firewall, and most importantly, the SDK (which is the heart of all the PGP programs.) Without the SDK, I'm not sure how useful any of the other code would be to a buyer. Apparently, not very. "McAfee E-Business Server, McAfee Desktop Firewall and McAfee VPN Client" have changed their names. I'm pretty sure that McAfee Desktop Firewall used to be PGPfire. McAfee VPN Client was PGPnet. and McAfee E-Business Server is the command-line version of PGP. I find it hard to believe that NAI expects to make money selling E-Business Server (for server-side PGP encryption) if there is no longer a supported client-side implementation. *boggle* --Len. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: PGP & GPG compatibility
On Sun, 20 Jan 2002, John Gilmore wrote: > These days, PGP is effectively useless for interoperable email. If > you have not prearranged with the recipient, you can't exchange > encrypted mail. And even if you have, one or the other of you will > probably have to change your software, which will produce other ripple > effects if you are trying to talk to TWO different people or groups > using encrypted email. Really, interoperability is not that bad. Aside from some rather obscure nits between implementations, every PGP implementation pretty much talks to every other one without any major problems. The biggest compatability barriers are PGP 2.6 users' inability to encrypt to v4 (the newer OpenPGP) keys, and GnuPG's lack of the IDEA algorithm. The former is solved either by PGP 2.6 users upgrading their PGP software to one that understands v4 keys (note that this doesn't mean they need to give up their older v3 (PGP 2.6-style) keys), or the other user generating a v3 key for use with 2.6 users. I use PGP on a regular basis for a large portion of my email, and rarely have I encountered this problem. Whenever this discussion comes up, someone inevitably insists that PGP 2.6 is in widespread use and PGP as a whole is flawed because 2.6 can't encrypt to the newer keys, but I just don't see this as a reality. The second problem is a less severe extension of the first problem, and used to be easily correctable by dropping in an IDEA algorithm module (which, unfortunately, seems to no longer exist on the GnuGP website). The Lack of IDEA in GnuPG makes it less friendly to those wishing to upgrade from PGP 2.6 or communicate with PGP 2.6 users, but again, this isn't noticeable by the majority of the users. The biggest problem with PGP is not an interoperability issue, but a UI issue. A secure email system should appeal to the casual user, and also be easily deployed by the casual user. Most email users don't understand how signatures work, why public key crypto really does, what signing keys and checking fingerprints are for, etc. Even if all versions of PGP had been designed perfectly the first time, interoperated with each other flawlessly, and had no bugs appear in them ever, this problem would still exist. PGP intentionally sacrifices usability for security. --Len. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
