Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA12057 for ietf-open-pgp-bks; Thu, 30 Apr 1998 16:59:28 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA12053 for ; Thu, 30 Apr 1998 16:59:28 -0700 (PDT) Received: from fnord (tns40.pgp.com [161.69.9.40]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id QAA22385; Thu, 30 Apr 1998 16:57:31 -0700 (PDT) Message-Id: <3.0.3.32.19980430165439.00a6d160@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 30 Apr 1998 16:54:39 -0700 To: Werner Koch , ietf-open-pgp@imc.org From: Jon Callas Subject: Re: Some suggestions Cc: g10@net.lut.ac.uk In-Reply-To: <19980428145734.A26213@frodo.isil.d.shuttle.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 02:57 PM 4/28/98 +0200, Werner Koch wrote: 1) The comment packets are gone. Ooops. How can write code when the specification is changed at will. I was lucky to find a solution for the moved comment packet number from 14 to 16 - and now there is no comment packet at all. So what shall I do? Go back to RFC1991 or stay with comment packet of type 16? Comment packets are very useful: I use them to store the factorization of the ElGamal prime (in case someone wants to check it), store a program version number to make debugging easier. Another use is to transport additional informations to other programs in a pipeline. *Please put the comment packets back into OpenPGP* The comment packet is gone at the area director's request. The uses you give for it are good ones, but other protocols with similar features have also had them removed. However, if you want to carry meta-data in a pipeline, there's no reason why you can't use packets 60-63 for this. They are specifically reserved for private or experimental use. 3) 4 new signature classes 0x14 to 0x17 which are like 0x10..0x13 but do a hash over all preceding user id packets. This has the advantage of keeping a public key certificate small but a signator is still able to sign more than one user-id. 4) A signature class which can used to sign the complete public key certificate would be very nice - or is there already one which can be used for this purpose? These are both good features for post-V1. Presently, the packets in a certificate can be re-ordered. Not arbitrarily, but sigs under a given user id can be reordered, and the user names themselves can be reordered. Because of this, there's no way to specify what it means for a user id to be preceding, or what order to hash the whole thing. I think this is a wonderful use for the extension mechanism -- you could write into an extension (notation) the values of the other user names you wanted to sign. Jon ----- Jon Callas jon@pgp.com CTO, Total Network Security 4200 Bohannon Drive Network Associates, Inc. Menlo Park, CA 94025 (650) 473-2860 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA12042 for ietf-open-pgp-bks; Thu, 30 Apr 1998 16:56:45 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA12038 for ; Thu, 30 Apr 1998 16:56:44 -0700 (PDT) Received: from fnord (tns40.pgp.com [161.69.9.40]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id QAA22378 for ; Thu, 30 Apr 1998 16:57:10 -0700 (PDT) Message-Id: <3.0.3.32.19980430165555.00b07d50@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 30 Apr 1998 16:55:55 -0700 To: ietf-open-pgp@imc.org From: Jon Callas Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt In-Reply-To: <199804231354.JAA02026@ns.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk The minutes from LA aren't out yet, so I'm going to relate my portion of them. My apologies for not getting this note out sooner. I wrote 80% of it last week, and then forgot to finish. I had been wondering why I hadn't seen it on the list. The draft I released is one that I'd like to make the "penultimate call." Think of it as dress rehearsal for last call, or my admitting that there will be minor things to change. As you've no doubt seen, the significant changes are some more re-ordering of sections, and a new section of notes on algorithms, and the new "five-octet" definite lengths (which actually hold a four-octet number). I've also done a few other things with algorithms. Rot-N is gone. There is an algorithm identifier for Elgamal encrypt-and-sign keys. I have a question on this -- we wanted to deprecate the usage-types on RSA keys (i.e. separate algorithm numbers for, but the issues surrounding Elgamal signatures make it apparent that it's good to have a separate algorithm ID for an encrypt-and-sign Elgamal key. See the algorithm notes for details. Does this mean, then, that we should de-deprecate the RSA usage-types? I'd just as soon keep them deprecated because there are real cryptographic reasons for a separate Elgamal ID. I added in MD2 as a hash algorithm. There are people who want to do PGP/X.509 interoperability, and they need an identifier for MD2. We still don't have an OID for HAVAL. Can someone get one? Having HAVAL in there is nice, but I'm a lazy SOB and it's easier for me to remove HAVAL than to get it an OID. I also think that if having HAVAL is important to the community, then there oughta be one person who would stand up and take it upon themself to get an OID. I'm going to go over comments on this draft over the next week or three and produce a last-call draft. Early revisions will go to the usual gang. If you have something you really, really want done, let me know. I'll make sure you get an early revision. I want last call to be quiet, so we can call this a wrap and then get on to the *real* discussions of what's good to have in OpenPGP. Jon ----- Jon Callas jon@pgp.com CTO, Total Network Security 4200 Bohannon Drive Network Associates, Inc. Menlo Park, CA 94025 (650) 473-2860 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id FAA15155 for ietf-open-pgp-bks; Wed, 29 Apr 1998 05:02:28 -0700 (PDT) Received: from gizmo.lut.ac.uk (gizmo.lut.ac.uk [158.125.96.46]) by mail.proper.com (8.8.8/8.7.3) with SMTP id EAA15137 for ; Wed, 29 Apr 1998 04:59:31 -0700 (PDT) Received: from root by gizmo.lut.ac.uk with local (Exim 1.82 #1) id 0yUUfJ-0003E5-00; Wed, 29 Apr 1998 12:04:41 +0100 Received: from (dfw-ix10.ix.netcom.com) [206.214.98.10] by gizmo.lut.ac.uk with esmtp (Exim 1.82 #1) id 0yUDEC-0000GB-00; Tue, 28 Apr 1998 17:27:32 +0100 Received: (from smap@localhost) by dfw-ix10.ix.netcom.com (8.8.4/8.8.4) id LAA04330; Tue, 28 Apr 1998 11:25:04 -0500 (CDT) Received: from sjc-ca6-11.ix.netcom.com(207.94.249.203) by dfw-ix10.ix.netcom.com via smap (V1.3) id rma004302; Tue Apr 28 11:24:51 1998 X-Sender: frantz@netcom7.netcom.com Message-Id: In-Reply-To: <19980428145734.A26213@frodo.isil.d.shuttle.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 Apr 1998 09:21:39 -0800 To: Werner Koch , ietf-open-pgp@imc.org From: Bill Frantz Subject: Re: Some suggestions Cc: g10@net.lut.ac.uk Content-MD5: wF/G1p48SbL7xGpW4gXxyw== Content-MD5-Origin: gizmo.lut.ac.uk Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 4:57 AM -0800 4/28/98, Werner Koch wrote: > 2) We need a new compression algorithm. > The ZIP algorithm with id 1 is not described in a RFC and > the support in zlib is not documented. I suggest a ZIP > algorithm with id 2 which complies to RFC1950. The version of ZIP in Java 1.1.3 has memory leaks and isn't thread safe. I don't know about other implementations using zlib. ------------------------------------------------------------------------- Bill Frantz | If hate must be my prison | Periwinkle -- Consulting (408)356-8506 | lock, then love must be | 16345 Englewood Ave. frantz@netcom.com | the key. - Phil Ochs | Los Gatos, CA 95032, USA Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id DAA14729 for ietf-open-pgp-bks; Wed, 29 Apr 1998 03:18:36 -0700 (PDT) Received: from koeln.shuttle.de (koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id DAA14725 for ; Wed, 29 Apr 1998 03:18:32 -0700 (PDT) Received: (from root@localhost) by koeln.shuttle.de (8.8.5/8.7.1) id MAA02421 for ietf-open-pgp@imc.org; Wed, 29 Apr 1998 12:20:24 +0200 (MET DST) X-Envelope-To: ietf-open-pgp@imc.org Received: (qmail 14663 invoked from network); 29 Apr 1998 10:04:38 -0000 Received: from frodo.isil.d.shuttle.de (qmailr@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 29 Apr 1998 10:04:38 -0000 Received: (qmail 29986 invoked by uid 501); 29 Apr 1998 10:05:34 -0000 Message-ID: <19980429120534.D29893@frodo.isil.d.shuttle.de> Date: Wed, 29 Apr 1998 12:05:34 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: implementing backwards compatibility Mail-Followup-To: ietf-open-pgp@imc.org References: <19980429094743.C29829@frodo.isil.d.shuttle.de> <199804290938.KAA01474@server.eternity.org> Mime-Version: 1.0 X-Mailer: Mutt 0.90.7i In-Reply-To: <199804290938.KAA01474@server.eternity.org>; from Adam Back on Wed, Apr 29, 1998 at 10:38:04AM +0100 X-URL: http://www.d.shuttle.de/isil Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Adam Back writes: > So backwards compatibility with what pgp-2.6.x does I think should be > viewed as more important than backwards compatibility with > rfc-1991.txt. That's okay for apps which support RSA and IDEA. For all others backwards compatibilty is only useful for packet formats (and maybe for command line switches), so that keyservers are able to process these messages. > verify a signature (which is say DSA or Elgamal) rather than refusing > to process the whole message. In any case pgp-2.6.x doesn't do either > of these things generally, I think. It should be easy to add this to pgp 2.6.3in ( Lutz ? ). Werner Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id CAA12739 for ietf-open-pgp-bks; Wed, 29 Apr 1998 02:40:23 -0700 (PDT) Received: from newmail.virgin.net (newmail.virgin.net [194.168.54.44]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id CAA12735 for ; Wed, 29 Apr 1998 02:40:21 -0700 (PDT) Received: from server.eternity.org ([194.168.66.176]) by newmail.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 1-55555U125000L125000S0) with ESMTP id AAA14995; Wed, 29 Apr 1998 09:42:11 +0000 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id KAA01474; Wed, 29 Apr 1998 10:38:04 +0100 Date: Wed, 29 Apr 1998 10:38:04 +0100 Message-Id: <199804290938.KAA01474@server.eternity.org> From: Adam Back To: wk@isil.d.shuttle.de CC: ietf-open-pgp@imc.org In-reply-to: <19980429094743.C29829@frodo.isil.d.shuttle.de> (message from Werner Koch on Wed, 29 Apr 1998 09:47:43 +0200) Subject: Re: implementing backwards compatibility Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Werner Koch writes: > Adam Back writes: > > you to draw the line at this kind of thing. It seems that pgp-2.6.x > > formats were not designed with enough forward compatibility in mind to > > allow doing this kind of thing without resorting to overloading > > This is true for the implemenations of pgp2.x but not for the > packet format as described in the rfc. Ah yes, but PGP 2.6.x isn't quite RFC 1991 compliant, in that it falls over in a heap when it should report that a new version is required, or that a particular signature can not be checked, or whatever other graceful recovery is specified in the circumstances. Your g10 implementation appears to be the only implementation which is paying much attention to rfc1991, and pgp-2.6.x is by far the largest deployed base -- larger than pgp-5.x and g10, and Tom's implementation. So backwards compatibility with what pgp-2.6.x does I think should be viewed as more important than backwards compatibility with rfc-1991.txt. > This format is as extensible as OpenPGP (see algorithm identifiers > and reserved values in the header) although there are some problems > with the grammar of the packet sequence. There is no reason for a > PGP 2 program not to work with other rfc1991 implementations, it > should just print a warning that that and that algorithm is not > supported and decryption/verification is not possible. There are other implications I think, such as saying that it can not verify a signature (which is say DSA or Elgamal) rather than refusing to process the whole message. In any case pgp-2.6.x doesn't do either of these things generally, I think. Adam -- print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Wed, 29 Apr 1998 00:48:37 -0700 (PDT) Received: (from root@localhost) by koeln.shuttle.de (8.8.5/8.7.1) id JAA13829 for ietf-open-pgp@imc.org; Wed, 29 Apr 1998 09:50:28 +0200 (MET DST) X-Envelope-To: ietf-open-pgp@imc.org Received: (qmail 14435 invoked from network); 29 Apr 1998 07:46:49 -0000 Received: from frodo.isil.d.shuttle.de (qmailr@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 29 Apr 1998 07:46:49 -0000 Received: (qmail 29856 invoked by uid 501); 29 Apr 1998 07:47:43 -0000 Message-ID: <19980429094743.C29829@frodo.isil.d.shuttle.de> Date: Wed, 29 Apr 1998 09:47:43 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: implementing backwards compatibility Mail-Followup-To: ietf-open-pgp@imc.org References: <19980428163022.B29022@frodo.isil.d.shuttle.de> <199804282105.WAA01899@server.eternity.org> Mime-Version: 1.0 X-Mailer: Mutt 0.90.7i In-Reply-To: <199804282105.WAA01899@server.eternity.org>; from Adam Back on Tue, Apr 28, 1998 at 10:05:30PM +0100 X-URL: http://www.d.shuttle.de/isil Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Adam Back writes: > you to draw the line at this kind of thing. It seems that pgp-2.6.x > formats were not designed with enough forward compatibility in mind to > allow doing this kind of thing without resorting to overloading This is true for the implemenations of pgp2.x but not for the packet format as described in the rfc. This format is as extensible as OpenPGP (see algorithm identifiers and reserved values in the header) although there are some problems with the grammar of the packet sequence. There is no reason for a PGP 2 program not to work with other rfc1991 implementations, it should just print a warning that that and that algorithm is not supported and decryption/verification is not possible. The new packet formats for packet types > 15 are a problem but as long as they are put at the end of a message, a pgp 2 app should print a warning that a newer version is needed (pgp2 does so in some cases). Werner > comment fields. > > In summary IF the openPGP application chooses to implement the MAY > cipher RSA and the MAY cipher IDEA, then you can have backwards > compatibility with pgp-2.6.x. > > This doesn't necessarily work with multiple crypto recipients, but we > already have problems with that: when one recipient can only cope with > IDEA because he has a pgp-2.6.x client, and another recipient has > implemented only the MUST options of openPGP you have no overlap in > cipher suite. (ie using 3DES no longer works because pgp-2.6.x can't > understand it, etc). > > > As a comment to Hal and Jon, I think that the PGP implementation could > use some improvement in the area of auto-detecting pgp-2.6.x and > reacting accordingly -- I receive messages from people using pgp-5.x > with RSA implemented, and the message is RSA and IDEA encrypted but > has (I think) DSA signatures contained even though the user also has > an RSA key. (Either that or is inserting a pgp5.x only packet which > otherwise throws pgp-2.6.x). > > Adam > -- > print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> > )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA26004 for ietf-open-pgp-bks; Tue, 28 Apr 1998 15:45:57 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA26000 for ; Tue, 28 Apr 1998 15:45:57 -0700 (PDT) Received: by brickwall.ceddec.com id <43010>; Tue, 28 Apr 1998 18:47:52 -0400 Date: Tue, 28 Apr 1998 18:47:33 -0400 From: dontspam-tzeruch@ceddec.com X-Sender: nobody@mars To: Adam Back cc: wk@isil.d.shuttle.de, ietf-open-pgp@imc.org Subject: Re: implementing backwards compatibility (Re: Some suggestions) In-Reply-To: <199804282105.WAA01899@server.eternity.org> Message-Id: <98Apr28.184752edt.43010@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Tue, 28 Apr 1998, Adam Back wrote: > An implementor is able within the OpenPGP spec I think to write an > openPGP implementation which is largely backwards compatible with > pgp-2.6.x. Actually there are enough enumerated points to allow it to be completely compatible. > Then, in addition you need to interpret a pgp-2.6.x formatted public > key as an implicit encoding of the fact that the sending application > can only cope with pgp-2.6.x packets, and only cope with algorithms > IDEA, MD5, and RSA. > > I think this should work. It would, but you might want to update your RSA key to v4 (though that would bring in the keyid problem) to say that you can do all of the new stuff. > It gets tricky when your application is creating clear signed > signatures -- you don't know who the message is targetted at -- so to > follow the backwards compatibility reasoning to it's logical > conclusion this implies that all clear signed messages (or at least > those where you don't know who will later wish to verify them) should > only use MD5, and RSA. Just doing multiple signatures is an issue. > > It would have been possible I think to hide an Elgamal/DSA key in a > pgp2.6.x format packet (for example in a comment field); using this > method we could have had full backwards compatibility. (A similar > trick is used in the move from SSLv2 to SSLv3.) (Similar kinds of > packet upgrades would have allowed backwards compatiblity for > signatures and encrypted information for multiple recipients with some > recipients being openPGP new algorithms over pgp-2.6.x). There is nothing within the V3 packet format precluding DSA keys. They can be output with 3 as the version, and the creation time and valid days fields: BEGIN PGP PUBLIC KEY BLOCK----- Version: OpenPrivacy 0.9 mQDkAzVGWtkAABECANS2E1sRohE7kN1IGj5IAbVQg/J+7SdaCWPzVOetXNhaFk2I fHvOa4aD6HcEl7mHNhhMe4VmuUeiITBnHCI9wA0AoPfThufPh/EhPUr3NiMY3Okd /OTNAf9cIrf46iJpum3IX4yor9d8d0FGX5fCZF3ajFMTAXOYc4pl427l32gvp5Bl 4KRO+kJ59Qb4YZ7vdlJp48uMoJPuAgCllOUKrDQG7gha0FKMPaslUtpycKZc9oWP AZ9rfu2Kan8mUxbR21gw6VUr2RtG+JmN6oRU3OmprlgYpRDePOlysAGHtAhWM0RI L0RTQbABA7kAzwM1RlrZAAAQAwD15Itoz82i/Q3Fkim7gGvloo0Q0Pu8r2VWZRa5 K0GinDuPnI/e6WfX2ABD7lYgIr1fmNrcheI7VfaLyHqsGLuXwN5uy+HJXNA05WLH MxyV52FefHCOWrunDgT91Q2f+AMAAwUC/2SvnNUE2HwsmGRuvNnNM093ClduEiMY YHvEcEeS3dumoMEdM7jv/GQ5TSfGTPLjUxsQglHwkzJxPbHZiHSVxoXxFBBvh6tT sBLGEDIrjJhYc1sopJNw7QDL5CJOimCgirABhw== =jl4k END PGP PUBLIC KEY BLOCK----- > As a comment to Hal and Jon, I think that the PGP implementation could > use some improvement in the area of auto-detecting pgp-2.6.x and > reacting accordingly -- I receive messages from people using pgp-5.x > with RSA implemented, and the message is RSA and IDEA encrypted but > has (I think) DSA signatures contained even though the user also has > an RSA key. (Either that or is inserting a pgp5.x only packet which > otherwise throws pgp-2.6.x). The problem is that there are problems with 2.6.x and that is why it is being dumped in favor of OpenPGP. My V3 handling does "the right thing" most places, so a 2.6.1998 is possible, but why bother? If you are going to move at all, OpenPGP is not that much of a jump. If you can't move, then there is no reason to do partial stuff --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA25670 for ietf-open-pgp-bks; Tue, 28 Apr 1998 14:54:51 -0700 (PDT) Received: from newmail.virgin.net (newmail.virgin.net [194.168.54.44]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA25666 for ; Tue, 28 Apr 1998 14:54:46 -0700 (PDT) Received: from server.eternity.org ([194.168.64.139]) by newmail.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 1-55555U125000L125000S0) with ESMTP id AAE26918; Tue, 28 Apr 1998 21:56:30 +0000 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id WAA01899; Tue, 28 Apr 1998 22:05:30 +0100 Date: Tue, 28 Apr 1998 22:05:30 +0100 Message-Id: <199804282105.WAA01899@server.eternity.org> From: Adam Back To: wk@isil.d.shuttle.de CC: ietf-open-pgp@imc.org In-reply-to: <19980428163022.B29022@frodo.isil.d.shuttle.de> (message from Werner Koch on Tue, 28 Apr 1998 16:30:22 +0200) Subject: implementing backwards compatibility (Re: Some suggestions) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Werner Koch writes: > Lindsay Mathieson writes: > > > break existing implementations and compatibility is one of the objectives > > for the spec. > > and why do we have identifiers for ElGamal, HAVAL or ECC ? This > would break existing implementations too. An implementor is able within the OpenPGP spec I think to write an openPGP implementation which is largely backwards compatible with pgp-2.6.x. I think the trick is to use the algorithm capability information in the public keys for people you are sending encrypted messages to to decide which algorithms you can use in your message, and which packet formats they will understand. Then, in addition you need to interpret a pgp-2.6.x formatted public key as an implicit encoding of the fact that the sending application can only cope with pgp-2.6.x packets, and only cope with algorithms IDEA, MD5, and RSA. I think this should work. It gets tricky when your application is creating clear signed signatures -- you don't know who the message is targetted at -- so to follow the backwards compatibility reasoning to it's logical conclusion this implies that all clear signed messages (or at least those where you don't know who will later wish to verify them) should only use MD5, and RSA. This last option is not that attractive because: a) RSA is a MAY cipher in openPGP due to patents; b) MD5 is mildly depracted because of Dobbertins partial attack on it being read as indicating the increased likelihood of stronger future attacks; c) MD5 has smaller output size than SHA1 the main alternative; d) to use the approach it requires that the open PGP user HAS an RSA key and several PGP Inc 5.x implementations do not support RSA, and those that do support it do not automatically generate one at the same time as the ElGamal/DSA keyset. It would have been possible I think to hide an Elgamal/DSA key in a pgp2.6.x format packet (for example in a comment field); using this method we could have had full backwards compatibility. (A similar trick is used in the move from SSLv2 to SSLv3.) (Similar kinds of packet upgrades would have allowed backwards compatiblity for signatures and encrypted information for multiple recipients with some recipients being openPGP new algorithms over pgp-2.6.x). However at this stage, doing this could not be made compatible with existing PGP 5.x implementations, and it is kind of ugly, and the directive of `limited backwards compatibility' it seems to me allows you to draw the line at this kind of thing. It seems that pgp-2.6.x formats were not designed with enough forward compatibility in mind to allow doing this kind of thing without resorting to overloading comment fields. In summary IF the openPGP application chooses to implement the MAY cipher RSA and the MAY cipher IDEA, then you can have backwards compatibility with pgp-2.6.x. This doesn't necessarily work with multiple crypto recipients, but we already have problems with that: when one recipient can only cope with IDEA because he has a pgp-2.6.x client, and another recipient has implemented only the MUST options of openPGP you have no overlap in cipher suite. (ie using 3DES no longer works because pgp-2.6.x can't understand it, etc). As a comment to Hal and Jon, I think that the PGP implementation could use some improvement in the area of auto-detecting pgp-2.6.x and reacting accordingly -- I receive messages from people using pgp-5.x with RSA implemented, and the message is RSA and IDEA encrypted but has (I think) DSA signatures contained even though the user also has an RSA key. (Either that or is inserting a pgp5.x only packet which otherwise throws pgp-2.6.x). Adam -- print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Tue, 28 Apr 1998 12:18:41 -0700 (PDT) Received: (from root@localhost) by koeln.shuttle.de (8.8.5/8.7.1) id VAA12331 for ietf-open-pgp@imc.org; Tue, 28 Apr 1998 21:20:29 +0200 (MET DST) X-Envelope-To: ietf-open-pgp@imc.org Received: (qmail 13491 invoked from network); 28 Apr 1998 19:17:58 -0000 Received: from frodo.isil.d.shuttle.de (qmailr@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 28 Apr 1998 19:17:57 -0000 Received: (qmail 29180 invoked by uid 501); 28 Apr 1998 19:18:47 -0000 Message-ID: <19980428211846.D29139@frodo.isil.d.shuttle.de> Date: Tue, 28 Apr 1998 21:18:46 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt Mail-Followup-To: ietf-open-pgp@imc.org References: <199804241942.MAA02309@s20.term1.sb.rain.org> <98Apr28.131756edt.43010@brickwall.ceddec.com> Mime-Version: 1.0 X-Mailer: Mutt 0.90.7i In-Reply-To: <98Apr28.131756edt.43010@brickwall.ceddec.com>; from tzeruch@ceddec.com on Tue, Apr 28, 1998 at 01:17:37PM -0400 X-URL: http://www.d.shuttle.de/isil Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-open-pgp@imc.org Precedence: bulk tzeruch@ceddec.com writes: > jump to V4. Otherwise you create a PGP 2.6.2-plus implicit within OpenPGP > and I think this is a bad idea. When there is a V3 way of doing things, > it should meet the old RFC completely since the single reason to do things > that way is to be backward compatible. Otherwise things should be done I did this for GNUPG because when I started, I didn't know any description of PGP 5 packet formats so I had to to use RFC1991 with only one extension (partial header length); this implementation is pretty compliant to RFC1991, due to the fact that this rfc is not specific in some parts :-) This isn't a perfect solution and so I plan to migrate to v4 as soon as OpenPGP is stable (actually I can already process v4 packets). Werner Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA24260 for ietf-open-pgp-bks; Tue, 28 Apr 1998 11:48:48 -0700 (PDT) Received: from koeln.shuttle.de (koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA24256 for ; Tue, 28 Apr 1998 11:48:47 -0700 (PDT) Received: (from root@localhost) by koeln.shuttle.de (8.8.5/8.7.1) id UAA08010 for ietf-open-pgp@imc.org; Tue, 28 Apr 1998 20:50:36 +0200 (MET DST) X-Envelope-To: ietf-open-pgp@imc.org Received: (qmail 13447 invoked from network); 28 Apr 1998 18:43:58 -0000 Received: from frodo.isil.d.shuttle.de (qmailr@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 28 Apr 1998 18:43:58 -0000 Received: (qmail 29169 invoked by uid 501); 28 Apr 1998 18:44:47 -0000 Message-ID: <19980428204446.C29139@frodo.isil.d.shuttle.de> Date: Tue, 28 Apr 1998 20:44:46 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: OID for TIGER/192 ? Mail-Followup-To: ietf-open-pgp@imc.org Mime-Version: 1.0 X-Mailer: Mutt 0.90.7i X-URL: http://www.d.shuttle.de/isil Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Hi, Does anyone know whether there is an registered ASN OID for TIGER/192 or a way to register this algorithm? Werner Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA24254 for ietf-open-pgp-bks; Tue, 28 Apr 1998 11:48:44 -0700 (PDT) Received: from koeln.shuttle.de (koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA24250 for ; Tue, 28 Apr 1998 11:48:42 -0700 (PDT) Received: (from root@localhost) by koeln.shuttle.de (8.8.5/8.7.1) id UAA07992 for ietf-open-pgp@imc.org; Tue, 28 Apr 1998 20:50:30 +0200 (MET DST) X-Envelope-To: ietf-open-pgp@imc.org Received: (qmail 13417 invoked from network); 28 Apr 1998 18:32:24 -0000 Received: from frodo.isil.d.shuttle.de (qmailr@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 28 Apr 1998 18:32:24 -0000 Received: (qmail 29153 invoked by uid 501); 28 Apr 1998 18:33:13 -0000 Message-ID: <19980428203313.B29139@frodo.isil.d.shuttle.de> Date: Tue, 28 Apr 1998 20:33:13 +0200 From: Werner Koch To: dontspam-tzeruch@ceddec.com Cc: IETF OpenPGP Subject: Re: Some suggestions (zlib info, and a correction) Mail-Followup-To: dontspam-tzeruch@ceddec.com, IETF OpenPGP References: <19980428162710.A29022@frodo.isil.d.shuttle.de> <98Apr28.140649edt.43009@brickwall.ceddec.com> Mime-Version: 1.0 X-Mailer: Mutt 0.90.7i In-Reply-To: <98Apr28.140649edt.43009@brickwall.ceddec.com>; from dontspam-tzeruch@ceddec.com on Tue, Apr 28, 1998 at 02:06:28PM -0400 X-URL: http://www.d.shuttle.de/isil Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-open-pgp@imc.org Precedence: bulk dontspam-tzeruch@ceddec.com writes: > gzip(?) style header in front and crc at the end. This is undocumented zip header, gzip is just another header in front of it. > It would be reasonable to use a new algorithm ID to add a direct zlib > feature. That's what I'm requesting. Werner Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA23831 for ietf-open-pgp-bks; Tue, 28 Apr 1998 11:04:55 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA23827 for ; Tue, 28 Apr 1998 11:04:54 -0700 (PDT) Received: by brickwall.ceddec.com id <43009>; Tue, 28 Apr 1998 14:06:49 -0400 Date: Tue, 28 Apr 1998 14:06:28 -0400 From: dontspam-tzeruch@ceddec.com X-Sender: nobody@mars To: Werner Koch cc: IETF OpenPGP Subject: Re: Some suggestions (zlib info, and a correction) In-Reply-To: <19980428162710.A29022@frodo.isil.d.shuttle.de> Message-Id: <98Apr28.140649edt.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Tue, 28 Apr 1998, Werner Koch wrote: > Lindsay Mathieson writes: > > > Why not just document the usage of zlib - A new compression algorithm would > > break existing implementations and compatibility is one of the objectives > > for the spec. > > PGP used an early version of zlib which was limited to a 13 bit > compression window, the RFC documented zlib does not have this > limitation. It's okay to support the old version, but why should > I not use a newer (and documented) one as an option? The other zlibism is that I still need to pass the value -15 in inflateInit2 instead of using InflateInit since the latter will place a gzip(?) style header in front and crc at the end. This is undocumented (except maybe in inflate.c) It would be reasonable to use a new algorithm ID to add a direct zlib feature. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA23471 for ietf-open-pgp-bks; Tue, 28 Apr 1998 10:31:34 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA23467 for ; Tue, 28 Apr 1998 10:31:33 -0700 (PDT) Received: by brickwall.ceddec.com id <43010>; Tue, 28 Apr 1998 13:33:24 -0400 Date: Tue, 28 Apr 1998 13:33:02 -0400 From: dontspam-tzeruch@ceddec.com X-Sender: nobody@mars Reply-To: dontspam-tzeruch@ceddec.com To: Werner Koch cc: IETF OpenPGP Subject: Re: Some suggestions In-Reply-To: <19980428162710.A29022@frodo.isil.d.shuttle.de> Message-Id: <98Apr28.133324edt.43010@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Tue, 28 Apr 1998, Werner Koch wrote: > Lindsay Mathieson writes: > > > Why not just document the usage of zlib - A new compression algorithm would > > break existing implementations and compatibility is one of the objectives > > for the spec. > > PGP used an early version of zlib which was limited to a 13 bit > compression window, the RFC documented zlib does not have this > limitation. It's okay to support the old version, but why should > I not use a newer (and documented) one as an option? They actually used infozip's original inflate code when they were cloning PKzip on unix. Because DOS and other machines had memory limitations, the window size was limited to 8K. One of these days I am going to get a palm pilot and port my lib. Enough of SSLeay and zlib are there. If this works with 5.x, there should be no reason to continue the limit. Also, the algorithm is *not* different, just that PGP 2.6.2's compression is not strictly compliant with the RFC. It takes about two minutes to change this in the PGP 2.6.2 code (at least the decompression side). To quote from RFC 1951: 3.3. Compliance A compressor may limit further the ranges of values specified in the previous section and still be compliant; for example, it may limit the range of backward pointers to some value smaller than 32K. Similarly, a compressor may limit the size of blocks so that a compressible block fits in memory. A compliant decompressor must accept the full range of possible values defined in the previous section, and must accept blocks of arbitrary size. around line 141 of src/zinflate.c (in one of the PGP 2.6.2 dists): #ifndef WSIZE # define WSIZE 8192 /* window size--must be a power of two, <= 32K, and equal to that of zip. * On 16 bit machines (MSDOS), WSIZE must be <= 16K (32K is possible * with a few hacks, see the zip archiver. */ #endif 2.6.2 should be fixed (including hacking the DOS version if needed). --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA23308 for ietf-open-pgp-bks; Tue, 28 Apr 1998 10:16:08 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA23304 for ; Tue, 28 Apr 1998 10:16:06 -0700 (PDT) Received: by brickwall.ceddec.com id <43010>; Tue, 28 Apr 1998 13:17:56 -0400 Date: Tue, 28 Apr 1998 13:17:37 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars To: Hal Finney cc: ietf-open-pgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt In-Reply-To: <199804241942.MAA02309@s20.term1.sb.rain.org> Message-Id: <98Apr28.131756edt.43010@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk (this might be a resend). On Fri, 24 Apr 1998, Hal Finney wrote: > > > V3 keys can switch to using the new iterated/salted passphrase hashing, > > > which is a major security improvement. > > > > The spec says V4 uses the new, V3 uses the old. Note that there are only > > two differences between V3 and V4 secret key packets, and the other is the > > version number at the head of the packet. It would be easy to modify > > things to use V4 S2K protection on V3 keys, but the spec should say this > > is permitted on a V3 key. > > Does the spec say that V3 keys cannot use string-to-key specifiers, > and/or that it must use only the Simple S2K? I don't see that, but maybe > I am not looking in the right place. Neither 3.6.X nor 5.5.3 say that. > 5.5.3 describes the difference in terms of what is encrypted, but doesn't > prevent you from using the new S2K packets. Is there someplace else > where it is mentioned? Not directly, but the reason for using V3 keys is for backwards compatibility. When I import them, they will be in the old passphrase format if they are encrypted. If in needed to export them, and wanted to retain the passphrase protection, they would need to be in the old format. I can use the new S2K passphrase protection with a V3, but is there then any reason to still leave it as a V3 key (other than keyid issues)? If I am going to use V4 passphrase encryption is there any reason I would not want to change the version number to 4? One thing I keep getting stuck on is that there are many places I can keep V3 as V3, but add extensions, when it seems to make more sense simply to jump to V4. Otherwise you create a PGP 2.6.2-plus implicit within OpenPGP and I think this is a bad idea. When there is a V3 way of doing things, it should meet the old RFC completely since the single reason to do things that way is to be backward compatible. Otherwise things should be done using purely V4 methods. I can hack V3 keyids of new keys (LSBs of the public_key parts of DSA/DSS). I can use a one pass signature prefix with a V3 format signature. And I can go on. But these shouldn't be done unless there are plans to extend some version of PGP 2.6.2 to PGP 2.7.x that might incorporate some Open PGP features. Since a PGP 2.7 would be undesirable, I would think doing anything to extend V3 instead of moving to V4 would be equally undesirable. > > Get a copy of the PKCS-1 spec and try writing something from it. Without > > looking at the preformatted number I challenge you to determine the other > > bytes in the packet. Even given SSLeay's ASN1 support it takes about 10 > > lines (optimizing more than is proper). Unless I haven't seen a good > > version of the spec (is there one beyond that on RSA.com?). > > It is true that you have to be able to read ASN.1 to understand this part > of PKCS-1. The actual code requirements are very simple, and perhaps we > should put them into the spec as you suggest. Our SHA-1 prefix looks like: (ASN1 breakout deleted - I assume you don't know ASN.1 by heart and copied it from the source). > You follow this by the 20 digest bytes, then pad it with block type > 1 from PKCS-1 section 8.1. We could take out the comments and it would > be pretty concise: > > 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 43, 14, 3, 2, 26, 0x05, 0x00, 0x04, 0x14 > > Similar structures could be provided for the other hashes. This might > be a better way to do it. Or if you have SSLeay 0.9.X: #include #include #include int main(int argc, char *argv[]) { unsigned char buf[4096], *bp; int i, j; ASN1_OCTET_STRING s; s.data = "0123456789ABCDEFGHIJ"; /* replace with actual hash */ s.length = 20; bp = &buf[4]; i2d_ASN1_OBJECT(OBJ_nid2obj(OBJ_sn2nid( "SHA1" )), &bp); ASN1_put_object(&bp, 0, 0, V_ASN1_NULL, V_ASN1_UNIVERSAL); j = bp - buf - 4; i2d_ASN1_OCTET_STRING(&s, &bp); i = bp - buf - 2; bp = &buf[2]; ASN1_put_object(&bp, 1, j, V_ASN1_SEQUENCE, V_ASN1_UNIVERSAL); bp = buf; ASN1_put_object(&bp, 1, i, V_ASN1_SEQUENCE, V_ASN1_UNIVERSAL); i += 2; for (j = 0; j < i - 20; j++) if ((j & 7) == 7) fprintf(stderr, "0x%02x,\n", buf[j]); else fprintf(stderr, "0x%02x, ", buf[j]); fprintf(stderr, "\n"); #if 1 fwrite(buf, 1, i, stdout); #endif return 0; } But this code is as obscure as the description. The fwrite to stdout allows piping to "asn1parse -inform DER" Change the "SHA1" to MD5, RIPEMD160, or MD2 (no oid for HAVAL yet), and change the s.length as needed. Because the above code is far longer and more complex than the tables, I didn't do the objects that way. I have a fuller version that writes out the tail of hasher.c (maybe I should do that as a .h file, but I only need run it once). > > > > 12.7 > > But implementors might also want to import secret V3 keys, so will need > > the general algorithm. And I don't use any of the FR, FRE or other > > registers described. I simply copy the last 8 bytes (actually the cipher > > block size, but all are 8 so far) of cyphertext into the IV and set the > > IVcount to zero. > > Yes, I wrote up that long description because I thought you were asking > how it worked, and Jon put it in the spec as an explicit example of > how the feedback works. I think the description in the earlier part > of the spec was OK but if we do want this kind of long description then > perhaps we should also do one (or two for the two cases) for the secret > key encryption as well. Or at least put a note that it would not be a good idea to hardcode parts of the method. The example gives symmetric encryption header specific stuff instead of being a general description. Were I reading it I might use fixed values. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id JAA23113 for ietf-open-pgp-bks; Tue, 28 Apr 1998 09:50:31 -0700 (PDT) Received: from koeln.shuttle.de (koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id JAA23109 for ; Tue, 28 Apr 1998 09:50:27 -0700 (PDT) Received: (from root@localhost) by koeln.shuttle.de (8.8.5/8.7.1) id SAA26882 for ietf-open-pgp@imc.org; Tue, 28 Apr 1998 18:52:15 +0200 (MET DST) X-Envelope-To: ietf-open-pgp@imc.org Received: (qmail 13036 invoked from network); 28 Apr 1998 16:51:04 -0000 Received: from frodo.isil.d.shuttle.de (qmailr@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 28 Apr 1998 16:51:04 -0000 Received: (qmail 29109 invoked by uid 501); 28 Apr 1998 16:51:52 -0000 Message-ID: <19980428185151.A29103@frodo.isil.d.shuttle.de> Date: Tue, 28 Apr 1998 18:51:51 +0200 From: Werner Koch To: ietf-open-pgp@imc.org, g10@net.lut.ac.uk Subject: Re: Some suggestions Mail-Followup-To: ietf-open-pgp@imc.org, g10@net.lut.ac.uk References: <19980428145734.A26213@frodo.isil.d.shuttle.de> Mime-Version: 1.0 X-Mailer: Mutt 0.90.7i In-Reply-To: ; from Bill Frantz on Tue, Apr 28, 1998 at 09:21:39AM -0800 X-URL: http://www.d.shuttle.de/isil Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Bill Frantz writes: > The version of ZIP in Java 1.1.3 has memory leaks and isn't thread safe. I > don't know about other implementations using zlib. Is this zlib version 1.0.4, Jul 24th, 1996? That one is thread safe - it was one of the goals: zlib 1.0.4 is a general purpose data compression library. All the code is reentrant (thread safe). The data format used by the zlib library is described by RFCs (Request for Comments) 1950 to 1952 in the files And _many_ tools link against this lib. Werner Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id JAA22893 for ietf-open-pgp-bks; Tue, 28 Apr 1998 09:24:36 -0700 (PDT) Received: from dfw-ix10.ix.netcom.com (dfw-ix10.ix.netcom.com [206.214.98.10]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id JAA22889 for ; Tue, 28 Apr 1998 09:24:35 -0700 (PDT) Received: (from smap@localhost) by dfw-ix10.ix.netcom.com (8.8.4/8.8.4) id LAA04330; Tue, 28 Apr 1998 11:25:04 -0500 (CDT) Received: from sjc-ca6-11.ix.netcom.com(207.94.249.203) by dfw-ix10.ix.netcom.com via smap (V1.3) id rma004302; Tue Apr 28 11:24:51 1998 X-Sender: frantz@netcom7.netcom.com Message-Id: In-Reply-To: <19980428145734.A26213@frodo.isil.d.shuttle.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 Apr 1998 09:21:39 -0800 To: Werner Koch , ietf-open-pgp@imc.org From: Bill Frantz Subject: Re: Some suggestions Cc: g10@net.lut.ac.uk Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 4:57 AM -0800 4/28/98, Werner Koch wrote: > 2) We need a new compression algorithm. > The ZIP algorithm with id 1 is not described in a RFC and > the support in zlib is not documented. I suggest a ZIP > algorithm with id 2 which complies to RFC1950. The version of ZIP in Java 1.1.3 has memory leaks and isn't thread safe. I don't know about other implementations using zlib. ------------------------------------------------------------------------- Bill Frantz | If hate must be my prison | Periwinkle -- Consulting (408)356-8506 | lock, then love must be | 16345 Englewood Ave. frantz@netcom.com | the key. - Phil Ochs | Los Gatos, CA 95032, USA Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id HAA22141 for ietf-open-pgp-bks; Tue, 28 Apr 1998 07:51:14 -0700 (PDT) Received: from koeln.shuttle.de (koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id HAA22109 for ; Tue, 28 Apr 1998 07:48:45 -0700 (PDT) Received: (from root@localhost) by koeln.shuttle.de (8.8.5/8.7.1) id QAA14143 for ietf-open-pgp@imc.org; Tue, 28 Apr 1998 16:50:24 +0200 (MET DST) X-Envelope-To: ietf-open-pgp@imc.org Received: (qmail 12781 invoked from network); 28 Apr 1998 14:26:23 -0000 Received: from frodo.isil.d.shuttle.de (qmailr@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 28 Apr 1998 14:26:23 -0000 Received: (qmail 29027 invoked by uid 501); 28 Apr 1998 14:27:10 -0000 Message-ID: <19980428162710.A29022@frodo.isil.d.shuttle.de> Date: Tue, 28 Apr 1998 16:27:10 +0200 From: Werner Koch To: IETF OpenPGP Subject: Re: Some suggestions Mail-Followup-To: IETF OpenPGP References: <199804281415.QAA10642@koeln.shuttle.de> Mime-Version: 1.0 X-Mailer: Mutt 0.90.7i In-Reply-To: <199804281415.QAA10642@koeln.shuttle.de>; from Lindsay Mathieson on Tue, Apr 28, 1998 at 12:58:24PM +0000 X-URL: http://www.d.shuttle.de/isil Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Lindsay Mathieson writes: > Why not just document the usage of zlib - A new compression algorithm would > break existing implementations and compatibility is one of the objectives > for the spec. PGP used an early version of zlib which was limited to a 13 bit compression window, the RFC documented zlib does not have this limitation. It's okay to support the old version, but why should I not use a newer (and documented) one as an option? Werner Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id HAA22113 for ietf-open-pgp-bks; Tue, 28 Apr 1998 07:48:59 -0700 (PDT) Received: from koeln.shuttle.de (koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id HAA22107 for ; Tue, 28 Apr 1998 07:48:37 -0700 (PDT) Received: (from root@localhost) by koeln.shuttle.de (8.8.5/8.7.1) id QAA14148 for ietf-open-pgp@imc.org; Tue, 28 Apr 1998 16:50:24 +0200 (MET DST) X-Envelope-To: ietf-open-pgp@imc.org Received: (qmail 12787 invoked from network); 28 Apr 1998 14:29:36 -0000 Received: from frodo.isil.d.shuttle.de (qmailr@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 28 Apr 1998 14:29:36 -0000 Received: (qmail 29036 invoked by uid 501); 28 Apr 1998 14:30:22 -0000 Message-ID: <19980428163022.B29022@frodo.isil.d.shuttle.de> Date: Tue, 28 Apr 1998 16:30:22 +0200 From: Werner Koch To: IETF OpenPGP Subject: Re: Some suggestions Mail-Followup-To: IETF OpenPGP References: <199804281415.QAA10642@koeln.shuttle.de> Mime-Version: 1.0 X-Mailer: Mutt 0.90.7i In-Reply-To: <199804281415.QAA10642@koeln.shuttle.de>; from Lindsay Mathieson on Tue, Apr 28, 1998 at 12:58:24PM +0000 X-URL: http://www.d.shuttle.de/isil Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Lindsay Mathieson writes: > break existing implementations and compatibility is one of the objectives > for the spec. and why do we have identifiers for ElGamal, HAVAL or ECC ? This would break existing implementations too. Werner Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id HAA21771 for ietf-open-pgp-bks; Tue, 28 Apr 1998 07:13:07 -0700 (PDT) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.8/8.7.3) with SMTP id HAA21767 for ; Tue, 28 Apr 1998 07:13:05 -0700 (PDT) Message-Id: <199804281413.HAA21767@mail.proper.com> Received: (qmail 4751 invoked from network); 28 Apr 1998 14:14:53 -0000 Received: from ts5645.powerup.com.au (HELO lindsay) (202.139.238.109) by enterprise.powerup.com.au with SMTP; 28 Apr 1998 14:14:53 -0000 Date: 28 Apr 1998 12:58:24 GMT From: Lindsay Mathieson Subject: Re: Some suggestions To: Werner Koch , IETF OpenPGP X-Mailer: Black Paw Communications's MailCat for Win32 Release Vs 2.7 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > 2) We need a new compression algorithm. > The ZIP algorithm with id 1 is not described in a RFC and > the support in zlib is not documented. Why not just document the usage of zlib - A new compression algorithm would break existing implementations and compatibility is one of the objectives for the spec. Cheers - Linz -- Lindsay Mathieson Black Paw Communications Using MailCat for Win32 Release Vs 2.7, on April 28, 1998, in Win95 4.0 http://www.blackpaw.com/ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id FAA21062 for ietf-open-pgp-bks; Tue, 28 Apr 1998 05:55:55 -0700 (PDT) Received: from koeln.shuttle.de (koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id FAA21058 for ; Tue, 28 Apr 1998 05:55:53 -0700 (PDT) Received: (from root@localhost) by koeln.shuttle.de (8.8.5/8.7.1) id OAA01844 for ietf-open-pgp@imc.org; Tue, 28 Apr 1998 14:57:35 +0200 (MET DST) X-Envelope-To: ietf-open-pgp@imc.org Received: (qmail 9255 invoked from network); 28 Apr 1998 12:56:49 -0000 Received: from frodo.isil.d.shuttle.de (qmailr@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 28 Apr 1998 12:56:49 -0000 Received: (qmail 26228 invoked by uid 501); 28 Apr 1998 12:57:35 -0000 Message-ID: <19980428145734.A26213@frodo.isil.d.shuttle.de> Date: Tue, 28 Apr 1998 14:57:34 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Cc: g10@net.lut.ac.uk Subject: Some suggestions Mail-Followup-To: ietf-open-pgp@imc.org, g10@net.lut.ac.uk Mime-Version: 1.0 X-Mailer: Mutt 0.90.7i X-URL: http://www.d.shuttle.de/isil Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Hi, After browsing through the latest draft I have some remarks: 1) The comment packets are gone. Ooops. How can write code when the specification is changed at will. I was lucky to find a solution for the moved comment packet number from 14 to 16 - and now there is no comment packet at all. So what shall I do? Go back to RFC1991 or stay with comment packet of type 16? Comment packets are very useful: I use them to store the factorization of the ElGamal prime (in case someone wants to check it), store a program version number to make debugging easier. Another use is to transport additional informations to other programs in a pipeline. *Please put the comment packets back into OpenPGP* 2) We need a new compression algorithm. The ZIP algorithm with id 1 is not described in a RFC and the support in zlib is not documented. I suggest a ZIP algorithm with id 2 which complies to RFC1950. 3) 4 new signature classes 0x14 to 0x17 which are like 0x10..0x13 but do a hash over all preceding user id packets. This has the advantage of keeping a public key certificate small but a signator is still able to sign more than one user-id. 4) A signature class which can used to sign the complete public key certificate would be very nice - or is there already one which can be used for this purpose? All these enhancements may be OPTIONAL. Werner Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA26135 for ietf-open-pgp-bks; Fri, 24 Apr 1998 15:34:03 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA26131 for ; Fri, 24 Apr 1998 15:34:02 -0700 (PDT) Received: by brickwall.ceddec.com id <43009>; Fri, 24 Apr 1998 18:35:29 -0400 Date: Fri, 24 Apr 1998 18:35:20 -0400 From: dontspam-tzeruch@ceddec.com X-Sender: nobody@mars To: Jon Callas cc: ietf-open-pgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt In-Reply-To: <3.0.3.32.19980424135320.00aa8580@mail.pgp.com> Message-Id: <98Apr24.183529edt.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Fri, 24 Apr 1998, Jon Callas wrote: > Let's not worry about V2. The charter of the working group says, "limited > backwards compatibility" and even RFC 1991 says that you should be > compatible back one version. Actually I have some code that handles 2.1 DEKs :). And signatures ;). > If you want, I can remove the reference to V2. I have mixed feelings. Some really old messages might use the RSAref V2 packets and then would not work, although they could. But in general it might be better to err on the other side (if they have such a message they should have a 2.X version of PGP around that can read it). But to avoid confusion, removing any reference to V2 is best (and let implementors who might want it read the old docs and figure out how to add this - the spec says nothing else about V2 compatibility). --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA25354 for ietf-open-pgp-bks; Fri, 24 Apr 1998 13:59:28 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id NAA25347 for ; Fri, 24 Apr 1998 13:59:22 -0700 (PDT) Received: from fnord (tns40.pgp.com [161.69.9.40]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id NAA25563; Fri, 24 Apr 1998 13:59:41 -0700 (PDT) Message-Id: <3.0.3.32.19980424135320.00aa8580@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 24 Apr 1998 13:53:20 -0700 To: tzeruch@ceddec.com, Jon Callas From: Jon Callas Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt Cc: ietf-open-pgp@imc.org In-Reply-To: <98Apr23.153927edt.43009@brickwall.ceddec.com> References: <3.0.3.32.19980423113031.00b39350@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 03:39 PM 4/23/98 -0400, dontspam-tzeruch@ceddec.com wrote: The internal format of what is RSAen/decrypted changed from 2.2 to 2.3, but not the version number. I don't know what the RFC says. So I can get a version with 2 and the old (pre RSAREF) format DEK. Let's not worry about V2. The charter of the working group says, "limited backwards compatibility" and even RFC 1991 says that you should be compatible back one version. If you want, I can remove the reference to V2. Jon ----- Jon Callas jon@pgp.com CTO, Total Network Security 4200 Bohannon Drive Network Associates, Inc. Menlo Park, CA 94025 (650) 473-2860 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA24906 for ietf-open-pgp-bks; Fri, 24 Apr 1998 12:56:49 -0700 (PDT) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA24902 for ; Fri, 24 Apr 1998 12:56:48 -0700 (PDT) Received: from s20.term1.sb.rain.org (s04.term1.sb.rain.org [198.68.144.134]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id MAA05380; Fri, 24 Apr 1998 12:58:13 -0700 (PDT) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id MAA02309; Fri, 24 Apr 1998 12:42:11 -0700 Date: Fri, 24 Apr 1998 12:42:11 -0700 From: Hal Finney Message-Id: <199804241942.MAA02309@s20.term1.sb.rain.org> To: hal@rain.org, tzeruch@ceddec.com Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > > V3 keys can switch to using the new iterated/salted passphrase hashing, > > which is a major security improvement. > > The spec says V4 uses the new, V3 uses the old. Note that there are only > two differences between V3 and V4 secret key packets, and the other is the > version number at the head of the packet. It would be easy to modify > things to use V4 S2K protection on V3 keys, but the spec should say this > is permitted on a V3 key. Does the spec say that V3 keys cannot use string-to-key specifiers, and/or that it must use only the Simple S2K? I don't see that, but maybe I am not looking in the right place. Neither 3.6.X nor 5.5.3 say that. 5.5.3 describes the difference in terms of what is encrypted, but doesn't prevent you from using the new S2K packets. Is there someplace else where it is mentioned? > > We are relying on PKCS-1 to explain how the byte stream is set up. > > PKCS-1 does not specify the OIDs for the algorithms we are using, so we > > provide those here. > > Get a copy of the PKCS-1 spec and try writing something from it. Without > looking at the preformatted number I challenge you to determine the other > bytes in the packet. Even given SSLeay's ASN1 support it takes about 10 > lines (optimizing more than is proper). Unless I haven't seen a good > version of the spec (is there one beyond that on RSA.com?). It is true that you have to be able to read ASN.1 to understand this part of PKCS-1. The actual code requirements are very simple, and perhaps we should put them into the spec as you suggest. Our SHA-1 prefix looks like: 0x30, /* Universal, Constructed, Sequence */ 0x21, /* Length 33 (bytes following) */ 0x30, /* Universal, Constructed, Sequence */ 0x09, /* Length 9 */ 0x06, /* Universal, Primitive, object-identifier */ 0x05, /* Length 8 */ 43, /* 43 = ISO(1)*40 + 3 */ 14, 3, 2, 26, 0x05, /* Universal, Primitive, NULL */ 0x00, /* Length 0 */ 0x04, /* Universal, Primitive, Octet string */ 0x14 /* Length 20 */ /* 20 SHA.1 digest bytes go here */ You follow this by the 20 digest bytes, then pad it with block type 1 from PKCS-1 section 8.1. We could take out the comments and it would be pretty concise: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 43, 14, 3, 2, 26, 0x05, 0x00, 0x04, 0x14 Similar structures could be provided for the other hashes. This might be a better way to do it. > MD2 was just added and is 128 bits if I remember right. I didn't ask why, > but maybe it would be appropriate. MD2 is used in some existing X.509/SSL signatures. Although it is only 128 bits there are no partial attacks against it as with MD4 and MD5. > > > 12.7 > But implementors might also want to import secret V3 keys, so will need > the general algorithm. And I don't use any of the FR, FRE or other > registers described. I simply copy the last 8 bytes (actually the cipher > block size, but all are 8 so far) of cyphertext into the IV and set the > IVcount to zero. Yes, I wrote up that long description because I thought you were asking how it worked, and Jon put it in the spec as an explicit example of how the feedback works. I think the description in the earlier part of the spec was OK but if we do want this kind of long description then perhaps we should also do one (or two for the two cases) for the secret key encryption as well. Hal Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id VAA04531 for ietf-open-pgp-bks; Thu, 23 Apr 1998 21:21:58 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id VAA04527 for ; Thu, 23 Apr 1998 21:21:57 -0700 (PDT) Received: by brickwall.ceddec.com id <43009>; Fri, 24 Apr 1998 00:23:15 -0400 Date: Fri, 24 Apr 1998 00:23:09 -0400 From: dontspam-tzeruch@ceddec.com X-Sender: nobody@mars To: Hal Finney cc: ietf-open-pgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt In-Reply-To: <199804232227.PAA00648@s20.term1.sb.rain.org> Message-Id: <98Apr24.002315edt.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Thu, 23 Apr 1998, Hal Finney wrote: > > 3.6.2.1, Cipher alg: use Simple S2K > > > > ... SHOULD NOT be generated. The only value for Cipher Alg should be 1 to > > (IDEA) to maintain compatability, so why not just say 1 instead of saying > > that you can theoretically use 3DES or CAST to do something you shouldn't > > be doing? > > A bit farther down, it says "it should be understood, but not generated." > Perhaps it needs some capital letters? SHOULD not as opposed to MUST not? Capitalizing a Should does not make it a Must, and the only way to generate a cipher alg other than IDEA is with a new implemetation. Why say Cipher alg instead of IDEA when you mean IDEA (to be backward compatible), unless you are trying to say if you want to be slightly noncompliant it is fine to be noncompliant using 3DES (which is unpatented and thus would make some sense). By saying "Cipher Algorithm" instead of "IDEA" you imply that there is a reason other than backward version interoperability to use this mode. > V3 keys can switch to using the new iterated/salted passphrase hashing, > which is a major security improvement. The spec says V4 uses the new, V3 uses the old. Note that there are only two differences between V3 and V4 secret key packets, and the other is the version number at the head of the packet. It would be easy to modify things to use V4 S2K protection on V3 keys, but the spec should say this is permitted on a V3 key. > > 5.2.2 > > > > The full prefix isn't given, just the OID in ASN1 form. The fuller > > version is sequence(sequence(object,null),octet-stream). > > We are relying on PKCS-1 to explain how the byte stream is set up. > PKCS-1 does not specify the OIDs for the algorithms we are using, so we > provide those here. Get a copy of the PKCS-1 spec and try writing something from it. Without looking at the preformatted number I challenge you to determine the other bytes in the packet. Even given SSLeay's ASN1 support it takes about 10 lines (optimizing more than is proper). Unless I haven't seen a good version of the spec (is there one beyond that on RSA.com?). > > If DSA is used (I know it SHOULD NOT) with a hash with less than 160 bits, ... > We really don't want to encourage any more use of MD5. MD2 was just added and is 128 bits if I remember right. I didn't ask why, but maybe it would be appropriate. > My preferred approach is simply to disallow non-SHA hashes with DSA. > That's what DSS says, after all. Sounds like there is a missing SHOULD NOT > > 7. Cleartest signature framework > > > > "The ASCII armored signature(s)" - for multiple signatures, is each > > signature individually armored, or are the signature packets concatenated > > and the whole armored? > > Despite allowing multiple Hash headers at the top of a clearsigned > message, there is no support at present for multiple signatures in > clearsigned text in our PGP code. But assuming I want to implement it, how should I do so? Or equally reasonable would be to simply allow one signature per clearsigning. > > "If there are no such [Hash:] headers, SHA-1 is used. So V3 Clearsigned > > messages won't interoperate with V4 implementations? Or should the > > default be MD5? > > What PGP does is if there are no hash headers it saves up the message > and then when it reads the signature at the bottom it goes back and > hashes it. However for backwards compatibility perhaps assuming MD5 > would make sense for OpenPGP. PGP 2.6.2 probably won't like it, but instead of choking early on the Hash, I am not sure what it would do beyond saying "invalid" signature. Worse, and OpenPGP implementation reading a 2.6.2 message would automatically do a useless SHA1 hash, then have to rewind and do MD5, as would the existing implementations. Also the whole point of having headers is to avoiding the rewind operation. I could initiate both MD5 and SHA1 hashes on the clearsigned text (so only RIPEMD160, HAVAL, and MD2 would need to be explicitly specified). > > 12.7 > > > > This describes ONLY the cfb reset for the symmetrical packet. V3 RSA > > secret keys also need the cfb reset (between MPIs), and they aren't > > usually on a 10 byte boundary. > > Perhaps this should be identified as the CFB mode used in symmetrically > encrypted data packets. But implementors might also want to import secret V3 keys, so will need the general algorithm. And I don't use any of the FR, FRE or other registers described. I simply copy the last 8 bytes (actually the cipher block size, but all are 8 so far) of cyphertext into the IV and set the IVcount to zero. > > 13 > > > > How can a broken hash algorithm leak a DSA secret key? (I would like a > > reference noting the above interoperability problems, or would this only > > affect a signing service where I could provide known plaintext). > > I don't know if this is possible. However a weak hash could allow you > to forge signatures, as described in Handbook of Applied Cryptography, > section 11.66(iii). Forging signatures by forging the hash value is obvious. However imagine something like a timestamping service which signs arbitrary text. I could send things with known hash values to be signed, like 0, 1, 2, 4, ... I would have to go back to the mathematics, but that is the origin of the threat because I might be able to derive the secret key. But if you want only SHA1 for DSA, and someone breaks SHA1 (without DSA) this could be interesting. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA03286 for ietf-open-pgp-bks; Thu, 23 Apr 1998 17:09:37 -0700 (PDT) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.8/8.7.3) with SMTP id RAA03282 for ; Thu, 23 Apr 1998 17:09:35 -0700 (PDT) Message-Id: <199804240009.RAA03282@mail.proper.com> Received: (qmail 29681 invoked from network); 24 Apr 1998 00:10:57 -0000 Received: from ts5423.powerup.com.au (HELO lindsay) (202.139.237.215) by enterprise.powerup.com.au with SMTP; 24 Apr 1998 00:10:57 -0000 Date: 24 Apr 1998 22:54:44 GMT From: Lindsay Mathieson Subject: Re: PGP Reference Implementation To: Marshall Clow , IETF OpenPGP X-Mailer: Black Paw Communications's MailCat for Win32 Release Vs 2.7 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >>The S/MIME had no encryption code it, just hooks for it, with >instructions on >how to use Crypto++ to fill it in. > Can you give me a >pointer to it? Thanks! Sure See . It is a freeware implementation of S/MIME v3. Although in its early stages, it's reasonably complete. -- Lindsay Mathieson Black Paw Communications Using MailCat for Win32 Release Vs 2.7, on April 24, 1998, in Win95 4.0 http://www.blackpaw.com/ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA02799 for ietf-open-pgp-bks; Thu, 23 Apr 1998 16:13:59 -0700 (PDT) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.8/8.7.3) with SMTP id QAA02795 for ; Thu, 23 Apr 1998 16:13:57 -0700 (PDT) Message-Id: <199804232313.QAA02795@mail.proper.com> Received: (qmail 12155 invoked from network); 23 Apr 1998 23:15:20 -0000 Received: from ts5654.powerup.com.au (HELO lindsay) (202.139.238.118) by enterprise.powerup.com.au with SMTP; 23 Apr 1998 23:15:20 -0000 Date: 24 Apr 1998 21:59:6 GMT From: Lindsay Mathieson Subject: PGP Reference Implementation To: IETF OpenPGP X-Mailer: Black Paw Communications's MailCat for Win32 Release Vs 2.7 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk The S/MIME people have put together a quite good reference S/MIME implementation (though it has the usual irritating Visual C dependancies). Is there a similar one for PGP, available internationally ? The S/MIME had no encryption code it, just hooks for it, with instructions on how to use Crypto++ to fill it in. -- Lindsay Mathieson Black Paw Communications Using MailCat for Win32 Release Vs 2.7, on April 24, 1998, in Win95 4.0 http://www.blackpaw.com/ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA02600 for ietf-open-pgp-bks; Thu, 23 Apr 1998 15:40:24 -0700 (PDT) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA02596 for ; Thu, 23 Apr 1998 15:40:24 -0700 (PDT) Received: from s20.term1.sb.rain.org (s22.term1.sb.rain.org [198.68.144.152]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id PAA22259; Thu, 23 Apr 1998 15:41:45 -0700 (PDT) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id PAA00648; Thu, 23 Apr 1998 15:27:57 -0700 Date: Thu, 23 Apr 1998 15:27:57 -0700 From: Hal Finney Message-Id: <199804232227.PAA00648@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org, tzeruch@ceddec.com Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > 3.6.2.1, Cipher alg: use Simple S2K > > ... SHOULD NOT be generated. The only value for Cipher Alg should be 1 to > (IDEA) to maintain compatability, so why not just say 1 instead of saying > that you can theoretically use 3DES or CAST to do something you shouldn't > be doing? A bit farther down, it says "it should be understood, but not generated." Perhaps it needs some capital letters? > (this also creates problems if you don't allow promoting V3 secret keys to > V4 retaining the key id and other associations since you can't use the new > secret key encryption algorithm). It is true that V3 keys have the secret key material encrypted slightly differently, with the bit lengths in the clear. However most of what is exposed is known values anyway. The size of n and e is known, the sizes of p, q, u and d can be guessed to within a few bits. So there is not much harm in exposing them. PRZ originally designed it like this to have less known plaintext which would give a cryptanalyst a possible opening. V3 keys can switch to using the new iterated/salted passphrase hashing, which is a major security improvement. > 4.2.2.3 Five octet lengths > > Nowhere does it say this SHOULD NOT be used after partial body lengths. > So can it occur in place of the One or Two octet lengths? If the idea was > to mimmic the old style CTB, I would think not. 4.2.2.4 describes the partial body length header, and says, "Another length header (of one of the three types) follows that portion." The "three types" should probably be enumerated as "one-octet, two-octet, or partial", or else we should say "four types". As TZ says, the former seems preferable, with the five octet length used only at the start of the packet. > 5.2.2 > > The full prefix isn't given, just the OID in ASN1 form. The fuller > version is sequence(sequence(object,null),octet-stream). We are relying on PKCS-1 to explain how the byte stream is set up. PKCS-1 does not specify the OIDs for the algorithms we are using, so we provide those here. > If DSA is used (I know it SHOULD NOT) with a hash with less than 160 bits, > I would suggest the data be padded with zeros on the left, or repeat the > hash result. What about a hash with >160? I would suggest the rightmost > (least significant) 160 bits. > > A reason to do this might be to use one hash algorithm for both V3 and V4 > signatures, which would mean MD5. We really don't want to encourage any more use of MD5. I also think we should stick to SHA-1 with DSA signatures. If a different hash is used, the client MUST expose the hash to the user so he can know whether a strong one was used. Otherwise, if one of our supported hashes were eventually be broken, someone could forge a DSA signature using the weak hash, and the user would think the signature is OK. My preferred approach is simply to disallow non-SHA hashes with DSA. That's what DSS says, after all. > 7. Cleartest signature framework > > "The ASCII armored signature(s)" - for multiple signatures, is each > signature individually armored, or are the signature packets concatenated > and the whole armored? Despite allowing multiple Hash headers at the top of a clearsigned message, there is no support at present for multiple signatures in clearsigned text in our PGP code. > "If there are no such [Hash:] headers, SHA-1 is used. So V3 Clearsigned > messages won't interoperate with V4 implementations? Or should the > default be MD5? What PGP does is if there are no hash headers it saves up the message and then when it reads the signature at the bottom it goes back and hashes it. However for backwards compatibility perhaps assuming MD5 would make sense for OpenPGP. > 12.7 > > This describes ONLY the cfb reset for the symmetrical packet. V3 RSA > secret keys also need the cfb reset (between MPIs), and they aren't > usually on a 10 byte boundary. Perhaps this should be identified as the CFB mode used in symmetrically encrypted data packets. > 13 > > How can a broken hash algorithm leak a DSA secret key? (I would like a > reference noting the above interoperability problems, or would this only > affect a signing service where I could provide known plaintext). I don't know if this is possible. However a weak hash could allow you to forge signatures, as described in Handbook of Applied Cryptography, section 11.66(iii). Hal Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA01805 for ietf-open-pgp-bks; Thu, 23 Apr 1998 14:06:55 -0700 (PDT) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA01801 for ; Thu, 23 Apr 1998 14:06:54 -0700 (PDT) Received: from s20.term1.sb.rain.org (s07.term1.sb.rain.org [198.68.144.137]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id OAA13695; Thu, 23 Apr 1998 14:07:57 -0700 (PDT) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id OAA00482; Thu, 23 Apr 1998 14:07:39 -0700 Date: Thu, 23 Apr 1998 14:07:39 -0700 From: Hal Finney Message-Id: <199804232107.OAA00482@s20.term1.sb.rain.org> To: jon@pgp.com, tzeruch@ceddec.com Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > The internal format of what is RSAen/decrypted changed from 2.2 to 2.3, > but not the version number. I don't know what the RFC says. I don't think we should try to support those old V2.2 messages in OpenPGP. That code has been long, long superceded. Anyone running PGP 2.2 should upgrade to at least 2.6.2. Hal Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA01045 for ietf-open-pgp-bks; Thu, 23 Apr 1998 12:38:11 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA01041 for ; Thu, 23 Apr 1998 12:38:10 -0700 (PDT) Received: by brickwall.ceddec.com id <43009>; Thu, 23 Apr 1998 15:39:27 -0400 Date: Thu, 23 Apr 1998 15:39:19 -0400 From: dontspam-tzeruch@ceddec.com X-Sender: nobody@mars To: Jon Callas cc: ietf-open-pgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt In-Reply-To: <3.0.3.32.19980423113031.00b39350@mail.pgp.com> Message-Id: <98Apr23.153927edt.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Thu, 23 Apr 1998, Jon Callas wrote: > At 02:16 PM 4/23/98 -0400, dontspam-tzeruch@ceddec.com wrote: > 5.1 PKESKPs > > "An implementation should accept, but not generate a version of 2, which > is equivalent to V3 in all other respects". > > Isn't V2 the old format using "1 [16 byte session key] [cksum]" instead > of the PKCS-1 block type 02 for the ESK. PGP 2.3? > > As I understand it, the only difference between V2 and V3 was version > number change; it was part of the shift to the RSAREF-based code, and the > version number shift was to force an upgrade to the RSAREF version. > > Jon The internal format of what is RSAen/decrypted changed from 2.2 to 2.3, but not the version number. I don't know what the RFC says. So I can get a version with 2 and the old (pre RSAREF) format DEK. http://www.chem.swin.edu.au/~graeme/pgformat/pgformat_1.html Note: packets that contain a version byte of 2 will contain a version byte of 3 when using versions of PGP >= 2.6 after 9/1/94. Page 7 has the version (==2) byte. Page 10 describes the DEK... The DEK has no CTB packet framing. The DEK is stored packetless and naked, with padding, encrypted inside the MPI in the RSA public-key-encrypted packet. [in the following it says "message digest", but means DEK] PGP versions 2.3 and later use a new format for encoding the message digest into the MPI in the signature packet. (This format is not presently based on any RFCs due to the use of the IDEA encryption system.) This format is accepted but not written by version 2.2. The older format used by versions 2.2 and earlier is also accepted by versions up to 2.4, but the RSAREF code in 2.5 is unable to cope with it. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA00888 for ietf-open-pgp-bks; Thu, 23 Apr 1998 12:18:04 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA00884 for ; Thu, 23 Apr 1998 12:18:03 -0700 (PDT) Received: by brickwall.ceddec.com id <43009>; Thu, 23 Apr 1998 15:19:20 -0400 Date: Thu, 23 Apr 1998 15:19:17 -0400 From: dontspam-tzeruch@ceddec.com X-Sender: nobody@mars To: Jon Callas cc: tzeruch@ceddec.com, ietf-open-pgp@imc.org Subject: Re: Before I forget - two more spec questions In-Reply-To: <3.0.3.32.19980423110657.00aa84e0@mail.pgp.com> Message-Id: <98Apr23.151920edt.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Thu, 23 Apr 1998, Jon Callas wrote: > At 12:32 AM 4/22/98 -0400, dontspam-tzeruch@ceddec.com wrote: > 1. I didn't read over the draft carefully and I don't have it in front of > me. Does it say that the new 5 octet 0xff packet-length MUST be the only > packet length (i.e. not at the end of partial-lengths)? > > No, it doesn't. Back to the code - I generally interpret this as an error, but it is easy to fix (introducing another if-then-else case everyhwere). > Incidentally, I was talking to PhilZ, who has expressed a desire to have > partial lengths deprecated. Only deprecated for the cases I mentioned (and are fixed in the spec), i.e. small blocks, headers, etc. or for everything? They can be useful if you wanted to use PGP in a stream to do something like SSL does. They can also be deprecated for compression without much of a problem. Maybe even Symmetrically encrypted packets (with a "look-for-eof" like compression) since they end when they end. Literals have problems since you have to find the signature(s) at the end. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA00525 for ietf-open-pgp-bks; Thu, 23 Apr 1998 11:31:07 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA00521 for ; Thu, 23 Apr 1998 11:31:06 -0700 (PDT) Received: from fnord (tns40.pgp.com [161.69.9.40]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id LAA14394; Thu, 23 Apr 1998 11:31:20 -0700 (PDT) Message-Id: <3.0.3.32.19980423113031.00b39350@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 23 Apr 1998 11:30:31 -0700 To: dontspam-tzeruch@ceddec.com, ietf-open-pgp@imc.org From: Jon Callas Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt Cc: jon@pgp.com, hal@rain.org In-Reply-To: <98Apr23.141700edt.43010@brickwall.ceddec.com> References: <199804231354.JAA02026@ns.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 02:16 PM 4/23/98 -0400, dontspam-tzeruch@ceddec.com wrote: 5.1 PKESKPs "An implementation should accept, but not generate a version of 2, which is equivalent to V3 in all other respects". Isn't V2 the old format using "1 [16 byte session key] [cksum]" instead of the PKCS-1 block type 02 for the ESK. PGP 2.3? As I understand it, the only difference between V2 and V3 was version number change; it was part of the shift to the RSAREF-based code, and the version number shift was to force an upgrade to the RSAREF version. Jon ----- Jon Callas jon@pgp.com CTO, Total Network Security 4200 Bohannon Drive Network Associates, Inc. Menlo Park, CA 94025 (650) 473-2860 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA00292 for ietf-open-pgp-bks; Thu, 23 Apr 1998 11:15:43 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA00288 for ; Thu, 23 Apr 1998 11:15:43 -0700 (PDT) Received: by brickwall.ceddec.com id <43010>; Thu, 23 Apr 1998 14:17:00 -0400 Date: Thu, 23 Apr 1998 14:16:54 -0400 From: dontspam-tzeruch@ceddec.com X-Sender: nobody@mars Reply-To: dontspam-tzeruch@ceddec.com To: ietf-open-pgp@imc.org cc: jon@pgp.com, hal@rain.org Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt In-Reply-To: <199804231354.JAA02026@ns.ietf.org> Message-Id: <98Apr23.141700edt.43010@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk 5.1 PKESKPs "An implementation should accept, but not generate a version of 2, which is equivalent to V3 in all other respects". Isn't V2 the old format using "1 [16 byte session key] [cksum]" instead of the PKCS-1 block type 02 for the ESK. PGP 2.3? --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA00218 for ietf-open-pgp-bks; Thu, 23 Apr 1998 11:10:29 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA00214 for ; Thu, 23 Apr 1998 11:10:28 -0700 (PDT) Received: from fnord (tns40.pgp.com [161.69.9.40]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id LAA14176; Thu, 23 Apr 1998 11:09:07 -0700 (PDT) Message-Id: <3.0.3.32.19980423110657.00aa84e0@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 23 Apr 1998 11:06:57 -0700 To: tzeruch@ceddec.com From: Jon Callas Subject: Re: Before I forget - two more spec questions Cc: ietf-open-pgp@imc.org In-Reply-To: <98Apr22.003226edt.43009@brickwall.ceddec.com> References: <3.0.3.32.19980403152958.00c23710@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 12:32 AM 4/22/98 -0400, dontspam-tzeruch@ceddec.com wrote: 1. I didn't read over the draft carefully and I don't have it in front of me. Does it say that the new 5 octet 0xff packet-length MUST be the only packet length (i.e. not at the end of partial-lengths)? No, it doesn't. Incidentally, I was talking to PhilZ, who has expressed a desire to have partial lengths deprecated. Jon ----- Jon Callas jon@pgp.com CTO, Total Network Security 4200 Bohannon Drive Network Associates, Inc. Menlo Park, CA 94025 (650) 473-2860 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA29994 for ietf-open-pgp-bks; Thu, 23 Apr 1998 10:58:03 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA29990 for ; Thu, 23 Apr 1998 10:58:02 -0700 (PDT) Received: by brickwall.ceddec.com id <43009>; Thu, 23 Apr 1998 13:59:19 -0400 Date: Thu, 23 Apr 1998 13:59:10 -0400 From: dontspam-tzeruch@ceddec.com X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt In-Reply-To: <199804231354.JAA02026@ns.ietf.org> Message-Id: <98Apr23.135919edt.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Thu, 23 Apr 1998 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the An Open Specification for Pretty Good Privacy > Working Group of the IETF. > > Title : OpenPGP Message Format > Author(s) : R. Thayer, J. Callas, L. Donnerhacke, H. Finney > Filename : draft-ietf-openpgp-formats-02.txt > Pages : 54 > Date : 22-Apr-98 3.6.2.1, Cipher alg: use Simple S2K ... SHOULD NOT be generated. The only value for Cipher Alg should be 1 to (IDEA) to maintain compatability, so why not just say 1 instead of saying that you can theoretically use 3DES or CAST to do something you shouldn't be doing? It says 'the cipher algorithm number with an implicit use of MD5 and IDEA' but the cipher algorithm number only means IDEA if it has the value of 1, so if there is a cipher algorithm number, then the cipher is *NOT* implicit, but specified by the number. (this also creates problems if you don't allow promoting V3 secret keys to V4 retaining the key id and other associations since you can't use the new secret key encryption algorithm). 4.2.2.3 Five octet lengths Nowhere does it say this SHOULD NOT be used after partial body lengths. So can it occur in place of the One or Two octet lengths? If the idea was to mimmic the old style CTB, I would think not. 5.2.2 The full prefix isn't given, just the OID in ASN1 form. The fuller version is sequence(sequence(object,null),octet-stream). If DSA is used (I know it SHOULD NOT) with a hash with less than 160 bits, I would suggest the data be padded with zeros on the left, or repeat the hash result. What about a hash with >160? I would suggest the rightmost (least significant) 160 bits. A reason to do this might be to use one hash algorithm for both V3 and V4 signatures, which would mean MD5. 7. Cleartest signature framework "The ASCII armored signature(s)" - for multiple signatures, is each signature individually armored, or are the signature packets concatenated and the whole armored? "If there are no such [Hash:] headers, SHA-1 is used. So V3 Clearsigned messages won't interoperate with V4 implementations? Or should the default be MD5? 12.7 This describes ONLY the cfb reset for the symmetrical packet. V3 RSA secret keys also need the cfb reset (between MPIs), and they aren't usually on a 10 byte boundary. 13 How can a broken hash algorithm leak a DSA secret key? (I would like a reference noting the above interoperability problems, or would this only affect a signing service where I could provide known plaintext). --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id GAA28337 for ietf-open-pgp-bks; Thu, 23 Apr 1998 06:53:51 -0700 (PDT) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id GAA28333 for ; Thu, 23 Apr 1998 06:53:49 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id JAA02026; Thu, 23 Apr 1998 09:54:41 -0400 (EDT) Message-Id: <199804231354.JAA02026@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-open-pgp@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-openpgp-formats-02.txt Date: Thu, 23 Apr 1998 09:54:40 -0400 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF. Title : OpenPGP Message Format Author(s) : R. Thayer, J. Callas, L. Donnerhacke, H. Finney Filename : draft-ietf-openpgp-formats-02.txt Pages : 54 Date : 22-Apr-98 This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. Open-PGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication and digital signatures. This document specifies the message formats used in OpenPGP. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-openpgp-formats-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-openpgp-formats-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-openpgp-formats-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980422102521.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-openpgp-formats-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-openpgp-formats-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980422102521.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id UAA10904 for ietf-open-pgp-bks; Wed, 22 Apr 1998 20:14:50 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id UAA10900 for ; Wed, 22 Apr 1998 20:14:50 -0700 (PDT) Received: by brickwall.ceddec.com id <43010>; Wed, 22 Apr 1998 23:16:01 -0400 Date: Wed, 22 Apr 1998 23:16:01 -0400 From: dontspam-tzeruch@ceddec.com X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: Announcing: opgp98.tgz In-Reply-To: <98Apr22.003226edt.43009@brickwall.ceddec.com> Message-Id: <98Apr22.231601edt.43010@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk The main change is that everything in the library is renamed with PGP_ as a prefix to avoid namespace collisions. More things work including upto 16 recipients and/or one passphrase for encryption. The last 2.6.2 bug has been squashed (passphrased secret keys that were not 8N bits long). Some slight restructuring and cleanup. Also now works with tempfiles as well as pipes. at www.cryptography.org, soon to be in new, and then libraries. I left a sed script in the goodies directory if you have some of your own test programs that need fixing. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id VAA17870 for ietf-open-pgp-bks; Tue, 21 Apr 1998 21:31:17 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id VAA17866 for ; Tue, 21 Apr 1998 21:31:17 -0700 (PDT) Received: by brickwall.ceddec.com id <43009>; Wed, 22 Apr 1998 00:32:26 -0400 Date: Wed, 22 Apr 1998 00:32:23 -0400 From: dontspam-tzeruch@ceddec.com X-Sender: nobody@mars To: Jon Callas cc: ietf-open-pgp@imc.org Subject: Before I forget - two more spec questions In-Reply-To: <3.0.3.32.19980403152958.00c23710@mail.pgp.com> Message-Id: <98Apr22.003226edt.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk 1. I didn't read over the draft carefully and I don't have it in front of me. Does it say that the new 5 octet 0xff packet-length MUST be the only packet length (i.e. not at the end of partial-lengths)? 2. You have multiple hashes for Clearsigned messages, but don't cover the format of the signatures themselves. Is it merely a bunch of concatenated signature packets? Or is there a -----BEGIN PGP SIG... for each of them? Can they be nested? Does nesting involve dash escaping? Since I don't have any example of a multiple signature clearsigned message I don't quite understand how this is to work. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id WAA07579 for ietf-open-pgp-bks; Sat, 18 Apr 1998 22:13:34 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id WAA07575 for ; Sat, 18 Apr 1998 22:13:33 -0700 (PDT) Received: by brickwall.ceddec.com id <43009>; Sun, 19 Apr 1998 01:14:22 -0400 Date: Sun, 19 Apr 1998 01:14:26 -0400 From: dontspam-tzeruch@ceddec.com X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: Re: 11.2 Dual KeyIDs for RSA keys? In-Reply-To: <9804181558.AA04646@mentat.com> Message-Id: <98Apr19.011422edt.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Sat, 18 Apr 1998, Jim Gillogly wrote: > tzeruch wrote: > > Generally, I think it would make sense to promote RSA keys to V4 format > > (and assuming a V4 keyserver), but be able to export them in V3 format > > when necessary. The keyserver could find the key given either the V3 or > > V4 keyid. > > Looking forward to a "semantics" document (if it comes to that) to > supplement the formats document, I'm uncomfortable making an explicit > linkage between the V3 and V4 format RSA keys unless we have a good > model of what signatures mean in this case. If a signer signs one or > the other format, would you assume that signature has the same meaning > for the other format? Would you have the Web of trust form the union > of signatures on the two styles of key? I suppose it makes sense, but > I'd want to think through the implications further. Certainly it would > be sufficient to have each of your signers sign both formats, but it > seems overly tricky to have to check a signature by failing, then > converting the key to the other format and trying again. > > Jim Gillogly The actual essence of the key is the modulus and exponent in the case of an RSA key (actually the Modulus - exponents would be subkeys). So a V3, and a V4 RSA key should mean the same "persistent identity" wherever the N/E pair appears. Same things applies for the public key parameter of DSS or DH keys. There is even a metacert group apparently trying to standardize on something that will encompass all usages so one set of key parameters will work everywhere. About a year ago I converted my PGP key to an X509 certificate request and had Verisign sign it when they were doing free user IDs, and should be able to take a Verisign X509 cert, pull the moduli, create a PGP public key that can verify the signatures (possibly giving it a high trust level). Since my implementation is SSLeay based, I already have most of the X509 style cert handling already available. Conversion is usually figuring out how to map the parameters (I usually use a oneline as the userid, and the NotAfter gives the expiration date, etc.), and calling my keyout5 routine with the x509 public key data. I can also take my PGP secret key and convert it to an SSLeay private key file. I haven't looked at S/MIME in any detail yet, but from what I have seen it shouldn't be too difficult to cross the boundary. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id JAA29429 for ietf-open-pgp-bks; Sat, 18 Apr 1998 09:01:20 -0700 (PDT) Received: from mentat.com (mentat.com [192.88.122.129]) by mail.proper.com (8.8.8/8.7.3) with SMTP id JAA29424 for ; Sat, 18 Apr 1998 09:01:18 -0700 (PDT) Received: from rock.mentat.com ([192.88.122.136]) by mentat.com (4.1/SMI-4.1) id AA04646; Sat, 18 Apr 98 08:58:33 PDT Date: Sat, 18 Apr 98 08:58:33 PDT From: jim@mentat.com (Jim Gillogly) Message-Id: <9804181558.AA04646@mentat.com> To: ietf-open-pgp@imc.org Subject: Re: 11.2 Dual KeyIDs for RSA keys? Sender: owner-ietf-open-pgp@imc.org Precedence: bulk tzeruch wrote: > Generally, I think it would make sense to promote RSA keys to V4 format > (and assuming a V4 keyserver), but be able to export them in V3 format > when necessary. The keyserver could find the key given either the V3 or > V4 keyid. Looking forward to a "semantics" document (if it comes to that) to supplement the formats document, I'm uncomfortable making an explicit linkage between the V3 and V4 format RSA keys unless we have a good model of what signatures mean in this case. If a signer signs one or the other format, would you assume that signature has the same meaning for the other format? Would you have the Web of trust form the union of signatures on the two styles of key? I suppose it makes sense, but I'd want to think through the implications further. Certainly it would be sufficient to have each of your signers sign both formats, but it seems overly tricky to have to check a signature by failing, then converting the key to the other format and trying again. Jim Gillogly Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id WAA19393 for ietf-open-pgp-bks; Fri, 17 Apr 1998 22:54:31 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id WAA19384 for ; Fri, 17 Apr 1998 22:54:29 -0700 (PDT) Received: by brickwall.ceddec.com id <43009>; Sat, 18 Apr 1998 01:54:59 -0400 Date: Sat, 18 Apr 1998 01:55:11 -0400 From: dontspam-tzeruch@ceddec.com X-Sender: nobody@mars To: Jim Gillogly cc: ietf-open-pgp@imc.org Subject: Re: 11.2 Dual KeyIDs for RSA keys? In-Reply-To: <9804180425.AA01894@mentat.com> Message-Id: <98Apr18.015459edt.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Sat, 18 Apr 1998, Jim Gillogly wrote: > > But then there is a problem. If I already have a V3 RSA key, and want to > > use the V4 features, I will have to convert the key. Considering it as a > > new key might work, but if I want to sign something to a V3 recipient, I > > have to use the old ID along with the format (i.e. keyservers won't have > > the key under the old ID). > > > > Or are you saying I MUST not generate any V3 signatures with V4 RSA keys? > > Could you achieve the desired effect by sending both the V3 and V4 > versions of your RSA key to the keyservers? Yes and no. The question is whether keyid 0x12345678 is the same identity as 0xdeadbeef . And then, what if you lookup me@here and get both keys, how do I say the V4 version is the preferred key when there is no real way to link them? And if I revoke one, the other is still good unless the keyserver links the keys. Generally, I think it would make sense to promote RSA keys to V4 format (and assuming a V4 keyserver), but be able to export them in V3 format when necessary. The keyserver could find the key given either the V3 or V4 keyid. > > Adding these MUST options is reasonable, but then they should be added to > > the spec. Letting implementations use RSA keys in both V3 and V4 contexts > > on the fly is also reasonable. But something should appear in the spec > > saying what should be done - Do I check both possible keyids on a V4 RSA > > signature or just the V4 type? Am I allowed to export my V4 RSA key in V3 > > format? > > I think this is an implementation and program behavior detail, and thus > should not be in the formats document. However, I approve of and applaud > your approach of being willing to accept many different combinations and > permutations of formats. I did my code such that it tries the V4 ID first, and only if that does not match, it then computes and tries to match on the V3 ID. When signing I use a specified keyid (but return the V3 ID by number for my testmode where a keyid of zero means get the first key supporting the algorithm). Even if the exact behavior isn't specified, this ambiguity should be noted so that implementors can take it into account instead of blindly assuming all RSA keys should use V3 keyids, and saying "Key not found" if I V4sign a document with an RSA key and place the V4 keyid in the signature (and looking it up on a keyserver returns the same key, but the ID is only computed the old way, so it will always look up the key, return it as correctly formatted, but never be able to find it). If an implementation imports a V4 RSA key without error, but doesn't accept the V4 keyid to match it (for things like signatures), I consider it a bug. And only that. Whether and how to promote/demote the keys can be implementation dependent. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id VAA17934 for ietf-open-pgp-bks; Fri, 17 Apr 1998 21:28:32 -0700 (PDT) Received: from mentat.com (mentat.com [192.88.122.129]) by mail.proper.com (8.8.8/8.7.3) with SMTP id VAA17930 for ; Fri, 17 Apr 1998 21:28:32 -0700 (PDT) Received: from rock.mentat.com ([192.88.122.136]) by mentat.com (4.1/SMI-4.1) id AA01894; Fri, 17 Apr 98 21:25:41 PDT Date: Fri, 17 Apr 98 21:25:41 PDT From: jim@mentat.com (Jim Gillogly) Message-Id: <9804180425.AA01894@mentat.com> To: ietf-open-pgp@imc.org Subject: Re: 11.2 Dual KeyIDs for RSA keys? Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > Jon Callas wrote: > > Within the openPGP framework, a keyid is a 64 bit number, and you can use > > them at will. tzeruch wrote: > Which is fine when there is a one-to-one mapping. What I am pointing out > is technically a keyid is either of two possible 64 bit numbers. > > > It's a perfectly fine feature to have V3 => V4 migration, but I'd consider > > the V4 key to be a completely separate key, and forget that it shares bits > > with the V3 one. I see nothing in the formats document that would contradict this. I also see nothing that would preclude the possibility of an implementation keeping track of both the V3 and V4 Key ID and fingerprints of the key and taking appropriate action if either of them is seen. I think it would be unlikely to achieve the desired effect across the range of PGP-like programs if you were to do V3 sigs with your V4 key or vice versa, but I feel it's not the place of the formats document to preclude this usage. > But then there is a problem. If I already have a V3 RSA key, and want to > use the V4 features, I will have to convert the key. Considering it as a > new key might work, but if I want to sign something to a V3 recipient, I > have to use the old ID along with the format (i.e. keyservers won't have > the key under the old ID). > > Or are you saying I MUST not generate any V3 signatures with V4 RSA keys? Could you achieve the desired effect by sending both the V3 and V4 versions of your RSA key to the keyservers? > Adding these MUST options is reasonable, but then they should be added to > the spec. Letting implementations use RSA keys in both V3 and V4 contexts > on the fly is also reasonable. But something should appear in the spec > saying what should be done - Do I check both possible keyids on a V4 RSA > signature or just the V4 type? Am I allowed to export my V4 RSA key in V3 > format? I think this is an implementation and program behavior detail, and thus should not be in the formats document. However, I approve of and applaud your approach of being willing to accept many different combinations and permutations of formats. Jim Gillogly Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id VAA17816 for ietf-open-pgp-bks; Fri, 17 Apr 1998 21:05:14 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id VAA17812 for ; Fri, 17 Apr 1998 21:05:12 -0700 (PDT) Received: by brickwall.ceddec.com id <43010>; Sat, 18 Apr 1998 00:05:42 -0400 Date: Sat, 18 Apr 1998 00:05:51 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars Reply-To: tzeruch@ceddec.com To: Jon Callas cc: ietf-open-pgp@imc.org Subject: Re: 11.2 Dual KeyIDs for RSA keys? In-Reply-To: <3.0.3.32.19980417153141.00bdd860@mail.pgp.com> Message-Id: <98Apr18.000542edt.43010@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Fri, 17 Apr 1998, Jon Callas wrote: > At 05:33 PM 4/17/98 -0400, tzeruch@ceddec.com wrote: > I brought this up before. I can create a V4 fingerprint and keyid using > an RSA key, but it will be different than the V3 keyid. I have some kluge > working so that PGP 2.6.X will work, but this isn't really addressed. > > If I use V4 stuff everywhere, shouldn't I use the V4 keyid? Does any > version of PGP match on a V4 (SHA1-hash) RSA Keyid? (I match on both - > the later versions of my code look for a matching V4 keyid and only if it > does NOT match will it compute the V3 keyid). > > If you have the same key material that is used in a V3 key and a V4 key, it > will have a different keyid and fingerprint. This is a feature, not a bug. > One of the reasons for the new format is that keyids can be forged. I didn't say it was a bug. But there is no mention in the section on Keyids of the fact that an RSA key will have a different value under V3 v.s. V4. And says nothing about which one to use in the KeyID fields in the subpackets I generate. > Within the openPGP framework, a keyid is a 64 bit number, and you can use > them at will. Which is fine when there is a one-to-one mapping. What I am pointing out is technically a keyid is either of two possible 64 bit numbers. > It's a perfectly fine feature to have V3 => V4 migration, but I'd consider > the V4 key to be a completely separate key, and forget that it shares bits > with the V3 one. But then there is a problem. If I already have a V3 RSA key, and want to use the V4 features, I will have to convert the key. Considering it as a new key might work, but if I want to sign something to a V3 recipient, I have to use the old ID along with the format (i.e. keyservers won't have the key under the old ID). Or are you saying I MUST not generate any V3 signatures with V4 RSA keys? i.e. that the migration creates an entirely new key (then why migrate?). If I want to have V3 capabilities, MUST? I leave the key and corresponding ID in a V3 format? So a corolary would be "I MUST not generate V4 signatures with a V3 RSA key? Adding these MUST options is reasonable, but then they should be added to the spec. Letting implementations use RSA keys in both V3 and V4 contexts on the fly is also reasonable. But something should appear in the spec saying what should be done - Do I check both possible keyids on a V4 RSA signature or just the V4 type? Am I allowed to export my V4 RSA key in V3 format? I am only pointing out that the current (preliminary) spec doesn't address this anywhere that I have found, and something should be written in before it is released. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id TAA14070 for ietf-open-pgp-bks; Wed, 15 Apr 1998 19:23:18 -0700 (PDT) Received: from dfw-ix11.ix.netcom.com (dfw-ix11.ix.netcom.com [206.214.98.11]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id TAA14066 for ; Wed, 15 Apr 1998 19:23:17 -0700 (PDT) Received: (from smap@localhost) by dfw-ix11.ix.netcom.com (8.8.4/8.8.4) id VAA02411; Wed, 15 Apr 1998 21:22:35 -0500 (CDT) Received: from pax-ca7-26.ix.netcom.com(204.30.66.58) by dfw-ix11.ix.netcom.com via smap (V1.3) id rma002295; Wed Apr 15 21:21:59 1998 Message-Id: <3.0.5.32.19980415100534.00860cc0@popd.ix.netcom.com> X-Sender: stewarts@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Wed, 15 Apr 1998 10:05:34 -0700 To: Jon Callas , ietf-open-pgp@imc.org From: Bill Stewart Subject: Re: Elgamal signatures In-Reply-To: <3.0.3.32.19980414174356.00a23e50@mail.pgp.com> References: <9804142145.AA01369@mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 05:43 PM 4/14/98 -0700, Jon Callas wrote: >Elgamal signatures are large [....] also slow [....] ... >allow a key to be used for both encryption and signatures. .... >Elgmal keys that are used for signing have to have more constraints placed >on them than encryption keys. The keys that PGP 5.x generates are not >suitable for signatures. Some facets of this are a serious consideration; I think tzeruch's position should dominate, that if you make ElGamal signatures a MAY, then all his ElGamal support code is "just authentication" and therefore exportable. Accepting ElGamal signatures may be more important than creating them, and implementations that create ElGamal keys MUST (or maybe SHOULD) generate strong keys (or the documentation should read something analagous to the link(2) manpage, which says that linking directories can only be done by root, who is presumed to know what he is doing. :-) Thanks! Bill Bill Stewart, bill.stewart@pobox.com PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id TAA12650 for ietf-open-pgp-bks; Wed, 15 Apr 1998 19:04:55 -0700 (PDT) Received: from relay15.jaring.my (relay15.jaring.my [192.228.128.126]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id TAA12644 for ; Wed, 15 Apr 1998 19:04:53 -0700 (PDT) Received: from pclow (j7.ptl35.jaring.my [161.142.115.201]) by relay15.jaring.my (8.8.8/8.8.8) with SMTP id KAA11961; Thu, 16 Apr 1998 10:04:52 +0800 (MYT) Message-ID: <353568ED.5102@pc.jaring.my> Date: Thu, 16 Apr 1998 10:11:57 +0800 From: griffin Reply-To: lpchiew@pc.jaring.my Organization: freebie X-Mailer: Mozilla 3.04Gold (Win95; I) MIME-Version: 1.0 To: dontspam-tzeruch@ceddec.com CC: ietf-open-pgp@imc.org Subject: Re: announce: opgp97.tgz - I've gone monolithic References: <98Apr15.184508edt.43010@brickwall.ceddec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk dontspam-tzeruch@ceddec.com wrote: > It should appear on www.cryptography.org by tomorrow in either the new or > libraries directory. I'm more interested in when it will appear in the European sites ;) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA05651 for ietf-open-pgp-bks; Wed, 15 Apr 1998 15:44:53 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA05647 for ; Wed, 15 Apr 1998 15:44:52 -0700 (PDT) Received: by brickwall.ceddec.com id <43010>; Wed, 15 Apr 1998 18:45:08 -0400 Date: Wed, 15 Apr 1998 18:45:23 -0400 From: dontspam-tzeruch@ceddec.com X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: announce: opgp97.tgz - I've gone monolithic In-Reply-To: <98Apr14.110820edt.43010@brickwall.ceddec.com> Message-Id: <98Apr15.184508edt.43010@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I now have replaced several things with a single pgp5 program. Apologies to PGP inc. since I couldn't think of something else to call it for this release and it is still intended to be a demo of the underlying library. If you have fork and pipe, it works in one pass, e.g. ./pgp5 -i FILE -o FILE.pgp -l FILE -1 -t 0 -z -e kid -m MESSAGE Signs, compresses, and encrypts to kid (keyid), and ascii armors. ./pgp5 -i FILE.pgp -o FILE.out Will recover the file and indicate the results of the signature check. This doesn't work everywhere (i.e. when the final step is not a literal or a text file), but I have an Increment flag for those cases. There are still some structures (e.g. multiple recipients) I don't do, and it is one file at a time, but I have full control of all the algorithms used internally and should be able to correctly generate or process anything which is in the OpenPGP specification and exists in SSLeay 0.9.0 (plus SAFER/SK128 and HAVAL). And the source is still under 3500 lines. clear-signing and testing clearsigned messages are done in two other auxillary programs. There is a new-to-old CTB program for 2.6.2 support and some keyring routines. A few internal improvements have been made since 95b7 - ROTN is out, armoring is many times faster. Lots of things from earlier versions are much improved. If you haven't upgraded in a while, check this version out. It requires SSLeay 0.9.0. Safer and Haval URLs are included and can be compiled in by simply installing the .c and .h files. Thanks to all who are bearing with me with a work in progress. It should appear on www.cryptography.org by tomorrow in either the new or libraries directory. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA10346 for ietf-open-pgp-bks; Tue, 14 Apr 1998 18:03:43 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id SAA10342 for ; Tue, 14 Apr 1998 18:03:43 -0700 (PDT) Received: from fnord (tns40.pgp.com [161.69.9.40]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id SAA19650; Tue, 14 Apr 1998 18:03:19 -0700 (PDT) Message-Id: <3.0.3.32.19980414175521.00b61570@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 14 Apr 1998 17:55:21 -0700 To: tzeruch@ceddec.com, Jon Callas From: Jon Callas Subject: Re: Elgamal signatures Cc: ietf-open-pgp@imc.org In-Reply-To: <98Apr14.184037edt.43011@brickwall.ceddec.com> References: <3.0.3.32.19980414142215.00b0a880@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 06:40 PM 4/14/98 -0400, dontspam-tzeruch@ceddec.com wrote: I assume you are going to leave ROT-N and SAFER/SK128 in? The former is specifically designed to be weak. ROT-N is out, SAFER is in. Jon ----- Jon Callas jon@pgp.com CTO, Total Network Security 4200 Bohannon Drive Network Associates, Inc. Menlo Park, CA 94025 (650) 473-2860 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA10253 for ietf-open-pgp-bks; Tue, 14 Apr 1998 17:53:28 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id RAA10249 for ; Tue, 14 Apr 1998 17:53:28 -0700 (PDT) Received: from fnord (tns40.pgp.com [161.69.9.40]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id RAA19577 for ; Tue, 14 Apr 1998 17:52:29 -0700 (PDT) Message-Id: <3.0.3.32.19980414174356.00a23e50@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 14 Apr 1998 17:43:56 -0700 To: ietf-open-pgp@imc.org From: Jon Callas Subject: Re: Elgamal signatures In-Reply-To: <9804142145.AA01369@mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk There are a number of issues around Elgmal signatures, as opposed to (say) DSA signatures. These are the ones I can remember off the top of my head: Al discrete-log signature systems have as part of their real strength the size of the hash function as well as the size of the key. Because of birthday attacks, the strength of the hash is half its length (a.k.a. the square root of the maximum hash number) -- so a 160 bit hash has a strength of 80 bits. This is alleged to be roughly the same strength as a 1024 bit key. The downside of this is that there is no reason to make a key longer than 1024 bits with no longer hashes, and in fact it is arguably a security weakness. The counter-argument to this is that without the longer keys, there's no reason to have longer hashes. (For the last couple of months, I've been waiting for someone to suggest a longer hash, like say Haval-5-256, or to even agree with my hints that such a thing would be a good idea.) Elgamal signatures are large when compared to DSA sigs -- two full-key MPIs, as opposed to two 160-bit MPIs. The counter-argument is, "so what?" They're also slow -- they require three exponentiations, as opposed to only one for DSA. Elgamal signatures allow a key to be used for both encryption and signatures. The counter argument is that many protocol designers think this is a Bad Thing, that keys should be single-purpose. The counter-counter argument is, "you design your protocols, I'll design mine." In other words, if there is *some* protocol that has a good use for a sual-use key, then the meta-protocol shouldn't forbid it. Elgmal keys that are used for signing have to have more constraints placed on them than encryption keys. The keys that PGP 5.x generates are not suitable for signatures. Some facets of this are a serious consideration; unlike some signature flaws that cause bad signatures, these cause loss of your key. There's a good discussion of these security considerations in Menezes, van Oorschot, and Vanstone, pp454-456. You can also find an interesting paper on mere forgeries at There are also some other fussy things you can do to forge signatures, like make r and s roughly twice the size of the prime p. It all just means you have to be extra careful with Elgamal sigs. Jon ----- Jon Callas jon@pgp.com CTO, Total Network Security 4200 Bohannon Drive Network Associates, Inc. Menlo Park, CA 94025 (650) 473-2860 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA09079 for ietf-open-pgp-bks; Tue, 14 Apr 1998 15:47:06 -0700 (PDT) Received: from newmail.virgin.net (newmail.virgin.net [194.168.54.44]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA09075 for ; Tue, 14 Apr 1998 15:47:03 -0700 (PDT) Received: from server.eternity.org ([194.168.68.208]) by newmail.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 1-55555U125000L125000S0) with ESMTP id AAA23609; Tue, 14 Apr 1998 22:47:26 +0000 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id XAA00821; Tue, 14 Apr 1998 23:42:44 +0100 Date: Tue, 14 Apr 1998 23:42:44 +0100 Message-Id: <199804142242.XAA00821@server.eternity.org> From: Adam Back To: jon@pgp.com CC: ietf-open-pgp@imc.org In-reply-to: <3.0.3.32.19980414142215.00b0a880@mail.pgp.com> (message from Jon Callas on Tue, 14 Apr 1998 14:22:15 -0700) Subject: Re: Elgamal signatures Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jon Callas writes: > I've been writing up a section on the care needed to select Elgamal keys so > that the resulting signatures are strong. In going through all of this, I > can't help but wonder if it's worth it. > > Should we forego Elgamal signatures in the spec and make Elgamal only an > encryption algorithm? One advantage of Elgamal signatures is that they are defined for hash algorithms producing more than 160 bits of output. So this might be nice for RIPE-MD with larger output to provide a more secure option than 160 bits. When you take into account birthday attacks, at 80 bits DSA doesn't look that strong, if we are talking about building in future proofing. For this reason I'd like to see Elgamal sigantures remain as a MAY. (And I'd also like by implication to see a larger output hash function in). Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA08983 for ietf-open-pgp-bks; Tue, 14 Apr 1998 15:40:39 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA08979 for ; Tue, 14 Apr 1998 15:40:38 -0700 (PDT) Received: by brickwall.ceddec.com id <43011>; Tue, 14 Apr 1998 18:40:37 -0400 Date: Tue, 14 Apr 1998 18:40:56 -0400 From: dontspam-tzeruch@ceddec.com X-Sender: nobody@mars To: Jon Callas cc: ietf-open-pgp@imc.org Subject: Re: Elgamal signatures In-Reply-To: <3.0.3.32.19980414142215.00b0a880@mail.pgp.com> Message-Id: <98Apr14.184037edt.43011@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Tue, 14 Apr 1998, Jon Callas wrote: > I've been writing up a section on the care needed to select Elgamal keys so > that the resulting signatures are strong. In going through all of this, I > can't help but wonder if it's worth it. You could also simply point to the external info, or just add info on how to detect weak signatures. > Should we forego Elgamal signatures in the spec and make Elgamal only an > encryption algorithm? I would rather leave a reserved number, etc. for it. DSA limits the signature size to 160 bits, so even if I create a 4096 bit p, it isn't any more secure than a 2048 bit p. Also, since one of the problem is the generators, if anyone wants to add ElGamal signatures later, it would help if people started using a generator other than 2 when creating the parameters even if they don't support ElGamal in the current version. There is one further complication. Right now I would leave them in as a MAY so that all my ring handling code is required for *authentication* and therefore *possibly* exportable (I actually have a slim version of my library without any encryption, but it still does clearsigning and verification using the 3 signature algorithms v.s. the 5 hashes). I assume you are going to leave ROT-N and SAFER/SK128 in? The former is specifically designed to be weak. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA08472 for ietf-open-pgp-bks; Tue, 14 Apr 1998 15:20:25 -0700 (PDT) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA08468 for ; Tue, 14 Apr 1998 15:20:24 -0700 (PDT) Received: from whgiii (jellyfish27.pcola.gulf.net [198.69.79.187]) by users.invweb.net (8.8.7/8.8.7) with SMTP id SAA23121; Tue, 14 Apr 1998 18:20:12 -0400 Message-Id: <199804142220.SAA23121@users.invweb.net> From: "William H. Geiger III" Date: Tue, 14 Apr 98 17:19:12 -0500 To: Jon Callas In-Reply-To: <3.0.3.32.19980414142215.00b0a880@mail.pgp.com> Cc: ietf-open-pgp@imc.org Subject: Re: Elgamal signatures X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.46b b46b Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <3.0.3.32.19980414142215.00b0a880@mail.pgp.com>, on 04/14/98 at 04:22 PM, Jon Callas said: >I've been writing up a section on the care needed to select Elgamal keys >so that the resulting signatures are strong. In going through all of >this, I can't help but wonder if it's worth it. >Should we forego Elgamal signatures in the spec and make Elgamal only an >encryption algorithm? No, I think that there is substantial interest in Elgamal signatures to include it in the spec. I admit I have not given Elgamal a through study but I am currious as to how an Elgamal key would be secure for encryption and yet not be so for a signature? - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html - --------------------------------------------------------------- Tag-O-Matic: PATH=C:\DOS;C:\DOS\RUN;C:\WIN\CRASH\DOS;C:\ME\DEL\WIN -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNTPh4I9Co1n+aLhhAQHv0QP/XyRDkhW5/hD82nSgEDfWkrYPb0ZvUUQX 1VLWRpOwJ5uyho26ygkWBfSmTZBxziTCXx4MSOH9lbXQ7z2P0BB6/D5uDJQLsy15 /tXtD8MVkysqeUTk0NFDx5VLVd4J+zwAGSPycYHUw/9xdFMUtkpk1koXR2bAS/Qi +IIQAvOtKMU= =Z5Oa -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA08170 for ietf-open-pgp-bks; Tue, 14 Apr 1998 14:48:27 -0700 (PDT) Received: from mentat.com (mentat.com [192.88.122.129]) by mail.proper.com (8.8.8/8.7.3) with SMTP id OAA08166 for ; Tue, 14 Apr 1998 14:48:26 -0700 (PDT) Received: from rock.mentat.com ([192.88.122.136]) by mentat.com (4.1/SMI-4.1) id AA01369; Tue, 14 Apr 98 14:45:23 PDT Date: Tue, 14 Apr 98 14:45:23 PDT From: jim@mentat.com (Jim Gillogly) Message-Id: <9804142145.AA01369@mentat.com> To: ietf-open-pgp@imc.org Subject: Re: Elgamal signatures Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jon sez: > I've been writing up a section on the care needed to select Elgamal keys so > that the resulting signatures are strong. In going through all of this, I > can't help but wonder if it's worth it. > > Should we forego Elgamal signatures in the spec and make Elgamal only an > encryption algorithm? Given the potential pitfalls and the fact that the first version of openpgp-formats is more a description of interoperability with existing versions (plus a little) than severe groundbreaking, I'm inclined to agree with this sentiment. Since there'll be a follow-on document at some distant point in the future, that'll even give time for more attacks to mature on various systems... i.e. we may be smarter in a year or two. It's a good idea to have dissimilar options for each variable, and we seem to have that already. The hashing department is the only one where the main algorithms we're using have very similar structures. Jim Gillogly Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA08071 for ietf-open-pgp-bks; Tue, 14 Apr 1998 14:33:47 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA08067 for ; Tue, 14 Apr 1998 14:33:47 -0700 (PDT) Received: from fnord (tns40.pgp.com [161.69.9.40]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id OAA18013 for ; Tue, 14 Apr 1998 14:32:52 -0700 (PDT) Message-Id: <3.0.3.32.19980414142215.00b0a880@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 14 Apr 1998 14:22:15 -0700 To: ietf-open-pgp@imc.org From: Jon Callas Subject: Elgamal signatures Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I've been writing up a section on the care needed to select Elgamal keys so that the resulting signatures are strong. In going through all of this, I can't help but wonder if it's worth it. Should we forego Elgamal signatures in the spec and make Elgamal only an encryption algorithm? Jon ----- Jon Callas jon@pgp.com CTO, Total Network Security 4200 Bohannon Drive Network Associates, Inc. Menlo Park, CA 94025 (650) 473-2860 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id IAA04549 for ietf-open-pgp-bks; Tue, 14 Apr 1998 08:08:13 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id IAA04545 for ; Tue, 14 Apr 1998 08:08:12 -0700 (PDT) Received: by brickwall.ceddec.com id <43010>; Tue, 14 Apr 1998 11:08:20 -0400 Date: Tue, 14 Apr 1998 11:08:37 -0400 From: dontspam-tzeruch@ceddec.com X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: update - how to get my latest code In-Reply-To: <98Apr13.214916edt.43010@brickwall.ceddec.com> Message-Id: <98Apr14.110820edt.43010@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk My versions have been coming rapidly, so occasionally it took time to appear in the libraries directory. There is a new system that will let my code reappear by the next day at: http://cryptography.org/cgi-bin/crypto.cgi/new/ (But also remember to look in the libraries directory). --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA15509 for ietf-open-pgp-bks; Mon, 13 Apr 1998 18:49:17 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id SAA15505 for ; Mon, 13 Apr 1998 18:49:16 -0700 (PDT) Received: by brickwall.ceddec.com id <43010>; Mon, 13 Apr 1998 21:49:16 -0400 Date: Mon, 13 Apr 1998 21:49:33 -0400 From: dontspam-tzeruch@ceddec.com X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: Armor CRC clarification In-Reply-To: <98Apr13.192431edt.43010@brickwall.ceddec.com> Message-Id: <98Apr13.214916edt.43010@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Nowhere does it say that CRC applies to each part of an armored message instead of a cumulative or other system. Also, I don't know if it belongs in the spec, but is the implementation supposed to sort the messages in the stream? I can do cat msg.a* | ./pgpv as long as they are already in sequence (as of 95b9). Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA14217 for ietf-open-pgp-bks; Mon, 13 Apr 1998 17:48:57 -0700 (PDT) Received: from om.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.7.3) with SMTP id RAA14211 for ; Mon, 13 Apr 1998 17:48:56 -0700 (PDT) Message-Id: <4.0.1.327.19980413174748.0109e680@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.327 (Beta) Date: Mon, 13 Apr 1998 17:48:04 -0700 To: ietf-open-pgp@imc.org From: Paul Hoffman / IMC Subject: SecureConnect 1 announcement Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk IMC's popular series of interoperability events for developers continues with SecureConnect 1 for S/MIME v2, S/MIME v3, PGP/MIME, and OpenPGP. SecureConnect 1 will be held July 23 and 24, and will cover end-to-end mail security, specifically using S/MIME v2, S/MIME v3, PGP/MIME, and OpenPGP. The market for mail clients using these technologies continues to grow, and the S/MIME v3 and OpenPGP specs are nearing completion. Now is the time for the industry to make sure that shipping and soon-to-be-shipping products interoperate. Signed messages require the presence of certificates, and SecureConnect 1 will also be a place for certificate Authority (CA) vendors to test the interoperability of the certificates generated by their products. Further, user agent vendors at SecureConnect 1 will be able to make sure that their products can create and verify messages that come with certificates from participating CAs. More information about SecureConnect 1 can be found at . --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA12997 for ietf-open-pgp-bks; Mon, 13 Apr 1998 16:24:35 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA12993 for ; Mon, 13 Apr 1998 16:24:34 -0700 (PDT) Received: by brickwall.ceddec.com id <43010>; Mon, 13 Apr 1998 19:24:31 -0400 Date: Mon, 13 Apr 1998 19:24:53 -0400 From: dontspam-tzeruch@ceddec.com X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: opgp95 beta 7 In-Reply-To: <98Apr11.180007edt.43009@brickwall.ceddec.com> Message-Id: <98Apr13.192431edt.43010@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk New - I actually documented the calls, though I need to flesh out the descriptions and insure that the very latest changed didn't damage anything. Updated to use SSLeay 0.9.0 (which has builtin CAST and RIPEMD). The only 2.6.2 routine left is keyout2 which does only V3 rsa keys. A new ringscan program has been added. I now use malloc for buffers, hash context, and do symmetrical encryption using a malloced context, and reorganized many other things. And it is even a little smaller (2257 lib, 3210 total source lines :). Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id AAA17084 for ietf-open-pgp-bks; Sun, 12 Apr 1998 00:23:30 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id AAA17080 for ; Sun, 12 Apr 1998 00:23:29 -0700 (PDT) Received: by brickwall.ceddec.com id <43009>; Sun, 12 Apr 1998 03:23:15 -0400 Date: Sun, 12 Apr 1998 03:23:42 -0400 From: dontspam-tzeruch@ceddec.com X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: Why no one-pass symmetric test packet? In-Reply-To: <98Apr11.180007edt.43009@brickwall.ceddec.com> Message-Id: <98Apr12.032315edt.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I mentioned this earlier in a different context. One problem is that each public key and passphrase key prepended to the symmetrically encrypted packet will need to create a context if I want to do things in one pass. What would be better is a one-pass-symencrypt header similar to the one pass sigs which would have the algorithm and the first 10 bytes so that you could pretest the passphrase keys as they occured (and the speculative public keys). Note this also creates a problem if there is ever a cipher with a block length greater than 8. Without the 10 byte header there would be no easy way to determine if a passphrase key actually worked. And I worry about the probability of the byte pair matching but with the wrong key. It would still help to have a checksum on the SKESK, and that too could be detected (by the key length determined by the algorithm leaving two bytes). Or a CRC since random bytes would tend to average to the same mean value. Or even an XOR of every byte pair or something. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA02620 for ietf-open-pgp-bks; Sat, 11 Apr 1998 15:00:18 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA02616 for ; Sat, 11 Apr 1998 15:00:17 -0700 (PDT) Received: by brickwall.ceddec.com id <43009>; Sat, 11 Apr 1998 18:00:07 -0400 Date: Sat, 11 Apr 1998 18:00:29 -0400 From: dontspam-tzeruch@ceddec.com X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: Well, I did a pgpv command... In-Reply-To: <98Apr9.180958edt.43009@brickwall.ceddec.com> Message-Id: <98Apr11.180007edt.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Since I added an autodetect to minipgp, it wasn't much of a leap to add a pipe/fork mechanism. It accepts armored, encrypted, compressed or literaled input and goes all the way to plaintext. Using SSLeay 0.9.0, the simple benchmarks indicates it is 50% to 100% faster than PGP 5.0 for linux. Interestingly enough, dearmoring proved to be a major bottleneck. The rest (about 80%) of the speed difference was not due to anything I did, but to Eric Young and Tim Hudson's work in speeding up SSLeay. This is in the archive opgp95b3.tgz, just uploaded to www.cryptography.org, or email me with the appropriate legalese about not exporting it if you want it sooner. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA13780 for ietf-open-pgp-bks; Fri, 10 Apr 1998 11:29:33 -0700 (PDT) Received: from mentat.com (mentat.com [192.88.122.129]) by mail.proper.com (8.8.8/8.7.3) with SMTP id LAA13776 for ; Fri, 10 Apr 1998 11:29:32 -0700 (PDT) Received: from zendia.mentat.com by mentat.com (4.1/SMI-4.1) id AA01391; Fri, 10 Apr 98 11:25:31 PDT Received: by zendia.mentat.com (SMI-8.6/SMI-SVR4) id LAA13951; Fri, 10 Apr 1998 11:26:03 -0700 Date: Fri, 10 Apr 1998 11:26:03 -0700 From: jimg@mentat.com (Jim Gillogly) Message-Id: <199804101826.LAA13951@zendia.mentat.com> To: ietf-open-pgp@imc.org, bill.stewart@pobox.com Subject: Re: RSA Key spec question X-Sun-Charset: US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > At 10:33 AM 4/3/98 -0500, tzeruch - at - ceddec - dot - com wrote: > >E is 17 in pgp, but often 3 or 65567 elsewhere. I know why 2**N+1, but is > >there anything that should be said about this in the spec? > > > >(Testing 2.6.2 v.s. SSLeay from long ago proved that any value of E worked > >in either; But only some could be generated, or would be by default). Bill Stewart writes: > The spec says that PKCS1 padding is required for the encrypted > session key packet, but it doesn't explicitly say that > in a message with multiple recipients, EVERY encrypted session > key packet needs to use a different random padding, as opposed to > making one copy of m and encrypting it separately with each key. > This needs to be fixed. > > The issue is preventing the low-exponent attack on RSA, > which is a particular risk for e=3, but occasionally messages > will have more than e=17 RSA-using recipients. Indeed. My PGP keyring may be odd, but I have several PGP keys that have exponents other than e=17: Richard Outerbridge's, Arnold Reinhold's, David Stoler's, and the IETF Registrar's all use 65537, and Christopher Drake (0xC0DED00D) has a 69-bit exponent. I'm guessing that's not an accidental number. :) Jim Gillogly Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA13385 for ietf-open-pgp-bks; Fri, 10 Apr 1998 10:46:19 -0700 (PDT) Received: from dfw-ix4.ix.netcom.com (dfw-ix4.ix.netcom.com [206.214.98.4]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA13381 for ; Fri, 10 Apr 1998 10:46:18 -0700 (PDT) Received: (from smap@localhost) by dfw-ix4.ix.netcom.com (8.8.4/8.8.4) id MAA04437 for ; Fri, 10 Apr 1998 12:03:58 -0500 (CDT) Received: from pax-ca7-01.ix.netcom.com(204.30.66.33) by dfw-ix4.ix.netcom.com via smap (V1.3) id rma004399; Fri Apr 10 12:03:37 1998 Message-Id: <3.0.5.32.19980409092438.00830100@popd.ix.netcom.com> X-Sender: stewarts@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 09 Apr 1998 09:24:38 -0700 To: ietf-open-pgp@imc.org From: Bill Stewart Subject: Re: RSA Key spec question In-Reply-To: <98Apr3.103254est.43010@brickwall.ceddec.com> References: <98Apr3.100646est.43012@brickwall.ceddec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 10:33 AM 4/3/98 -0500, tzeruch - at - ceddec - dot - com wrote: >E is 17 in pgp, but often 3 or 65567 elsewhere. I know why 2**N+1, but is >there anything that should be said about this in the spec? > >(Testing 2.6.2 v.s. SSLeay from long ago proved that any value of E worked >in either; But only some could be generated, or would be by default). The spec says that PKCS1 padding is required for the encrypted session key packet, but it doesn't explicitly say that in a message with multiple recipients, EVERY encrypted session key packet needs to use a different random padding, as opposed to making one copy of m and encrypting it separately with each key. This needs to be fixed. The issue is preventing the low-exponent attack on RSA, which is a particular risk for e=3, but occasionally messages will have more than e=17 RSA-using recipients. Mentioning that 17, 3, and 65537 are popular values of e seems worthwhile; it's probably not important to say that implementations MUST or SHOULD support encrypting with other values of e, since there's no realy reason to assume they wouldn't. A more interestng problem is whether implementations SHOULD or MAY refuse to encrypt to RSA keys with e=1, at least for multiple- recipient messages. Are there other categories of keys that are easily detected as weak, e.g. composites, or do you really need to know p and q to detect weak keys? Are there similar problems for ElGamal / Diffie Hellman? Section 5.1 of the spec currently says: > The encrypted value "m" in the above formulas is derived from the > session key as follows. First the session key is prepended with a > one-octet algorithm identifier that specifies the conventional > encryption algorithm used to encrypt the following Symmetrically > Encrypted Data Packet. Then a two-octet checksum is appended which is > equal to the sum of the preceding octets, including the algorithm > identifier and session key, modulo 65536. This value is then padded as > described in PKCS-1 block type 02 [PKCS1] to form the "m" value used in > the formulas above. Thanks! Bill Bill Stewart, bill.stewart@pobox.com PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id TAA24699 for ietf-open-pgp-bks; Thu, 9 Apr 1998 19:36:22 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id TAA24695 for ; Thu, 9 Apr 1998 19:36:21 -0700 (PDT) Received: by brickwall.ceddec.com id <43009>; Thu, 9 Apr 1998 22:35:51 -0400 Date: Thu, 9 Apr 1998 22:36:22 -0400 From: dontspam-tzeruch@ceddec.com X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: Update: V4 RSA keys work, if they aren't protected In-Reply-To: <98Apr3.143749est.43009@brickwall.ceddec.com> Message-Id: <98Apr9.223551edt.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I found a problem with my V4 RSA key export routine. Now if I don't passphrase them, PGP 5.0 seems to be able to understand them. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA21637 for ietf-open-pgp-bks; Thu, 9 Apr 1998 15:10:36 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA21633 for ; Thu, 9 Apr 1998 15:10:35 -0700 (PDT) Received: by brickwall.ceddec.com id <43009>; Thu, 9 Apr 1998 18:09:58 -0400 Date: Thu, 9 Apr 1998 18:10:22 -0400 From: dontspam-tzeruch@ceddec.com X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: preannounce: opgp95 In-Reply-To: <98Apr2.160148est.43010@brickwall.ceddec.com> Message-Id: <98Apr9.180958edt.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Lots of fixes, enhancements, etc. to meet the spec as I currently understand it. I don't do multiple [P|S]KESKs, multiple 1 pass signatures, and keymanagement, and I do support ElGamal signatures, so I am not in 100% compliance. But it works and can interoperate with other programs insofar as they meet the spec. The big news is that everything is now done by one program, i.e. cat cryptfile | minipgp5 | minipgp5 | minipgp5 | minipgp5 >plainfile ................dearmor.....decrypt...decompress..deliteral When not piping, or with onepass sigs, the deliteral will also check the signature. And these work with either the old or new CTB format (as long as the new format isn't fragmented, but I have a preprocessor for that). And the reverse steps would be cat plainfile | minipgp5 -l plainfile | \ minipgp5 -z | minipgp5 -k >cryptfile. (signatures are generated detached with or without onepass headers and assembled using cat). The minipgp5 program is mostly glue to invoke the proper library routine and is designed more to allow testing of the library or provide samples of how to preparse and invoke the functions. It is not a designed to be a practical or usable implementation. The only difficulty is that with a swiss-army-knife approach, I now have about 20 options that can be specified, and some must be precise to cause the right thing to happen (and my checking isn't good, if you ask for both armoring and compression only one will happen). In the other direction, the autodetect is fairly good. I have updated my awk scripts so they now work with minipgp5 to generate or check clearsigned messages on OpenPGP messages. Another big note is that with a ctb conversion program it is now fully backward compatible - minipgp5 only generates new CTBs, but the tooldctb program will fix that. I also removed the SKESK for the case where everything is 2.x default (and assume 2.x defaults if I see the CTB for a symmetrical data packet before an ESK). The old minipgp directory is going away (but all the functions are moving into the newpgp directory which will likely be renamed). SSLeay 0.9 is due out in a few days, so I am going to be adapting the program to use that so you may want to wait. www.cryptography.org has been backlogged, so if you want an alpha version, email me with the appropriate "I can legally send to you and you know about exporting and should not" information. I also managed to cut the codesize (all .c and .h files are under 3500 lines, not counting safer, haval, and ripemd). --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA01598 for ietf-open-pgp-bks; Tue, 7 Apr 1998 18:58:28 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id SAA01594 for ; Tue, 7 Apr 1998 18:58:27 -0700 (PDT) Received: from fnord (tns40.pgp.com [161.69.9.40]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id SAA12879; Tue, 7 Apr 1998 18:55:31 -0700 (PDT) Message-Id: <3.0.3.32.19980407184251.00b085d0@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 07 Apr 1998 18:42:51 -0700 To: ulf@fitug.de (Ulf =?iso-8859-1?Q?M=F6ller?= ), ietf-open-pgp@imc.org From: Jon Callas Subject: Re: character set In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 01:48 AM 4/8/98 DST, Ulf M=F6ller wrote: The draft says that user IDs are encoded in UTF-8. Do the current versions of PGP actually do that? My user ID, which I generated with PGP 5.0 for Windows, is plain Latin-1. =20 Nope, they don't. That means they aren't OpenPGP compliant, and will have to change that. Jon ----- Jon Callas jon@pgp.com CTO, Total Network Security 4200 Bohannon Drive Network Associates, Inc. Menlo Park, CA 94025 (650) 473-2860 =20 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA00839 for ietf-open-pgp-bks; Tue, 7 Apr 1998 17:30:43 -0700 (PDT) Received: from public.uni-hamburg.de (public.uni-hamburg.de [134.100.41.1]) by mail.proper.com (8.8.8/8.7.3) with SMTP id RAA00833 for ; Tue, 7 Apr 1998 17:30:41 -0700 (PDT) Received: from max2-215.public.uni-hamburg.de by public.uni-hamburg.de (AIX 4.1/UCB 5.64/4.03) id AA51840; Wed, 8 Apr 1998 02:30:41 +0200 Received: by ulf.mali.sub.org (Smail3.1.28.1 #1) id m0yMi6h-0003b8C; Wed, 8 Apr 98 01:48 CET DST Message-Id: Date: Wed, 8 Apr 98 01:48 CET DST From: ulf@fitug.de (Ulf =?iso-8859-1?Q?M=F6ller?=) To: ietf-open-pgp@imc.org Subject: character set Organization: HR13 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk The draft says that user IDs are encoded in UTF-8. Do the current versions of PGP actually do that? My user ID, which I generated with PGP 5.0 for Windows, is plain Latin-1. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA28857 for ietf-open-pgp-bks; Tue, 7 Apr 1998 14:27:25 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA28853 for ; Tue, 7 Apr 1998 14:27:23 -0700 (PDT) Received: by brickwall.ceddec.com id <43011>; Tue, 7 Apr 1998 17:26:45 -0400 Date: Tue, 7 Apr 1998 17:27:21 -0400 From: dontspam-tzeruch@ceddec.com X-Sender: nobody@mars Reply-To: dontspam-tzeruch@ceddec.com To: ietf-open-pgp@imc.org Subject: Updates - opgp93 soon. In-Reply-To: <98Apr6.131735edt.43013@brickwall.ceddec.com> Message-Id: <98Apr7.172645edt.43011@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I now have more test cases, but the tgz is 4+Mb. This includes all extra stuff like blowfish, safer, and haval, and even ROT-N and plaintext. I recreated a pgpz/pgpunz which can take literal packets directly to/from pgp5 compressed packets. These may disappear from the release. I also have CTB to rawstream and rawstream to CTB code (which collects tiny fragments into large ones so they can be used with the rest of my routines). (note that the version of pgp 5.0 I use can't accept a raw compressed packet in either form - but if I encrypt it everything works) www.cryptography.org has been unattended, so if someone is desparate (and a US citizen in the US, etc), I can email them. SSLeay has an impending release which should include CAST and RIPEMD160, and I am working toward that. My #define setup now assumes the newer version as the default (as I understand it will be, since the code isn't released yet and I don't have it) and has everything turned on that comes with SSLeay. Other changes include V4 RSA keys, fixes to conventional encryption and a fix that prevented my awk clearsign signature checker from working in minipgp. The readme files have been tweaked, and code reorganized. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA02272 for ietf-open-pgp-bks; Mon, 6 Apr 1998 12:43:21 -0700 (PDT) Received: from www.unitools.com.br (www.unitools.com.br [200.245.246.2]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA02266 for ; Mon, 6 Apr 1998 12:43:09 -0700 (PDT) Received: from Paulo ([200.245.246.29]) by www.unitools.com.br (Netscape Mail Server v2.0) with SMTP id AAA18215; Mon, 6 Apr 1998 16:42:42 -0300 Message-Id: <3.0.3.32.19980406164338.006c5678@www.unitools.com.br> X-Sender: paulo.barreto@www.unitools.com.br X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 06 Apr 1998 16:43:38 -0300 To: Jon Callas From: paulo.barreto@unitools.com.br (Paulo Barreto) Subject: Re: On my HAVAL implementation Cc: ietf-open-pgp@imc.org In-Reply-To: <3.0.3.32.19980403175856.00c1bac0@mail.pgp.com> References: <3.0.3.32.19980330154137.006e3460@www.unitools.com.br> <351FE2DD.31DFF4F5@systemics.com> <3.0.3.32.19980330092841.006d7b5c@www.unitools.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 05:58 PM 98/04/03 -0800, Jon Callas wrote: >At 03:41 PM 3/30/98 -0300, Paulo Barreto wrote: > > 1. Though my implementation is indeed public domain, the very algorithm is > *not*, as Dr. Yuliang Zheng clearly states in his HAVAL page. However, > he's very liberal in conceding "licenses" (in fact, absolutely no fee is > due; Dr. Zheng only wants to keep track of where HAVAL is being used). > >I'm a little concerned about this. It is my understanding of copyright law >that one can copyright an *implementation* but not an algorithm. I wrote >Dr. Zheng, and he gave me permission to put it in OpenPGP. However, I am >still concerned about putting in an algorithm that someone claims >"copyright" on. Furthermore, we need an OID for it. I agree with you, but I'm not a lawyer, so I'm not sure about what can be copyrighted and what can't; this could even be country-dependent. But since Dr. Zheng gave permission to use HAVAL in OpenPGP, I don't think this is a problem anymore. >Does anyone have an opinion? Should I strike HAVAL? Should I leave it there >even if it's just a placeholder for later? It's certainly nice to have >extra hash algorithms, but it is by no means something we should delay >over. It can always go in 1.1. Remember that there aren't that many 256-bit fast hashing functions around (Tiger is only 192-bit, and the only other such a function I know of is J. Daemen's StepRightUp, which is not widely known), so dropping HAVAL would be a great loss. Paulo Barreto. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA00912 for ietf-open-pgp-bks; Mon, 6 Apr 1998 10:17:45 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA00908 for ; Mon, 6 Apr 1998 10:17:35 -0700 (PDT) Received: by brickwall.ceddec.com id <43013>; Mon, 6 Apr 1998 13:17:35 -0400 Date: Mon, 6 Apr 1998 13:18:13 -0400 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: Re: Preliminary V4 RSA key support added. But I can't test... In-Reply-To: <98Apr3.143749est.43009@brickwall.ceddec.com> Message-Id: <98Apr6.131735edt.43013@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Part of PGP 5.0 wants the format to be MPI-checksum-MPI-checksum... and another part MPI-MPI-...-checksum, so I can't use pgpv to decrypt using V4 RSA keys. I did some major rework to my keypacket input and output routines, but www.cryptography.org is backlogged. If anyone need this quickly, please email me (with a note about your export status). Also, a new rev of SSLeay should be out in a week or so with CAST and RIPEMD160 included. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id TAA10673 for ietf-open-pgp-bks; Sun, 5 Apr 1998 19:42:03 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id TAA10651 for ; Sun, 5 Apr 1998 19:39:22 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id WAA03948; Sun, 5 Apr 1998 22:37:47 -0400 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id WAA16482; Sun, 5 Apr 1998 22:35:04 -0400 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA40866; Sun, 5 Apr 1998 22:30:58 -0400 From: Uri Blumenthal Message-Id: <9804060230.AA40866@watpub1.watson.ibm.com> Subject: Re: On my HAVAL implementation To: jon@pgp.com (Jon Callas) Date: Sun, 5 Apr 1998 22:30:57 -0400 (EDT) Cc: paulo.barreto@unitools.com.br, ietf-open-pgp@imc.org In-Reply-To: <3.0.3.32.19980403175856.00c1bac0@mail.pgp.com> from "Jon Callas" at Apr 3, 98 05:58:56 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jon Callas says: > 1. Though my implementation is indeed public domain, the very algorithm is > *not*, as Dr. Yuliang Zheng clearly states in his HAVAL page. However, > he's very liberal in conceding "licenses" (in fact, absolutely no fee is > due; Dr. Zheng only wants to keep track of where HAVAL is being used). > > I'm a little concerned about this. It is my understanding of copyright law > that one can copyright an *implementation* but not an algorithm. I wrote > Dr. Zheng, and he gave me permission to put it in OpenPGP. However, I am > still concerned about putting in an algorithm that someone claims > "copyright" on. Furthermore, we need an OID for it. I would not be concerned of mere "copyrights" - for example, I say that DES/SK is "copyrighted" by me and Steve Bellovin. So what? As long as that ownership is acknowledged and the authors are held harmless, anybody can do whatever they wish with the algorithm: implement it, sell the implementation, give the implementation away, etc. > Does anyone have an opinion? Should I strike HAVAL? Should I leave it there > even if it's just a placeholder for later? It's certainly nice to have > extra hash algorithms, but it is by no means something we should delay > over. It can always go in 1.1. I think this is a no-brainer. If Dr. Zheng only wants his "ownership" to be acknowledged (like - "this is HAVAL function invented by Dr. Zheng") there is no problem. If however he demands something more than a mere recognition - you may consider striking the algorithm out. The simplest solution is to check with Dr. Zheng and ask what his requirements are and what his copyright says. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id IAA07194 for ietf-open-pgp-bks; Sun, 5 Apr 1998 08:15:19 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id IAA07182 for ; Sun, 5 Apr 1998 08:13:58 -0700 (PDT) Received: by brickwall.ceddec.com id <43009>; Sun, 5 Apr 1998 11:14:07 -0400 Date: Sun, 5 Apr 1998 11:14:44 -0400 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars To: ietf-open-pgp@imc.org cc: Jon Callas Subject: More spec cleanup/suggestions In-Reply-To: <98Apr4.172229est.43009@brickwall.ceddec.com> Message-Id: <98Apr5.111407edt.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Move section 11 (Ehnanced Key Formats) to 5.5.4 or something else near the rest of the descriptions. 5.11 "Trust Packet" either needs to describe the existing format or it should be listed as purely implementation dependant. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA20431 for ietf-open-pgp-bks; Sat, 4 Apr 1998 14:23:51 -0800 (PST) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA20424 for ; Sat, 4 Apr 1998 14:22:30 -0800 (PST) Received: by brickwall.ceddec.com id <43009>; Sat, 4 Apr 1998 17:22:29 -0500 Date: Sat, 4 Apr 1998 17:23:13 -0500 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars To: Jon Callas cc: ietf-open-pgp@imc.org Subject: Re: Preliminary V4 RSA key support added. But I can't test... In-Reply-To: <3.0.3.32.19980403152958.00c23710@mail.pgp.com> Message-Id: <98Apr4.172229est.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Fri, 3 Apr 1998, Jon Callas wrote: > I was wrong, it is a V4 packet. But it uses V3 including keyids for > everything else, so I can't find the key on the keyring. > > I needed to compensate for the checksums unique to RSA secret MPIs. > > Nonetheless, this sounds like a bug in 5.0. Bug or feature? It appears that a V4 RSA secret material is handled identically to V3 secret material. It appears that the version byte is ignored unless it is not 3 or 4. I can make my code do the right thing (for OpenPGP). As soon as what the right thing requires is defined. But it would break 5.0. Anyone working on an implementation for the Palm Pilot Pro? --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id CAA16234 for ietf-open-pgp-bks; Sat, 4 Apr 1998 02:28:26 -0800 (PST) Received: from ns1.via.at (ns1.via.at [194.41.60.10]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id CAA16230 for ; Sat, 4 Apr 1998 02:28:24 -0800 (PST) Received: (from root@localhost) by ns1.via.at (8.7.5/8.7.3) id MAA13893; Sat, 4 Apr 1998 12:29:18 +0200 (MET DST) To: gkwagner@via.at Received: from mail.proper.com(206.86.127.224) by ns1.via.at via smap (V2.0) id xma018440; Fri, 3 Apr 98 22:14:07 +0200 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA29737 for ietf-open-pgp-bks; Fri, 3 Apr 1998 11:37:59 -0800 (PST) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA29733 for ; Fri, 3 Apr 1998 11:37:58 -0800 (PST) Received: by brickwall.ceddec.com id <43009>; Fri, 3 Apr 1998 14:37:49 -0500 Date: Fri, 3 Apr 1998 14:38:32 -0500 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: Preliminary V4 RSA key support added. But I can't test... In-Reply-To: <98Apr3.100646est.43012@brickwall.ceddec.com> Message-Id: <98Apr3.143749est.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Fri, 3 Apr 1998 nospam-seesignature@ceddec.com wrote: > Why not, for V4 keys, treat RSA MPIs just like DSA or DH MPIs? That is, encrypt the MPI whole and not do any resets. In this case encrypt all 4 MPIs in a stream starting with the first bitcount octet. And while I am here, you are storing U (which is iqmp in SSLeay) as part of the RSA secret key. Might I suggest (given the rest of the incompatibilites already there) that we also include dmp1 and dmq1? And place those just above U? I calculate them, but I could calculate U. (see my getkey2.c and rsa.h from SSLeay, and the SSLeay docs about what these are used for - it works with just N,E, and D, but is much faster with the rest of these params). > I also have a problem with Key v.s. Subkey packets. I use DH keys for El > Gamal signing. Do they belong in a key or subkey packet? What about an > RSA key used for both? I generated a V4 RSA key as a primary key and PGP 5.0 promptly converted it to a V3 packet, V3 Keyid, V3 Fingerprint, etc. Since I can't export a V4 RSA key at the moment, I don't know if I would be able to read it. I am going to have to rework my interface, currently I have it if the DSA and DH pointers are identical, then it points to a RSA structure. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id AAA13597 for ietf-open-pgp-bks; Sat, 4 Apr 1998 00:08:25 -0800 (PST) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id AAA13589 for ; Sat, 4 Apr 1998 00:08:23 -0800 (PST) Received: by brickwall.ceddec.com id <43009>; Sat, 4 Apr 1998 03:08:19 -0500 Date: Sat, 4 Apr 1998 03:09:03 -0500 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars To: Jon Callas cc: ietf-open-pgp@imc.org Subject: V4 RSA key update. In-Reply-To: <3.0.3.32.19980403152958.00c23710@mail.pgp.com> Message-Id: <98Apr4.030819est.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I have working? V4 rsa keys. 1. When encrypting to RSA keys, PGP 5.0 always uses the old packet format. adding this allowed me to decrypt a pgpe encrypted message. I am generating the new format. 2. I haven't tried passphrase protected V4 RSA keys, since that is being added. I may dupe PGP 5.0 behavior. 3. PGP 5.0 only uses the old style RSA key ids. 4. pgpv still won't recognize a pgpe produced RSA message., nor one I create, so I suspect it has something to do with the V4 key. A new opgp should happen sometime this weekend. I also reorganized some more things. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id UAA02983 for ietf-open-pgp-bks; Fri, 3 Apr 1998 20:34:51 -0800 (PST) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id UAA02979 for ; Fri, 3 Apr 1998 20:34:50 -0800 (PST) Received: by brickwall.ceddec.com id <43009>; Fri, 3 Apr 1998 23:34:50 -0500 Date: Fri, 3 Apr 1998 23:35:33 -0500 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars To: Jon Callas cc: ietf-open-pgp@imc.org Subject: Re: Preliminary V4 RSA key support added. But I can't test... In-Reply-To: <3.0.3.32.19980403152958.00c23710@mail.pgp.com> Message-Id: <98Apr3.233450est.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Fri, 3 Apr 1998, Jon Callas wrote: > Nonetheless, this sounds like a bug in 5.0. > > Jon One note is that SSLeay and OpenPGP label the P and Q RSA constants the reverse of each other. Normally it doesn't matter, but if you use the extension with D mod Q-1 and D mod P-1 for the SSLeay structure you need to get these right. Also I see it says in the spec, P < Q Which may explain why it is reversed. But it still doesn't interoperate with PGP 5.0. I may still have a problem with my secring format (but the pubring V4 format seems to work fine). Worse, pgpe also encrypts using one of my keys (pgpk says it is fine too), but I can't decrypt it - pgpv acts the same. pgpk: Type Bits KeyID Created Expires Algorithm Use sec 512 331A8FBD 1998-04-04 ---------- RSA Sign and Encrypt f16 Fingerprint16 = AF F7 A7 54 6F EB 62 C1 72 86 90 BA 18 0E D6 64 uid RSAKey (it can say sec+ if I set it to axiomatic, but it still does the same thing). pgpv: Message is encrypted. Cannot decrypt message. It can only be decrypted by: 512 bits, Key ID 331A8FBD, Created 1998-04-04 "RSAKey" --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA02661 for ietf-open-pgp-bks; Fri, 3 Apr 1998 18:49:59 -0800 (PST) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id SAA02657 for ; Fri, 3 Apr 1998 18:49:58 -0800 (PST) Received: by brickwall.ceddec.com id <43009>; Fri, 3 Apr 1998 21:49:55 -0500 Date: Fri, 3 Apr 1998 21:50:42 -0500 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars To: Jon Callas cc: ietf-open-pgp@imc.org Subject: Re: On my HAVAL implementation In-Reply-To: <3.0.3.32.19980403175856.00c1bac0@mail.pgp.com> Message-Id: <98Apr3.214955est.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Fri, 3 Apr 1998, Jon Callas wrote: > At 03:41 PM 3/30/98 -0300, Paulo Barreto wrote: > > I'm a little concerned about this. It is my understanding of copyright law > that one can copyright an *implementation* but not an algorithm. I wrote > Dr. Zheng, and he gave me permission to put it in OpenPGP. However, I am > still concerned about putting in an algorithm that someone claims > "copyright" on. Furthermore, we need an OID for it. 1. I would get a clarification that it would be something like GPL, i.e. no restriction on incorporation or distribution if we put it in, or something like "No restrictions on use in OpenPGP implementations". 2. You don't need an OID to use it with DSS, only RSA and El Gamal, and currently I say the OID is length zero, but have some appropriate constants which will never get in. 3. Even if you leave in a placeholder, at least it would help to define the rounds and length of the hash. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA02634 for ietf-open-pgp-bks; Fri, 3 Apr 1998 18:38:49 -0800 (PST) Received: from mentat.com (mentat.com [192.88.122.129]) by mail.proper.com (8.8.8/8.7.3) with SMTP id SAA02630 for ; Fri, 3 Apr 1998 18:38:49 -0800 (PST) Received: from rock.mentat.com ([192.88.122.136]) by mentat.com (4.1/SMI-4.1) id AA23197; Fri, 3 Apr 98 18:36:06 PST Date: Fri, 3 Apr 98 18:36:06 PST From: jim@mentat.com (Jim Gillogly) Message-Id: <9804040236.AA23197@mentat.com> To: ietf-open-pgp@imc.org Subject: Re: On my HAVAL implementation Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jon says: > At 03:41 PM 3/30/98 -0300, Paulo Barreto wrote: > > 1. Though my implementation is indeed public domain, the very algorithm is > *not*, as Dr. Yuliang Zheng clearly states in his HAVAL page. However, > he's very liberal in conceding "licenses" (in fact, absolutely no fee is > due; Dr. Zheng only wants to keep track of where HAVAL is being used). > > I'm a little concerned about this. It is my understanding of copyright law > that one can copyright an *implementation* but not an algorithm. I wrote Yes, that's my understanding as well. People have been getting away with patenting algorithms and other mathematics (pretending they're process patents and using appropriately convoluted language in the patent to further that fiction), but copyright covers only the expression and not the factual content. > Does anyone have an opinion? Should I strike HAVAL? Should I leave it there > even if it's just a placeholder for later? It's certainly nice to have > extra hash algorithms, but it is by no means something we should delay > over. It can always go in 1.1. I'd like to keep it, but not at the cost of substantial delays. Perhaps another iteration or two, having somebody assign an OID while discussing it with Prof. Zheng, would be enough to resolve it. And if it isn't resolved by Last Call, it's OAPL. Another possibility is Tiger (Anderson & Biham, http://www.cs.technion.ac.il/~biham). I don't see an OID for it either, though, nor do I see anything about IPR for it. Its design is different from MD5 and SHA-1 (which are in the same general family), which is a plus. Perhaps it's premature to include either HAVAL or Tiger in the spec, though, since neither has gotten a fraction of the attention of MD5 and SHA-1. Jim Gillogly Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA02599 for ietf-open-pgp-bks; Fri, 3 Apr 1998 18:26:09 -0800 (PST) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id SAA02595 for ; Fri, 3 Apr 1998 18:26:07 -0800 (PST) Received: by brickwall.ceddec.com id <43009>; Fri, 3 Apr 1998 21:25:55 -0500 Date: Fri, 3 Apr 1998 21:26:38 -0500 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars To: Jon Callas cc: ietf-open-pgp@imc.org Subject: Re: V4 RSA keys??? Incongruities In-Reply-To: <3.0.3.32.19980403151103.00c479c0@mail.pgp.com> Message-Id: <98Apr3.212555est.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Fri, 3 Apr 1998, Jon Callas wrote: > At 10:07 AM 4/3/98 -0500, nospam-seesignature@ceddec.com wrote: > We should. All public keys should be handled the same in V4 formats. I've > changed that. Thanks for pointing it out. There are a number of places > where the original text uses "RSA" to mean "V3." It is my intent for > OpenPGP to extend V4 to all key types, even the ones that Team PGP never > implemented (such as V4 RSA keys, Elgamal signing keys, etc). I've changed > the text in that paragraph and the one after to reflect this. And nuke the checksum on unencrypted keys (i.e. make the routines identical). > I also have a problem with Key v.s. Subkey packets. I use DH keys for El > Gamal signing. Do they belong in a key or subkey packet? What about an > RSA key used for both? > > When Viacrypt wanted to make sign-only and encrypt-only keys, they added > the new PKC types for those uses. There are a (small) number of those keys > still hanging around. Personally, I think Lutz's new subpacket for marking > key usage is a better solution for the long term, and I wouldn't mind > deprecating the RSA usage types (comments?). I didn't even know they > existed until some code I had written (based upon RFC1991 and other > documents) blew up. It would be much cleaner to have type == 1 instead of type == 1 || type == 2 all over the place. The only counter I would have is DH keys with generators of 2 which aren't appropriate for El Gamal signatures. I generate DH keys not subceptible to the known attacks against El Gamal signatures (assuming I understood the paper right - and I think a few people are reviewing what I did to see if it is sufficient). If you have an old DH key, it can simply not be used if the signature would be weak (I do this too). > I believe that the "extended key structure" consists of a top-level key > which MUST be able to sign, but MAY also be able to encrypt, and a > collection of subkeys which may be of any type. The top leve key is the key > that certifications (a.k.a. key signatures) are made over, and the > top-level key also makes its own certifications which state its ownership > of the subkeys. Agreed. It helps to have one central key per identity. > Now then, it is my considered opinion that it is a bad idea to use a > top-level key for encryption. My ideal world would also have the top-level > key only used for certifying other keys, and you'd have subkeys for > document signing. But that's my opinion. I don't think it's erroneous for > an implementation to let you do that, but if I were writing an > implementation, that's what I'd implement. This is why I like Lutz's key > use subpacket. It is, though, an subject on which gentlebeings may > disagree, so I don't want to mandate things in the spec. This is good. I might want to use the top key for internal personal encryption, e.g. local files or something. I would leave the model to by default be PS(SE...,SS...) especially so that the PS would be used so that the keyservers could easily manage things. (prior Acronyms expand to Primary/Secondary Sign/Encrypt). You could override things for special usages. > Another note: A Subkey MAY??? MAY_NOT??? appear under more than one Key. > > I think that it is a Bad Idea to use a subkey in more than one extended > key. But I can think of situations where you'd want to migrate a subkey > from one extended key to another. For example, I get a new job, so I torch > all my signing keys (top-level included), and make a new extended key, > copying over all the old encryption keys. Want me to say things like this > in the security considerations section? Yes, red lights should flash if you find the same subkey under two non-revoked primary keys (and then should consult a keyserver). I would say SHOULD NOT with the note that the implementation should complain, but might want to complete the operation, since I might get your new keys before I can confirm your old primary key is invalid --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA02552 for ietf-open-pgp-bks; Fri, 3 Apr 1998 18:12:58 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id SAA02548 for ; Fri, 3 Apr 1998 18:12:56 -0800 (PST) Received: from fnord (tns40.pgp.com [161.69.9.40]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id SAA22394; Fri, 3 Apr 1998 18:10:00 -0800 (PST) Message-Id: <3.0.3.32.19980403175856.00c1bac0@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 03 Apr 1998 17:58:56 -0800 To: paulo.barreto@unitools.com.br (Paulo Barreto), ietf-open-pgp@imc.org From: Jon Callas Subject: Re: On my HAVAL implementation In-Reply-To: <3.0.3.32.19980330154137.006e3460@www.unitools.com.br> References: <351FE2DD.31DFF4F5@systemics.com> <3.0.3.32.19980330092841.006d7b5c@www.unitools.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 03:41 PM 3/30/98 -0300, Paulo Barreto wrote: 1. Though my implementation is indeed public domain, the very algorithm is *not*, as Dr. Yuliang Zheng clearly states in his HAVAL page. However, he's very liberal in conceding "licenses" (in fact, absolutely no fee is due; Dr. Zheng only wants to keep track of where HAVAL is being used). I'm a little concerned about this. It is my understanding of copyright law that one can copyright an *implementation* but not an algorithm. I wrote Dr. Zheng, and he gave me permission to put it in OpenPGP. However, I am still concerned about putting in an algorithm that someone claims "copyright" on. Furthermore, we need an OID for it. Does anyone have an opinion? Should I strike HAVAL? Should I leave it there even if it's just a placeholder for later? It's certainly nice to have extra hash algorithms, but it is by no means something we should delay over. It can always go in 1.1. Jon ----- Jon Callas jon@pgp.com CTO, Total Network Security 4200 Bohannon Drive Network Associates, Inc. Menlo Park, CA 94025 (650) 473-2860 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA01552 for ietf-open-pgp-bks; Fri, 3 Apr 1998 15:39:24 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA01548 for ; Fri, 3 Apr 1998 15:39:23 -0800 (PST) Received: from fnord (tns40.pgp.com [161.69.9.40]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id PAA21468; Fri, 3 Apr 1998 15:39:35 -0800 (PST) Message-Id: <3.0.3.32.19980403152958.00c23710@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 03 Apr 1998 15:29:58 -0800 To: nospam-seesignature@ceddec.com, ietf-open-pgp@imc.org From: Jon Callas Subject: Re: Preliminary V4 RSA key support added. But I can't test... In-Reply-To: <98Apr3.172242est.43009@brickwall.ceddec.com> References: <98Apr3.143749est.43009@brickwall.ceddec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 05:23 PM 4/3/98 -0500, nospam-seesignature@ceddec.com wrote: On Fri, 3 Apr 1998 nospam-seesignature@ceddec.com wrote: > I generated a V4 RSA key as a primary key and PGP 5.0 promptly converted > it to a V3 packet, V3 Keyid, V3 Fingerprint, etc. Since I can't export > a V4 RSA key at the moment, I don't know if I would be able to read it. I was wrong, it is a V4 packet. But it uses V3 including keyids for everything else, so I can't find the key on the keyring. I needed to compensate for the checksums unique to RSA secret MPIs. Nonetheless, this sounds like a bug in 5.0. Jon ----- Jon Callas jon@pgp.com CTO, Total Network Security 4200 Bohannon Drive Network Associates, Inc. Menlo Park, CA 94025 (650) 473-2860 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA01415 for ietf-open-pgp-bks; Fri, 3 Apr 1998 15:19:25 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA01411 for ; Fri, 3 Apr 1998 15:19:24 -0800 (PST) Received: from fnord (tns40.pgp.com [161.69.9.40]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id PAA21283 for ; Fri, 3 Apr 1998 15:19:37 -0800 (PST) Message-Id: <3.0.3.32.19980403151103.00c479c0@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 03 Apr 1998 15:11:03 -0800 To: ietf-open-pgp@imc.org From: Jon Callas Subject: Re: V4 RSA keys??? Incongruities In-Reply-To: <98Apr3.100646est.43012@brickwall.ceddec.com> References: <98Apr1.233933est.43009@brickwall.ceddec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 10:07 AM 4/3/98 -0500, nospam-seesignature@ceddec.com wrote: In the V4 section it says "With RSA keys, the MPI bit count prefix... is not encrypted...". So you are using old V3 style encryption. But you will probably be using 3DES to encrypt the secret key itself, so it would be incompatible. Why not, for V4 keys, treat RSA MPIs just like DSA or DH MPIs? We should. All public keys should be handled the same in V4 formats. I've changed that. Thanks for pointing it out. There are a number of places where the original text uses "RSA" to mean "V3." It is my intent for OpenPGP to extend V4 to all key types, even the ones that Team PGP never implemented (such as V4 RSA keys, Elgamal signing keys, etc). I've changed the text in that paragraph and the one after to reflect this. An historical note about this is that in the early days of PGP, they were very concerned about known plaintext. Consequently, a number of attempts were made to hide the structure of PGP data and encrypted data. That is the reason for the "hand-huffman-coding" and other facets like not encrypting the bit count (because that was known). By the time the V4 structures were made, there was less fear of known plaintext. I also have a problem with Key v.s. Subkey packets. I use DH keys for El Gamal signing. Do they belong in a key or subkey packet? What about an RSA key used for both? When Viacrypt wanted to make sign-only and encrypt-only keys, they added the new PKC types for those uses. There are a (small) number of those keys still hanging around. Personally, I think Lutz's new subpacket for marking key usage is a better solution for the long term, and I wouldn't mind deprecating the RSA usage types (comments?). I didn't even know they existed until some code I had written (based upon RFC1991 and other documents) blew up. I believe that the "extended key structure" consists of a top-level key which MUST be able to sign, but MAY also be able to encrypt, and a collection of subkeys which may be of any type. The top leve key is the key that certifications (a.k.a. key signatures) are made over, and the top-level key also makes its own certifications which state its ownership of the subkeys. Now then, it is my considered opinion that it is a bad idea to use a top-level key for encryption. My ideal world would also have the top-level key only used for certifying other keys, and you'd have subkeys for document signing. But that's my opinion. I don't think it's erroneous for an implementation to let you do that, but if I were writing an implementation, that's what I'd implement. This is why I like Lutz's key use subpacket. It is, though, an subject on which gentlebeings may disagree, so I don't want to mandate things in the spec. How about something like: A Key packet MUST be able to be used for signing and MUST be used to sign all subkey information. A Subkey packet MAY be used for siging. Either MAY be used for encryption if an algorithm is defined for the type. In effect, a two level hierarchy. I can use a very secure signing key for the Key Packet, but use a faster, shorter, (disposable?) signing subkey. The high security key would be used for all the UserID stuff, etc. and define the particular online persona, with the subkeys being used as desired. I don't know if this was the full intent, but if it is not signing v.s. encryption (so an RSA key would have to appear as both) this is the most obvious next choice - primary and secondary. It sounds like we're pretty much in agreement. Another note: A Subkey MAY??? MAY_NOT??? appear under more than one Key. I think that it is a Bad Idea to use a subkey in more than one extended key. But I can think of situations where you'd want to migrate a subkey from one extended key to another. For example, I get a new job, so I torch all my signing keys (top-level included), and make a new extended key, copying over all the old encryption keys. Want me to say things like this in the security considerations section? Jon ----- Jon Callas jon@pgp.com CTO, Total Network Security 4200 Bohannon Drive Network Associates, Inc. Menlo Park, CA 94025 (650) 473-2860 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id OAA00971 for ietf-open-pgp-bks; Fri, 3 Apr 1998 14:22:51 -0800 (PST) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id OAA00967 for ; Fri, 3 Apr 1998 14:22:50 -0800 (PST) Received: by brickwall.ceddec.com id <43009>; Fri, 3 Apr 1998 17:22:42 -0500 Date: Fri, 3 Apr 1998 17:23:21 -0500 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: Re: Preliminary V4 RSA key support added. But I can't test... In-Reply-To: <98Apr3.143749est.43009@brickwall.ceddec.com> Message-Id: <98Apr3.172242est.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Fri, 3 Apr 1998 nospam-seesignature@ceddec.com wrote: > I generated a V4 RSA key as a primary key and PGP 5.0 promptly converted > it to a V3 packet, V3 Keyid, V3 Fingerprint, etc. Since I can't export > a V4 RSA key at the moment, I don't know if I would be able to read it. I was wrong, it is a V4 packet. But it uses V3 including keyids for everything else, so I can't find the key on the keyring. I needed to compensate for the checksums unique to RSA secret MPIs. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA29737 for ietf-open-pgp-bks; Fri, 3 Apr 1998 11:37:59 -0800 (PST) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id LAA29733 for ; Fri, 3 Apr 1998 11:37:58 -0800 (PST) Received: by brickwall.ceddec.com id <43009>; Fri, 3 Apr 1998 14:37:49 -0500 Date: Fri, 3 Apr 1998 14:38:32 -0500 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: Preliminary V4 RSA key support added. But I can't test... In-Reply-To: <98Apr3.100646est.43012@brickwall.ceddec.com> Message-Id: <98Apr3.143749est.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Fri, 3 Apr 1998 nospam-seesignature@ceddec.com wrote: > Why not, for V4 keys, treat RSA MPIs just like DSA or DH MPIs? That is, encrypt the MPI whole and not do any resets. In this case encrypt all 4 MPIs in a stream starting with the first bitcount octet. And while I am here, you are storing U (which is iqmp in SSLeay) as part of the RSA secret key. Might I suggest (given the rest of the incompatibilites already there) that we also include dmp1 and dmq1? And place those just above U? I calculate them, but I could calculate U. (see my getkey2.c and rsa.h from SSLeay, and the SSLeay docs about what these are used for - it works with just N,E, and D, but is much faster with the rest of these params). > I also have a problem with Key v.s. Subkey packets. I use DH keys for El > Gamal signing. Do they belong in a key or subkey packet? What about an > RSA key used for both? I generated a V4 RSA key as a primary key and PGP 5.0 promptly converted it to a V3 packet, V3 Keyid, V3 Fingerprint, etc. Since I can't export a V4 RSA key at the moment, I don't know if I would be able to read it. I am going to have to rework my interface, currently I have it if the DSA and DH pointers are identical, then it points to a RSA structure. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id HAA27845 for ietf-open-pgp-bks; Fri, 3 Apr 1998 07:33:01 -0800 (PST) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id HAA27841 for ; Fri, 3 Apr 1998 07:33:00 -0800 (PST) Received: by brickwall.ceddec.com id <43010>; Fri, 3 Apr 1998 10:32:54 -0500 Date: Fri, 3 Apr 1998 10:33:38 -0500 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: RSA Key spec question In-Reply-To: <98Apr3.100646est.43012@brickwall.ceddec.com> Message-Id: <98Apr3.103254est.43010@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk E is 17 in pgp, but often 3 or 65567 elsewhere. I know why 2**N+1, but is there anything that should be said about this in the spec? (Testing 2.6.2 v.s. SSLeay from long ago proved that any value of E worked in either; But only some could be generated, or would be by default). --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id HAA27647 for ietf-open-pgp-bks; Fri, 3 Apr 1998 07:07:01 -0800 (PST) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id HAA27643 for ; Fri, 3 Apr 1998 07:06:59 -0800 (PST) Received: by brickwall.ceddec.com id <43012>; Fri, 3 Apr 1998 10:06:46 -0500 Date: Fri, 3 Apr 1998 10:07:31 -0500 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: V4 RSA keys??? Incongruities In-Reply-To: <98Apr1.233933est.43009@brickwall.ceddec.com> Message-Id: <98Apr3.100646est.43012@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Wed, 1 Apr 1998 nospam-seesignature@ceddec.com wrote: > Also some note that V4 RSA key ids are valid and different from V3. > i.e. Same Key, different ID. > > Right now, I have RSA as V3, and DH/DSS as V4. It is one of the remaining > things I should do is add RSA to V4 and relegate the V3 to my pgp 2.6.2 > subset. Having started the implementation, there are a few problems. In the V4 section it says "With RSA keys, the MPI bit count prefix... is not encrypted...". So you are using old V3 style encryption. But you will probably be using 3DES to encrypt the secret key itself, so it would be incompatible. Why not, for V4 keys, treat RSA MPIs just like DSA or DH MPIs? I also have a problem with Key v.s. Subkey packets. I use DH keys for El Gamal signing. Do they belong in a key or subkey packet? What about an RSA key used for both? How about something like: A Key packet MUST be able to be used for signing and MUST be used to sign all subkey information. A Subkey packet MAY be used for siging. Either MAY be used for encryption if an algorithm is defined for the type. In effect, a two level hierarchy. I can use a very secure signing key for the Key Packet, but use a faster, shorter, (disposable?) signing subkey. The high security key would be used for all the UserID stuff, etc. and define the particular online persona, with the subkeys being used as desired. I don't know if this was the full intent, but if it is not signing v.s. encryption (so an RSA key would have to appear as both) this is the most obvious next choice - primary and secondary. Another note: A Subkey MAY??? MAY_NOT??? appear under more than one Key. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA07982 for ietf-open-pgp-bks; Thu, 2 Apr 1998 13:02:10 -0800 (PST) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id NAA07978 for ; Thu, 2 Apr 1998 13:02:09 -0800 (PST) Received: by brickwall.ceddec.com id <43010>; Thu, 2 Apr 1998 16:01:48 -0500 Date: Thu, 2 Apr 1998 16:02:36 -0500 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars To: Jim Gillogly cc: ietf-open-pgp@imc.org Subject: Re: Wordsmithing in 3.6.3.3 In-Reply-To: <3523E723.1DBF666C@acm.org> Message-Id: <98Apr2.160148est.43010@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Thu, 2 Apr 1998, Jim Gillogly wrote: > I'm probably unusually thick, but I found the wording of 3.6.3.3 > difficult. Despite words to the contrary, it took me a while to > get away from the idea that it was being run through multiple > hashes -- I've been looking at too many HMACs lately -- rather > than simply being duplicate data sent into the same hash. The > current second paragraph is: > ------------------------------------------------------------------- > Initially, one or more hash contexts are set up as with the other S2K > algorithms, depending on how many octets of key data are needed. Then > the salt, followed by the passphrase data is repeatedly hashed until > the number of octets specified by the octet count has been hashed. The > one exception is that if the octet count is less than the size of the > salt plus passphrase, the full salt plus passphrase will be hashed even > though that is greater than the octet count. After the hashing is done > the data is unloaded from the hash context(s) as with the other S2K > algorithms. > ------------------------------------------------------------------- > Would it be too redundant to add a little more to it, like this? > ------------------------------------------------------------------- > Initially, one or more hash contexts are set up as with the other S2K > algorithms, depending on how many octets of key data are needed. Then > the > salt, followed by the passphrase data is repeatedly hashed until the > number of octets specified by the octet count has been hashed. That is, > each hash context is fed the initial zero-valued octets (if any), the > salt, the passphrase, the salt again, the passphrase again, and so on > until the specified octet count has been hashed, not counting the > initializing zero-valued octets. The one exception is that if the octet > count is less than the size of the salt plus passphrase, the full salt > plus passphrase will be hashed even though that is greater than the > octet > count. > > After the hashing is done the data is unloaded from the hash context(s) > as with the other S2K algorithms. > ---------------------------------------------------------------------- Or (since I do them serially), The number of octets of key material is determined by the conventional algorithm. If the hash result is larger than the number needed, the first octets are used. If more octets are required, the hash is repeated but is started by hashing zero octets, one for each extra pass, before hashing the key material, i.e for hash pass N, N-1 zero octets are hashed first. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id LAA07359 for ietf-open-pgp-bks; Thu, 2 Apr 1998 11:23:49 -0800 (PST) Received: from mentat.com (mentat.com [192.88.122.129]) by mail.proper.com (8.8.8/8.7.3) with SMTP id LAA07355 for ; Thu, 2 Apr 1998 11:23:47 -0800 (PST) Received: from zendia.mentat.com by mentat.com (4.1/SMI-4.1) id AA20174; Thu, 2 Apr 98 11:20:20 PST Received: from acm.org by zendia.mentat.com (SMI-8.6/SMI-SVR4) id LAA01703; Thu, 2 Apr 1998 11:29:40 -0800 Message-Id: <3523E723.1DBF666C@acm.org> Date: Thu, 02 Apr 1998 11:29:39 -0800 From: Jim Gillogly Organization: Banzai Institute X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 5.5.1 i86pc) Mime-Version: 1.0 To: ietf-open-pgp@imc.org Subject: Wordsmithing in 3.6.3.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I'm probably unusually thick, but I found the wording of 3.6.3.3 difficult. Despite words to the contrary, it took me a while to get away from the idea that it was being run through multiple hashes -- I've been looking at too many HMACs lately -- rather than simply being duplicate data sent into the same hash. The current second paragraph is: ------------------------------------------------------------------- Initially, one or more hash contexts are set up as with the other S2K algorithms, depending on how many octets of key data are needed. Then the salt, followed by the passphrase data is repeatedly hashed until the number of octets specified by the octet count has been hashed. The one exception is that if the octet count is less than the size of the salt plus passphrase, the full salt plus passphrase will be hashed even though that is greater than the octet count. After the hashing is done the data is unloaded from the hash context(s) as with the other S2K algorithms. ------------------------------------------------------------------- Would it be too redundant to add a little more to it, like this? ------------------------------------------------------------------- Initially, one or more hash contexts are set up as with the other S2K algorithms, depending on how many octets of key data are needed. Then the salt, followed by the passphrase data is repeatedly hashed until the number of octets specified by the octet count has been hashed. That is, each hash context is fed the initial zero-valued octets (if any), the salt, the passphrase, the salt again, the passphrase again, and so on until the specified octet count has been hashed, not counting the initializing zero-valued octets. The one exception is that if the octet count is less than the size of the salt plus passphrase, the full salt plus passphrase will be hashed even though that is greater than the octet count. After the hashing is done the data is unloaded from the hash context(s) as with the other S2K algorithms. ---------------------------------------------------------------------- -- Jim Gillogly Trewesday, 11 Astron S.R. 1998, 19:21 12.19.5.1.1, 7 Imix 19 Cumku, Third Lord of Night Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id VAA14751 for ietf-open-pgp-bks; Wed, 1 Apr 1998 21:30:51 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id VAA14747 for ; Wed, 1 Apr 1998 21:30:50 -0800 (PST) Received: from s20.term1.sb.rain.org (s08.term1.sb.rain.org [198.68.144.138]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id VAA20710; Wed, 1 Apr 1998 21:30:59 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id VAA00255; Wed, 1 Apr 1998 21:31:30 -0800 Date: Wed, 1 Apr 1998 21:31:30 -0800 From: Hal Finney Message-Id: <199804020531.VAA00255@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org, jim@acm.org Subject: Re: Key IDs Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jim Gillogly, , writes: > - 5.5.2 alludes to the 0xDEADBEEF problem with respect to v3 keys. > Geoff Keating posted a message Monday in > comp.security.pgp.tech entitled "Two different DSA keys with > identical key IDs", but I haven't been able to confirm them: > pgpk -a goes haring off to the Netherlands to try to install > them (I didn't realize PGP had a browser built in!). Doing the > fingerprinting "by hand" results in different IDs than the ones > shown in his message -- at least for me. If somebody else can > confirm his result, the v4 key explanation might need to include > a similar caveat. I have confirmed that the two keys he showed do in fact generate matching 64-bit keyids. The 64 bit keyid of a DSA key is simply the rightmost 64 bits of the fingerprint, which is the SHA-1 hash of the key. Generating two keys with matching keyids is then a matter of finding a 64 bit hash collision. This requires approximately 2^32 keys to be generated. You can generate multiple DSA keys quickly if they all share the same p, q and g values. You pick a random x and calculate the public value from y = g^x mod p. Then you hash p, q, g and y to form the fingerprint. Artificially generating two keys with matching keyids is therefore relatively easy. It is much more difficult to generate a key which matches the keyid of a given key, which was the original so-called "0xDEADBEEF attack" that Jim mentions, and which the spec alludes to in section 5.5.2. That would require generating approximately 2^64 keys, which would be a huge effort. Hal Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id UAA14511 for ietf-open-pgp-bks; Wed, 1 Apr 1998 20:39:49 -0800 (PST) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id UAA14507 for ; Wed, 1 Apr 1998 20:39:48 -0800 (PST) Received: by brickwall.ceddec.com id <43009>; Wed, 1 Apr 1998 23:39:33 -0500 Date: Wed, 1 Apr 1998 23:40:16 -0500 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: Re: Key IDs In-Reply-To: <35230A43.8B8F855E@acm.org> Message-Id: <98Apr1.233933est.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Wed, 1 Apr 1998, Jim Gillogly wrote: > Jon announced at IETF that he's about ready to go to a penultimate > call on op-fmts.txt, so I'd better get a few suggestions into the > hopper. > > Here's a cluster of Key ID comments and questions. > > - v3 Key ID and Fingerprint are handled in 5.5.2 > v4 Key ID and Fingerprint are handled in 11.2 > I suggest they ought to be discussed in the same place, or that > the v3 and v4 discussions be more parallel. I understand that the > current structure is the result of handling it from a historical > or archaeological viewpoint, but I think a functional breakdown > makes more sense. At least a pointer in 5.5.2 to 11.2. Also some note that V4 RSA key ids are valid and different from V3. i.e. Same Key, different ID. Right now, I have RSA as V3, and DH/DSS as V4. It is one of the remaining things I should do is add RSA to V4 and relegate the V3 to my pgp 2.6.2 subset. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id TAA14139 for ietf-open-pgp-bks; Wed, 1 Apr 1998 19:46:25 -0800 (PST) Received: from scryer.mentat.com ([192.88.122.130]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id TAA14134 for ; Wed, 1 Apr 1998 19:46:20 -0800 (PST) Received: from acm.org (jim@localhost [127.0.0.1]) by scryer.mentat.com (8.8.6/8.8.6) with ESMTP id TAA00334; Wed, 1 Apr 1998 19:47:16 -0800 Message-ID: <35230A43.8B8F855E@acm.org> Date: Wed, 01 Apr 1998 19:47:15 -0800 From: Jim Gillogly Organization: Banzai Institute X-Mailer: Mozilla 4.03 [en] (X11; U; Linux 2.0.32 i586) MIME-Version: 1.0 To: ietf-open-pgp@imc.org Subject: Key IDs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jon announced at IETF that he's about ready to go to a penultimate call on op-fmts.txt, so I'd better get a few suggestions into the hopper. Here's a cluster of Key ID comments and questions. - v3 Key ID and Fingerprint are handled in 5.5.2 v4 Key ID and Fingerprint are handled in 11.2 I suggest they ought to be discussed in the same place, or that the v3 and v4 discussions be more parallel. I understand that the current structure is the result of handling it from a historical or archaeological viewpoint, but I think a functional breakdown makes more sense. - 11.2 says a Key ID may be 32 or 64 bits, but doesn't say when each is meaningful. From a formats point of view I think we always use 64 bits for the Key ID, and truncating it for display to 32 bits is a user interface issue, so we may as well say flat out that it's a 64 bit quantity. - 5.5.2 alludes to the 0xDEADBEEF problem with respect to v3 keys. Geoff Keating posted a message Monday in comp.security.pgp.tech entitled "Two different DSA keys with identical key IDs", but I haven't been able to confirm them: pgpk -a goes haring off to the Netherlands to try to install them (I didn't realize PGP had a browser built in!). Doing the fingerprinting "by hand" results in different IDs than the ones shown in his message -- at least for me. If somebody else can confirm his result, the v4 key explanation might need to include a similar caveat. Also, this discussion seems awkward. I suggest replacing Since the release of V3 keys, there have been a number of improvements desired in the key format. For example, if the key ID is a function of the public modulus, it is easy for a person to create a key that has the same key ID as some existing key. Similarly, MD5 is no longer the preferred hash algorithm, and not hashing the length of an MPI with its body increases the chances of a fingerprint collision. with something along the lines of V3 keys SHOULD be used only for backward compatibility because of three weaknesses. First, they are subject to a Key ID spoofing attack: a key can easily be constructed with an ID matching the ID of any target key. Second, the fingerprint of a key may often be made to match the fingerprint of a target key by taking advantage of the fact that MPI lengths are not included in the hash. Finally, the MD5 algorithm used in V3 keys has begun to come under mild suspicion. - Should we offer any more specific advice than in 3.3 about when an implementation SHOULD NOT assume the Key ID is unique? Like "if the signature doesn't match, see if you have another such Key ID"? Or is even the mention in 3.3 beyond the scope of a formats document? -- Jim Gillogly Trewesday, 11 Astron S.R. 1998, 01:25 12.19.5.1.0, 6 Ahau 18 Cumku, Second Lord of Night Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id SAA13628 for ietf-open-pgp-bks; Wed, 1 Apr 1998 18:01:53 -0800 (PST) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id SAA13624 for ; Wed, 1 Apr 1998 18:01:52 -0800 (PST) Received: by brickwall.ceddec.com id <43010>; Wed, 1 Apr 1998 21:01:37 -0500 Date: Wed, 1 Apr 1998 20:55:39 -0500 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars To: Jon Callas cc: ietf-open-pgp@imc.org Subject: Re: Status from the Working Group Meeting In-Reply-To: Message-Id: <98Apr1.210137est.43010@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Wed, 1 Apr 1998, Jon Callas wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHAme On You Well, I just completed an SSL layer for Mozilla 5.0b1, so I should have time to implement any of the things on your list. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA13213 for ietf-open-pgp-bks; Wed, 1 Apr 1998 16:38:23 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA13209 for ; Wed, 1 Apr 1998 16:38:22 -0800 (PST) Received: from [198.94.11.139] (ietf-11-62.mtg.ietf.org [198.94.11.62]) by fusebox.pgp.com (8.8.7/8.8.7) with ESMTP id QAA28430; Wed, 1 Apr 1998 16:38:21 -0800 (PST) X-Sender: jon@mail.pgp.com Message-Id: Mime-Version: 1.0 Date: Wed, 1 Apr 1998 16:37:14 -0800 To: ietf-open-pgp@imc.org From: Jon Callas Subject: Status from the Working Group Meeting Cc: Jon Callas Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Today at the OpenPGP meeting, I announced some new features for OpenPGP. The attendees thought that I should send them to the list, stressing that it was vital they get sent today, even before the minutes get posted to the list. The first new feature is a new type of signature, "Message Validity Signatures." These new signatures are a mechanism that contains information that allows a user to determine whether a message is true. This new technology has a number of uses, particularly with electronic commerce and digital contracts. They also employ an extension to the PGP Web of Trust called the Web of Contempt. The Web of Contempt is a cumulative system that uses aggregate information from a family of users. It mirrors the Web of Trust and has in it user-customizable settings for Partially Contemptible Keys, Completely Contemptible Keys, and Axiomatically Contemptible Keys. The last ones are the root keys from which the PGP contempt model extends contempt. This new mechanism is especially useful for diplomacy and other systems that require plausible deniability, withering remarks, faint praise, or backhand compliments. A new type of signature, the "Anti-Identity Signature" allows a user to declare that they do not have a given identity. For example, a user can declare that he or she is not Bill Clinton. It also allows a user to declare that someone else does not have a certain identity, perhaps attesting that someone else is not Bill Clinton. Lastly, when used in combination with the Web of Contempt, a group of users can combine their digital signatures to invalidate the identity of another certificate. This is especially useful for fighting the widespread crime of identity theft, by revoking the stolen identity. It also works in situations where you want to keep a person around, but want someone else to fulfill that role. This new signature type can also solve the Internet problem of email spam by letting users revoke the identity of spammers. Bit-Sorted Escrow is a technique that satisfies the concerns that law enforcement agencies have about cryptography, while preserving the privacy needed for electronic commerce. In Bit-Sorted Escrow, the user can reserve 40 (which do not have to be contiguous) bits of a key to remain secret, and the other remaining bits are sorted (big-endian, zeroes to the MSB), and then sent to the Bit-Sorted Escrow Server run by the United States Department of Justice at . This has the advantage of providing strong cryptography for honest users while giving the government the access to message content that it deserves. Many organizations need to test the implementations of their public key infrastructure, especially when rapidly deploying new systems such as the Web of Contempt to a large introduction. PGP 6.6.6 implements a new solution to this problem, called the Beta-Introducer. A Beta-Introducer allows an organization to test out their infrastructure, while not actually granting undue trust or contempt to their members. We are also going to start working on some new RFCs for two new servers and some more infrastructure. The first new server is the "Passphrase Recovery Server." The largest obstacle to deploying strong crypto is that people keep forgetting their passphrases. Even people at the IETF from time to time have to tell someone not to use a key because they have lost their passphrase. A Passphrase Recovery Server lets a user who has lost their passphrase get a new one. The second sever is the "Key Generation Server." Many, many organizations have people who are (as Mel Brooks put it) "the salt of the earth." These people are incapable of generating their own keys, so they can get them from the server. Interestingly, the combination of these is quite powerful. People who lose their passphrases some number of times can be given a new key from the key generation server (or perhaps one that's specified in the RFC), and have their settings appropriately modified in the Web of Contempt. The last new RFC is for a generalized Emotion-Model System. Having already two emotions, trust and contempt, we should define the general case. It can work with a web of affection (useful for computer dating services), a web of benevolence (for charitable organizations), or even a web of lust (useful for the Executive Branch). As time permits, we will do more work on these new systems. I'd like it if this time next year, there were some drafts that could be sent to the working group. If anyone wants to work on these drafts, let me know, especially if they have any ideas for new things to suggest then. Jon - ----- Jon Callas jon@pgp.com CTO, Total Network Security 4200 Bohannon Drive Network Associates, Inc. Menlo Park, CA 94025 (650) 473-2860 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.5.3 iQA/AwUBNSLeCn35wubxKSepEQKaKwCgufz++aaCjQohNbNswyMn8gaRW6sAnj3h b5vxMESMnMs/Q4hY7dt9Y9vp =hp0w -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA11598 for ietf-open-pgp-bks; Wed, 1 Apr 1998 12:11:13 -0800 (PST) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA11594 for ; Wed, 1 Apr 1998 12:11:11 -0800 (PST) Received: by brickwall.ceddec.com id <43009>; Wed, 1 Apr 1998 15:10:46 -0500 Date: Wed, 1 Apr 1998 15:11:31 -0500 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars To: ietf-open-pgp@imc.org cc: Jon Callas Subject: Re: Obvious (?) question about interoperability In-Reply-To: <98Apr1.120743est.43009@brickwall.ceddec.com> Message-Id: <98Apr1.151046est.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > > There has been a suggestion for a new-format length that would use the > > length byte of 0xFF (which would ordinarily be a stream-chunk of 2GB) as a > > marker for a four-octet length that follows. So you would see: > > > > <0xFF> > > > > as a packet form. That lets someone bring in the whole packet without the > > streaming mechanism. People sounded supportive of that, and my slides for > > tomorrow have that on there as a feature I want to have in the next draft. The above is implicitly a terminal packet-length ... > I want a rule that if the content of a packet is less than the maximum > terminal packet size (8192+192? bytes), then it MUST NOT be split up. With the new packet type above, you can also require that things like keys, signatures, etc. be monolithic even if they are larger than the largest terminal length packet. They either use a terminal small packet length or the 0xff-4-octet form. So I vote for the new packet length type *and* forcing certain packets to be monolithic. Otherwise someone will use incremental lengths for each unit within a subpacket, e.g. for an MPI integer <0xE1> 0x00 0xA0 <0xE4>...<0xE2>... which is what I really don't want to have to handle. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id JAA10144 for ietf-open-pgp-bks; Wed, 1 Apr 1998 09:08:11 -0800 (PST) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id JAA10140 for ; Wed, 1 Apr 1998 09:08:10 -0800 (PST) Received: by brickwall.ceddec.com id <43009>; Wed, 1 Apr 1998 12:07:43 -0500 Date: Wed, 1 Apr 1998 12:08:34 -0500 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars To: Jon Callas cc: ietf-open-pgp@imc.org Subject: Re: Obvious (?) question about interoperability In-Reply-To: Message-Id: <98Apr1.120743est.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Wed, 1 Apr 1998, Jon Callas wrote: > At 6:11 PM -0800 3/31/98, nospam-seesignature@ceddec.com wrote: > > Generally PGP 5.0 will interoperate, except any secret keyrings won't be > decryptable in OpenPGP (because of the loss of type 3 Iterated S2K being > replaced by type 4). It will also cause problems for conventionally > encrypted packets. > > We're going back to the type 3 iterated-salted s2ks. Simplicity is a > virtue, but not when it makes things harder. So I can rip out type 4 (which I haven't tested). Good. Easy != Simple > The charter calls for "limited" backwards compatibility. I think for your > purposes it depends on how much you want to do. Our predecessor, RFC 1991, > recommended backwards compatibility to one previous version. That would > mean you could ignore 2.6. That wouldn't particularly nice, though. There > are a number of things you can do that are easy to make things work with > 2.6. Actually I have code to allow the 2.6 code to handle 2.1 (or whatever the pre PKCS padding PGP2 was and it may still be in the minipgp README). > I am planning on putting in the algorithm notes that a V3 key with a V3 > self signature MAY be considered to have an implicit preference for IDEA > alone. This would mean that a considerate OpenPGP implementation can freely > interoperate with 2.6, but a minimal one doesn't have to. > > For you, do as much as you want above what is required. If you want your > implementation to be widely used and interoperable with old versions, you > can do a lot. Otherwise, you can leave the annoying stuff to someone else. Actually I just updated my 2.6.2 libraries and am retaining them as separate routines since they are fairly short. It would make a -V3-compatible flag much easier than trying to fiddle with each bit. > ------------------ > > Another problem I have is with the new CTB, at least for intrinsically > short packets like keys, signatures, P/SKESK headers, etc. > If these are normalized (Monolithic if overall length is <4096 bytes), I > can use ordinary libc calls (fread, fwrite). Otherwise I need a > normalization pass. I think implementations SHOULD store anything except > compressed, literal, or conventionally encrypted packets in normalized > form. Further, the conventionally encrypted packets should not divide the > first 10 bytes (actually 11) of the stream. > > There has been a suggestion for a new-format length that would use the > length byte of 0xFF (which would ordinarily be a stream-chunk of 2GB) as a > marker for a four-octet length that follows. So you would see: > > <0xFF> > > as a packet form. That lets someone bring in the whole packet without the > streaming mechanism. People sounded supportive of that, and my slides for > tomorrow have that on there as a feature I want to have in the next draft. NO! NO! NO! IT DOESN'T - I will still have to support the V3, the degenerate packet length <0xe0>f<0xe0>o<0xe0>r<0xe0>m<0xe0>a<0xe0>t<0x01>s, and this new one. I can't magically force all messages sent to me to use this new format. Actually, I don't object to the new packet above, at least not until I think about it. Remember that ADDING anything for one implementation will require all other implementations to support it or not be able to read it. What I object to is what I did with the <0x07>formats string above. Perfectly valid. Pefectly horrid. I want a rule that if the content of a packet is less than the maximum terminal packet size (8192+192? bytes), then it MUST NOT be split up. Barring that (for small memory or something), that the first partial-packet-length must encompass any header information and at least one byte of data (i.e. the 10 byte startup encryption packet, or the entire literal header for literal packets). That way I can use fread instead of another layer to extract the data from the packet-length bytes. --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id IAA09978 for ietf-open-pgp-bks; Wed, 1 Apr 1998 08:47:08 -0800 (PST) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id IAA09974 for ; Wed, 1 Apr 1998 08:47:07 -0800 (PST) Received: by brickwall.ceddec.com id <43009>; Wed, 1 Apr 1998 11:46:44 -0500 Date: Wed, 1 Apr 1998 11:47:29 -0500 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars To: Hal Finney cc: ietf-open-pgp@imc.org Subject: Re: Why one pass sigs? In-Reply-To: <199804010523.VAA02250@s20.term1.sb.rain.org> Message-Id: <98Apr1.114644est.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Wed, 1 Apr 1998, Hal Finney wrote: > The purpose of the 1-pass signature packets is not primarily to provide > multiple signature capability. The main purpose is to allow the signer > to process the entire message in one pass. The rest of the message is technical commentary, sort of Oh, yea - it would have to be done this way. The SIGNER needs the one pass format to do signatures in one pass. > With old-style signatures, the signature has to go at the front of > the message. But the signer can't create the signature until he has > processed the whole message. So he then has to go back and stick the > signature back at the front of the message, which requires some buffering > and re-scanning of the data. It requires two read passes. The first doesn't write, but only formats and hashes. Then the sig would be written out. Then a second read would write out the real (e.g. literal encasulated) data. But you are right, you could not handle a stream this way. Unless you had a filesystem that allowed for insertion at the head as well as the tail. > With the 1-pass signature, the signer puts the 1-pass packet at the > front to tell the verifier what hash to use, then comes the message, > and then comes the signature. This is a much more natural flow for all > parties. Except that the validity data comes later (which would be known), so you do all the work and find the signature is expired or something else is wrong. You could also have split the signature packet, with everything up to the 2 hash verification bytes and the MPI integers appearing afterword. This would leave one format and thus one mode and parser. > PGP 2.X creates many temp files to deal with the buffering needed by the > signature structure, and the need to know all packet lengths in advance. > The one-pass signature packets and partial packet length specifiers are > designed to allow processing messages without any temporary files, which > enhances security and performance. Security, maybe. If you implement a loop that can pass data between each layer: in->dearmor->decrypt->decompress->deliteral->out something like: ret=fread(BUFSIZ); ret=dearmor_update(ret); ret=decrypt_update(ret) ... with the potential for missing layers, etc. This is not something that would help performance (since you have to call the update lots of times instead of one call to a sub with an internal loop). You could use huge buffers, and comression would still require realloc, but that is a memory usage for CPU tradeoff. If you use threads with pipes or other OS structures, then those become an attack point as much as temp files. Even if you use huge buffers, the OS will probably respond by swapping out your passphrase, so you have a virtual temp file. For *verification*, you merely need to retain the original signature packet until the end, so it is a few K. For pure signing, the file must already exist as plaintext to be read in (so there is no added security in not reading it a second time, but there is added performance), and then the signature packet can be written out (like a detached signature, and then optionally append the plaintext). --- reply to tzeruch - at - ceddec - dot - com --- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id HAA09510 for ietf-open-pgp-bks; Wed, 1 Apr 1998 07:55:35 -0800 (PST) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id HAA09506 for ; Wed, 1 Apr 1998 07:55:34 -0800 (PST) Received: by brickwall.ceddec.com id <43009>; Wed, 1 Apr 1998 10:55:09 -0500 Date: Wed, 1 Apr 1998 10:55:58 -0500 From: nospam-seesignature@ceddec.com X-Sender: nobody@mars To: Hal Finney cc: ietf-open-pgp@imc.org Subject: Re: Obvious (?) question about interoperability In-Reply-To: <199804010516.VAA02240@s20.term1.sb.rain.org> Message-Id: <98Apr1.105509est.43009@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Wed, 1 Apr 1998, Hal Finney wrote: > > can use ordinary libc calls (fread, fwrite). Otherwise I need a > > normalization pass. I think implementations SHOULD store anything except > > compressed, literal, or conventionally encrypted packets in normalized > > form. Further, the conventionally encrypted packets should not divide the > > first 10 bytes (actually 11) of the stream. > > By "normalization" do you mean the problem of assembling packets which use > partial-length fields? If so, it was for this reason that I recommended > adopting a four-byte length field option. I understand this will be > discussed at the OpenPGP meeting tomorrow. Exactly, but it doesn't matter the length field. As long as you can have a valid message of <0xe0>t<0xe0>h<0xe0>i<0x01>s form, evil things happen to the code. It is easy to detect, since if the first partial length field is for <4096 I can call a normalizer which would collapse the above to <0x04>this. > > I would make all of these MUSTs, but embedded applications may have > > reasons not to, and I can normalize the stream myself. > > What exactly would you make MUSTs? Do you mean you would disallow the > partial-length packets? Disallow the partial length packets EXCEPT in literal, compressed, and symmetrically encrypted packets (though if any of the other could exceed the 8192+192 byte limit I would allow this; I could contrive an exaple but I don't know if one would exist in the real world since such things might break other static limits - huge MPIs, excessive hashed subpackets, etc.). Do not allow the partial length packet to subdivide a literal header or the first 11 bytes of an encrypted packet (I would say 10 bytes, but this way I can be sure of one byte to decipher which makes the decryption loop much nicer, and the partial length would be 16 if it met this). > > Since I introduced the term normalized, I should define it - > > > > packet :- oldCTB-len, datachunk... | newCTB len-stream > > > > len-stream :- nontermlen, datachunk, len-stream | termlen, datachunk > > > > The len-stream is normal if it does not contain any nontermlen entries > > indicating the following datachunk is less than 4096 bytes. > > I don't understand the significance of this definition. What is it about > normal vs non-normal streams which requires them to be treated differently? > I could see a distinction between packets which have the length at the > beginning vs packets whose length is not known until you have read the > whole thing. But I don't understand why the issue is whether the > partial length packets are less than 4096 bytes. For things like [PS]KESKs, signature packets, key material, they are normally all under 4096 bytes. They SHOULD all be under the 8192+ size of the largest terminal packet length. This allows express handling: Normal stream: get packet length of L /* you can allocate an L byte buffer */ fread(buf,1,L,fp); /* process buf */ Unnormal stream: /* make buf *big*, or do a lot of reallocs */ bufp = buf; get length packet L while( partial ) fread(bufp,1,L,fp); bufp += L; get length packet L fread(bufp,1,L,fp); /* process buf */ Or: Len = pgpfread(buf,1,BUFMAX,fp); /* containing the above */ My 5.X implementation handles things by reading the whole thing in (if there is a sane upper limit on the size), and then processing by moving a buffer pointer. If you do a series of pgpfread(..) for every subpacket or atomic data type, it changes things (and I think this is how PGP5.0 does it), But one problem with this is that you need state information as to how much data is left before the next expected packet-length, i.e. Sub: I want 10 bytes pgpfread: I have 5 bytes buffered, send them, read next packet length, oh, it is 0xef, malloc 2147483648 bytes :), read them, return 5 more, remembering that we have 2147483643 left. Or: pgpfread: 0xef, read BUFMAX (4096) bytes, and note there are 2**31-4096 bytes left until the next ctb, send the 5 and note there are 4091 bytes left in the buffer. pgpfread now has lots of states and if tests to determine how to respond. This is ugly. Really ugly. I need to do this anyway for indeterminate length types (SymEncPkt, Compressed, Literal), but having to handle it withing subfields within the header is painful. But I can then inline the state info with the read-decrypt (see my implementation). --- reply to tzeruch - at - ceddec - dot - com ---