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]
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 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, 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]
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: 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]
