From owner-ietf-openpgp@mail.imc.org Wed Mar 01 09:29:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FESKz-00052J-U5 for openpgp-archive@lists.ietf.org; Wed, 01 Mar 2006 09:29:57 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FESKw-00085O-Hd for openpgp-archive@lists.ietf.org; Wed, 01 Mar 2006 09:29:57 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k21DlTr8076821; Wed, 1 Mar 2006 06:47:29 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k21DlTpE076820; Wed, 1 Mar 2006 06:47:29 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k21DlSTM076814 for ; Wed, 1 Mar 2006 06:47:29 -0700 (MST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id AA0EB33C3F for ; Wed, 1 Mar 2006 13:47:27 +0000 (GMT) Message-ID: <4405A5F4.5000108@algroup.co.uk> Date: Wed, 01 Mar 2006 13:47:32 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: OpenPGP Subject: Utterly Confused by Resync X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a I just implemented the Symmetrically Encrypted Data packet. It also does a "resync" after the first blocksize+2 bytes. However, I find that, unlike the MPI resync for v3 keys, as well as wiggling around the IV I have to encrypt it. That is, the resync operation for MPI looks like this: 1. Set the IV to the last blocksize bytes of ciphertext 2. Set the offset within the IV to zero. Whereas for the Symmetrically Encrypted Data resync looks like: 1. Set the IV to the last blocksize bytes of ciphertext 2. Encrypt the IV 3. Set the offset within the IV to zero. Can this possibly be right? Does the spec explain this at all? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-ietf-openpgp@mail.imc.org Wed Mar 01 13:05:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEVhR-0005nO-OT for openpgp-archive@lists.ietf.org; Wed, 01 Mar 2006 13:05:21 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEVhQ-0000Lr-Cu for openpgp-archive@lists.ietf.org; Wed, 01 Mar 2006 13:05:21 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k21HUOaQ062287; Wed, 1 Mar 2006 10:30:24 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k21HUO4e062286; Wed, 1 Mar 2006 10:30:24 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k21HUMdQ062248 for ; Wed, 1 Mar 2006 10:30:23 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id D665657FAF; Wed, 1 Mar 2006 09:35:27 -0800 (PST) To: ben@algroup.co.uk, ietf-openpgp@imc.org Subject: Re: Utterly Confused by Resync Message-Id: <20060301173527.D665657FAF@finney.org> Date: Wed, 1 Mar 2006 09:35:27 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Ben Laurie writes: > I just implemented the Symmetrically Encrypted Data packet. > > It also does a "resync" after the first blocksize+2 bytes. However, I > find that, unlike the MPI resync for v3 keys, as well as wiggling around > the IV I have to encrypt it. > > That is, the resync operation for MPI looks like this: > > 1. Set the IV to the last blocksize bytes of ciphertext > 2. Set the offset within the IV to zero. > > Whereas for the Symmetrically Encrypted Data resync looks like: > > 1. Set the IV to the last blocksize bytes of ciphertext > 2. Encrypt the IV > 3. Set the offset within the IV to zero. > > Can this possibly be right? Does the spec explain this at all? The resync operation is the same for encrypted data packets as for V3 keys. There is a difference between the two cases, but it doesn't involve the resync. The difference is that V3 keys use a regular IV, while encrypted data packets use an IV of 0 and then discard the first blocksize+2 bytes. But that does not affect the resync; the resync is done exactly in the same way. CFB works like this. Encrypting plaintext block N starts with the ciphertext of block N-1. Encrypt that ciphertext and then XOR the result with plaintext block N to get ciphertext block N. For the 1st block, where there is no previous ciphertext block, the IV is used. Encrypt the IV and XOR with the 1st plaintext block to get the 1st ciphertext block. The resync operation can be though of as setting the IV to the previous blocksize bytes of ciphertext, and starting this process from the beginning. Encrypt the IV, XOR with the 1st bytes of the plaintext, and you get your ciphertext. This will work for both encrypted data packets and for V3 private keys. Your description fo the data packet case says as step 2, encrypt the IV. I don't know how to interpret that. Of course you encrypt the IV, it is part of the CFB process as I just described. Is that all you mean? Or do you think you encrypt the IV twice? Is that what you are implying? That would not work. The details of encryption for data packets are described in RFC2440bis in section 12.8. It's a cumbersome and wordy description but if you read it carefully it will hopefully shed light on what you need to do. Hal Finney From owner-ietf-openpgp@mail.imc.org Thu Mar 02 07:30:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEmxD-0005IT-DV for openpgp-archive@lists.ietf.org; Thu, 02 Mar 2006 07:30:47 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEmxC-0003xv-0t for openpgp-archive@lists.ietf.org; Thu, 02 Mar 2006 07:30:47 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k22Bsjh8088326; Thu, 2 Mar 2006 04:54:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k22Bsj2s088325; Thu, 2 Mar 2006 04:54:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k22BsiRX088318 for ; Thu, 2 Mar 2006 04:54:44 -0700 (MST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id A106F33C1C; Thu, 2 Mar 2006 11:54:43 +0000 (GMT) Message-ID: <4406DD0A.4010103@algroup.co.uk> Date: Thu, 02 Mar 2006 11:54:50 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Hal Finney CC: ietf-openpgp@imc.org Subject: Re: Utterly Confused by Resync References: <20060301173527.D665657FAF@finney.org> In-Reply-To: <20060301173527.D665657FAF@finney.org> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Hal Finney wrote: > Ben Laurie writes: >> I just implemented the Symmetrically Encrypted Data packet. >> >> It also does a "resync" after the first blocksize+2 bytes. However, I >> find that, unlike the MPI resync for v3 keys, as well as wiggling around >> the IV I have to encrypt it. >> >> That is, the resync operation for MPI looks like this: >> >> 1. Set the IV to the last blocksize bytes of ciphertext >> 2. Set the offset within the IV to zero. >> >> Whereas for the Symmetrically Encrypted Data resync looks like: >> >> 1. Set the IV to the last blocksize bytes of ciphertext >> 2. Encrypt the IV >> 3. Set the offset within the IV to zero. >> >> Can this possibly be right? Does the spec explain this at all? > > The resync operation is the same for encrypted data packets as for > V3 keys. There is a difference between the two cases, but it doesn't > involve the resync. The difference is that V3 keys use a regular IV, > while encrypted data packets use an IV of 0 and then discard the first > blocksize+2 bytes. But that does not affect the resync; the resync is > done exactly in the same way. > > CFB works like this. Encrypting plaintext block N starts with the > ciphertext of block N-1. Encrypt that ciphertext and then XOR the result > with plaintext block N to get ciphertext block N. For the 1st block, > where there is no previous ciphertext block, the IV is used. Encrypt the > IV and XOR with the 1st plaintext block to get the 1st ciphertext block. > > The resync operation can be though of as setting the IV to the previous > blocksize bytes of ciphertext, and starting this process from the > beginning. Encrypt the IV, XOR with the 1st bytes of the plaintext, > and you get your ciphertext. > > This will work for both encrypted data packets and for V3 private keys. > Your description fo the data packet case says as step 2, encrypt the IV. > I don't know how to interpret that. Of course you encrypt the IV, it > is part of the CFB process as I just described. Is that all you mean? > Or do you think you encrypt the IV twice? Is that what you are implying? > That would not work. > > The details of encryption for data packets are described in RFC2440bis > in section 12.8. It's a cumbersome and wordy description but if you read > it carefully it will hopefully shed light on what you need to do. I'm hesitant to say definitively I'm right, after the previous debacle, but... my resync function does _not_ perform an encryption, all it does is wriggle around the previous and current IVs, and it works fine with V3 keys. After I have called resync for the symmetric encrypted data packet, I have to encrypt the new IV, or it doesn't work. If I add the encrypt step to the resync, it breaks V3 keys. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From richard@prostateforum.biz Mon Mar 06 19:42:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGQHr-0006Cy-3X for openpgp-archive@ietf.org; Mon, 06 Mar 2006 19:42:51 -0500 Received: from 201-43-151-40.dsl.telesp.net.br ([201.43.151.40] helo=friend) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGQHn-0000iq-1C for openpgp-archive@ietf.org; Mon, 06 Mar 2006 19:42:51 -0500 Message-ID: <000001c6417f$e11c0600$0100007f@rocha-auskdbbc0> From: "Alexander" To: Subject: All love enhancers on one portal! Date: Mon, 06 Mar 2006 21:41:32 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------ms000208030505060104090308" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.7 (+++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. --------------ms000208030505060104090308 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Cheapest medications based LICENSED online phartmacy! Cialis Soft Tabs as low as $4.72 Viagra Professional as low as $3.8 Viagra Soft Tabs as low as $3.8 Cialis as low as $5.67 Valium as low as $2.85 Generic Viagra as low as $3.5 Need medicine? All here! --------------ms000208030505060104090308 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

Cheapest medications based LICENSED online=20 phartmacy!

Cialis Soft Tabs as low as=20 $4.72

Viagra Professional as low as=20 $3.8

Viagra Soft Tabs as low as=20 $3.8

Cialis as=20 low as $5.67

Valium as low as=20 $2.85

Generic Viagra as low as = $3.5

Need medicine?=20 All=20 here!

 --------------ms000208030505060104090308-- From owner-ietf-openpgp@mail.imc.org Sat Mar 11 17:38:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FICjY-0006AA-Iz for openpgp-archive@lists.ietf.org; Sat, 11 Mar 2006 17:38:48 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FICjX-0005DY-5q for openpgp-archive@lists.ietf.org; Sat, 11 Mar 2006 17:38:48 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2BMCYVD034072; Sat, 11 Mar 2006 15:12:34 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2BMCYOR034071; Sat, 11 Mar 2006 15:12:34 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2BMCVlF034064 for ; Sat, 11 Mar 2006 15:12:32 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 2B66357FAE; Sat, 11 Mar 2006 14:18:18 -0800 (PST) To: ietf-openpgp@imc.org Subject: GnuPG does not detect injection of unsigned data Message-Id: <20060311221818.2B66357FAE@finney.org> Date: Sat, 11 Mar 2006 14:18:18 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 There has been much discussion on the net of a GnuPG bug reported by Werner Koch on Thursday: http://lists.gnupg.org/pipermail/gnupg-announce/2006q1/000216.html The problem is that a sequence of OpenPGP packets, some signed and some unsigned, was being output with the different types of data concatenated and no indication of what part was signed and what part wasn't. (This is my understanding from reading the report, apologies if I am misstating it.) Ironically I described a similar problem last month when we were talking about packet formats for exchanging public keys. I mentioned that I was not sure our PGP software would always work well with arbitrary sequences of OpenPGP packets, and that such messages raise difficult issues. Here is what I wrote on Feb 7, replying to Ben Laurie: > > Hmm. My implementation will eat _any_ sequence of packets. > > So what do you do if you decrypt a file and find a sequence of encrypted > packets? Or perhaps some packets signed, some encrypted, some both, all > concatenated? Do you concatenate the results into a single output file > (erasing the boundaries between the plaintexts, as well as information > about what was signed and what wasn't); do you concatenate them along > with some header information to identify where each piece starts and ends > (which won't be reliable due to spoofing); do you output each piece to > separate output files? Or ask the user what he wants to do? It appears that this was a case of exactly what I described as the first possibility, concatenating the results, with the problem of losing the information about what was signed and what wasn't. As usual the GnuPG guys have done a good job of publicizing this problem and quickly getting a bug fix out. It appears that the new version will only allow signed messages that have a simple format and will intentionally _not_ eat any sequence of packets. This is a good lesson for other implementors, to be aware of user information issues when dealing with complex cryptographic operations. Our OpenPGP packet format is extremely flexible, but that flexibility may not be appropriate for exposure directly to end users. Here is how I concluded my Feb 7 message: > This kind of operation introduces considerable complexity in terms of > providing a reasonable interface. We generally assume we are dealing > with a single message consisting of one or more PKESK/SKESK packets with > an encrypted packet, or a similar signed message. Once you go beyond > this and try to deal with arbitrary sequences of packets it becomes > highly problematic to make sure the user is getting the full benefit > from the cryptography. If you have a custom program which is using this > for internal, program-to-program communication, then go ahead and knock > yourself out, use the data structures as you wish. But for person to > person communication I think it is difficult and often unwise to try to > deal with arbitrary sequences. Hal Finney From owner-ietf-openpgp@mail.imc.org Tue Mar 14 11:27:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJCMx-0006Vo-GU for openpgp-archive@lists.ietf.org; Tue, 14 Mar 2006 11:27:35 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJCMw-0006Sv-4b for openpgp-archive@lists.ietf.org; Tue, 14 Mar 2006 11:27:35 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EFwv9U097067; Tue, 14 Mar 2006 08:58:57 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2EFwvUd097066; Tue, 14 Mar 2006 08:58:57 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EFwu6p097058 for ; Tue, 14 Mar 2006 08:58:57 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2EFwjk04292 for ; Tue, 14 Mar 2006 10:58:45 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id k2EFwf6c030341 for ; Tue, 14 Mar 2006 10:58:41 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2EFwdmM001159 for ; Tue, 14 Mar 2006 10:58:39 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2EFwdmJ001158 for ietf-openpgp@imc.org; Tue, 14 Mar 2006 10:58:39 -0500 Date: Tue, 14 Mar 2006 10:58:39 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: NIST publishes new DSA draft Message-ID: <20060314155839.GA1029@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 In the OpenPGP context, probably the most interesting bit is that the 160-bit hash limit has been removed. The sizes supported are: * 1024-bit key, 160-bit hash (the current DSA) * 2048-bit key, 224-bit hash (presumably aimed at SHA-224) * 2048-bit key, 256-bit hash (presumably aimed at SHA-256) * 3072-bit key, 256-bit hash (presumably aimed at SHA-256) It also adds the concept of using a larger hash than will fit by taking the leftmost bits. http://csrc.nist.gov/publications/drafts.html David From owner-ietf-openpgp@mail.imc.org Tue Mar 14 15:06:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJFms-0000Yb-PJ for openpgp-archive@lists.ietf.org; Tue, 14 Mar 2006 15:06:34 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJFms-0003tb-Cp for openpgp-archive@lists.ietf.org; Tue, 14 Mar 2006 15:06:34 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EJcuAc008404; Tue, 14 Mar 2006 12:38:56 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2EJcurl008403; Tue, 14 Mar 2006 12:38:56 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EJcpbJ008396 for ; Tue, 14 Mar 2006 12:38:54 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 4D59A57FB0; Tue, 14 Mar 2006 11:44:47 -0800 (PST) To: dshaw@jabberwocky.com, ietf-openpgp@imc.org Subject: Re: NIST publishes new DSA draft Message-Id: <20060314194447.4D59A57FB0@finney.org> Date: Tue, 14 Mar 2006 11:44:47 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c David Shaw writes: > In the OpenPGP context, probably the most interesting bit is that the > 160-bit hash limit has been removed. The sizes supported are: > > * 1024-bit key, 160-bit hash (the current DSA) > * 2048-bit key, 224-bit hash (presumably aimed at SHA-224) > * 2048-bit key, 256-bit hash (presumably aimed at SHA-256) > * 3072-bit key, 256-bit hash (presumably aimed at SHA-256) > > It also adds the concept of using a larger hash than will fit by > taking the leftmost bits. The main question is whether we want to change the current draft to make these changes. That would probably require backing it out of "last call" status. Personally I think this makes sense. There is no one waiting urgently for this draft to be finalized AFAIK. The alternative will be to immediately amend the RFC with another RFC. But for the sake of future implementors I think it would be better to wait a few months more and put it all into one draft. In two places in RFC2440-bis, we mention that DSA signatures must use a 160 bit hash. The main one is in section 5.2.2, Version 3 Signature Packet Format. This is not a good location as it is not information that is specific to V3 signature packets. It applies to V4 signatures as well. This information should probably be in 5.5.2 on public key packet formats, or at least should be repeated in 5.2.3 for V4 sigs. It is also mentioned in section 13, Security Considerations, where we state explicitly that RIPEMD-160 can be used, but that "DSS" as compared to "DSA" requires SHA-1. One of the implications of the changes in the new draft is that 1024 bit DSA keys can use SHA-256 (truncated to 160 bits). We should probably allow that as an alternative to SHA-1, although it raises backwards compatibility issues. For 2048 bit keys they allow either 224 or 256 bit hashes. This also means allowing a subgroup "q" size of either 224 or 256 bits, I think. The hash then must either match "q" or be larger, in which case it is left-truncated. We do not have an algorithm ID for SHA-224. SHA-224 is the same algorithm as SHA-256 but uses different initial values internally, and then truncates the result to 224 bits. I don't see any advantage in this case to using SHA-224 over using SHA-256 truncated to 224 bits. However we might want to add an ID for it in case an implementor wanted to follow the new DSS spec very closely. The simplest change we could make would be to allow that DSA keys can use modulus "p" and subgroup "q" values of the specified sizes, based on the table above. Hashes should be equal in size or larger than the "q" size. Hashes larger than the "q" size should be left-truncated. Then we could note that for DSS compliance the hashes must be taken from the SHA family, either SHA-1 or one of the larger SHA's. We might want to think about making SHA-256 be another MUST algorithm. The only MUST hash now is SHA-1. Making SHA-256 be a MUST would make these new key sizes be more useful, and also give us an easier fallback if SHA-1 should be broken. I also think we should change the names of SHA256 etc to use dashes as in SHA-256; those are the official names. Hal Finney From owner-ietf-openpgp@mail.imc.org Tue Mar 14 17:00:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJHZP-0002zj-K5 for openpgp-archive@lists.ietf.org; Tue, 14 Mar 2006 17:00:47 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJHZN-0007DU-Ss for openpgp-archive@lists.ietf.org; Tue, 14 Mar 2006 17:00:47 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2ELVNUg013856; Tue, 14 Mar 2006 14:31:23 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2ELVNNs013855; Tue, 14 Mar 2006 14:31:23 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sarge.electric.net (sarge.electric.net [216.129.90.31]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2ELVN4w013849 for ; Tue, 14 Mar 2006 14:31:23 -0700 (MST) (envelope-from james.couzens@electricmail.com) Received: from root by sarge.electric.net with emc1-ok (Exim 4.60) (envelope-from ) id 1FJH6t-000443-Vw; Tue, 14 Mar 2006 13:31:20 -0800 Received: by emcmailer; Tue, 14 Mar 2006 13:31:19 -0800 Received: from [199.175.137.27] (helo=antitrust.electric.net) by sarge.electric.net with esmtpsa (SSL 3.0:RSA_ARCFOUR_MD5:16) (Exim 4.60) (envelope-from ) id 1FJH6s-00042x-Vc; Tue, 14 Mar 2006 13:31:19 -0800 Subject: Re: NIST publishes new DSA draft From: James Couzens Reply-To: james.couzens@electricmail.com To: ietf-openpgp@imc.org Cc: hal@finney.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2oR8HVwpzkCvBwce15wZ" Organization: Electric Mail Inc. Date: Tue, 14 Mar 2006 13:31:57 -0800 Message-Id: <1142371918.23097.19.camel@antitrust.electric.net> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-Origin-IP: 199.175.137.27 X-Env-From: james.couzens@electricmail.com X-Virus-Status: Scanned by VirusSMART (s) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c --=-2oR8HVwpzkCvBwce15wZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > We might want to think about making SHA-256 be another MUST algorithm. > The only MUST hash now is SHA-1. Making SHA-256 be a MUST would make > these new key sizes be more useful, and also give us an easier fallback > if SHA-1 should be broken. SHA-1 was broken, last month by three Chinese cryptographers as reported=20 by Bruce Schneier through is website. On February 15, 2006 he wrote of=20 a new cryptographic result, an attack faster than brute-force against=20 SHA-1. Two days later he wrote an update to his original post and a=20 quote from within it: > Earlier this week, three Chinese cryptographers showed that SHA-1 is not=20 > collision-free. That is, they developed an algorithm for finding collisio= ns > faster than brute force. >=20 > ... >=20 > They can find collisions in SHA-1 in 2^69 calculations, about 2,000 times > faster than brute force. Right now, that is just on the far edge of=20 > feasibility with current technology. Two comparable massive computations=20 > illustrate that point. Reference URL (02/18/2006): http://tinyurl.com/4rl78 Original post (02/15/2006): http://tinyurl.com/4bmcc With respect to your suggestion about thinking about making SHA-256 a MUST=20 algorithm I couldn't agree more. Cheers, James --=20 James Couzens, Programmer ___ __ __ ___=20 | __| \/ |/ __| The Electric Mail Company | _|| |\/| | (__ Managed, Secure Email Services |___|_| |_|\___| http://www.electricmail.com Direct Line: 604.482.1111 x152 -------------------------------------------------- PGP Key Fingerprint: B2EF B741 1807 2F24 8B70 F89B 03D2 6CFF C52F 0052 --=-2oR8HVwpzkCvBwce15wZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.7 (GNU/Linux) iD8DBQBEFzZNA9Js/8UvAFIRArrwAKCWc+RkFHF/JI1k69y8XC3j4kZwSACeIiGv dU828YLmJjhKzFjaPFrUgow= =b9fr -----END PGP SIGNATURE----- --=-2oR8HVwpzkCvBwce15wZ-- From owner-ietf-openpgp@mail.imc.org Tue Mar 14 17:44:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJIFO-0006kQ-E7 for openpgp-archive@lists.ietf.org; Tue, 14 Mar 2006 17:44:10 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJIFN-0008LF-1i for openpgp-archive@lists.ietf.org; Tue, 14 Mar 2006 17:44:10 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EME6Hd016364; Tue, 14 Mar 2006 15:14:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2EME6hv016363; Tue, 14 Mar 2006 15:14:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EME3Sm016356 for ; Tue, 14 Mar 2006 15:14:06 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 38E3857FB0; Tue, 14 Mar 2006 14:19:59 -0800 (PST) To: james.couzens@electricmail.com Subject: Re: NIST publishes new DSA draft Cc: ietf-openpgp@imc.org Message-Id: <20060314221959.38E3857FB0@finney.org> Date: Tue, 14 Mar 2006 14:19:59 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Hi, James - I'm afraid you are off by a year on that. Those reports were from 2005, not 2006. They have been intensively discussed here and elsewhere in the cryptographic community. Indeed, those findings are a good part of why I was proposing making SHA-256 a MUST, along with the fact that this hash will now be able to be used with DSS signatures. Hal Finney > > We might want to think about making SHA-256 be another MUST algorithm. > > The only MUST hash now is SHA-1. Making SHA-256 be a MUST would make > > these new key sizes be more useful, and also give us an easier fallback > > if SHA-1 should be broken. > > SHA-1 was broken, last month by three Chinese cryptographers as reported > by Bruce Schneier through is website. On February 15, 2006 he wrote of > a new cryptographic result, an attack faster than brute-force against > SHA-1. Two days later he wrote an update to his original post and a > quote from within it: > > > Earlier this week, three Chinese cryptographers showed that SHA-1 is not > > collision-free. That is, they developed an algorithm for finding collisions > > faster than brute force. > > > > ... > > > > They can find collisions in SHA-1 in 2^69 calculations, about 2,000 times > > faster than brute force. Right now, that is just on the far edge of > > feasibility with current technology. Two comparable massive computations > > illustrate that point. > > Reference URL (02/18/2006): http://tinyurl.com/4rl78 > Original post (02/15/2006): http://tinyurl.com/4bmcc > > With respect to your suggestion about thinking about making SHA-256 a MUST > algorithm I couldn't agree more. > > Cheers, > > James > > -- > James Couzens, > Programmer > ___ __ __ ___ > | __| \/ |/ __| The Electric Mail Company > | _|| |\/| | (__ Managed, Secure Email Services > |___|_| |_|\___| http://www.electricmail.com > Direct Line: 604.482.1111 x152 > -------------------------------------------------- > PGP Key Fingerprint: > B2EF B741 1807 2F24 8B70 F89B 03D2 6CFF C52F 0052 From owner-ietf-openpgp@mail.imc.org Tue Mar 14 18:24:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJIsJ-0000Om-In for openpgp-archive@lists.ietf.org; Tue, 14 Mar 2006 18:24:23 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJIsH-0001Su-V8 for openpgp-archive@lists.ietf.org; Tue, 14 Mar 2006 18:24:23 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EMxUlV018640; Tue, 14 Mar 2006 15:59:30 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2EMxUTS018639; Tue, 14 Mar 2006 15:59:30 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from herring.electric.net (herring.electric.net [216.129.90.28]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EMxTXW018619 for ; Tue, 14 Mar 2006 15:59:29 -0700 (MST) (envelope-from james.couzens@electricmail.com) Received: from root by herring.electric.net with emc1-ok (Exim 4.60) (envelope-from ) id 1FJIUB-0007Iw-Vz; Tue, 14 Mar 2006 14:59:27 -0800 Received: by emcmailer; Tue, 14 Mar 2006 14:59:27 -0800 Received: from [199.175.137.27] (helo=antitrust.electric.net) by herring.electric.net with esmtpsa (SSL 3.0:RSA_ARCFOUR_MD5:16) (Exim 4.60) (envelope-from ) id 1FJIUB-0007Ie-Tr; Tue, 14 Mar 2006 14:59:27 -0800 Subject: Re: NIST publishes new DSA draft From: James Couzens Reply-To: james.couzens@electricmail.com To: ietf-openpgp@imc.org Cc: hal@finney.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-iOvAS1f9XE6vu/PuqDYZ" Organization: Electric Mail Inc. Date: Tue, 14 Mar 2006 15:00:07 -0800 Message-Id: <1142377207.25875.10.camel@antitrust.electric.net> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-Outbound-IP: 199.175.137.27 X-Env-From: james.couzens@electricmail.com X-Virus-Status: Scanned by VirusSMART (s) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 --=-iOvAS1f9XE6vu/PuqDYZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > Hi, James - I'm afraid you are off by a year on that. Those reports > were from 2005, not 2006. They have been intensively discussed here and > elsewhere in the cryptographic community. Indeed, those findings are a > good part of why I was proposing making SHA-256 a MUST, along with the > fact that this hash will now be able to be used with DSS signatures. My apologies, you are quite correct. I recently joined the list a few months ago, and haven't reviewed it historically, and as such I wasn't present for the referenced discussion(s) intense or otherwise :-) =20 I had thought it a bit strange that someone writing so comprehensively about something related to digital signatures and to then make the statement as you did at the end of the paragraph I quoted. Did you have some other intended meaning, such as broken by draft explicit prohibition or otherwise declared deprecated in a future draft? Cheers, James --=20 James Couzens, Programmer ___ __ __ ___=20 | __| \/ |/ __| The Electric Mail Company | _|| |\/| | (__ Managed, Secure Email Services |___|_| |_|\___| http://www.electricmail.com Direct Line: 604.482.1111 x152 -------------------------------------------------- PGP Key Fingerprint: B2EF B741 1807 2F24 8B70 F89B 03D2 6CFF C52F 0052 --=-iOvAS1f9XE6vu/PuqDYZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.7 (GNU/Linux) iD8DBQBEF0r3A9Js/8UvAFIRAmTQAJsGjuPpL/DDDmzlxcRMKU6n7xRhRgCgiJe2 gpu3cOjx6ykGwu+ibwrUxwA= =tSJP -----END PGP SIGNATURE----- --=-iOvAS1f9XE6vu/PuqDYZ-- From owner-ietf-openpgp@mail.imc.org Tue Mar 14 18:49:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJJH5-0003hb-NL for openpgp-archive@lists.ietf.org; Tue, 14 Mar 2006 18:49:59 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJJH4-000245-BZ for openpgp-archive@lists.ietf.org; Tue, 14 Mar 2006 18:49:59 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2ENPEb4019847; Tue, 14 Mar 2006 16:25:14 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2ENPEdl019846; Tue, 14 Mar 2006 16:25:14 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2ENPC4B019840 for ; Tue, 14 Mar 2006 16:25:12 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 1B3AF57FB0; Tue, 14 Mar 2006 15:31:08 -0800 (PST) To: james.couzens@electricmail.com Subject: Re: NIST publishes new DSA draft Cc: ietf-openpgp@imc.org Message-Id: <20060314233108.1B3AF57FB0@finney.org> Date: Tue, 14 Mar 2006 15:31:08 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab James Couzens writes: > I had thought it a bit strange that someone writing so comprehensively > about something related to digital signatures and to then make the > statement as you did at the end of the paragraph I quoted. Did you have > some other intended meaning, such as broken by draft explicit > prohibition or otherwise declared deprecated in a future draft? Yes, sorry, my language was not as precise as it might have been. I said we should be ready in case SHA-1 were broken, but as you note it has been officially "broken" for over a year. However that is just a theoretical break and no actual examples of SHA-1 message collisions have yet been published. So at this point SHA-1 is in a bit of a limbo state, theoretically broken but still in widespread use. If the attack should get worse so that SHA-1 collisions could be found in a practical amount of time, then we would have a much more urgent need to switch to another hash. That is what I really meant when I said we should be ready if SHA-1 should be broken. Hal Finney From owner-ietf-openpgp@mail.imc.org Wed Mar 15 04:53:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJShT-0004g0-0D for openpgp-archive@lists.ietf.org; Wed, 15 Mar 2006 04:53:51 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJShQ-0002jH-K4 for openpgp-archive@lists.ietf.org; Wed, 15 Mar 2006 04:53:50 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2F9TEG1040195; Wed, 15 Mar 2006 02:29:14 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2F9TEWn040194; Wed, 15 Mar 2006 02:29:14 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wbm2.pair.net (wbm2.pair.net [209.68.3.43]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2F9TDv8040186 for ; Wed, 15 Mar 2006 02:29:14 -0700 (MST) (envelope-from iang@systemics.com) Received: by wbm2.pair.net (Postfix, from userid 65534) id 3F95811725; Wed, 15 Mar 2006 04:29:10 -0500 (EST) Received: from 84.131.251.69 ([84.131.251.69]) (SquirrelMail authenticated user john@systemics.com) by webmail2.pair.com with HTTP; Wed, 15 Mar 2006 04:29:10 -0500 (EST) Message-ID: <61223.84.131.251.69.1142414950.squirrel@webmail2.pair.com> In-Reply-To: <20060314233108.1B3AF57FB0@finney.org> References: <20060314233108.1B3AF57FB0@finney.org> Date: Wed, 15 Mar 2006 04:29:10 -0500 (EST) Subject: Re: NIST publishes new DSA draft From: "Ian Grigg" To: ietf-openpgp@imc.org Reply-To: iang@systemics.com User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 > > James Couzens writes: >> I had thought it a bit strange that someone writing so comprehensively >> about something related to digital signatures and to then make the >> statement as you did at the end of the paragraph I quoted. Did you have >> some other intended meaning, such as broken by draft explicit >> prohibition or otherwise declared deprecated in a future draft? > > Yes, sorry, my language was not as precise as it might have been. > I said we should be ready in case SHA-1 were broken, but as you note > it has been officially "broken" for over a year. However that is just > a theoretical break and no actual examples of SHA-1 message collisions > have yet been published. So at this point SHA-1 is in a bit of a limbo > state, theoretically broken but still in widespread use. The problem lies in the use of the term "broken" which sounds great in the popular press, but is insufficiently precise for serious forums and serious protocol work. A more appropriate term is that SHA1 is weakened - from 80 bits to 69 bits - for some uses. Analysis in this forum in the past has indicated that - approximately - SHA1 is still good, but we should move over as and when we can select good alternatives. NIST's new DSA announcement I think makes the case that SHA256 is going to be around a lot longer than some of us earlier speculated, so that looks like the target for now. > If the attack should get worse so that SHA-1 collisions could be found > in a practical amount of time, then we would have a much more urgent > need to switch to another hash. That is what I really meant when I > said we should be ready if SHA-1 should be broken. Yes, it's a concern. FTR, I agree with Hal that we should seriously consider taking the draft out of last call (dammit!) ... hopefully it won't take too long to get enough consensus and some rough working code? iang From owner-ietf-openpgp@mail.imc.org Wed Mar 15 06:57:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJUdG-0007fm-NH for openpgp-archive@lists.ietf.org; Wed, 15 Mar 2006 06:57:38 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJUdF-0006Yk-CH for openpgp-archive@lists.ietf.org; Wed, 15 Mar 2006 06:57:38 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FBWmAD044550; Wed, 15 Mar 2006 04:32:48 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2FBWmA4044543; Wed, 15 Mar 2006 04:32:48 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FBWkli044514 for ; Wed, 15 Mar 2006 04:32:47 -0700 (MST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1FJUNH-0003ZD-Sd for ; Wed, 15 Mar 2006 12:41:07 +0100 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1FJUBu-0008Tj-22; Wed, 15 Mar 2006 12:29:22 +0100 From: Werner Koch To: iang@systemics.com Cc: ietf-openpgp@imc.org Subject: Re: NIST publishes new DSA draft References: <20060314233108.1B3AF57FB0@finney.org> <61223.84.131.251.69.1142414950.squirrel@webmail2.pair.com> Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Wed, 15 Mar 2006 12:29:21 +0100 In-Reply-To: <61223.84.131.251.69.1142414950.squirrel@webmail2.pair.com> (Ian Grigg's message of "Wed, 15 Mar 2006 04:29:10 -0500 (EST)") Message-ID: <87fylk6j5a.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On Wed, 15 Mar 2006 04:29:10 -0500 (EST), Ian Grigg said: > Yes, it's a concern. FTR, I agree with Hal that > we should seriously consider taking the draft out > of last call (dammit!) ... hopefully it won't take I agree. However, SHA-256 should not be a MUST but a SHOULD. Otherwise many OpenPGP applications won't be compliant anymore. In particular applications on small devices may only support the MUST algorithms. A remark that this SHOULD will be changed to a MUST algorithm in the future will help to explain that we really want SHA-256. Salam-Shalom, Werner From owner-ietf-openpgp@mail.imc.org Wed Mar 15 07:22:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJV1B-0002Pp-I1 for openpgp-archive@lists.ietf.org; Wed, 15 Mar 2006 07:22:21 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJV1A-0007KX-6A for openpgp-archive@lists.ietf.org; Wed, 15 Mar 2006 07:22:21 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FBv7pV045266; Wed, 15 Mar 2006 04:57:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2FBv7cg045265; Wed, 15 Mar 2006 04:57:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FBv6TD045259 for ; Wed, 15 Mar 2006 04:57:07 -0700 (MST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 2BD7C33C1C; Wed, 15 Mar 2006 11:57:06 +0000 (GMT) Message-ID: <4418011B.2020708@algroup.co.uk> Date: Wed, 15 Mar 2006 11:57:15 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Hal Finney CC: james.couzens@electricmail.com, ietf-openpgp@imc.org Subject: Re: NIST publishes new DSA draft References: <20060314233108.1B3AF57FB0@finney.org> In-Reply-To: <20060314233108.1B3AF57FB0@finney.org> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hal Finney wrote: > James Couzens writes: >> I had thought it a bit strange that someone writing so comprehensively >> about something related to digital signatures and to then make the >> statement as you did at the end of the paragraph I quoted. Did you have >> some other intended meaning, such as broken by draft explicit >> prohibition or otherwise declared deprecated in a future draft? > > Yes, sorry, my language was not as precise as it might have been. > I said we should be ready in case SHA-1 were broken, but as you note > it has been officially "broken" for over a year. However that is just > a theoretical break and no actual examples of SHA-1 message collisions > have yet been published. So at this point SHA-1 is in a bit of a limbo > state, theoretically broken but still in widespread use. Its also worth noting that reducing the collision resistance to 2^69 still leaves it stronger than unbroken MD5 and is still well within the realms of hardness we require. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-ietf-openpgp@mail.imc.org Wed Mar 15 09:43:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJXDs-0005j3-Te for openpgp-archive@lists.ietf.org; Wed, 15 Mar 2006 09:43:36 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJXDr-0003Fa-Fv for openpgp-archive@lists.ietf.org; Wed, 15 Mar 2006 09:43:36 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FEK3NV051322; Wed, 15 Mar 2006 07:20:03 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2FEK3Tc051321; Wed, 15 Mar 2006 07:20:03 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FEK1Dv051314 for ; Wed, 15 Mar 2006 07:20:02 -0700 (MST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id F2ED333C1C; Wed, 15 Mar 2006 14:20:00 +0000 (GMT) Message-ID: <44182299.2010507@algroup.co.uk> Date: Wed, 15 Mar 2006 14:20:09 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Hal Finney CC: dshaw@jabberwocky.com, ietf-openpgp@imc.org Subject: Re: NIST publishes new DSA draft References: <20060314194447.4D59A57FB0@finney.org> In-Reply-To: <20060314194447.4D59A57FB0@finney.org> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Hal Finney wrote: > David Shaw writes: >> In the OpenPGP context, probably the most interesting bit is that the >> 160-bit hash limit has been removed. The sizes supported are: >> >> * 1024-bit key, 160-bit hash (the current DSA) >> * 2048-bit key, 224-bit hash (presumably aimed at SHA-224) >> * 2048-bit key, 256-bit hash (presumably aimed at SHA-256) >> * 3072-bit key, 256-bit hash (presumably aimed at SHA-256) >> >> It also adds the concept of using a larger hash than will fit by >> taking the leftmost bits. > > The main question is whether we want to change the current draft to make > these changes. That would probably require backing it out of "last > call" status. Personally I think this makes sense. There is no one > waiting urgently for this draft to be finalized AFAIK. The alternative > will be to immediately amend the RFC with another RFC. But for the sake > of future implementors I think it would be better to wait a few months > more and put it all into one draft. > > In two places in RFC2440-bis, we mention that DSA signatures must use > a 160 bit hash. The main one is in section 5.2.2, Version 3 Signature > Packet Format. This is not a good location as it is not information > that is specific to V3 signature packets. It applies to V4 signatures > as well. This information should probably be in 5.5.2 on public key > packet formats, or at least should be repeated in 5.2.3 for V4 sigs. > > It is also mentioned in section 13, Security Considerations, where we > state explicitly that RIPEMD-160 can be used, but that "DSS" as compared > to "DSA" requires SHA-1. > > One of the implications of the changes in the new draft is that 1024 bit > DSA keys can use SHA-256 (truncated to 160 bits). We should probably > allow that as an alternative to SHA-1, although it raises backwards > compatibility issues. > > For 2048 bit keys they allow either 224 or 256 bit hashes. This also > means allowing a subgroup "q" size of either 224 or 256 bits, I think. > The hash then must either match "q" or be larger, in which case it is > left-truncated. > > We do not have an algorithm ID for SHA-224. SHA-224 is the same > algorithm as SHA-256 but uses different initial values internally, > and then truncates the result to 224 bits. I don't see any advantage > in this case to using SHA-224 over using SHA-256 truncated to 224 bits. > However we might want to add an ID for it in case an implementor wanted > to follow the new DSS spec very closely. > > The simplest change we could make would be to allow that DSA keys can > use modulus "p" and subgroup "q" values of the specified sizes, based > on the table above. Hashes should be equal in size or larger than the > "q" size. Hashes larger than the "q" size should be left-truncated. > Then we could note that for DSS compliance the hashes must be taken from > the SHA family, either SHA-1 or one of the larger SHA's. > > We might want to think about making SHA-256 be another MUST algorithm. > The only MUST hash now is SHA-1. Making SHA-256 be a MUST would make > these new key sizes be more useful, and also give us an easier fallback > if SHA-1 should be broken. > > I also think we should change the names of SHA256 etc to use dashes > as in SHA-256; those are the official names. I'm in favour of making these changes now rather than waiting for the next version. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-ietf-openpgp@mail.imc.org Wed Mar 15 14:36:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJbnf-0001WL-DS for openpgp-archive@lists.ietf.org; Wed, 15 Mar 2006 14:36:51 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJbnd-0004eC-0p for openpgp-archive@lists.ietf.org; Wed, 15 Mar 2006 14:36:51 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FJE705061951; Wed, 15 Mar 2006 12:14:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2FJE7KU061950; Wed, 15 Mar 2006 12:14:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FJE6RC061943 for ; Wed, 15 Mar 2006 12:14:06 -0700 (MST) (envelope-from vedaal@hush.com) Received: from smtp3.hushmail.com (localhost.hushmail.com [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 9B0B1A3305 for ; Wed, 15 Mar 2006 11:14:05 -0800 (PST) Received: from mailserver2.hushmail.com (mailserver2.hushmail.com [65.39.178.21]) by smtp3.hushmail.com (Postfix) with ESMTP for ; Wed, 15 Mar 2006 11:14:05 -0800 (PST) Received: from mailserver2.hushmail.com (localhost.hushmail.com [127.0.0.1]) by mailserver2.hushmail.com (8.12.6/8.12.3) with ESMTP id k2FJE5Z3081898 for ; Wed, 15 Mar 2006 11:14:05 -0800 (PST) (envelope-from vedaal@hush.com) Received: (from nobody@localhost) by mailserver2.hushmail.com (8.12.6/8.12.3/Submit) id k2FJE45H081897 for ; Wed, 15 Mar 2006 14:14:04 -0500 (GMT) Message-Id: <200603151914.k2FJE45H081897@mailserver2.hushmail.com> Date: Wed, 15 Mar 2006 14:14:02 -0500 To: Cc: Subject: Re: NIST publishes new DSA draft From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.8 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 On Tue, 14 Mar 2006 10:58:39 -0500 David Shaw wrote: >In the OpenPGP context, probably the most interesting bit is that >the >160-bit hash limit has been removed. The sizes supported are: > >* 1024-bit key, 160-bit hash (the current DSA) >* 2048-bit key, 224-bit hash (presumably aimed at SHA-224) >* 2048-bit key, 256-bit hash (presumably aimed at SHA-256) >* 3072-bit key, 256-bit hash (presumably aimed at SHA-256) > >It also adds the concept of using a larger hash than will fit by >taking the leftmost bits. > >http://csrc.nist.gov/publications/drafts.html the draft also refers to a previous draft of August/2005 (SP 800- 57) which publishes a table of comparable strengths: http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57- Part1.pdf p.63 note that 3-DES is now referred to as TDEA should this perhaps be included in rfc 2440 when 3-DES is mentioned? i.e. when 3-DES is first mentioned, it should be referred to as 3-DES(also known as TDEA) vedaal Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485 From owner-ietf-openpgp@mail.imc.org Thu Mar 16 10:08:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJu5Q-0003vY-Cc for openpgp-archive@lists.ietf.org; Thu, 16 Mar 2006 10:08:24 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJu5N-0004h4-Up for openpgp-archive@lists.ietf.org; Thu, 16 Mar 2006 10:08:24 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2GEcxtH001749; Thu, 16 Mar 2006 07:38:59 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2GEcxOo001748; Thu, 16 Mar 2006 07:38:59 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.okiok.com (host70.okiok.com [207.61.238.70] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2GEcwW8001741 for ; Thu, 16 Mar 2006 07:38:59 -0700 (MST) (envelope-from astiglic@okiok.com) Received: from P1038Mobile (unknown [70.82.189.188]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.okiok.com (Postfix) with ESMTP id 7E6961683D3 for ; Wed, 15 Mar 2006 21:46:48 -0500 (EST) From: "Anton Stiglic" To: Subject: RE: NIST publishes new DSA draft Date: Wed, 15 Mar 2006 21:40:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <44182299.2010507@algroup.co.uk> Thread-Index: AcZIQD3ijlagomLPTr6kHg5G5VtN5AAYJAlg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20060316024648.7E6961683D3@mail.okiok.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 I haven't participated in this list so far but I have been lurking here for some time. I agree with the phasing out of SHA1, as soon as possible! Indeed there have been some vulnerabilities demonstrated, collisions on arbitrary inputs (as this has already been discussed before, this is not as strong attack as 2nd pre-image attack which would directly affect digital signatures based on SHA1 for example, but still an indication of weakness in the hash algorithm). Also governments have plans of phasing SHA1 out soon. CSE in Canada plans to take it out of commission by 2008 for the protection of certain types of information, see for example http://www.cse-cst.gc.ca/services/crypto-services/crypto-algorithms-e.html --Anton -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 268.1.2/274 - Release Date: 03/03/2006 From owner-ietf-openpgp@mail.imc.org Thu Mar 16 14:55:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJyZ9-0008GW-Hg for openpgp-archive@lists.ietf.org; Thu, 16 Mar 2006 14:55:23 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJyZ9-0006YI-3q for openpgp-archive@lists.ietf.org; Thu, 16 Mar 2006 14:55:23 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2GJSXNZ015826; Thu, 16 Mar 2006 12:28:33 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2GJSX5D015825; Thu, 16 Mar 2006 12:28:33 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2GJSWPM015813 for ; Thu, 16 Mar 2006 12:28:33 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2GJSTk17364; Thu, 16 Mar 2006 14:28:29 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id k2GJSR6c009284; Thu, 16 Mar 2006 14:28:27 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2GJSNP1009978; Thu, 16 Mar 2006 14:28:23 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2GJSNRi009977; Thu, 16 Mar 2006 14:28:23 -0500 Date: Thu, 16 Mar 2006 14:28:23 -0500 From: David Shaw To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: NIST publishes new DSA draft Message-ID: <20060316192823.GA9945@jabberwocky.com> Mail-Followup-To: Hal Finney , ietf-openpgp@imc.org References: <20060314194447.4D59A57FB0@finney.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060314194447.4D59A57FB0@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 On Tue, Mar 14, 2006 at 11:44:47AM -0800, "Hal Finney" wrote: > The main question is whether we want to change the current draft to make > these changes. That would probably require backing it out of "last > call" status. Personally I think this makes sense. There is no one > waiting urgently for this draft to be finalized AFAIK. The alternative > will be to immediately amend the RFC with another RFC. But for the sake > of future implementors I think it would be better to wait a few months > more and put it all into one draft. I agree with this. It is unfortunate, but will ultimately result in a better RFC. > We do not have an algorithm ID for SHA-224. SHA-224 is the same > algorithm as SHA-256 but uses different initial values internally, > and then truncates the result to 224 bits. I don't see any advantage > in this case to using SHA-224 over using SHA-256 truncated to 224 bits. > However we might want to add an ID for it in case an implementor wanted > to follow the new DSS spec very closely. Given that the main alternative is truncated SHA-256, which implies SHA-256 support in the first place, and the code difference between SHA-256 and 224 is simple to say the least (as you say, same algorithm), I think we should add the ID (#7 ?) for SHA-224. It's a checkbox item that we can trivially support. > The simplest change we could make would be to allow that DSA keys can > use modulus "p" and subgroup "q" values of the specified sizes, based > on the table above. Hashes should be equal in size or larger than the > "q" size. Hashes larger than the "q" size should be left-truncated. > Then we could note that for DSS compliance the hashes must be taken from > the SHA family, either SHA-1 or one of the larger SHA's. > > We might want to think about making SHA-256 be another MUST algorithm. > The only MUST hash now is SHA-1. Making SHA-256 be a MUST would make > these new key sizes be more useful, and also give us an easier fallback > if SHA-1 should be broken. Unless DSA2 is also a MUST, I wonder what the practical advantage to that would be (beyond making the social point that we really, really want people to move away from SHA-1). Since an OpenPGP program would not necessarily know whether the recipient could handle SHA-256 (SHA-256 dates from around 2004, implementation-wise), it would have to use SHA-1 in many or most cases anyway. Obviously a DSA2 signature wouldn't be expected to work, but an RSA signature would have this problem, and DSA1 (using a truncated SHA-256) would have the problem as well for both truncation and SHA-256 reasons. A few months back you asked the question whether new DSAs would best be supported by extending the definition of the current DSA, or by assigning a new algorithm ID for DSA2. At the time, most people (myself included) felt that extending the current DSA would be the right answer. Now that we have actual information about DSA2, perhaps it would be worth revisiting that question. A new algorithm ID for DSA2 resolves a number of problems in one fell swoop as there is no expectation of interoperability. SHA-256 is always usable (effectively the default) for DSA2, and there is no problem with knowing when it is possible to use truncation (always). > I also think we should change the names of SHA256 etc to use dashes > as in SHA-256; those are the official names. To be clear here: are you referring to changing the descriptive text in the draft or changing the hash name strings as used in clearsigned message "Hash:" headers? The first is easy and I agree should be done, the second has compatibility implications. David From owner-ietf-openpgp@mail.imc.org Thu Mar 16 15:30:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJz7N-0007sK-Ag for openpgp-archive@lists.ietf.org; Thu, 16 Mar 2006 15:30:45 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJz7M-0007uQ-US for openpgp-archive@lists.ietf.org; Thu, 16 Mar 2006 15:30:45 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2GKDkvg017500; Thu, 16 Mar 2006 13:13:46 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2GKDkek017499; Thu, 16 Mar 2006 13:13:46 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2GKDjiv017493 for ; Thu, 16 Mar 2006 13:13:45 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 3A87557FB0; Thu, 16 Mar 2006 12:19:51 -0800 (PST) To: dshaw@jabberwocky.com, hal@finney.org Subject: Re: NIST publishes new DSA draft Cc: ietf-openpgp@imc.org Message-Id: <20060316201951.3A87557FB0@finney.org> Date: Thu, 16 Mar 2006 12:19:51 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 David Shaw writes: > On Tue, Mar 14, 2006 at 11:44:47AM -0800, "Hal Finney" wrote: > > We might want to think about making SHA-256 be another MUST algorithm. > > The only MUST hash now is SHA-1. Making SHA-256 be a MUST would make > > these new key sizes be more useful, and also give us an easier fallback > > if SHA-1 should be broken. > > Unless DSA2 is also a MUST, I wonder what the practical advantage to > that would be (beyond making the social point that we really, really > want people to move away from SHA-1). Since an OpenPGP program would > not necessarily know whether the recipient could handle SHA-256 > (SHA-256 dates from around 2004, implementation-wise), it would have > to use SHA-1 in many or most cases anyway. Obviously a DSA2 signature > wouldn't be expected to work, but an RSA signature would have this > problem, and DSA1 (using a truncated SHA-256) would have the problem > as well for both truncation and SHA-256 reasons. OK, but maybe a "SHOULD" like Werner suggested, then? > A few months back you asked the question whether new DSAs would best > be supported by extending the definition of the current DSA, or by > assigning a new algorithm ID for DSA2. At the time, most people > (myself included) felt that extending the current DSA would be the > right answer. Now that we have actual information about DSA2, perhaps > it would be worth revisiting that question. A new algorithm ID for > DSA2 resolves a number of problems in one fell swoop as there is no > expectation of interoperability. SHA-256 is always usable > (effectively the default) for DSA2, and there is no problem with > knowing when it is possible to use truncation (always). At this point I like the idea of keeping the same algorithm ID. All the code and algorithms are the same, so using a different alg ID just for different key sizes doesn't really make sense. Using a different algorithm ID will be, from the future perspective, a historical artifact. And I don't see that it really helps interoperability to use a new ID. Either way, the bottom line is that old code won't work with the new keys and new code will. Plus it makes implementation of the change a lot easier - granted, a minor point, but on top of everything else I see this as the preferable strategy. > > I also think we should change the names of SHA256 etc to use dashes > > as in SHA-256; those are the official names. > > To be clear here: are you referring to changing the descriptive text > in the draft or changing the hash name strings as used in clearsigned > message "Hash:" headers? The first is easy and I agree should be > done, the second has compatibility implications. Just in the draft, then. I guess we're stuck with the name strings. It's not a big deal either way. Hal Finney From owner-ietf-openpgp@mail.imc.org Thu Mar 16 16:22:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJzvO-00050d-QZ for openpgp-archive@lists.ietf.org; Thu, 16 Mar 2006 16:22:26 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJzvO-0001R3-E0 for openpgp-archive@lists.ietf.org; Thu, 16 Mar 2006 16:22:26 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2GKpArU018960; Thu, 16 Mar 2006 13:51:10 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2GKpA9p018959; Thu, 16 Mar 2006 13:51:10 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2GKp9vN018953 for ; Thu, 16 Mar 2006 13:51:10 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2GKp8k17729; Thu, 16 Mar 2006 15:51:08 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id k2GKp76c009560; Thu, 16 Mar 2006 15:51:07 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2GKp2tb010073; Thu, 16 Mar 2006 15:51:02 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2GKp2Px010072; Thu, 16 Mar 2006 15:51:02 -0500 Date: Thu, 16 Mar 2006 15:51:02 -0500 From: David Shaw To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: NIST publishes new DSA draft Message-ID: <20060316205102.GB9834@jabberwocky.com> Mail-Followup-To: Hal Finney , ietf-openpgp@imc.org References: <20060316201951.3A87557FB0@finney.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060316201951.3A87557FB0@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 On Thu, Mar 16, 2006 at 12:19:51PM -0800, "Hal Finney" wrote: > David Shaw writes: > > Unless DSA2 is also a MUST, I wonder what the practical advantage to > > that would be (beyond making the social point that we really, really > > want people to move away from SHA-1). Since an OpenPGP program would > > not necessarily know whether the recipient could handle SHA-256 > > (SHA-256 dates from around 2004, implementation-wise), it would have > > to use SHA-1 in many or most cases anyway. Obviously a DSA2 signature > > wouldn't be expected to work, but an RSA signature would have this > > problem, and DSA1 (using a truncated SHA-256) would have the problem > > as well for both truncation and SHA-256 reasons. > > OK, but maybe a "SHOULD" like Werner suggested, then? Absolutely. I'm in favor of SHOULD. This implies that DSA with 160-bit q is a MUST (as it is now), and DSA with >160-bit q is not a MUST (though an implementation must at least know that DSA might have a larger q and not blow up). > At this point I like the idea of keeping the same algorithm ID. All the > code and algorithms are the same, so using a different alg ID just > for different key sizes doesn't really make sense. Using a different > algorithm ID will be, from the future perspective, a historical artifact. > And I don't see that it really helps interoperability to use a new ID. > Either way, the bottom line is that old code won't work with the new > keys and new code will. Plus it makes implementation of the change a > lot easier - granted, a minor point, but on top of everything else I > see this as the preferable strategy. While I agree that the bottom line is that the old code won't work and the new code will, using a different algorithm ID potentially gives a better (and more user-comprehensible) error than using the same algorithm ID does when the old code doesn't work. That is to say, it may fail "prettier" (it does in the GPG case). I don't think it's that big of a deal, and I'm not arguing for it. On a related issue, do you think a feature flag to indicate the ability to handle a truncated hash would be a good idea? I'm leaning towards no, as it would only be really useful in the sign+encrypt case (where the implementation knows who the recipient(s) are and can thus consult feature flags), but perhaps that's enough to justify it. David From owner-ietf-openpgp@mail.imc.org Fri Mar 17 10:27:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKGrt-00063v-OH for openpgp-archive@lists.ietf.org; Fri, 17 Mar 2006 10:27:57 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKGrs-0002NH-AF for openpgp-archive@lists.ietf.org; Fri, 17 Mar 2006 10:27:57 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2HF3U8b063928; Fri, 17 Mar 2006 08:03:30 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2HF3US0063927; Fri, 17 Mar 2006 08:03:30 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2HF3SXZ063920 for ; Fri, 17 Mar 2006 08:03:29 -0700 (MST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 361EE4137A; Fri, 17 Mar 2006 15:03:23 +0000 (GMT) Message-ID: <441ACF45.704@systemics.com> Date: Fri, 17 Mar 2006 16:01:25 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Shaw Cc: Hal Finney , ietf-openpgp@imc.org Subject: Re: NIST publishes new DSA draft References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> In-Reply-To: <20060316192823.GA9945@jabberwocky.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d David Shaw wrote: >>We might want to think about making SHA-256 be another MUST algorithm. >>The only MUST hash now is SHA-1. Making SHA-256 be a MUST would make >>these new key sizes be more useful, and also give us an easier fallback >>if SHA-1 should be broken. > > > Unless DSA2 is also a MUST, I wonder what the practical advantage to > that would be (beyond making the social point that we really, really > want people to move away from SHA-1). I think this is pretty much all of the point. Any new DSA signing method or other usage will likely be non-obligatory, but pushing the implementations into that direction seems useful. > right answer. Now that we have actual information about DSA2, perhaps > it would be worth revisiting that question. A new algorithm ID for > DSA2 resolves a number of problems in one fell swoop as there is no > expectation of interoperability. SHA-256 is always usable > (effectively the default) for DSA2, and there is no problem with > knowing when it is possible to use truncation (always). Sounds good to me. iang From owner-ietf-openpgp@mail.imc.org Fri Mar 17 11:17:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKHeC-0008Hb-5G for openpgp-archive@lists.ietf.org; Fri, 17 Mar 2006 11:17:52 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKHeA-0004Ek-QO for openpgp-archive@lists.ietf.org; Fri, 17 Mar 2006 11:17:52 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2HFvl4v066691; Fri, 17 Mar 2006 08:57:47 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2HFvlYX066690; Fri, 17 Mar 2006 08:57:47 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2HFvkgc066684 for ; Fri, 17 Mar 2006 08:57:47 -0700 (MST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1FKHSq-0000Zu-27 for ; Fri, 17 Mar 2006 17:06:08 +0100 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1FKHHR-0007Ws-58; Fri, 17 Mar 2006 16:54:21 +0100 From: Werner Koch To: Ian G Cc: David Shaw , Hal Finney , ietf-openpgp@imc.org Subject: Re: NIST publishes new DSA draft References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> <441ACF45.704@systemics.com> Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Fri, 17 Mar 2006 16:54:21 +0100 In-Reply-To: <441ACF45.704@systemics.com> (Ian G.'s message of "Fri, 17 Mar 2006 16:01:25 +0100") Message-ID: <87fylhdq36.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Fri, 17 Mar 2006 16:01:25 +0100, Ian G said: >> right answer. Now that we have actual information about DSA2, perhaps >> it would be worth revisiting that question. A new algorithm ID for >> DSA2 resolves a number of problems in one fell swoop as there is no >> expectation of interoperability. SHA-256 is always usable >> (effectively the default) for DSA2, and there is no problem with >> knowing when it is possible to use truncation (always). > Sounds good to me. I support this too. The majority of keys are DSA keys q=160 bit. Having a new algorithm indentifier will help more than harm. Salam-Shalom, Werner From owner-ietf-openpgp@mail.imc.org Fri Mar 17 13:07:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJMa-0007uo-Tl for openpgp-archive@lists.ietf.org; Fri, 17 Mar 2006 13:07:48 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKJMa-0007yh-Gw for openpgp-archive@lists.ietf.org; Fri, 17 Mar 2006 13:07:48 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2HHnoLi070981; Fri, 17 Mar 2006 10:49:50 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2HHno5H070980; Fri, 17 Mar 2006 10:49:50 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2HHnnI5070972 for ; Fri, 17 Mar 2006 10:49:49 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2HHnhk23159; Fri, 17 Mar 2006 12:49:43 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id k2HHni6c014653; Fri, 17 Mar 2006 12:49:44 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2HHnbwh013529; Fri, 17 Mar 2006 12:49:37 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2HHnbAn013528; Fri, 17 Mar 2006 12:49:37 -0500 Date: Fri, 17 Mar 2006 12:49:37 -0500 From: David Shaw To: Werner Koch Cc: Ian G , Hal Finney , ietf-openpgp@imc.org Subject: Re: NIST publishes new DSA draft Message-ID: <20060317174937.GC13241@jabberwocky.com> Mail-Followup-To: Werner Koch , Ian G , Hal Finney , ietf-openpgp@imc.org References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> <441ACF45.704@systemics.com> <87fylhdq36.fsf@wheatstone.g10code.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87fylhdq36.fsf@wheatstone.g10code.de> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 On Fri, Mar 17, 2006 at 04:54:21PM +0100, Werner Koch wrote: > > On Fri, 17 Mar 2006 16:01:25 +0100, Ian G said: > > >> right answer. Now that we have actual information about DSA2, perhaps > >> it would be worth revisiting that question. A new algorithm ID for > >> DSA2 resolves a number of problems in one fell swoop as there is no > >> expectation of interoperability. SHA-256 is always usable > >> (effectively the default) for DSA2, and there is no problem with > >> knowing when it is possible to use truncation (always). > > > Sounds good to me. > > I support this too. The majority of keys are DSA keys q=160 bit. > Having a new algorithm indentifier will help more than harm. Even though I originally brought it up, I've given this a good bit of additional thought while mailing with Hal on the list yesterday, and I think it really does come down to something as simple as a question of error messages. I'm not for a new algorithm ID. It breaks down like this: 1) a q==160 signature without truncation (hash size matches q exactly) 2) a q==160 signature with truncation (hash left-truncated to match q) 3) a q!=160 signature without truncation (hash size matches q exactly) 4) a q!=160 signature with truncation (hash left-truncated to match q) I'm not mentioning the larger key size in DSA2 as I believe that deployed code will handle larger DSA key sizes correctly. Obviously #1 isn't a problem, as it is what DSA is today. I think PGP can actually do #2, but for the sake of argument, let's say that nobody can do #2, #3, or #4 on current code. If we don't assign a new algo ID for DSA2, #3 and #4 will fail because of the wrong q size, and #2 will fail because of the truncation. If we do assign the new ID, as before #2, #3, and #4 will fail - but so will #1! Even though the signatures are compatible, the new algo ID will cause the signature to fail on the older implementation. This argues against a new algo ID. Even if we don't create DSA2 q=160 keys (internally changing them to DSA1 keys), this just returns the question to neutral, and the extra code complexity and questions (will it break any keyservers? It will certainly break pksd) of assigning the new algo ID argue against it. David From owner-ietf-openpgp@mail.imc.org Sun Mar 19 15:15:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL4JZ-0001rx-7o for openpgp-archive@lists.ietf.org; Sun, 19 Mar 2006 15:15:49 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL4JU-0000Db-No for openpgp-archive@lists.ietf.org; Sun, 19 Mar 2006 15:15:49 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2JJpLVZ072894; Sun, 19 Mar 2006 12:51:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2JJpL8l072893; Sun, 19 Mar 2006 12:51:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2JJpKrI072886 for ; Sun, 19 Mar 2006 12:51:21 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7) for ; Sun, 19 Mar 2006 11:51:18 -0800 Received: from [130.129.130.213] ([130.129.130.213]) by keys.merrymeet.com (PGP Universal service); Sun, 19 Mar 2006 11:51:18 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Sun, 19 Mar 2006 11:51:18 -0800 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <20060317174937.GC13241@jabberwocky.com> References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> <441ACF45.704@systemics.com> <87fylhdq36.fsf@wheatstone.g10code.de> <20060317174937.GC13241@jabberwocky.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: NIST publishes new DSA draft Date: Sun, 19 Mar 2006 11:51:17 -0800 To: OpenPGP X-Mailer: Apple Mail (2.746.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 I think we ought to keep it with the same algorithm number. I'm happy to put in SHA-224 (meaning it's trivial work), but I don't like it, myself. The reason is that SHA-224 is really a truncated SHA-256. Thus, it has no advantages over SHA-256 except being smaller by 32-bits with 112 bits of security. The reason it exists at all is for crypto-balance with 2-key 3DES (which is not TDEA), which we don't allow at all. I don't think we should have it as it goes against our principles of wanting a minimum of 128-bits of security in OpenPGP. (Yes, yes, I know that SHA-1 doesn't meet this either, but until SHA-256, we didn't have many options. That doesn't mean the principle is wrong; we *have* options.) Jon From owner-ietf-openpgp@mail.imc.org Sun Mar 19 15:22:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL4QL-00034q-H4 for openpgp-archive@lists.ietf.org; Sun, 19 Mar 2006 15:22:49 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL4QL-0000Y9-1E for openpgp-archive@lists.ietf.org; Sun, 19 Mar 2006 15:22:49 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2JK2HP5073179; Sun, 19 Mar 2006 13:02:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2JK2HIC073178; Sun, 19 Mar 2006 13:02:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2JK2GMt073171 for ; Sun, 19 Mar 2006 13:02:16 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7) for ; Sun, 19 Mar 2006 12:02:13 -0800 Received: from [130.129.130.213] ([130.129.130.213]) by keys.merrymeet.com (PGP Universal service); Sun, 19 Mar 2006 12:02:13 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Sun, 19 Mar 2006 12:02:13 -0800 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <200603151914.k2FJE45H081897@mailserver2.hushmail.com> References: <200603151914.k2FJE45H081897@mailserver2.hushmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5BA6C174-0734-48CA-8D66-325081E5AEFF@callas.org> Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: NIST publishes new DSA draft Date: Sun, 19 Mar 2006 12:02:11 -0800 To: OpenPGP X-Mailer: Apple Mail (2.746.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 > note that 3-DES is now referred to as TDEA > should this perhaps be included in rfc 2440 when 3-DES is > mentioned? > i.e. > when 3-DES is first mentioned, > it should be referred to as 3-DES(also known as TDEA) They're not the same. There is DES and DEA, just as there is DSA and DSS. In each pair, there is an Algorithm and a Standard. The standard is the algorithm plus other stuff. In the case of DES, it specifies that the low bit of each byte (excuse me, octet) of the key is a parity bit (and possibly other stuff I don't remember). Everyone uses DES, not DEA. What we use is 3DES, not TDEA. In the case of DSS, we *do* mean DSA because there were people who wanted (for example) to use RIPE-MD/160 with DSA, not SHA-1, as DSS. I suppose we could call it "TDES," but it's been called "3DES" or "Triple-DES" for ages. If all of a sudden we start calling it TDES, there will be many people who will rightly mutter, "TDES? What the % $@! is TDES? Oh, *3DES*, why didn't you say so?" Jon From owner-ietf-openpgp@mail.imc.org Mon Mar 20 15:15:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLQmZ-0008Ar-7M for openpgp-archive@lists.ietf.org; Mon, 20 Mar 2006 15:15:15 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLQmX-0001EY-Gi for openpgp-archive@lists.ietf.org; Mon, 20 Mar 2006 15:15:15 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KJejPt025405; Mon, 20 Mar 2006 12:40:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2KJejo6025404; Mon, 20 Mar 2006 12:40:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KJeibK025398 for ; Mon, 20 Mar 2006 12:40:45 -0700 (MST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 2384451D85; Mon, 20 Mar 2006 19:40:41 +0000 (GMT) Message-ID: <441F04C7.1060909@systemics.com> Date: Mon, 20 Mar 2006 20:38:47 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Callas Cc: OpenPGP Subject: Re: NIST publishes new DSA draft References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> <441ACF45.704@systemics.com> <87fylhdq36.fsf@wheatstone.g10code.de> <20060317174937.GC13241@jabberwocky.com> <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> In-Reply-To: <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Jon Callas wrote: > > I think we ought to keep it with the same algorithm number. > > I'm happy to put in SHA-224 (meaning it's trivial work), but I don't > like it, myself. The reason is that SHA-224 is really a truncated > SHA-256. Thus, it has no advantages over SHA-256 except being smaller > by 32-bits with 112 bits of security. The reason it exists at all is > for crypto-balance with 2-key 3DES (which is not TDEA), which we don't > allow at all. I don't think we should have it as it goes against our > principles of wanting a minimum of 128-bits of security in OpenPGP. > (Yes, yes, I know that SHA-1 doesn't meet this either, but until > SHA-256, we didn't have many options. That doesn't mean the principle > is wrong; we *have* options.) In general I'd agree that the less algorithms/lengths the better. I'd certainly be keen to drop SHA-224 if there is no good reason for it. iang From owner-ietf-openpgp@mail.imc.org Mon Mar 20 15:52:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLRN2-0004Lb-2z for openpgp-archive@lists.ietf.org; Mon, 20 Mar 2006 15:52:56 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLRN0-0002nQ-AH for openpgp-archive@lists.ietf.org; Mon, 20 Mar 2006 15:52:55 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KKSovJ027375; Mon, 20 Mar 2006 13:28:50 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2KKSoDX027374; Mon, 20 Mar 2006 13:28:50 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KKSndh027368 for ; Mon, 20 Mar 2006 13:28:49 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2KKSlk08116 for ; Mon, 20 Mar 2006 15:28:47 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id k2KKSk6c006824 for ; Mon, 20 Mar 2006 15:28:46 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2KKSfCT004087 for ; Mon, 20 Mar 2006 15:28:41 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2KKSfWg004086 for ietf-openpgp@imc.org; Mon, 20 Mar 2006 15:28:41 -0500 Date: Mon, 20 Mar 2006 15:28:41 -0500 From: David Shaw To: OpenPGP Subject: Re: NIST publishes new DSA draft Message-ID: <20060320202841.GA3994@jabberwocky.com> Mail-Followup-To: OpenPGP References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> <441ACF45.704@systemics.com> <87fylhdq36.fsf@wheatstone.g10code.de> <20060317174937.GC13241@jabberwocky.com> <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d On Sun, Mar 19, 2006 at 11:51:17AM -0800, Jon Callas wrote: > I'm happy to put in SHA-224 (meaning it's trivial work), but I don't > like it, myself. The reason is that SHA-224 is really a truncated > SHA-256. Thus, it has no advantages over SHA-256 except being smaller > by 32-bits with 112 bits of security. The reason it exists at all is > for crypto-balance with 2-key 3DES (which is not TDEA), which we > don't allow at all. I don't think we should have it as it goes > against our principles of wanting a minimum of 128-bits of security > in OpenPGP. (Yes, yes, I know that SHA-1 doesn't meet this either, > but until SHA-256, we didn't have many options. That doesn't mean the > principle is wrong; we *have* options.) I understand the argument about wanting 128 bits of security, but since the new DSA allows a 224 bit q, there just isn't room for 128 bits of security. Whether we truncate SHA-256 and call it "truncated SHA-256" or truncate SHA-256 and call it "SHA-224", we have to truncate. We support DSA now, with a note saying that if someone wants DSS, they need to use SHA-1. I suspect we'll end up in a similar place with DSA2 allowing whatever key size and q size that people want to use and a note that if they want DSS they need to use one of the four NIST-blessed key size / q size pairs. I lean towards adding SHA-224 as one of those four pairs has a 224-bit q, and NIST suggests SHA-224 for this size. It's only a lean towards adding it as NIST also suggests truncated 256, 384, or 512 as valid options, so 224 is not the only game in town. (384 seems a little silly as it would be a truncation of a truncation, but it's an option.) It's really a feeling that we currently support 4 out of the 5 FIPS-approved hash functions (SHA-1, 256, 384, 512), and since supporting the 5th (224) is so trivial, we may as well be complete. I'll defer to someone who feels more strongly about this than I do. David From owner-ietf-openpgp@mail.imc.org Mon Mar 20 16:30:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLRx5-00049S-Sr for openpgp-archive@lists.ietf.org; Mon, 20 Mar 2006 16:30:11 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLRx2-0004gA-6c for openpgp-archive@lists.ietf.org; Mon, 20 Mar 2006 16:30:11 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KL8feR028977; Mon, 20 Mar 2006 14:08:41 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2KL8f4T028975; Mon, 20 Mar 2006 14:08:41 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k2KL8eYI028933 for ; Mon, 20 Mar 2006 14:08:40 -0700 (MST) (envelope-from tony@att.com) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-7.tower-120.messagelabs.com!1142888912!10043411!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 24426 invoked from network); 20 Mar 2006 21:08:32 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-7.tower-120.messagelabs.com with SMTP; 20 Mar 2006 21:08:32 -0000 Received: from [135.70.80.181] (unknown[135.70.80.181](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060320210832gw100100dee> (Authid: tony); Mon, 20 Mar 2006 21:08:32 +0000 Message-ID: <441F19CC.9080004@att.com> Date: Mon, 20 Mar 2006 16:08:28 -0500 From: Tony Hansen User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: OpenPGP Subject: Re: NIST publishes new DSA draft References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> <441ACF45.704@systemics.com> <87fylhdq36.fsf@wheatstone.g10code.de> <20060317174937.GC13241@jabberwocky.com> <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> <20060320202841.GA3994@jabberwocky.com> In-Reply-To: <20060320202841.GA3994@jabberwocky.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Just a quibble. Truncating sha-256 down to 224 bits does not give the same output as sha-224, as sha-256 and sha-224 use different initialization vectors. So "truncated sha-256" and "sha-224" really would be totally different hash values. No comment on the rest of what you say. Tony Hansen tony@att.com David Shaw wrote: > I understand the argument about wanting 128 bits of security, but > since the new DSA allows a 224 bit q, there just isn't room for 128 > bits of security. Whether we truncate SHA-256 and call it "truncated > SHA-256" or truncate SHA-256 and call it "SHA-224", we have to > truncate. From owner-ietf-openpgp@mail.imc.org Mon Mar 20 16:51:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLSI5-0000SQ-6h for openpgp-archive@lists.ietf.org; Mon, 20 Mar 2006 16:51:53 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLSI4-0005N0-RS for openpgp-archive@lists.ietf.org; Mon, 20 Mar 2006 16:51:53 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KLZWlV030022; Mon, 20 Mar 2006 14:35:32 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2KLZWvK030021; Mon, 20 Mar 2006 14:35:32 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KLZVwU030014 for ; Mon, 20 Mar 2006 14:35:32 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2KLZUk08791; Mon, 20 Mar 2006 16:35:30 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id k2KLZS6c007309; Mon, 20 Mar 2006 16:35:28 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2KLZOis004182; Mon, 20 Mar 2006 16:35:24 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2KLZNtX004181; Mon, 20 Mar 2006 16:35:23 -0500 Date: Mon, 20 Mar 2006 16:35:23 -0500 From: David Shaw To: Tony Hansen Cc: OpenPGP Subject: Re: NIST publishes new DSA draft Message-ID: <20060320213523.GB3994@jabberwocky.com> Mail-Followup-To: Tony Hansen , OpenPGP References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> <441ACF45.704@systemics.com> <87fylhdq36.fsf@wheatstone.g10code.de> <20060317174937.GC13241@jabberwocky.com> <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> <20060320202841.GA3994@jabberwocky.com> <441F19CC.9080004@att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <441F19CC.9080004@att.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 No, it is not the same output, but it is the same amount of security. Which hash and which IV doesn't matter here - just that the end result is 224 bits long. David On Mon, Mar 20, 2006 at 04:08:28PM -0500, Tony Hansen wrote: > > Just a quibble. Truncating sha-256 down to 224 bits does not give the > same output as sha-224, as sha-256 and sha-224 use different > initialization vectors. So "truncated sha-256" and "sha-224" really > would be totally different hash values. > > No comment on the rest of what you say. > > Tony Hansen > tony@att.com > > David Shaw wrote: > > I understand the argument about wanting 128 bits of security, but > > since the new DSA allows a 224 bit q, there just isn't room for 128 > > bits of security. Whether we truncate SHA-256 and call it "truncated > > SHA-256" or truncate SHA-256 and call it "SHA-224", we have to > > truncate. From owner-ietf-openpgp@mail.imc.org Tue Mar 21 19:15:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLqzg-0004EA-WF for openpgp-archive@lists.ietf.org; Tue, 21 Mar 2006 19:14:33 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLqqC-0002ct-WF for openpgp-archive@lists.ietf.org; Tue, 21 Mar 2006 19:04:47 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LNbkrb095326; Tue, 21 Mar 2006 16:37:46 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2LNbkKV095325; Tue, 21 Mar 2006 16:37:46 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LNbjS8095318 for ; Tue, 21 Mar 2006 16:37:45 -0700 (MST) (envelope-from vedaal@hush.com) Received: from smtp3.hushmail.com (localhost.hushmail.com [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id B96B7A32BF for ; Tue, 21 Mar 2006 15:37:44 -0800 (PST) Received: from mailserver2.hushmail.com (mailserver2.hushmail.com [65.39.178.21]) by smtp3.hushmail.com (Postfix) with ESMTP for ; Tue, 21 Mar 2006 15:37:44 -0800 (PST) Received: from mailserver2.hushmail.com (localhost.hushmail.com [127.0.0.1]) by mailserver2.hushmail.com (8.12.6/8.12.3) with ESMTP id k2LNbiZ3015585 for ; Tue, 21 Mar 2006 15:37:44 -0800 (PST) (envelope-from vedaal@hush.com) Received: (from nobody@localhost) by mailserver2.hushmail.com (8.12.6/8.12.3/Submit) id k2LNbhfv015584 for ; Tue, 21 Mar 2006 18:37:43 -0500 (GMT) Message-Id: <200603212337.k2LNbhfv015584@mailserver2.hushmail.com> Date: Tue, 21 Mar 2006 18:37:43 -0500 To: Cc: Subject: Re: NIST publishes new DSA draft // larger DSA signing keys ? From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.8 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 until now the discussion has centered on the larger SHA hash sizes in section 4.2 of the NIST draft, the following recommendation about key sizes is listed, and seems to imply that DSA signing key sizes should be the same as DH encryption key sizes: =====[ begin quote ]===== It is recommended that the security strength of the (L, N) pair and the hash function be the same unless an agreement has been made between participating entities to use a stronger hash function; a hash function that provides a lower security strength than the (L,N) pair shall not be used. If the output of the hash function is greater than N (i.e., the bit length of q), then the leftmost N bits of the hash function output block shall be used in any calculation using the hash function output during the generation or verification of a digital signature. Special Publication (SP) 800-57 provides information about the selection of the appropriate (L,N) pair in accordance with a desired security strength for a given time period. An (L, N) pair shall be chosen that protects the signed information during the entire expected lifetime of that information. For example, if a digital signature is generated in 2008 for information that needs to be protected for five years, and a particular (L, N) pair is invalid after 2010, then a larger (L, N)pair shall be used that remains valid for the entire period of time that the information needs to be protected. A Federal Government entity other than a Certification Authority (CA) should use only the first three (L, N) pairs (i.e., the (1024, 160), (2048, 224) and (2048, 256) pairs). A CA shall use an (L,N) pair that is equal to or greater than the (L, N) pairs used by its subscribers. For example, if subscribers are using the (2048, 224) pair, then the CA shall use either the (2048, 224), (2048,256) or (3072, 256) pair. Possible exceptions to this rule include cross certification between CAs, certifying keys for purposes other than digital signatures and transitioning from one key size or algorithm to another. See SP 800- 57 for further guidance. =====[ end quote ]===== can increasing the size of a DSA signing key to equal a the size of a DH encryption key be done, and still be a valid V4 key, with larger SHA signatures verifiable by existing open-pgp implementations, or does it need a new key type before it can be done? vedaal Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485 From owner-ietf-openpgp@mail.imc.org Tue Mar 21 19:16:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLqzf-0004EA-4G for openpgp-archive@lists.ietf.org; Tue, 21 Mar 2006 19:14:31 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLqsI-0002jG-KO for openpgp-archive@lists.ietf.org; Tue, 21 Mar 2006 19:06:56 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LNjop3095916; Tue, 21 Mar 2006 16:45:50 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2LNjoeS095915; Tue, 21 Mar 2006 16:45:50 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LNjnAp095908 for ; Tue, 21 Mar 2006 16:45:50 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2LNjdk14930 for ; Tue, 21 Mar 2006 18:45:44 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id k2LNje6c013530 for ; Tue, 21 Mar 2006 18:45:40 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2LNjXAH015637 for ; Tue, 21 Mar 2006 18:45:33 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2LNjWti015636 for ietf-openpgp@imc.org; Tue, 21 Mar 2006 18:45:32 -0500 Date: Tue, 21 Mar 2006 18:45:32 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Suggested changes for DSA2 Message-ID: <20060321234532.GA15554@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Here are some suggested changes for DSA2. I'm sure this will prompt other suggestions - think of this as a starting point. ================================== Section 5.2.2 (Version 3 Signature Packet Format) says: DSA signatures MUST use hashes with a size of 160 bits, to match q, the size of the group generated by the DSA key's generator value. The hash function result is treated as a 160 bit number and used directly in the DSA signature algorithm. change to: DSA signatures MUST use hashes that are equal to or larger than the size of q, the group generated by the DSA key's generator value. If the chosen hash is larger than the size of q, the hash result is truncated to fit by taking the appropriate number of leftmost bits. This (possibly truncated) hash function result is treated as a number and used directly in the DSA signature algorithm. ================================== Section 12.5. (DSA) says: An implementation SHOULD NOT implement DSA keys of size less than 1024 bits. Note that present DSA is limited to a maximum of 1024 bit keys, which are recommended for long-term use. Also, DSA keys MUST be an even multiple of 64 bits long. change to: An implementation SHOULD NOT implement DSA keys of size less than 1024 bits. DSA keys MUST be an even multiple of 64 bits long. The Digital Signature Standard (DSS) specifies that DSA be used in one of the following ways: * 1024-bit key, 160-bit q, SHA-1 hash * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384 or SHA-512 hash * 2048-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash * 3072-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash Other key size and hash combinations are usable in OpenPGP, but would not be compliant to DSS. Note that earlier versions of this standard only supported a 160-bit q, so earlier implementations may not be able to handle a signature with a different q size. DSA keys are a multiple of 64 bits. Are there similar requirements with regards to the size of q that are worth mentioning here? I don't mean the NIST DSS requirements, but rather inherent requirements of the algorithm. ================================== Section 13. (Security Considerations) says: * The DSA algorithm will work with any 160-bit hash, but it is sensitive to the quality of the hash algorithm, if the hash algorithm is broken, it can leak the secret key. The Digital Signature Standard (DSS) specifies that DSA be used with SHA-1. RIPEMD-160 is considered by many cryptographers to be as strong. An implementation should take care which hash algorithms are used with DSA, as a weak hash can not only allow a signature to be forged, but could leak the secret key. change to: * The DSA algorithm will work with any hash, but it is sensitive to the quality of the hash algorithm. An implementation should take care which hash algorithms are used with DSA, as a weak hash can not only allow a signature to be forged, but could leak the secret key. Hal has expressed concern with the "weak hash can leak the secret key" warning in the past, so perhaps he'll comment here. ================================== David From owner-ietf-openpgp@mail.imc.org Fri Mar 24 15:46:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMtAo-0007wQ-5J for openpgp-archive@lists.ietf.org; Fri, 24 Mar 2006 15:46:18 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMtAn-00020o-JH for openpgp-archive@lists.ietf.org; Fri, 24 Mar 2006 15:46:18 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2OKNauw073340; Fri, 24 Mar 2006 13:23:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2OKNaFV073339; Fri, 24 Mar 2006 13:23:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2OKNZXM073333 for ; Fri, 24 Mar 2006 13:23:35 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 8E06257FAE; Fri, 24 Mar 2006 12:21:42 -0800 (PST) To: dshaw@jabberwocky.com, ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-Id: <20060324202142.8E06257FAE@finney.org> Date: Fri, 24 Mar 2006 12:21:42 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f David's suggestions are a good starting point but I have a few comments: > ================================== > > Section 5.2.2 (Version 3 Signature Packet Format) says: > > DSA signatures MUST use hashes with a size of 160 bits, to match q, > the size of the group generated by the DSA key's generator value. > The hash function result is treated as a 160 bit number and used > directly in the DSA signature algorithm. > > change to: > > DSA signatures MUST use hashes that are equal to or larger than > the size of q, the group generated by the DSA key's generator > value. If the chosen hash is larger than the size of q, the hash > result is truncated to fit by taking the appropriate number of > leftmost bits. This (possibly truncated) hash function result is > treated as a number and used directly in the DSA signature > algorithm. First, I think this needs to be moved out of 5.2.2 since it is not specific to V3 signatures; either that, or it needs to be replicated in 5.2.3 on V4 sigs. Actually there is a lot of stuff in 5.2.2 about signatures that does not belong there, a bunch of rules for RSA, OIDs and such. Perhaps this should all go into 5.2.4, Computing Signatures; or into a new section, 5.2.5. Unfortunately for the readability of the document, 5.2.3 is extremely long as it discusses each subpacket, so many people don't necessarily notice 5.2.4 and realize how crucially important it is. I wonder if it would make sense to move the subpackets out of 5.2.3 and into a new 5.2.6 section, so that 5.2.4 and the new 5.2.5 would be right up front with the other data. Aside from this I think David's wording is a little unclear about "the appropriate number" of leftmost bits. Maybe we could say: DSA signatures MUST use hashes that are equal to or larger than the size of q, the group generated by the DSA key's generator value. If the chosen hash is larger than the size of q, the hash result is truncated to fit by taking a number of leftmost bits equal to the number of bits in q. This (possibly truncated) hash function result is treated as a number and used directly in the DSA signature algorithm. Note that this truncation (or non-truncation) could still leave the hash as bigger than q, but that is OK as the signature and validation algorithms will either explicitly or implicitly take it mod q as it is used. So I don't think we have to tell them to take it mod q. > ================================== > > Section 12.5. (DSA) says: > > An implementation SHOULD NOT implement DSA keys of size less than > 1024 bits. Note that present DSA is limited to a maximum of 1024 bit > keys, which are recommended for long-term use. Also, DSA keys MUST > be an even multiple of 64 bits long. > > change to: > > An implementation SHOULD NOT implement DSA keys of size less than > 1024 bits. DSA keys MUST be an even multiple of 64 bits long. > The Digital Signature Standard (DSS) specifies that DSA be used > in one of the following ways: > > * 1024-bit key, 160-bit q, SHA-1 hash > * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384 or SHA-512 hash > * 2048-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash > * 3072-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash > > Other key size and hash combinations are usable in OpenPGP, but > would not be compliant to DSS. > > Note that earlier versions of this standard only supported a > 160-bit q, so earlier implementations may not be able to > handle a signature with a different q size. > > DSA keys are a multiple of 64 bits. Are there similar requirements > with regards to the size of q that are worth mentioning here? I don't > mean the NIST DSS requirements, but rather inherent requirements of > the algorithm. That's a good question. I am uncomfortable permitting larger DSA keys of sizes different than the DSS ones. The balancing of the q and p sizes is something of an art and people tend to disagree somewhat. What size should q be for a 1568 bit modulus? Or a 1024+64=1090 bit one? It's very questionable. I would feel more comfortable restricting to the DSS key sizes even for OpenPGP keys. Is there really much benefit to intermediate sizes? The size of the signature is dependent only on the size of q, and I don't know how we could legitimately scale up from 160 to 224 or 256 as we increase p from 1024 to 2048 bits. Yes, we could come up with some formula, but there would not be much consensus. The FIPS guys undoubtedly faced the same problem and decided to finalize on just these two new sizes, and I am inclined to do the same. > ================================== > > Section 13. (Security Considerations) says: > > * The DSA algorithm will work with any 160-bit hash, but it is > sensitive to the quality of the hash algorithm, if the hash > algorithm is broken, it can leak the secret key. The Digital > Signature Standard (DSS) specifies that DSA be used with SHA-1. > RIPEMD-160 is considered by many cryptographers to be as strong. > An implementation should take care which hash algorithms are > used with DSA, as a weak hash can not only allow a signature to > be forged, but could leak the secret key. > > change to: > > * The DSA algorithm will work with any hash, but it is > sensitive to the quality of the hash algorithm. An > implementation should take care which hash algorithms are > used with DSA, as a weak hash can not only allow a signature to > be forged, but could leak the secret key. > > Hal has expressed concern with the "weak hash can leak the secret key" > warning in the past, so perhaps he'll comment here. Right, I don't believe it is true that a weak hash can leak the secret key. Rather, a weak random choice of the "k" value in the signature can leak the secret key, but that is a completely different issue. As far as this wording, it is OK but it needs to be emphasized for the verifier as much as or more than for the signer. One problem with the new DSS is that it does not specify a unique hash algorithm, hence if any of them break then an attacker could take an existing signature, modify the hash algorithm ID, and perhaps create a fake message that works with that signature and the broken hash. There is nothing the signer can do to prevent this. Even if he uses a strong hash, if there is a broken hash around someone can change the signature to use that hash. So the point is that the verifier more than the signer must make sure that a DSA signature is signed by an acceptably strong hash. If SHA-256 breaks but SHA-512 is still OK it needs to warn on signatures using SHA-256. So I would suggest something like this: * The DSA algorithm will work with any hash, but it is sensitive to the quality of the hash algorithm. An implementation should take care which hash algorithms are used with DSA. Verifiers should be aware that even if the signer used a strong hash, an attacker could have modified a signature to use a weak one. Only signatures issued using acceptably strong hash algorithms should be accepted as valid. Hal Finney From owner-ietf-openpgp@mail.imc.org Fri Mar 24 16:32:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMttT-0001jU-Bs for openpgp-archive@lists.ietf.org; Fri, 24 Mar 2006 16:32:27 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMttS-0004Bb-QT for openpgp-archive@lists.ietf.org; Fri, 24 Mar 2006 16:32:27 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2OLDxhp075358; Fri, 24 Mar 2006 14:13:59 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2OLDxv0075357; Fri, 24 Mar 2006 14:13:59 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2OLDwi3075351 for ; Fri, 24 Mar 2006 14:13:59 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2OLDuk00642; Fri, 24 Mar 2006 16:13:56 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id k2OLDt6c031004; Fri, 24 Mar 2006 16:13:55 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2OLDoXO025378; Fri, 24 Mar 2006 16:13:50 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2OLDoib025377; Fri, 24 Mar 2006 16:13:50 -0500 Date: Fri, 24 Mar 2006 16:13:50 -0500 From: David Shaw To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-ID: <20060324211350.GA25330@jabberwocky.com> Mail-Followup-To: Hal Finney , ietf-openpgp@imc.org References: <20060324202142.8E06257FAE@finney.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060324202142.8E06257FAE@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 On Fri, Mar 24, 2006 at 12:21:42PM -0800, "Hal Finney" wrote: > First, I think this needs to be moved out of 5.2.2 since it is not > specific to V3 signatures; either that, or it needs to be replicated > in 5.2.3 on V4 sigs. Actually there is a lot of stuff in 5.2.2 about > signatures that does not belong there, a bunch of rules for RSA, OIDs > and such. > > Perhaps this should all go into 5.2.4, Computing Signatures; or into a > new section, 5.2.5. Unfortunately for the readability of the document, > 5.2.3 is extremely long as it discusses each subpacket, so many people > don't necessarily notice 5.2.4 and realize how crucially important it is. > I wonder if it would make sense to move the subpackets out of 5.2.3 and > into a new 5.2.6 section, so that 5.2.4 and the new 5.2.5 would be right > up front with the other data. I agree with all this. > Aside from this I think David's wording is a little unclear about "the > appropriate number" of leftmost bits. Maybe we could say: > > DSA signatures MUST use hashes that are equal to or larger than the > size of q, the group generated by the DSA key's generator value. > If the chosen hash is larger than the size of q, the hash result > is truncated to fit by taking a number of leftmost bits equal to > the number of bits in q. This (possibly truncated) hash function > result is treated as a number and used directly in the DSA signature > algorithm. > > Note that this truncation (or non-truncation) could still leave the > hash as bigger than q, but that is OK as the signature and validation > algorithms will either explicitly or implicitly take it mod q as it > is used. So I don't think we have to tell them to take it mod q. I agree with your suggested change, but I'm not sure I follow this comment. How could the hash still be bigger than q if we're explicitly truncating it to be the same size as q? > That's a good question. I am uncomfortable permitting larger DSA > keys of sizes different than the DSS ones. The balancing of the q and > p sizes is something of an art and people tend to disagree somewhat. > What size should q be for a 1568 bit modulus? Or a 1024+64=1090 bit one? > It's very questionable. > > I would feel more comfortable restricting to the DSS key sizes even > for OpenPGP keys. Is there really much benefit to intermediate sizes? > The size of the signature is dependent only on the size of q, and I > don't know how we could legitimately scale up from 160 to 224 or 256 > as we increase p from 1024 to 2048 bits. Yes, we could come up with > some formula, but there would not be much consensus. The FIPS guys > undoubtedly faced the same problem and decided to finalize on just these > two new sizes, and I am inclined to do the same. I wasn't so much thinking about which q to use for intermediate p sizes, but rather thinking more from the verification end: namely, we can't stop people from generating whatever key they like, sensible or not. So rather than defining the set of valid p/q pairs, and presumably rejecting any p or q outside the defined set, I was thinking of just stepping back and saying, in effect, that this isn't our problem to solve. Give SHOULD guidance on what to generate (i.e. the FIPS list), but don't make it a MUST to lock things down to that list. Otherwise, a few years from now, FIPS-186-4 will come out and define a p/q pair not on the FIPS-186-3 list and break all of our implementations. The FIPS draft refers such questions to NIST publication SP800-57, which actually does mention two larger p/q pairs: p=7680 q=384 and p=15360 q=512 (see page 63). Not that I think that a 15360-bit DSA key is useful in practice in 2006, but clearly there is already consideration of other key sizes. > > Hal has expressed concern with the "weak hash can leak the secret key" > > warning in the past, so perhaps he'll comment here. > > Right, I don't believe it is true that a weak hash can leak the secret > key. Rather, a weak random choice of the "k" value in the signature > can leak the secret key, but that is a completely different issue. > > As far as this wording, it is OK but it needs to be emphasized for the > verifier as much as or more than for the signer. One problem with the > new DSS is that it does not specify a unique hash algorithm, hence if > any of them break then an attacker could take an existing signature, > modify the hash algorithm ID, and perhaps create a fake message that > works with that signature and the broken hash. There is nothing the > signer can do to prevent this. Even if he uses a strong hash, if there > is a broken hash around someone can change the signature to use that hash. > So the point is that the verifier more than the signer must make sure that > a DSA signature is signed by an acceptably strong hash. If SHA-256 breaks > but SHA-512 is still OK it needs to warn on signatures using SHA-256. > > So I would suggest something like this: > > * The DSA algorithm will work with any hash, but it is > sensitive to the quality of the hash algorithm. An implementation > should take care which hash algorithms are used with DSA. > Verifiers should be aware that even if the signer used a strong > hash, an attacker could have modified a signature to use a > weak one. Only signatures issued using acceptably strong hash > algorithms should be accepted as valid. Agreed. David From owner-ietf-openpgp@mail.imc.org Sun Mar 26 06:43:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNTeL-0000Iw-FP for openpgp-archive@lists.ietf.org; Sun, 26 Mar 2006 06:43:13 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNTeK-0004rF-3e for openpgp-archive@lists.ietf.org; Sun, 26 Mar 2006 06:43:13 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QBEQF2020808; Sun, 26 Mar 2006 04:14:27 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2QBEQpV020807; Sun, 26 Mar 2006 04:14:26 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QBEPKX020800 for ; Sun, 26 Mar 2006 04:14:26 -0700 (MST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 15BF233C1C; Sun, 26 Mar 2006 12:14:24 +0100 (BST) Message-ID: <44267719.1060302@algroup.co.uk> Date: Sun, 26 Mar 2006 12:12:25 +0100 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Jon Callas CC: OpenPGP Subject: Re: NIST publishes new DSA draft References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> <441ACF45.704@systemics.com> <87fylhdq36.fsf@wheatstone.g10code.de> <20060317174937.GC13241@jabberwocky.com> <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> In-Reply-To: <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Jon Callas wrote: > > I think we ought to keep it with the same algorithm number. > > I'm happy to put in SHA-224 (meaning it's trivial work), but I don't > like it, myself. The reason is that SHA-224 is really a truncated > SHA-256. Thus, it has no advantages over SHA-256 except being smaller by > 32-bits with 112 bits of security. The reason it exists at all is for > crypto-balance with 2-key 3DES (which is not TDEA), which we don't allow > at all. 3-key DES also has a strength of 112 bits. > I don't think we should have it as it goes against our > principles of wanting a minimum of 128-bits of security in OpenPGP. > (Yes, yes, I know that SHA-1 doesn't meet this either, but until > SHA-256, we didn't have many options. That doesn't mean the principle is > wrong; we *have* options.) > > Jon > > -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-ietf-openpgp@mail.imc.org Sun Mar 26 10:09:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNWrk-0002IR-IE for openpgp-archive@lists.ietf.org; Sun, 26 Mar 2006 10:09:16 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNWrj-0003oC-6G for openpgp-archive@lists.ietf.org; Sun, 26 Mar 2006 10:09:16 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QEmdP7028514; Sun, 26 Mar 2006 07:48:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2QEmdkD028513; Sun, 26 Mar 2006 07:48:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QEmcOI028507 for ; Sun, 26 Mar 2006 07:48:38 -0700 (MST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 7D10033C1C; Sun, 26 Mar 2006 15:48:37 +0100 (BST) Message-ID: <4426A94F.6050806@algroup.co.uk> Date: Sun, 26 Mar 2006 15:46:39 +0100 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Hal Finney CC: dshaw@jabberwocky.com, ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 References: <20060324202142.8E06257FAE@finney.org> In-Reply-To: <20060324202142.8E06257FAE@finney.org> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hal Finney wrote: > DSA signatures MUST use hashes that are equal to or larger than the > size of q, the group generated by the DSA key's generator value. > If the chosen hash is larger than the size of q, the hash result > is truncated to fit by taking a number of leftmost bits equal to > the number of bits in q. This (possibly truncated) hash function > result is treated as a number and used directly in the DSA signature > algorithm. > > Note that this truncation (or non-truncation) could still leave the > hash as bigger than q, but that is OK as the signature and validation > algorithms will either explicitly or implicitly take it mod q as it > is used. So I don't think we have to tell them to take it mod q. Not sure what you mean by this - the point is that the hash should end up with the same number of bits as q. BTW, I don't believe truncation is actually required mathematically, but it is presumably more efficient to truncate. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-ietf-openpgp@mail.imc.org Sun Mar 26 11:47:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNYOv-0000yp-0k for openpgp-archive@lists.ietf.org; Sun, 26 Mar 2006 11:47:37 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNYOu-00074p-Jb for openpgp-archive@lists.ietf.org; Sun, 26 Mar 2006 11:47:37 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QGNnln032358; Sun, 26 Mar 2006 09:23:49 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2QGNn1j032357; Sun, 26 Mar 2006 09:23:49 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QGNnQF032351 for ; Sun, 26 Mar 2006 09:23:49 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2QGNlk12030 for ; Sun, 26 Mar 2006 11:23:47 -0500 Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.13.6/8.13.5) with ESMTP id k2QGNi9P019499 for ; Sun, 26 Mar 2006 11:23:44 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2QGNfxK022185 for ; Sun, 26 Mar 2006 11:23:41 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2QGNfch022184 for ietf-openpgp@imc.org; Sun, 26 Mar 2006 11:23:41 -0500 Date: Sun, 26 Mar 2006 11:23:41 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Suggested changes for DSA2, take 2 Message-ID: <20060326162341.GE30637@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Here is some revised suggested DSA2 language, taking Hal's comments into account and adding some extra polish. While I agree with his suggestion to reorganize the signature sections, I'm reluctant to get into that in this mail as I think that getting general consensus on DSA2 language would be easier if the two weren't combined. I'd be happy to take it up separately though. ================================== Section 5.2.2 (Version 3 Signature Packet Format) says: DSA signatures MUST use hashes with a size of 160 bits, to match q, the size of the group generated by the DSA key's generator value. The hash function result is treated as a 160 bit number and used directly in the DSA signature algorithm. change to: DSA signatures MUST use hashes that are equal to or larger than the size of q, the group generated by the DSA key's generator value. If the chosen hash is larger than the size of q, the hash result is truncated to fit by taking a number of leftmost bits equal to the number of bits in q. This (possibly truncated) hash function result is treated as a number and used directly in the DSA signature algorithm. ================================== Section 12.5. (DSA) says: An implementation SHOULD NOT implement DSA keys of size less than 1024 bits. Note that present DSA is limited to a maximum of 1024 bit keys, which are recommended for long-term use. Also, DSA keys MUST be an even multiple of 64 bits long. change to: An implementation SHOULD NOT implement DSA keys of size less than 1024 bits or with a q size of less than 160 bits. DSA keys MUST be an even multiple of 64 bits long. The Digital Signature Standard (DSS) specifies that DSA be used in one of the following ways: * 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384 or SHA-512 hash * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384 or SHA-512 hash * 2048-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash * 3072-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash Implementations SHOULD use one of the above key and q size pairs when generating DSA keys. For full DSS compliance, one of the specified SHA hashes must be used as well. Note that earlier versions of this standard only allowed a 160-bit q with no truncation allowed, so earlier implementations may not be able to handle signatures with a different q size or a truncated hash. The intent here is to say we really want you to use these p/q sizes, and if you want to be DSS-compliant, you need to use these hashes too. I removed the bit about how other key sizes, q sizes, and hashes were legal as it really just restates the same thing again. ================================== Section 13. (Security Considerations) says: * The DSA algorithm will work with any 160-bit hash, but it is sensitive to the quality of the hash algorithm, if the hash algorithm is broken, it can leak the secret key. The Digital Signature Standard (DSS) specifies that DSA be used with SHA-1. RIPEMD-160 is considered by many cryptographers to be as strong. An implementation should take care which hash algorithms are used with DSA, as a weak hash can not only allow a signature to be forged, but could leak the secret key. change to: * The DSA algorithm will work with any hash, but is sensitive to the quality of the hash algorithm. An implementation should take care which hash algorithms are used with DSA. Verifiers should be aware that even if the signer used a strong hash, an attacker could have modified the signature to use a weak one. Only signatures using acceptably strong hash algorithms should be accepted as valid. ================================== David From owner-ietf-openpgp@mail.imc.org Sun Mar 26 12:39:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNZDP-00071h-AV for openpgp-archive@lists.ietf.org; Sun, 26 Mar 2006 12:39:47 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNZDN-0000Ir-Ul for openpgp-archive@lists.ietf.org; Sun, 26 Mar 2006 12:39:47 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QHNEVi034960; Sun, 26 Mar 2006 10:23:14 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2QHNEKc034959; Sun, 26 Mar 2006 10:23:14 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QHND07034953 for ; Sun, 26 Mar 2006 10:23:13 -0700 (MST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 8CABD33C1C for ; Sun, 26 Mar 2006 18:23:12 +0100 (BST) Message-ID: <4426CD8A.4080105@algroup.co.uk> Date: Sun, 26 Mar 2006 18:21:14 +0100 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2, take 2 References: <20060326162341.GE30637@jabberwocky.com> In-Reply-To: <20060326162341.GE30637@jabberwocky.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 David Shaw wrote: > Here is some revised suggested DSA2 language, taking Hal's comments > into account and adding some extra polish. While I agree with his > suggestion to reorganize the signature sections, I'm reluctant to get > into that in this mail as I think that getting general consensus on > DSA2 language would be easier if the two weren't combined. I'd be > happy to take it up separately though. > > ================================== > > Section 5.2.2 (Version 3 Signature Packet Format) says: > > DSA signatures MUST use hashes with a size of 160 bits, to match q, > the size of the group generated by the DSA key's generator value. > The hash function result is treated as a 160 bit number and used > directly in the DSA signature algorithm. > > change to: > > DSA signatures MUST use hashes that are equal to or larger than language nit: "equal in size to" > the size of q, the group generated by the DSA key's generator > value. If the chosen hash is larger than the size of q, the hash > result is truncated to fit by taking a number of leftmost bits > equal to the number of bits in q. This (possibly truncated) hash > function result is treated as a number and used directly in the > DSA signature algorithm. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-ietf-openpgp@mail.imc.org Sun Mar 26 13:24:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNZuY-0008F3-W3 for openpgp-archive@lists.ietf.org; Sun, 26 Mar 2006 13:24:22 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNZuW-0002qM-Hn for openpgp-archive@lists.ietf.org; Sun, 26 Mar 2006 13:24:22 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QI44kw037256; Sun, 26 Mar 2006 11:04:04 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2QI44Aq037255; Sun, 26 Mar 2006 11:04:04 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QI43t2037249 for ; Sun, 26 Mar 2006 11:04:03 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 12C8057FAE; Sun, 26 Mar 2006 10:02:18 -0800 (PST) To: dshaw@jabberwocky.com, hal@finney.org Subject: Re: Suggested changes for DSA2 Cc: ietf-openpgp@imc.org Message-Id: <20060326180218.12C8057FAE@finney.org> Date: Sun, 26 Mar 2006 10:02:18 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 David Shaw writes: > On Fri, Mar 24, 2006 at 12:21:42PM -0800, "Hal Finney" wrote: > > Aside from this I think David's wording is a little unclear about "the > > appropriate number" of leftmost bits. Maybe we could say: > > > > DSA signatures MUST use hashes that are equal to or larger than the > > size of q, the group generated by the DSA key's generator value. > > If the chosen hash is larger than the size of q, the hash result > > is truncated to fit by taking a number of leftmost bits equal to > > the number of bits in q. This (possibly truncated) hash function > > result is treated as a number and used directly in the DSA signature > > algorithm. > > > > Note that this truncation (or non-truncation) could still leave the > > hash as bigger than q, but that is OK as the signature and validation > > algorithms will either explicitly or implicitly take it mod q as it > > is used. So I don't think we have to tell them to take it mod q. > > I agree with your suggested change, but I'm not sure I follow this > comment. How could the hash still be bigger than q if we're > explicitly truncating it to be the same size as q? For example, we have a 1024 bit key with a 160 bit q. We truncate a SHA-256 hash to 160 bits. But q < 2^160, hence the truncated hash can still be greater than q, i.e. q < trunc(hash) < 2^160. I see that my proposed text still has this somewhat ambiguous reference to "the size of q". It also refers to the size of the chosen hash when it should say the output size. If I fix those two it becomes: DSA signatures MUST use hashes whose output size is equal to or larger than the number of bits of q, the group generated by the DSA key's generator value. If the output size of the chosen hash is larger than the number of bits of q, the hash result is truncated to fit by taking a number of leftmost bits equal to the number of bits of q. This (possibly truncated) hash function result is treated as a number and used directly in the DSA signature algorithm. Regarding the question of whether to allow intermediate sizes: > I wasn't so much thinking about which q to use for intermediate p > sizes, but rather thinking more from the verification end: namely, we > can't stop people from generating whatever key they like, sensible or > not. So rather than defining the set of valid p/q pairs, and > presumably rejecting any p or q outside the defined set, I was > thinking of just stepping back and saying, in effect, that this isn't > our problem to solve. Give SHOULD guidance on what to generate > (i.e. the FIPS list), but don't make it a MUST to lock things down to > that list. Otherwise, a few years from now, FIPS-186-4 will come out > and define a p/q pair not on the FIPS-186-3 list and break all of our > implementations. > > The FIPS draft refers such questions to NIST publication SP800-57, > which actually does mention two larger p/q pairs: p=7680 q=384 and > p=15360 q=512 (see page 63). Not that I think that a 15360-bit DSA > key is useful in practice in 2006, but clearly there is already > consideration of other key sizes. It's always a tricky question, how much we should try to enforce security standards in a data-format document. We do put minimum length restrictions on the moduli to try to protect users against making one kind of mistake, using a too-short key. In the same way, I don't think we should allow them to use a 160-bit q for a 3072-bit p. This is the spirit behind my suggestion to just allow the NIST sizes. Allowing the bigger sizes would also be consistent with this proposal but I don't think everyone would want to support those. > > * The DSA algorithm will work with any hash, but it is > > sensitive to the quality of the hash algorithm. An implementation > > should take care which hash algorithms are used with DSA. > > Verifiers should be aware that even if the signer used a strong > > hash, an attacker could have modified a signature to use a > > weak one. Only signatures issued using acceptably strong hash > > algorithms should be accepted as valid. On re-reading this I have two improvements. The second sentence is redundant. And the last sentence cautions verifiers about what hash was used when the sig was "issued", but the verifier doesn't know this (that is the point), it only knows what it sees: * The DSA algorithm will work with any hash, but it is sensitive to the quality of the hash algorithm. Verifiers should be aware that even if the signer used a strong hash, an attacker could have modified a signature to use a weak one. Only signatures using acceptably strong hash algorithms should be accepted as valid. Hal Finney From owner-ietf-openpgp@mail.imc.org Sun Mar 26 17:19:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNdZo-0003lR-PM for openpgp-archive@lists.ietf.org; Sun, 26 Mar 2006 17:19:12 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNdZn-0003LK-DE for openpgp-archive@lists.ietf.org; Sun, 26 Mar 2006 17:19:12 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QLtkJn046188; Sun, 26 Mar 2006 14:55:46 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2QLtkPR046187; Sun, 26 Mar 2006 14:55:46 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QLtjgs046181 for ; Sun, 26 Mar 2006 14:55:45 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2QLtdk13445; Sun, 26 Mar 2006 16:55:39 -0500 Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.13.6/8.13.5) with ESMTP id k2QLtbEU002855; Sun, 26 Mar 2006 16:55:37 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2QLtWCC023209; Sun, 26 Mar 2006 16:55:32 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2QLtVNm023208; Sun, 26 Mar 2006 16:55:31 -0500 Date: Sun, 26 Mar 2006 16:55:31 -0500 From: David Shaw To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-ID: <20060326215531.GF30637@jabberwocky.com> Mail-Followup-To: Hal Finney , ietf-openpgp@imc.org References: <20060326180218.12C8057FAE@finney.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060326180218.12C8057FAE@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Sun, Mar 26, 2006 at 10:02:18AM -0800, "Hal Finney" wrote: > It's always a tricky question, how much we should try to enforce > security standards in a data-format document. We do put minimum length > restrictions on the moduli to try to protect users against making one > kind of mistake, using a too-short key. In the same way, I don't think > we should allow them to use a 160-bit q for a 3072-bit p. This is the > spirit behind my suggestion to just allow the NIST sizes. I think we more or less agree on this. My only sticking point is the idea of allowing people to do something other than the NIST sizes. How about we make the NIST sizes a SHOULD (like the minimum length restrictions are SHOULD NOTs), and add a sentence after that to read something like "Caution should be taken when deviating from the above parameters which were carefully chosen to balance the strength of the hash with the strength of the key." ? That would seem to be the best of all worlds: we strongly advise people to use the NIST sizes, tell them why we want them to use the NIST sizes, but don't lock them down. David From owner-ietf-openpgp@mail.imc.org Mon Mar 27 08:43:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNrzp-0004RI-Vf for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 08:43:01 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNrzn-0006kk-GO for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 08:43:01 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RDLxjH086420; Mon, 27 Mar 2006 06:21:59 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RDLxPF086419; Mon, 27 Mar 2006 06:21:59 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RDLwrx086413 for ; Mon, 27 Mar 2006 06:21:59 -0700 (MST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 1733C41679; Mon, 27 Mar 2006 14:21:57 +0100 (BST) Message-ID: <4427E67A.8050202@systemics.com> Date: Mon, 27 Mar 2006 15:19:54 +0200 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Shaw Cc: Hal Finney , ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 References: <20060326180218.12C8057FAE@finney.org> <20060326215531.GF30637@jabberwocky.com> In-Reply-To: <20060326215531.GF30637@jabberwocky.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 David Shaw wrote: > On Sun, Mar 26, 2006 at 10:02:18AM -0800, "Hal Finney" wrote: > > >>It's always a tricky question, how much we should try to enforce >>security standards in a data-format document. We do put minimum length >>restrictions on the moduli to try to protect users against making one >>kind of mistake, using a too-short key. In the same way, I don't think >>we should allow them to use a 160-bit q for a 3072-bit p. This is the >>spirit behind my suggestion to just allow the NIST sizes. > > > I think we more or less agree on this. My only sticking point is the > idea of allowing people to do something other than the NIST sizes. > How about we make the NIST sizes a SHOULD (like the minimum length > restrictions are SHOULD NOTs), and add a sentence after that to read > something like "Caution should be taken when deviating from the above > parameters which were carefully chosen to balance the strength of the > hash with the strength of the key." ? > > That would seem to be the best of all worlds: we strongly advise > people to use the NIST sizes, tell them why we want them to use the > NIST sizes, but don't lock them down. The question is more whether a receiving implementation should / may read non-preferred sizes. My inclination is to reduce them wherever possible. I've yet to see a real case where it has been useful to have non-standard sizes, and I've seen many cases where incompatibilities have sprung from overly broad readings of what was allowed. There's also no need for the standard to say this at all. If there was a need for a variant, then the various implementations can try it out and implement it as a non- standard variant. I would vote for just allowing a subset of the NIST sizes. That is, something like an implementation MUST accept the NIST set, and SHOULD reject all others. If a need for a variant comes up, the developers have to battle it out and justify going up against the SHOULD. If there is a clear need, then they'll work it out. iang PS: was it Bernstein who said, be precise in what you output, and be precise in what you accept for input? From owner-ietf-openpgp@mail.imc.org Mon Mar 27 10:28:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNtdu-0000Ne-CE for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 10:28:30 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNtdt-0003Du-0i for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 10:28:30 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RF1T1F090912; Mon, 27 Mar 2006 08:01:29 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RF1TuU090911; Mon, 27 Mar 2006 08:01:29 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RF1SLm090905 for ; Mon, 27 Mar 2006 08:01:28 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2RF1Qk17454; Mon, 27 Mar 2006 10:01:26 -0500 Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.13.6/8.13.5) with ESMTP id k2RF1Rcw013654; Mon, 27 Mar 2006 10:01:27 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2RF1KPw025477; Mon, 27 Mar 2006 10:01:20 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2RF1KYG025476; Mon, 27 Mar 2006 10:01:20 -0500 Date: Mon, 27 Mar 2006 10:01:20 -0500 From: David Shaw To: Ian G Cc: Hal Finney , ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-ID: <20060327150120.GA25414@jabberwocky.com> Mail-Followup-To: Ian G , Hal Finney , ietf-openpgp@imc.org References: <20060326180218.12C8057FAE@finney.org> <20060326215531.GF30637@jabberwocky.com> <4427E67A.8050202@systemics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4427E67A.8050202@systemics.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f On Mon, Mar 27, 2006 at 03:19:54PM +0200, Ian G wrote: > I would vote for just allowing a subset of the NIST sizes. > That is, something like an implementation MUST accept the > NIST set, and SHOULD reject all others. If a need for a > variant comes up, the developers have to battle it out and > justify going up against the SHOULD. If there is a clear > need, then they'll work it out. It is not the place of a data format standard to hold people's hands to that extent. We (correctly) don't tell people to reject signatures from a 512-bit RSA key. That's not our job in the standard. If an *implementation* wants to do that, that's just fine, but it does not need permission from the standard to do it. David From owner-ietf-openpgp@mail.imc.org Mon Mar 27 10:49:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNtxy-0003aX-Sp for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 10:49:14 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNtxy-0004AO-HL for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 10:49:14 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RFO6vi092599; Mon, 27 Mar 2006 08:24:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RFO6UK092598; Mon, 27 Mar 2006 08:24:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RFO1we092591 for ; Mon, 27 Mar 2006 08:24:05 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2RFO0k17499; Mon, 27 Mar 2006 10:24:00 -0500 Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.13.6/8.13.5) with ESMTP id k2RFO1GT014059; Mon, 27 Mar 2006 10:24:01 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2RFNsnB025570; Mon, 27 Mar 2006 10:23:54 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2RFNsGT025569; Mon, 27 Mar 2006 10:23:54 -0500 Date: Mon, 27 Mar 2006 10:23:54 -0500 From: David Shaw To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-ID: <20060327152354.GB25414@jabberwocky.com> Mail-Followup-To: Hal Finney , ietf-openpgp@imc.org References: <20060326180218.12C8057FAE@finney.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060326180218.12C8057FAE@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On Sun, Mar 26, 2006 at 10:02:18AM -0800, "Hal Finney" wrote: > > > * The DSA algorithm will work with any hash, but it is > > > sensitive to the quality of the hash algorithm. An implementation > > > should take care which hash algorithms are used with DSA. > > > Verifiers should be aware that even if the signer used a strong > > > hash, an attacker could have modified a signature to use a > > > weak one. Only signatures issued using acceptably strong hash > > > algorithms should be accepted as valid. > > On re-reading this I have two improvements. The second sentence is > redundant. And the last sentence cautions verifiers about what hash > was used when the sig was "issued", but the verifier doesn't know this > (that is the point), it only knows what it sees: > > * The DSA algorithm will work with any hash, but it is > sensitive to the quality of the hash algorithm. Verifiers > should be aware that even if the signer used a strong hash, > an attacker could have modified a signature to use a weak one. > Only signatures using acceptably strong hash algorithms should > be accepted as valid. Yes, I made a similar change in the "round 2" changes for the same reason. I've fixed the redundant second sentence for round 3. David From owner-ietf-openpgp@mail.imc.org Mon Mar 27 10:58:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNu6e-0001Xi-EX for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 10:58:12 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNu6e-0004MT-13 for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 10:58:12 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RFVPqc093064; Mon, 27 Mar 2006 08:31:25 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RFVP8N093063; Mon, 27 Mar 2006 08:31:25 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RFVO6D093057 for ; Mon, 27 Mar 2006 08:31:24 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2RFVNk17528 for ; Mon, 27 Mar 2006 10:31:23 -0500 Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.13.6/8.13.5) with ESMTP id k2RFVOF8014146 for ; Mon, 27 Mar 2006 10:31:24 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2RFVHoU025589 for ; Mon, 27 Mar 2006 10:31:17 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2RFVHIx025588 for ietf-openpgp@imc.org; Mon, 27 Mar 2006 10:31:17 -0500 Date: Mon, 27 Mar 2006 10:31:17 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Suggested changes for DSA2, take 3 Message-ID: <20060327153117.GA25534@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Here is round three with suggested changes from Hal and Ben. ================================== Section 5.2.2 (Version 3 Signature Packet Format) says: DSA signatures MUST use hashes with a size of 160 bits, to match q, the size of the group generated by the DSA key's generator value. The hash function result is treated as a 160 bit number and used directly in the DSA signature algorithm. change to: DSA signatures MUST use hashes that are equal in size to the number of bits of q, the group generated by the DSA key's generator value. If the output size of the chosen hash is larger than the number of bits of q, the hash result is truncated to fit by taking the number of leftmost bits equal to the number of bits of q. This (possibly truncated) hash function result is treated as a number and used directly in the DSA signature algorithm. Changes from both Hal and Ben. ================================== Section 12.5. (DSA) says: An implementation SHOULD NOT implement DSA keys of size less than 1024 bits. Note that present DSA is limited to a maximum of 1024 bit keys, which are recommended for long-term use. Also, DSA keys MUST be an even multiple of 64 bits long. change to: An implementation SHOULD NOT implement DSA keys of size less than 1024 bits or with a q size of less than 160 bits. DSA keys MUST also be an even multiple of 64 bits long. The Digital Signature Standard (DSS) [FIPS186] specifies that DSA be used in one of the following ways: * 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384 or SHA-512 hash * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384 or SHA-512 hash * 2048-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash * 3072-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash The above key and q size pairs were chosen to best balance the strength of the key with the strength of the hash. Implementations SHOULD use one of the above key and q size pairs when generating DSA keys. If DSS compliance is desired, one of the specified SHA hashes must be used as well. [FIPS186] is the ultimate authority on DSS, and should be consulted for all questions of DSS compliance. Note that earlier versions of this standard only allowed a 160-bit q with no truncation allowed, so earlier implementations may not be able to handle signatures with a different q size or a truncated hash. Added a reminder why we really, really want people to use one of the four DSS p/q pairs, plus a change with regards to referring people to FIPS186 for the DSS spec. DSS has other requirements besides the four p/q sizes and list of SHA hashes, and the original language implied that using the right size and right hash was enough for DSS compliance. ================================== Section 13. (Security Considerations) says: * The DSA algorithm will work with any 160-bit hash, but it is sensitive to the quality of the hash algorithm, if the hash algorithm is broken, it can leak the secret key. The Digital Signature Standard (DSS) specifies that DSA be used with SHA-1. RIPEMD-160 is considered by many cryptographers to be as strong. An implementation should take care which hash algorithms are used with DSA, as a weak hash can not only allow a signature to be forged, but could leak the secret key. change to: * The DSA algorithm will work with any hash, but is sensitive to the quality of the hash algorithm. Verifiers should be aware that even if the signer used a strong hash, an attacker could have modified the signature to use a weak one. Only signatures using acceptably strong hash algorithms should be accepted as valid. Change from Hal. ================================== David From owner-ietf-openpgp@mail.imc.org Mon Mar 27 11:15:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNuNY-0001K6-AM for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 11:15:40 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNuNW-0005Eh-VL for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 11:15:40 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RFiclN093522; Mon, 27 Mar 2006 08:44:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RFicr7093521; Mon, 27 Mar 2006 08:44:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RFib10093467 for ; Mon, 27 Mar 2006 08:44:37 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id D6CDD5456; Mon, 27 Mar 2006 17:44:27 +0200 (CEST) Date: Mon, 27 Mar 2006 17:44:27 +0200 To: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-ID: <20060327154427.GC7346@epointsystem.org> References: <20060326180218.12C8057FAE@finney.org> <20060326215531.GF30637@jabberwocky.com> <4427E67A.8050202@systemics.com> <20060327150120.GA25414@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060327150120.GA25414@jabberwocky.com> User-Agent: Mutt/1.5.9i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On Mon, Mar 27, 2006 at 10:01:20AM -0500, David Shaw wrote: > It is not the place of a data format standard to hold people's hands > to that extent. We (correctly) don't tell people to reject signatures > from a 512-bit RSA key. That's not our job in the standard. If an > *implementation* wants to do that, that's just fine, but it does not > need permission from the standard to do it. I agree with David here. The standard's purpose is to ensure interoperability. It should tell us the sematics behind sequences of bytes. It is up to the implementation to make decisions based on these semantics. Valid reasons to exclude certain combinations from the standard include ambiguity of interpretation, inherent insecurity or a wide installed base of incompatible implementations, but not the possibility of weird uses, IMHO. Regards, -- Daniel From owner-ietf-openpgp@mail.imc.org Mon Mar 27 15:24:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNyGZ-0002lW-Cp for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 15:24:43 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNyGX-0007fc-Rb for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 15:24:43 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RK0TDN083228; Mon, 27 Mar 2006 13:00:29 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RK0TUD083227; Mon, 27 Mar 2006 13:00:29 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RK0T0Z083197 for ; Mon, 27 Mar 2006 13:00:29 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7); Mon, 27 Mar 2006 12:00:24 -0800 Received: from [63.251.255.205] ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Mon, 27 Mar 2006 12:00:24 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 27 Mar 2006 12:00:24 -0800 In-Reply-To: <44267719.1060302@algroup.co.uk> References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> <441ACF45.704@systemics.com> <87fylhdq36.fsf@wheatstone.g10code.de> <20060317174937.GC13241@jabberwocky.com> <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> <44267719.1060302@algroup.co.uk> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: OpenPGP Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: NIST publishes new DSA draft Date: Mon, 27 Mar 2006 12:00:20 -0800 To: Ben Laurie X-Mailer: Apple Mail (2.746.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 On 26 Mar 2006, at 3:12 AM, Ben Laurie wrote: > Jon Callas wrote: >> >> I think we ought to keep it with the same algorithm number. >> >> I'm happy to put in SHA-224 (meaning it's trivial work), but I don't >> like it, myself. The reason is that SHA-224 is really a truncated >> SHA-256. Thus, it has no advantages over SHA-256 except being >> smaller by >> 32-bits with 112 bits of security. The reason it exists at all is for >> crypto-balance with 2-key 3DES (which is not TDEA), which we don't >> allow >> at all. > > > > 3-key DES also has a strength of 112 bits. > > > There are certainly good arguments for that, but if 3-key 3DES is no stronger than 2-key, then there shouldn't be any harm in dropping the third key. Right? If you don't like this idea (that 2-key and 3-key are equivalent), which I don't, then 3-key must be some stronger. It just isn't easy to know how much more. I wrote a long thing on this a couple years ago at: Jon From owner-ietf-openpgp@mail.imc.org Mon Mar 27 16:49:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNzaP-0005dd-3F for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 16:49:17 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNzaO-0005KK-Bg for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 16:49:17 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RLQSPL017924; Mon, 27 Mar 2006 14:26:28 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RLQSUB017923; Mon, 27 Mar 2006 14:26:28 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RLQRZH017916 for ; Mon, 27 Mar 2006 14:26:27 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7) for ; Mon, 27 Mar 2006 13:25:40 -0800 Received: from [63.251.255.205] ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Mon, 27 Mar 2006 13:25:40 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 27 Mar 2006 13:25:40 -0800 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <20060327154427.GC7346@epointsystem.org> References: <20060326180218.12C8057FAE@finney.org> <20060326215531.GF30637@jabberwocky.com> <4427E67A.8050202@systemics.com> <20060327150120.GA25414@jabberwocky.com> <20060327154427.GC7346@epointsystem.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <23598E55-F454-4ED8-B3C7-7B716FDC3205@callas.org> Cc: OpenPGP Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: Suggested changes for DSA2 Date: Mon, 27 Mar 2006 13:25:38 -0800 X-Mailer: Apple Mail (2.746.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f On 27 Mar 2006, at 7:44 AM, Daniel A. Nagy wrote: > I agree with David here. The standard's purpose is to ensure > interoperability. It should tell us the sematics behind sequences > of bytes. > It is up to the implementation to make decisions based on these > semantics. > Valid reasons to exclude certain combinations from the standard > include > ambiguity of interpretation, inherent insecurity or a wide > installed base of > incompatible implementations, but not the possibility of weird > uses, IMHO. > I agree as well with both Davids. As an observation, in 2440 one of the things we allowed was deviation from DSS because the rough consensus had a certain amount of grumpiness with the US Government. In practice, hardly anyone did anything different with DSA than DSS. We even removed hash functions. Many things have changed in the last decade, but toeing the exact NIST line or even being like them only moreso is going a bit too far. In the next decade, we're going to see a lot of advancement in hash functions. Someone is going to want to use those new hash functions with DSA, and it would be nice to be able to move faster than NIST. Let's suppose someone comes up with a new hash function that is 251 bits. (I picked 251 because it's prime and less than 256.) We don't want a constitutional crisis over using it. We want to be flexible enough that it's pretty obvious how to extend OpenPGP to use new hash functions with DSA. Jon From owner-ietf-openpgp@mail.imc.org Mon Mar 27 16:49:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNzaP-0005dm-4L for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 16:49:17 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNzaO-0005KL-Bf for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 16:49:17 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RLSLjF018913; Mon, 27 Mar 2006 14:28:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RLSLKR018909; Mon, 27 Mar 2006 14:28:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RLSKgR018888 for ; Mon, 27 Mar 2006 14:28:20 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7) for ; Mon, 27 Mar 2006 13:28:14 -0800 Received: from [63.251.255.205] ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Mon, 27 Mar 2006 13:28:14 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 27 Mar 2006 13:28:14 -0800 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <44284CDB.9040504@algroup.co.uk> References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> <441ACF45.704@systemics.com> <87fylhdq36.fsf@wheatstone.g10code.de> <20060317174937.GC13241@jabberwocky.com> <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> <44267719.1060302@algroup.co.uk> <44284CDB.9040504@algroup.co.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <494A8BEE-97D3-4B31-92C3-D67A645D8EE0@callas.org> Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: NIST publishes new DSA draft Date: Mon, 27 Mar 2006 13:28:13 -0800 To: OpenPGP X-Mailer: Apple Mail (2.746.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a On 27 Mar 2006, at 12:36 PM, Ben Laurie wrote: > > I'm not going to argue with this, but it clearly ain't much more. You > would be out on a limb to argue that it provided usefully more than > 112 > bits - though I won't hesitate to agree that 2DES < 3DES. > Ben, I think we're far closer to agreeing than disagreeing. During The Crypto Wars, we crypto-proponents made a point of saying that the minimum crypto we'd live with was 128-bit. The reasons for this had as much to do with the simple mathematical fact that 128 was the next convenient power of two as anything else. So therefore, viva IDEA, viva CAST, viva Blowfish. A lot of it was also just sheer politics. But what about three-key 3DES? Collectively, we agreed to include it as a "128-bit" cipher (the quotes are there to mean quasi-, or so- called). The reasons for this were also mostly politics. It would have been unwise to say, "ooo, ick, 3DES" and in fact in this group, arguably the most political standards group of them all, we not only *accepted* 3DES as 128-bit cipher, but made it the MUST. That was also mostly a political decision. It saved us a long, acrimonious argument about Blowfish and CAST with side trips along 3DES itself, DES/X, SAFER and others. Bravi us. (Personally, I say "3DES" to mean three-key-3DES. I consider the two-key version to be some unmentioned step-down, kinda the way that Blowfish will work with 32-bit keys. It's true, but we don't even grace it with a mention.) Reality is a collective hunch, especially in the IETF. The hunch is that 3DES is as good as IDEA, CAST, Blowfish, etc. Now, a decade later, we all mostly use AES. In fact, we mostly use AES-256, and that for marketing reasons. AES-128 runs faster than single-DES, and AES-256 is only 20% slower than -128, so there is pressure to step up to 256-bit keys. People do it because all the other kids are doing it, not for security. You are right that we've *agreed* that 3DES is a "128"-bit algorithm and there's no math to back it up. As fantasies (or collective hunches) go, it's not a bad one. The strength of 3DES all revolves around how much it's not a group. It appears to be enough of a non- group that this isn't a mad thought. Better, though, to just use AES. Or Twofish. Or petition the group to put Serpent in. Nonetheless, getting back to the hash functions, the *only* reason to use SHA-224 is that you have an application where a 28-byte hash will work and a 32-byte one will not. If one person thinks that's important for engineering reasons, I'm happy to have it in. If zero people think it has engineering value, then less is more. We don't need another hash function with no obvious value because in the future there will be more hash functions. Save room on the bus for the ones that aren't born yet. Jon From owner-ietf-openpgp@mail.imc.org Mon Mar 27 17:13:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNzxi-00058C-SI for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 17:13:22 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNzxh-0006wq-I7 for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 17:13:22 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RLt9ei021568; Mon, 27 Mar 2006 14:55:09 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RLt9qM021567; Mon, 27 Mar 2006 14:55:09 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from XBOX.spatialrift.com (xbox.spatialrift.com [64.146.111.237]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RLt8QN021561 for ; Mon, 27 Mar 2006 14:55:08 -0700 (MST) (envelope-from postmaster@mypgp.com) Received: from ([127.0.0.1]) with MailEnable ESMTP; Mon, 27 Mar 2006 15:50:01 -0600 Message-ID: <44285ED5.9050505@mypgp.com> Date: Mon, 27 Mar 2006 15:53:25 -0600 From: Sean Heeger Reply-To: postmaster@mypgp.com Organization: MyPGP.Com - Public PGP Resources User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: OpenPGP X-Enigmail-Version: 0.94.0.0 OpenPGP: id=025D7C5D; url=http://www.gettrusted.com/postmaster@mypgp.com.asc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.6 (+) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 unsubscribe From owner-ietf-openpgp@mail.imc.org Mon Mar 27 17:23:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO07l-00011h-HN for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 17:23:45 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNzRY-00052W-ML for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 16:40:08 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FNynL-0002q8-E7 for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 15:58:38 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RKcjcB002026; Mon, 27 Mar 2006 13:38:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RKcjgo002025; Mon, 27 Mar 2006 13:38:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RKciDa001997 for ; Mon, 27 Mar 2006 13:38:45 -0700 (MST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 3C22333C1C; Mon, 27 Mar 2006 21:38:40 +0100 (BST) Message-ID: <44284CDB.9040504@algroup.co.uk> Date: Mon, 27 Mar 2006 21:36:43 +0100 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Jon Callas CC: OpenPGP Subject: Re: NIST publishes new DSA draft References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> <441ACF45.704@systemics.com> <87fylhdq36.fsf@wheatstone.g10code.de> <20060317174937.GC13241@jabberwocky.com> <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> <44267719.1060302@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: -1.3 (-) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Jon Callas wrote: > On 26 Mar 2006, at 3:12 AM, Ben Laurie wrote: > >> Jon Callas wrote: >>> >>> I think we ought to keep it with the same algorithm number. >>> >>> I'm happy to put in SHA-224 (meaning it's trivial work), but I don't >>> like it, myself. The reason is that SHA-224 is really a truncated >>> SHA-256. Thus, it has no advantages over SHA-256 except being smaller by >>> 32-bits with 112 bits of security. The reason it exists at all is for >>> crypto-balance with 2-key 3DES (which is not TDEA), which we don't allow >>> at all. >> >> >> >> 3-key DES also has a strength of 112 bits. >> >> >> > > There are certainly good arguments for that, but if 3-key 3DES is no > stronger than 2-key, then there shouldn't be any harm in dropping the > third key. Right? If you don't like this idea (that 2-key and 3-key are > equivalent), which I don't, then 3-key must be some stronger. It just > isn't easy to know how much more. I'm not going to argue with this, but it clearly ain't much more. You would be out on a limb to argue that it provided usefully more than 112 bits - though I won't hesitate to agree that 2DES < 3DES. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-ietf-openpgp@mail.imc.org Mon Mar 27 17:27:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO0Au-0001oP-6G for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 17:27:00 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO0As-0008Nx-Rq for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 17:27:00 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RM9wrS022289; Mon, 27 Mar 2006 15:09:58 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RM9w1O022288; Mon, 27 Mar 2006 15:09:58 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RM9vqg022279 for ; Mon, 27 Mar 2006 15:09:58 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 2716157FAE; Mon, 27 Mar 2006 14:08:15 -0800 (PST) To: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-Id: <20060327220815.2716157FAE@finney.org> Date: Mon, 27 Mar 2006 14:08:15 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 As an implementor, the question remains: when I verify a signature, what q sizes should I allow for a given p? For example, what q is OK for a p of 1536? What q is OK for a p of 4096? Should I just make something up? How is that going to promote interoperability? Hal From owner-ietf-openpgp@mail.imc.org Mon Mar 27 17:51:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO0Yd-0004aP-5t for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 17:51:31 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO0Yb-0000Jr-Qg for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 17:51:31 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RMWWSO023191; Mon, 27 Mar 2006 15:32:32 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RMWW9m023190; Mon, 27 Mar 2006 15:32:32 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RMWVcI023184 for ; Mon, 27 Mar 2006 15:32:31 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2RMWNk19287; Mon, 27 Mar 2006 17:32:23 -0500 Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.13.6/8.13.5) with ESMTP id k2RMWQ8q018805; Mon, 27 Mar 2006 17:32:26 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2RMWH7G026234; Mon, 27 Mar 2006 17:32:17 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2RMWH7V026233; Mon, 27 Mar 2006 17:32:17 -0500 Date: Mon, 27 Mar 2006 17:32:16 -0500 From: David Shaw To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-ID: <20060327223216.GA25952@jabberwocky.com> Mail-Followup-To: Hal Finney , ietf-openpgp@imc.org References: <20060327220815.2716157FAE@finney.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060327220815.2716157FAE@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 On Mon, Mar 27, 2006 at 02:08:15PM -0800, "Hal Finney" wrote: > > As an implementor, the question remains: when I verify a signature, what > q sizes should I allow for a given p? For example, what q is OK for a p > of 1536? What q is OK for a p of 4096? Should I just make something up? > How is that going to promote interoperability? For implementation of signature verification you can just take p and q straight from the public key. You don't need to guess since the key has all the information you need. David From owner-ietf-openpgp@mail.imc.org Mon Mar 27 18:45:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO1Os-0003eM-3b for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 18:45:30 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO1Oq-0002x8-Ot for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 18:45:30 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RNNuoJ025399; Mon, 27 Mar 2006 16:23:56 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RNNuNd025398; Mon, 27 Mar 2006 16:23:56 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RNNuie025392 for ; Mon, 27 Mar 2006 16:23:56 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 1754257FAE; Mon, 27 Mar 2006 15:22:15 -0800 (PST) To: dshaw@jabberwocky.com, hal@finney.org Subject: Re: Suggested changes for DSA2 Cc: ietf-openpgp@imc.org Message-Id: <20060327232215.1754257FAE@finney.org> Date: Mon, 27 Mar 2006 15:22:15 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 David writes: > For implementation of signature verification you can just take p and q > straight from the public key. You don't need to guess since the key > has all the information you need. With signatures, it is the verifier more than the signer who is vulnerable and who needs to be protected. The problem is that as the verifying software it is my responsibility to provide some level of assurance to the user about how strong this signature is. Right now at best we only report the key size. I'd like to make sure that q is as strong as p. Otherwise we might see a 4096 bit key with a 160 bit q, so it is really no stronger than a 1024 bit key. It is hard to report to the user how strong a signature by that key should be considered to be. This problem goes away if we standardize on the q sizes that go with certain p sizes. That's what I'd like to do. Any keys that break the rules would be considered invalid. Maybe we don't have to just do the FIPS ones but could extend them somewhat. Hal From owner-ietf-openpgp@mail.imc.org Mon Mar 27 21:32:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO40U-0003pA-Ja for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 21:32:30 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO40U-0001SB-6p for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 21:32:30 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S22Rc1032973; Mon, 27 Mar 2006 19:02:27 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2S22Rdq032972; Mon, 27 Mar 2006 19:02:27 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S22Q8f032966 for ; Mon, 27 Mar 2006 19:02:27 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2S22Pk20897; Mon, 27 Mar 2006 21:02:25 -0500 Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.13.6/8.13.5) with ESMTP id k2S22SWe020966; Mon, 27 Mar 2006 21:02:28 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2S22I8u026527; Mon, 27 Mar 2006 21:02:18 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2S22FGL026526; Mon, 27 Mar 2006 21:02:15 -0500 Date: Mon, 27 Mar 2006 21:02:15 -0500 From: David Shaw To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-ID: <20060328020215.GA26393@jabberwocky.com> Mail-Followup-To: Hal Finney , ietf-openpgp@imc.org References: <20060327232215.1754257FAE@finney.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060327232215.1754257FAE@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 On Mon, Mar 27, 2006 at 03:22:15PM -0800, "Hal Finney" wrote: > David writes: > > For implementation of signature verification you can just take p and q > > straight from the public key. You don't need to guess since the key > > has all the information you need. > > With signatures, it is the verifier more than the signer who is vulnerable > and who needs to be protected. The problem is that as the verifying > software it is my responsibility to provide some level of assurance to > the user about how strong this signature is. > > Right now at best we only report the key size. I'd like to make sure that > q is as strong as p. Otherwise we might see a 4096 bit key with a 160 bit > q, so it is really no stronger than a 1024 bit key. It is hard to report > to the user how strong a signature by that key should be considered to be. > > This problem goes away if we standardize on the q sizes that go with > certain p sizes. That's what I'd like to do. Any keys that break the > rules would be considered invalid. Maybe we don't have to just do the > FIPS ones but could extend them somewhat. Forgetting DSA2 for a moment, this isn't a new problem. We have this same key size / hash size mismatch possibility today with DSA1 (since DSA in 2440 could be 768-1024 bits), and again with RSA (which can use any hash, regardless of the key size). Fixing the q sizes for DSA2 doesn't really solve this. I do agree there is an issue here, but I have trouble seeing it in terms of something that can be fixed in the standard, especially in a reasonably future-proofed way. It just feels a bit like pushing a user or UI problem into the data specification. Implementations are free to use whatever guidelines they like in presenting signature information to the user. It would be very reasonable for a program to pop up some sort of "Warning: the hash used in this signature is weaker than the key", or "this signature has xxxx bits of assurance" or whatever sort of message is deemed most understandable. I just think that the onus is on the implementation to do this, and not the standard. That said, I would support language (perhaps in the Security Considerations or signature sections) that read something like this: When verifying a signature, it may be noted that the strength of the signing key and the strength of the hash used are not similar. In such cases, implementations MAY/SHOULD warn the user that the overall signature strength is limited by the weakest part. In extreme cases, the implementation may wish to consider the signature to be in error. While conventional wisdom may change over time as to the strength of algorithms, at publication time, one such set of guidelines is [SP800]. And add a cite for [SP800] to the NIST key length / hash length guide. David From owner-ietf-openpgp@mail.imc.org Tue Mar 28 04:14:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOAHZ-000364-Os for openpgp-archive@lists.ietf.org; Tue, 28 Mar 2006 04:14:33 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOAHZ-00082I-Cu for openpgp-archive@lists.ietf.org; Tue, 28 Mar 2006 04:14:33 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S8kO17050845; Tue, 28 Mar 2006 01:46:24 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2S8kOTc050844; Tue, 28 Mar 2006 01:46:24 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S8kNE1050838 for ; Tue, 28 Mar 2006 01:46:23 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id F30DA5440; Tue, 28 Mar 2006 10:46:21 +0200 (CEST) Date: Tue, 28 Mar 2006 10:46:21 +0200 To: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-ID: <20060328084621.GA13268@epointsystem.org> References: <20060327232215.1754257FAE@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060327232215.1754257FAE@finney.org> User-Agent: Mutt/1.5.9i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 On Mon, Mar 27, 2006 at 03:22:15PM -0800, "Hal Finney" wrote: > > David writes: > > For implementation of signature verification you can just take p and q > > straight from the public key. You don't need to guess since the key > > has all the information you need. > > With signatures, it is the verifier more than the signer who is vulnerable > and who needs to be protected. The problem is that as the verifying > software it is my responsibility to provide some level of assurance to > the user about how strong this signature is. Right, but it still boils down to whether or not the verifier trusts a certain public key. Thus, the decision needs to be made on a per-key, rather than per-signature basis. I am not arguing here; it is just a remark. > Right now at best we only report the key size. I'd like to make sure that > q is as strong as p. Otherwise we might see a 4096 bit key with a 160 bit > q, so it is really no stronger than a 1024 bit key. That is not quite precise, either. Increasing the size of q and the size of p protect against two different attacks. Large q's protect against (optimized) brute-force or random guessing of the discrete logarithm, while large p's protect against sieve methods. The relative strength of the two attacks is not easily assessed. Sieve methods are getting better and better. Thus, in the future it may very well happen that the balanced choice will be 4096 bits for p and 160 bits for q. As desirable as describing strength in some one-dimensional quantity is, it is hardly possible. NIST's choice of matching modulus sizes and group orders reflect the balancing of time costs of state-of-the-art attacks with no regard to memory costs. (by the way, this same approach is reflected in declaring 3DES as strong as a 112-bit cipher -- as if 2^62 bits of memory were free) This is a long-standing tradition in the main-steam crypto community, but there is no universal consensus about this. > It is hard to report > to the user how strong a signature by that key should be considered to be. Yes, it is. That is one reason not to reflect _our_ judgement (even if we could ever come to an agreement) about it in the standard. > This problem goes away if we standardize on the q sizes that go with > certain p sizes. That's what I'd like to do. Any keys that break the > rules would be considered invalid. No, it won't go away. Moreoever, why would you declare |p|=1024 |q|=160 valid, while |p|=4096 |q|=160 invalid, while the second choice is clearly no weaker than the first one? Putting lower limits on both the modulus size and the group order makes more sense, but that also does not merit more than a passing remark in the standard. IMHO, of course. -- Daniel From owner-ietf-openpgp@mail.imc.org Tue Mar 28 04:57:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOAx4-0007n2-CG for openpgp-archive@lists.ietf.org; Tue, 28 Mar 2006 04:57:26 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOAx4-0001y4-0m for openpgp-archive@lists.ietf.org; Tue, 28 Mar 2006 04:57:26 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S9bHW9053310; Tue, 28 Mar 2006 02:37:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2S9bHpa053309; Tue, 28 Mar 2006 02:37:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S9bFLF053303 for ; Tue, 28 Mar 2006 02:37:16 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 20BD05447; Tue, 28 Mar 2006 11:37:15 +0200 (CEST) Date: Tue, 28 Mar 2006 11:37:15 +0200 To: ietf-openpgp@imc.org Subject: General remarks on uses of OpenPGP Message-ID: <20060328093715.GA20426@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 This message is not directly relevant for the ongoing discussions, just a few thoughts inspired by them. The short summary is that I am advocating a conservative approach, and arguing against changing anything in the minimal requirements. Historically OpenPGP (and PGP) has been designed with the hypotetical NSA as an adversary in mind. As long as being secure against extremely well-funded adversaries does not put unnecessary burden on those of us, who only have less powerful enemies to worry about, this approach is more than welcome. It is great marketing, a safe bet, etc., etc., etc. The low cost of OpenPGP-based encryption of email has made it the solution of choice for the majority of those who care at all, even in the face of the fact that S/MIME is supported out-of-the-box on all popular email clients, while adding OpenPGP support requires non-trivial effort. This feat alone justifies the general approach of OpenPGP. I am extremely greatful to this WG of IETF for your choice of MUST algorithms, as it allowed me to implement the standard on the J2SE 1.4 platform without implementing any cryptography. Even on the somewhat crypto-crippled versions of Java, it is a full-strength, interoperable implementation. It allowed me to implement java applets weighing a few dozen kilobytes(!) that perform various PGP-operations and run on the vast majority of java-enabled browsers. A full-fledged GUI-client that does everything except key management fits into 140 kilobytes, including the gui. It is precisely the 3DES, SHA1, MD5, RSA-s, DSA-s, RSA-e and ELG-e choice of alrogithms that made this possible. Requiring AES or IDEA would have made it much more difficult, although I understand that letting go of IDEA and excluding Rijndael were both controversial choices at the time. If the standard's requirements exceed the bare minimum that one can count on in all sorts of legacy systems still in wide use, just to keep everybody secure against the hypotetical NSA (not the real one, by the way -- cryptography alone cannot achieve that), it would put an unnecessary burden on all sorts of practical applications where this is not a requirement. I think, that the standard should definitely allow building heavy-duty super-secure and super-efficient cryptosystems, if someone feels like that, but _requiring_ excessive strength and efficiency would be, well, excessive. -- Daniel From owner-ietf-openpgp@mail.imc.org Tue Mar 28 16:25:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOLh2-0005Kr-Tu for openpgp-archive@lists.ietf.org; Tue, 28 Mar 2006 16:25:36 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOLh1-0008ET-HC for openpgp-archive@lists.ietf.org; Tue, 28 Mar 2006 16:25:36 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2SL5pNw092238; Tue, 28 Mar 2006 14:05:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2SL5pG6092237; Tue, 28 Mar 2006 14:05:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2SL5oZP092231 for ; Tue, 28 Mar 2006 14:05:50 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 631EA57FAE; Tue, 28 Mar 2006 13:04:12 -0800 (PST) To: dshaw@jabberwocky.com, hal@finney.org Subject: Re: Suggested changes for DSA2 Cc: ietf-openpgp@imc.org Message-Id: <20060328210412.631EA57FAE@finney.org> Date: Tue, 28 Mar 2006 13:04:12 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a David writes: > Forgetting DSA2 for a moment, this isn't a new problem. We have this > same key size / hash size mismatch possibility today with DSA1 (since > DSA in 2440 could be 768-1024 bits), and again with RSA (which can use > any hash, regardless of the key size). Fixing the q sizes for DSA2 > doesn't really solve this. The problem is not so bad with DSA1 because at worst the hash and subgroup would have been stronger than the key size, so by reporting the modulus we are giving an accurate lower bound on the strength. But you're right that we have had the problem all along with RSA. In fact in the old days I don't doubt that we had many users with 8K bit RSA keys using 128 bit MD5 for signatures. Daniel is right too that there is not complete agreement about the proper balance between subgroup/hash size and modulus size, and that future cryptographic developments may change this balance. Although we have not discussed it, the same problem arises for encryption, balancing the symmetric algorithm key size with the public key size. I've heard complaints that letting people use AES-256 with a 1024 or 2048 bit RSA key gives them a false sense of security. Clearly this complexity is a challenge to deal with. However we have made attempts in the past to provide minimal security guidelines. In our section 12 Notes on Algorithms we have sections 12.4, 12.5 and 12.6 giving minimum key sizes for RSA, DSA and DH as SHOULDs. I support David's suggestion to include a SHOULD relating hash size to key size. But it makes sense to me to extend our current key size SHOULD recommendations to include advice regarding subgroup size, hash size, and symmetric cipher key size. This would correspond to Table 2 on page 63 of NIST's SP800-57: http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf The sizes from that table are: 1024 / 160 / 80 2048 / 224 / 112 3072 / 512 / 256 7680 / 768 / 384 15360 / 1024 / 512 where the 1st column is the RSA, DSA or DH modulus size, the second column is the hash/subgroup size, and the 3rd column is the symmetric cipher key size (which is also the strength in bits). We could do as David suggests and say that implementors SHOULD follow SP800-57 or whatever updates it. However this will require implementors to acquire and read through this 220 page document in order to find these five lines of information. It seems to me that it is worthwhile to include these lines, and also to refer to SP800-57 and advise implementors to check for updates. Proposed language: In order to provide consistent levels of security for end users, implementors SHOULD balance public key modulus size, subgroup size, hash size, and symmetric algorithm key size. While consensus about appropriate choices of these parameters may change with time, NIST Special Publication 800-57 recommends the following parameter size choices: [Some version of NIST's Table 2 here] Implementors SHOULD use and require public key and other parameters consistent with values in this table, or updated information based on evolving consensus in the field. We could use this to replace the current language about key sizes in section 12, since the 1024 bit minimum is implicit in the table. Hal From owner-ietf-openpgp@mail.imc.org Tue Mar 28 19:09:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOOFZ-0001zO-UG for openpgp-archive@lists.ietf.org; Tue, 28 Mar 2006 19:09:25 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOOFY-0006QQ-HO for openpgp-archive@lists.ietf.org; Tue, 28 Mar 2006 19:09:25 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2SNqaFu001864; Tue, 28 Mar 2006 16:52:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2SNqaAx001863; Tue, 28 Mar 2006 16:52:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2SNqZ5N001857 for ; Tue, 28 Mar 2006 16:52:35 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 9FD9857FAE; Tue, 28 Mar 2006 15:50:58 -0800 (PST) To: dshaw@jabberwocky.com, hal@finney.org Subject: Re: Suggested changes for DSA2 Cc: ietf-openpgp@imc.org Message-Id: <20060328235058.9FD9857FAE@finney.org> Date: Tue, 28 Mar 2006 15:50:58 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 David Shaw wrote: > On Tue, Mar 28, 2006 at 01:04:12PM -0800, "Hal Finney" wrote: > > > I support David's suggestion to include a SHOULD relating hash size to key > > size. But it makes sense to me to extend our current key size SHOULD > > recommendations to include advice regarding subgroup size, hash size, > > and symmetric cipher key size. This would correspond to Table 2 on page > > 63 of NIST's SP800-57: > > http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf > > > > The sizes from that table are: > > > > 1024 / 160 / 80 > > 2048 / 224 / 112 > > 3072 / 512 / 256 > > 7680 / 768 / 384 > > 15360 / 1024 / 512 > > > > where the 1st column is the RSA, DSA or DH modulus size, the second > > column is the hash/subgroup size, and the 3rd column is the symmetric > > cipher key size (which is also the strength in bits). > > Are you sure that table is correct? I thought it was: > > 1024 / 160 / 80 > 2048 / 224 / 112 > 3072 / 256 / 128 > 7680 / 384 / 192 > 15360 / 512 / 256 Yes, sorry, you're right. I transcribed it wrong and doubled when I should have halved. > I'm not sure this is the right way to go about it. Is balance > actually what we want, or would it be better to just remind people > that the weakest parameter constrains the level of security? There is > nothing invalid about a 8192-bit RSA key making SHA-1 signatures. It > just means that the signature has at most 80 bits of strength. The > signer could have used a 1024-bit RSA key and gotten the same 80 bits > of strength, but that doesn't make the 8192-bit signature wrong (just > large). My suggested wording was more to encourage implementors to > indicate the actual strength, rather than to force balance. > > How about this (presumably for the Security Considerations section): > > As OpenPGP combines many different asymmetric, symmetric, and hash > algorithms, each with different measures of strength, care should > be taken that the weakest element of an OpenPGP message is still > sufficiently strong for the purpose at hand. Implementations > receiving messages SHOULD indicate to the user the actual strength > of the messages. While consensus about the the strength of a given > algorithm may evolve, at publication time, NIST Special Publication > 800-57 [SP800-57] recommended the following list of equivalent > strengths: > > [ put table here ] I like this general direction, but I don't think it will work to indicate to users the actual strength of message encryptions or signatures. There is no convenient way to express this information that will be understandable to the layman. We could say that a DSA1 signature has 80 bits of strength, and a 2048 bit RSA encryption using AES-256 has 112 bits of strength, but that is too technical and also in most cases too much information. It's also non-standard practice in crypto implementations to provide this information, and I don't feel comfortable putting in a requirement for something this novel, without having experience to justify it. I can see that invalidating 2048 bit RSA key signatures that use SHA-1 is not the right thing to do either, which my earlier language proposal could be interpreted to recommend. > I'm still in favor of making the NIST list a SHOULD for generating > DSA2 keys, of course. Okay, well, maybe the rest of it is too complex to deal with for now. Hal From owner-ietf-openpgp@mail.imc.org Tue Mar 28 20:21:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOPN3-0002H5-9e for openpgp-archive@lists.ietf.org; Tue, 28 Mar 2006 20:21:13 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOO3j-0005qk-65 for openpgp-archive@lists.ietf.org; Tue, 28 Mar 2006 18:57:11 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FONnY-0005jq-Gr for openpgp-archive@lists.ietf.org; Tue, 28 Mar 2006 18:40:31 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2SNMwHD099500; Tue, 28 Mar 2006 16:22:58 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2SNMwtL099499; Tue, 28 Mar 2006 16:22:58 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2SNMvwn099491 for ; Tue, 28 Mar 2006 16:22:57 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2SNMtk26366; Tue, 28 Mar 2006 18:22:55 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.13.6/8.13.5) with ESMTP id k2SNMuOe015416; Tue, 28 Mar 2006 18:22:56 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2SNMno9029152; Tue, 28 Mar 2006 18:22:49 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2SNMnCL029151; Tue, 28 Mar 2006 18:22:49 -0500 Date: Tue, 28 Mar 2006 18:22:49 -0500 From: David Shaw To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-ID: <20060328232249.GC28776@jabberwocky.com> Mail-Followup-To: Hal Finney , ietf-openpgp@imc.org References: <20060328210412.631EA57FAE@finney.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060328210412.631EA57FAE@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: -2.6 (--) X-Scan-Signature: 25620135586de10c627e3628c432b04a On Tue, Mar 28, 2006 at 01:04:12PM -0800, "Hal Finney" wrote: > I support David's suggestion to include a SHOULD relating hash size to key > size. But it makes sense to me to extend our current key size SHOULD > recommendations to include advice regarding subgroup size, hash size, > and symmetric cipher key size. This would correspond to Table 2 on page > 63 of NIST's SP800-57: > http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf > > The sizes from that table are: > > 1024 / 160 / 80 > 2048 / 224 / 112 > 3072 / 512 / 256 > 7680 / 768 / 384 > 15360 / 1024 / 512 > > where the 1st column is the RSA, DSA or DH modulus size, the second > column is the hash/subgroup size, and the 3rd column is the symmetric > cipher key size (which is also the strength in bits). Are you sure that table is correct? I thought it was: 1024 / 160 / 80 2048 / 224 / 112 3072 / 256 / 128 7680 / 384 / 192 15360 / 512 / 256 > Proposed language: > > In order to provide consistent levels of security for end users, > implementors SHOULD balance public key modulus size, subgroup size, > hash size, and symmetric algorithm key size. While consensus about > appropriate choices of these parameters may change with time, NIST > Special Publication 800-57 recommends the following parameter size > choices: > > [Some version of NIST's Table 2 here] > > Implementors SHOULD use and require public key and other parameters > consistent with values in this table, or updated information based > on evolving consensus in the field. I'm not sure this is the right way to go about it. Is balance actually what we want, or would it be better to just remind people that the weakest parameter constrains the level of security? There is nothing invalid about a 8192-bit RSA key making SHA-1 signatures. It just means that the signature has at most 80 bits of strength. The signer could have used a 1024-bit RSA key and gotten the same 80 bits of strength, but that doesn't make the 8192-bit signature wrong (just large). My suggested wording was more to encourage implementors to indicate the actual strength, rather than to force balance. How about this (presumably for the Security Considerations section): As OpenPGP combines many different asymmetric, symmetric, and hash algorithms, each with different measures of strength, care should be taken that the weakest element of an OpenPGP message is still sufficiently strong for the purpose at hand. Implementations receiving messages SHOULD indicate to the user the actual strength of the messages. While consensus about the the strength of a given algorithm may evolve, at publication time, NIST Special Publication 800-57 [SP800-57] recommended the following list of equivalent strengths: [ put table here ] I'm still in favor of making the NIST list a SHOULD for generating DSA2 keys, of course. David From owner-ietf-openpgp@mail.imc.org Wed Mar 29 11:57:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOdzH-00054r-Gu for openpgp-archive@lists.ietf.org; Wed, 29 Mar 2006 11:57:39 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOdzH-0006Cq-2b for openpgp-archive@lists.ietf.org; Wed, 29 Mar 2006 11:57:39 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2TGXXfg053037; Wed, 29 Mar 2006 09:33:33 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2TGXXxF053036; Wed, 29 Mar 2006 09:33:33 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2TGXWXH053030 for ; Wed, 29 Mar 2006 09:33:32 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2TGXVk30758; Wed, 29 Mar 2006 11:33:31 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.13.6/8.13.5) with ESMTP id k2TGXYC4026622; Wed, 29 Mar 2006 11:33:34 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2TGXPos001136; Wed, 29 Mar 2006 11:33:25 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2TGXM3b001135; Wed, 29 Mar 2006 11:33:22 -0500 Date: Wed, 29 Mar 2006 11:33:22 -0500 From: David Shaw To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-ID: <20060329163322.GA1001@jabberwocky.com> Mail-Followup-To: Hal Finney , ietf-openpgp@imc.org References: <20060328235058.9FD9857FAE@finney.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060328235058.9FD9857FAE@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 On Tue, Mar 28, 2006 at 03:50:58PM -0800, "Hal Finney" wrote: > David Shaw wrote: > > How about this (presumably for the Security Considerations section): > > > > As OpenPGP combines many different asymmetric, symmetric, and hash > > algorithms, each with different measures of strength, care should > > be taken that the weakest element of an OpenPGP message is still > > sufficiently strong for the purpose at hand. Implementations > > receiving messages SHOULD indicate to the user the actual strength > > of the messages. While consensus about the the strength of a given > > algorithm may evolve, at publication time, NIST Special Publication > > 800-57 [SP800-57] recommended the following list of equivalent > > strengths: > > > > [ put table here ] > > I like this general direction, but I don't think it will work to indicate > to users the actual strength of message encryptions or signatures. > There is no convenient way to express this information that will be > understandable to the layman. We could say that a DSA1 signature has 80 > bits of strength, and a 2048 bit RSA encryption using AES-256 has 112 bits > of strength, but that is too technical and also in most cases too much > information. It's also non-standard practice in crypto implementations > to provide this information, and I don't feel comfortable putting in > a requirement for something this novel, without having experience to > justify it. I actually think this may well be simpler than what we have now. Right now GPG says things like "Signature made with 4096-bit RSA key" and optionally "Hash used was SHA-1" and such. I don't have a copy of PGP handy at the moment to check, but I recall it doesn't say either. Saying something like "This signature is 80 bits strong" would actually give a single, reasonably accurate number to indicate relative strength. I doubt many users can translate "4096 bit RSA with SHA-1" into a strength value they can compare with other strength values. However, you're quite right that it is a large step to make such a thing a SHOULD without any experience to justify it first. Certainly any implementation that wants to experiment down that route can do so without any special mandate in the standard. Dropping the notification SHOULD from the change gives this (for the Security Considerations section): As OpenPGP combines many different asymmetric, symmetric, and hash algorithms, each with different measures of strength, care should be taken that the weakest element of an OpenPGP message is still sufficiently strong for the purpose at hand. While consensus about the the strength of a given algorithm may evolve, at publication time, NIST Special Publication 800-57 [SP800-57] recommended the following list of equivalent strengths: [ put table here ] This is perhaps stating the obvious, but I think still worth mentioning. > > I'm still in favor of making the NIST list a SHOULD for generating > > DSA2 keys, of course. > > Okay, well, maybe the rest of it is too complex to deal with for now. Ok. I'll roll together a change take 4 and send it to the list. David From owner-ietf-openpgp@mail.imc.org Wed Mar 29 12:02:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOe43-0000Bz-8R for openpgp-archive@lists.ietf.org; Wed, 29 Mar 2006 12:02:35 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOe42-0006YX-PV for openpgp-archive@lists.ietf.org; Wed, 29 Mar 2006 12:02:35 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2TGc3bq053235; Wed, 29 Mar 2006 09:38:03 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2TGc33O053234; Wed, 29 Mar 2006 09:38:03 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2TGc239053228 for ; Wed, 29 Mar 2006 09:38:03 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2TGc2k30776 for ; Wed, 29 Mar 2006 11:38:02 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.13.6/8.13.5) with ESMTP id k2TGc5og026681 for ; Wed, 29 Mar 2006 11:38:05 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2TGbu2n001148 for ; Wed, 29 Mar 2006 11:37:56 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2TGbuVZ001147 for ietf-openpgp@imc.org; Wed, 29 Mar 2006 11:37:56 -0500 Date: Wed, 29 Mar 2006 11:37:56 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Suggested changes for DSA2, take 4 Message-ID: <20060329163756.GB1001@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Here is round four. Only little fiddle changes at this point. ================================== Section 5.2.2 (Version 3 Signature Packet Format) says: DSA signatures MUST use hashes with a size of 160 bits, to match q, the size of the group generated by the DSA key's generator value. The hash function result is treated as a 160 bit number and used directly in the DSA signature algorithm. change to: DSA signatures MUST use hashes that are equal in size to the number of bits of q, the group generated by the DSA key's generator value. If the output size of the chosen hash is larger than the number of bits of q, the hash result is truncated to fit by taking the number of leftmost bits equal to the number of bits of q. This (possibly truncated) hash function result is treated as a number and used directly in the DSA signature algorithm. No change. ================================== Section 12.5. (DSA) says: An implementation SHOULD NOT implement DSA keys of size less than 1024 bits. Note that present DSA is limited to a maximum of 1024 bit keys, which are recommended for long-term use. Also, DSA keys MUST be an even multiple of 64 bits long. change to: An implementation SHOULD NOT implement DSA keys of size less than 1024 bits or with a q size of less than 160 bits. DSA keys MUST also be a multiple of 64 bits, and the q size MUST be a multiple of 8 bits. The Digital Signature Standard (DSS) [FIPS186] specifies that DSA be used in one of the following ways: * 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384 or SHA-512 hash * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384 or SHA-512 hash * 2048-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash * 3072-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash The above key and q size pairs were chosen to best balance the strength of the key with the strength of the hash. Implementations SHOULD use one of the above key and q size pairs when generating DSA keys. If DSS compliance is desired, one of the specified SHA hashes must be used as well. [FIPS186] is the ultimate authority on DSS, and should be consulted for all questions of DSS compliance. Note that earlier versions of this standard only allowed a 160-bit q with no truncation allowed, so earlier implementations may not be able to handle signatures with a different q size or a truncated hash. Added a MUST that the q size is a multiple of 8. I don't think any of us want to deal with hashes that don't end on a byte boundary. ================================== Section 13. (Security Considerations) says: * The DSA algorithm will work with any 160-bit hash, but it is sensitive to the quality of the hash algorithm, if the hash algorithm is broken, it can leak the secret key. The Digital Signature Standard (DSS) specifies that DSA be used with SHA-1. RIPEMD-160 is considered by many cryptographers to be as strong. An implementation should take care which hash algorithms are used with DSA, as a weak hash can not only allow a signature to be forged, but could leak the secret key. change to: * The DSA algorithm will work with any hash, but is sensitive to the quality of the hash algorithm. Verifiers should be aware that even if the signer used a strong hash, an attacker could have modified the signature to use a weak one. Only signatures using acceptably strong hash algorithms should be accepted as valid. Also add: * As OpenPGP combines many different asymmetric, symmetric, and hash algorithms, each with different measures of strength, care should be taken that the weakest element of an OpenPGP message is still sufficiently strong for the purpose at hand. While consensus about the the strength of a given algorithm may evolve, at publication time, NIST Special Publication 800-57 [SP800-57] recommended the following list of equivalent strengths: Asymmetric | Hash | Symmetric key size | size | key size ------------+--------+----------- 1024 160 80 2048 224 112 3072 256 128 7680 384 192 15360 512 256 Added the key size reminder. ================================== David From owner-ietf-openpgp@mail.imc.org Wed Mar 29 12:53:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOerN-0001vn-Bz for openpgp-archive@lists.ietf.org; Wed, 29 Mar 2006 12:53:33 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOerM-00006n-0B for openpgp-archive@lists.ietf.org; Wed, 29 Mar 2006 12:53:33 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2THUqe3056089; Wed, 29 Mar 2006 10:30:52 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2THUqLB056088; Wed, 29 Mar 2006 10:30:52 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2THUpDU056082 for ; Wed, 29 Mar 2006 10:30:52 -0700 (MST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id D6F0633C44 for ; Wed, 29 Mar 2006 18:30:50 +0100 (BST) Message-ID: <442AC3D9.9000905@algroup.co.uk> Date: Wed, 29 Mar 2006 18:28:57 +0100 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2, take 4 References: <20060329163756.GB1001@jabberwocky.com> In-Reply-To: <20060329163756.GB1001@jabberwocky.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 David Shaw wrote: > Here is round four. Only little fiddle changes at this point. > > ================================== > > Section 5.2.2 (Version 3 Signature Packet Format) says: > > DSA signatures MUST use hashes with a size of 160 bits, to match q, > the size of the group generated by the DSA key's generator value. > The hash function result is treated as a 160 bit number and used > directly in the DSA signature algorithm. > > change to: > > DSA signatures MUST use hashes that are equal in size to the > number of bits of q, the group generated by the DSA key's > generator value. If the output size of the chosen hash is larger > than the number of bits of q, the hash result is truncated to fit > by taking the number of leftmost bits equal to the number of bits > of q. This (possibly truncated) hash function result is treated > as a number and used directly in the DSA signature algorithm. > > No change. Slightly late to the party here, but I should note that hash truncation is not an operation that is thoroughly approved of. In particular I would worry that if it is permitted a cunning attacker might be able to choose a new q s.t. the signature still validated on a much shorter version of the hash, and thus show a valid signature on the wrong document. I would therefore suggest that we do _not_ permit arbitrary truncation of hashes. Secondly, q is not a group, it is a prime. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-ietf-openpgp@mail.imc.org Wed Mar 29 14:04:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOfyT-0001hk-47 for openpgp-archive@lists.ietf.org; Wed, 29 Mar 2006 14:04:57 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOfyR-00048B-PF for openpgp-archive@lists.ietf.org; Wed, 29 Mar 2006 14:04:57 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2TIl6hj059523; Wed, 29 Mar 2006 11:47:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2TIl6X3059522; Wed, 29 Mar 2006 11:47:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2TIl53l059516 for ; Wed, 29 Mar 2006 11:47:05 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id E0E5A57FAE; Wed, 29 Mar 2006 10:45:30 -0800 (PST) To: ben@algroup.co.uk, ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2, take 4 Message-Id: <20060329184530.E0E5A57FAE@finney.org> Date: Wed, 29 Mar 2006 10:45:30 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Ben Laurie writes: > Slightly late to the party here, but I should note that hash truncation > is not an operation that is thoroughly approved of. In particular I > would worry that if it is permitted a cunning attacker might be able to > choose a new q s.t. the signature still validated on a much shorter > version of the hash, and thus show a valid signature on the wrong > document. I would therefore suggest that we do _not_ permit arbitrary > truncation of hashes. I don't understand what you are proposing here. To choose a new q means to create a new key: a new (p, q, g, x, y) tuple. Then you are worried that an existing (r, s) signature could be made to work with this new key? I don't see why this would be a concern even if it worked; and it could be eliminated by checking that r and s are < q, which you should do anyway. The NIST standard supports arbitrary truncation of (strong) hashes, and if it were that risky I doubt very much that it would have gotten in. John Kelsey at NIST is one of the top people in the field today and I am sure this has been reviewed by him and other cryptographers. Hal Finney From owner-ietf-openpgp@mail.imc.org Wed Mar 29 16:43:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOiSI-0004Y6-Ot for openpgp-archive@lists.ietf.org; Wed, 29 Mar 2006 16:43:54 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOiSH-0002Gp-Ch for openpgp-archive@lists.ietf.org; Wed, 29 Mar 2006 16:43:54 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2TLOsmS066163; Wed, 29 Mar 2006 14:24:54 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2TLOs6r066162; Wed, 29 Mar 2006 14:24:54 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2TLOrQ3066154 for ; Wed, 29 Mar 2006 14:24:54 -0700 (MST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 0F16233C3F; Wed, 29 Mar 2006 22:24:49 +0100 (BST) Message-ID: <442AFAAF.5090105@algroup.co.uk> Date: Wed, 29 Mar 2006 22:22:55 +0100 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Hal Finney CC: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2, take 4 References: <20060329184530.E0E5A57FAE@finney.org> In-Reply-To: <20060329184530.E0E5A57FAE@finney.org> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hal Finney wrote: > Ben Laurie writes: >> Slightly late to the party here, but I should note that hash truncation >> is not an operation that is thoroughly approved of. In particular I >> would worry that if it is permitted a cunning attacker might be able to >> choose a new q s.t. the signature still validated on a much shorter >> version of the hash, and thus show a valid signature on the wrong >> document. I would therefore suggest that we do _not_ permit arbitrary >> truncation of hashes. > > I don't understand what you are proposing here. To choose a new q means > to create a new key: a new (p, q, g, x, y) tuple. Then you are worried > that an existing (r, s) signature could be made to work with this new key? > I don't see why this would be a concern even if it worked; and it could be > eliminated by checking that r and s are < q, which you should do anyway. > > The NIST standard supports arbitrary truncation of (strong) hashes, and > if it were that risky I doubt very much that it would have gotten in. > John Kelsey at NIST is one of the top people in the field today and I > am sure this has been reviewed by him and other cryptographers. OK, you are right, I guess I'll count this nebulous concern as void. Certainly the language proposed accords with 186-3 on hash truncation. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-ietf-openpgp@mail.imc.org Thu Mar 30 09:31:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOyB8-0007rs-O4 for openpgp-archive@lists.ietf.org; Thu, 30 Mar 2006 09:31:14 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOy4y-0006sO-0W for openpgp-archive@lists.ietf.org; Thu, 30 Mar 2006 09:24:52 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2UDxLsN010672; Thu, 30 Mar 2006 06:59:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2UDxLpQ010671; Thu, 30 Mar 2006 06:59:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2UDxJxm010661 for ; Thu, 30 Mar 2006 06:59:20 -0700 (MST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id D9AFE5A40F; Thu, 30 Mar 2006 14:59:17 +0100 (BST) Message-ID: <442BE3BC.8050002@systemics.com> Date: Thu, 30 Mar 2006 15:57:16 +0200 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OpenPGP Cc: Jon Callas Subject: Cost-benefit analysis of algorithm substitution References: <20060326180218.12C8057FAE@finney.org> <20060326215531.GF30637@jabberwocky.com> <4427E67A.8050202@systemics.com> <20060327150120.GA25414@jabberwocky.com> <20060327154427.GC7346@epointsystem.org> <23598E55-F454-4ED8-B3C7-7B716FDC3205@callas.org> In-Reply-To: <23598E55-F454-4ED8-B3C7-7B716FDC3205@callas.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Jon Callas wrote: > > On 27 Mar 2006, at 7:44 AM, Daniel A. Nagy wrote: > >> I agree with David here. The standard's purpose is to ensure >> interoperability. It should tell us the sematics behind sequences of >> bytes. >> It is up to the implementation to make decisions based on these >> semantics. >> Valid reasons to exclude certain combinations from the standard include >> ambiguity of interpretation, inherent insecurity or a wide installed >> base of >> incompatible implementations, but not the possibility of weird uses, >> IMHO. >> > > I agree as well with both Davids. Well, I can see I've lost the consensus battle on this one - but I would propose that the purpose of the ID is security, over and above interoperability, and that is an entirely valid reason to exclude "Weird Uses." In general, with security, the less choice the better. > As an observation, in 2440 one of the things we allowed was deviation > from DSS because the rough consensus had a certain amount of grumpiness > with the US Government. In practice, hardly anyone did anything > different with DSA than DSS. We even removed hash functions. > > Many things have changed in the last decade, but toeing the exact NIST > line or even being like them only moreso is going a bit too far. In the > next decade, we're going to see a lot of advancement in hash functions. > Someone is going to want to use those new hash functions with DSA, and > it would be nice to be able to move faster than NIST. As to the political circumstances of the past, it is true that the community did certain daft things that reduced security in response to the USG's own set of daft things that reduced security. It's definately not good to follow either lead... > Let's suppose someone comes up with a new hash function that is 251 > bits. (I picked 251 because it's prime and less than 256.) We don't > want a constitutional crisis over using it. We want to be flexible > enough that it's pretty obvious how to extend OpenPGP to use new hash > functions with DSA. It seems that PGP's design bends over backwards to be flexible. It's a lot of fun for crypto- plumbers; in fact it looks like it has been designed as a toykit for programmers to muck around with algorithms. In practice, though, this flexibility seems to rarely be used in any sensible way. And, again, in practice, this flexibility causes endless discussions on this mailgroup - as seen this week - and other places where implementors and users try and figure what goes with what. It all takes up time from other important things. So I guess what I'm saying is ... all this flexibility ... how many times has it been used to advantage, and how many times to disadvantage? What's the cost-benefit analysis here? iang From owner-ietf-openpgp@mail.imc.org Thu Mar 30 10:00:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOyd0-0002s7-VH for openpgp-archive@lists.ietf.org; Thu, 30 Mar 2006 10:00:02 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOycz-0008Ve-IJ for openpgp-archive@lists.ietf.org; Thu, 30 Mar 2006 10:00:02 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2UEavTR012923; Thu, 30 Mar 2006 07:36:57 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2UEavob012922; Thu, 30 Mar 2006 07:36:57 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from ns1.cpanel.btnaccess.com (ns1.cpanel.btnaccess.com [205.177.121.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2UEauvs012916 for ; Thu, 30 Mar 2006 07:36:56 -0700 (MST) (envelope-from robholliday@isocore.com) Message-Id: <200603301436.k2UEauvs012916@balder-227.proper.com> Received: from [65.213.193.6] (helo=ISODELL001) by ns1.cpanel.btnaccess.com with esmtp (Exim 4.52) id 1FOyGc-0006BR-FU for ietf-openpgp@imc.org; Thu, 30 Mar 2006 09:36:54 -0500 From: "Robert Holliday" To: Subject: ICNS 2006: Early Registration Ends April 1 Date: Thu, 30 Mar 2006 09:36:51 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C653DD.798E8920" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcZUB2I5fEyLW54yTgWB6+wodxSpAA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C653DD.798E8920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit International Conference on Network Security 2006, April 17-19, Reston, Virginia Only a few days remain to take advantage of Early Bird Specials when registering for ICNS2006. All those registering before April 1 receive will receive a $200 dollar discount. Don't miss out on the chance to interact with industry leaders in a personal setting and unique format. Technical Program: http://www.isocore.com/networksecurity2006/program.htm Registration: http://www.isocore.com/networksecurity2006/onlineregis.htm ------=_NextPart_000_0019_01C653DD.798E8920 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

International Conference on Network Security 2006, April 17-19, = Reston, Virginia

 <= /p>

Only a few days remain to = take advantage of Early Bird Specials when registering for ICNS2006.  = All those registering before April 1 receive will receive a $200 dollar = discount.  Don’t miss out on the chance to interact with industry leaders in = a personal setting and unique format.

 

Technical = Program: http://ww= w.isocore.com/networksecurity2006/program.htm

 

Registratio= n: http:= //www.isocore.com/networksecurity2006/onlineregis.htm

 

------=_NextPart_000_0019_01C653DD.798E8920-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2UEavTR012923; Thu, 30 Mar 2006 07:36:57 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2UEavob012922; Thu, 30 Mar 2006 07:36:57 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from ns1.cpanel.btnaccess.com (ns1.cpanel.btnaccess.com [205.177.121.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2UEauvs012916 for ; Thu, 30 Mar 2006 07:36:56 -0700 (MST) (envelope-from robholliday@isocore.com) Message-Id: <200603301436.k2UEauvs012916@balder-227.proper.com> Received: from [65.213.193.6] (helo=ISODELL001) by ns1.cpanel.btnaccess.com with esmtp (Exim 4.52) id 1FOyGc-0006BR-FU for ietf-openpgp@imc.org; Thu, 30 Mar 2006 09:36:54 -0500 From: "Robert Holliday" To: Subject: ICNS 2006: Early Registration Ends April 1 Date: Thu, 30 Mar 2006 09:36:51 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C653DD.798E8920" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcZUB2I5fEyLW54yTgWB6+wodxSpAA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C653DD.798E8920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit International Conference on Network Security 2006, April 17-19, Reston, Virginia Only a few days remain to take advantage of Early Bird Specials when registering for ICNS2006. All those registering before April 1 receive will receive a $200 dollar discount. Don't miss out on the chance to interact with industry leaders in a personal setting and unique format. Technical Program: http://www.isocore.com/networksecurity2006/program.htm Registration: http://www.isocore.com/networksecurity2006/onlineregis.htm ------=_NextPart_000_0019_01C653DD.798E8920 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

International Conference on Network Security 2006, April 17-19, = Reston, Virginia

 <= /p>

Only a few days remain to = take advantage of Early Bird Specials when registering for ICNS2006.  = All those registering before April 1 receive will receive a $200 dollar = discount.  Don’t miss out on the chance to interact with industry leaders in = a personal setting and unique format.

 

Technical = Program: http://ww= w.isocore.com/networksecurity2006/program.htm

 

Registratio= n: http:= //www.isocore.com/networksecurity2006/onlineregis.htm

 

------=_NextPart_000_0019_01C653DD.798E8920-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2UDxLsN010672; Thu, 30 Mar 2006 06:59:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2UDxLpQ010671; Thu, 30 Mar 2006 06:59:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2UDxJxm010661 for ; Thu, 30 Mar 2006 06:59:20 -0700 (MST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id D9AFE5A40F; Thu, 30 Mar 2006 14:59:17 +0100 (BST) Message-ID: <442BE3BC.8050002@systemics.com> Date: Thu, 30 Mar 2006 15:57:16 +0200 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OpenPGP Cc: Jon Callas Subject: Cost-benefit analysis of algorithm substitution References: <20060326180218.12C8057FAE@finney.org> <20060326215531.GF30637@jabberwocky.com> <4427E67A.8050202@systemics.com> <20060327150120.GA25414@jabberwocky.com> <20060327154427.GC7346@epointsystem.org> <23598E55-F454-4ED8-B3C7-7B716FDC3205@callas.org> In-Reply-To: <23598E55-F454-4ED8-B3C7-7B716FDC3205@callas.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas wrote: > > On 27 Mar 2006, at 7:44 AM, Daniel A. Nagy wrote: > >> I agree with David here. The standard's purpose is to ensure >> interoperability. It should tell us the sematics behind sequences of >> bytes. >> It is up to the implementation to make decisions based on these >> semantics. >> Valid reasons to exclude certain combinations from the standard include >> ambiguity of interpretation, inherent insecurity or a wide installed >> base of >> incompatible implementations, but not the possibility of weird uses, >> IMHO. >> > > I agree as well with both Davids. Well, I can see I've lost the consensus battle on this one - but I would propose that the purpose of the ID is security, over and above interoperability, and that is an entirely valid reason to exclude "Weird Uses." In general, with security, the less choice the better. > As an observation, in 2440 one of the things we allowed was deviation > from DSS because the rough consensus had a certain amount of grumpiness > with the US Government. In practice, hardly anyone did anything > different with DSA than DSS. We even removed hash functions. > > Many things have changed in the last decade, but toeing the exact NIST > line or even being like them only moreso is going a bit too far. In the > next decade, we're going to see a lot of advancement in hash functions. > Someone is going to want to use those new hash functions with DSA, and > it would be nice to be able to move faster than NIST. As to the political circumstances of the past, it is true that the community did certain daft things that reduced security in response to the USG's own set of daft things that reduced security. It's definately not good to follow either lead... > Let's suppose someone comes up with a new hash function that is 251 > bits. (I picked 251 because it's prime and less than 256.) We don't > want a constitutional crisis over using it. We want to be flexible > enough that it's pretty obvious how to extend OpenPGP to use new hash > functions with DSA. It seems that PGP's design bends over backwards to be flexible. It's a lot of fun for crypto- plumbers; in fact it looks like it has been designed as a toykit for programmers to muck around with algorithms. In practice, though, this flexibility seems to rarely be used in any sensible way. And, again, in practice, this flexibility causes endless discussions on this mailgroup - as seen this week - and other places where implementors and users try and figure what goes with what. It all takes up time from other important things. So I guess what I'm saying is ... all this flexibility ... how many times has it been used to advantage, and how many times to disadvantage? What's the cost-benefit analysis here? iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2TLOsmS066163; Wed, 29 Mar 2006 14:24:54 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2TLOs6r066162; Wed, 29 Mar 2006 14:24:54 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2TLOrQ3066154 for ; Wed, 29 Mar 2006 14:24:54 -0700 (MST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 0F16233C3F; Wed, 29 Mar 2006 22:24:49 +0100 (BST) Message-ID: <442AFAAF.5090105@algroup.co.uk> Date: Wed, 29 Mar 2006 22:22:55 +0100 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Hal Finney CC: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2, take 4 References: <20060329184530.E0E5A57FAE@finney.org> In-Reply-To: <20060329184530.E0E5A57FAE@finney.org> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hal Finney wrote: > Ben Laurie writes: >> Slightly late to the party here, but I should note that hash truncation >> is not an operation that is thoroughly approved of. In particular I >> would worry that if it is permitted a cunning attacker might be able to >> choose a new q s.t. the signature still validated on a much shorter >> version of the hash, and thus show a valid signature on the wrong >> document. I would therefore suggest that we do _not_ permit arbitrary >> truncation of hashes. > > I don't understand what you are proposing here. To choose a new q means > to create a new key: a new (p, q, g, x, y) tuple. Then you are worried > that an existing (r, s) signature could be made to work with this new key? > I don't see why this would be a concern even if it worked; and it could be > eliminated by checking that r and s are < q, which you should do anyway. > > The NIST standard supports arbitrary truncation of (strong) hashes, and > if it were that risky I doubt very much that it would have gotten in. > John Kelsey at NIST is one of the top people in the field today and I > am sure this has been reviewed by him and other cryptographers. OK, you are right, I guess I'll count this nebulous concern as void. Certainly the language proposed accords with 186-3 on hash truncation. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2TIl6hj059523; Wed, 29 Mar 2006 11:47:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2TIl6X3059522; Wed, 29 Mar 2006 11:47:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2TIl53l059516 for ; Wed, 29 Mar 2006 11:47:05 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id E0E5A57FAE; Wed, 29 Mar 2006 10:45:30 -0800 (PST) To: ben@algroup.co.uk, ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2, take 4 Message-Id: <20060329184530.E0E5A57FAE@finney.org> Date: Wed, 29 Mar 2006 10:45:30 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ben Laurie writes: > Slightly late to the party here, but I should note that hash truncation > is not an operation that is thoroughly approved of. In particular I > would worry that if it is permitted a cunning attacker might be able to > choose a new q s.t. the signature still validated on a much shorter > version of the hash, and thus show a valid signature on the wrong > document. I would therefore suggest that we do _not_ permit arbitrary > truncation of hashes. I don't understand what you are proposing here. To choose a new q means to create a new key: a new (p, q, g, x, y) tuple. Then you are worried that an existing (r, s) signature could be made to work with this new key? I don't see why this would be a concern even if it worked; and it could be eliminated by checking that r and s are < q, which you should do anyway. The NIST standard supports arbitrary truncation of (strong) hashes, and if it were that risky I doubt very much that it would have gotten in. John Kelsey at NIST is one of the top people in the field today and I am sure this has been reviewed by him and other cryptographers. Hal Finney Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2THUqe3056089; Wed, 29 Mar 2006 10:30:52 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2THUqLB056088; Wed, 29 Mar 2006 10:30:52 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2THUpDU056082 for ; Wed, 29 Mar 2006 10:30:52 -0700 (MST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id D6F0633C44 for ; Wed, 29 Mar 2006 18:30:50 +0100 (BST) Message-ID: <442AC3D9.9000905@algroup.co.uk> Date: Wed, 29 Mar 2006 18:28:57 +0100 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2, take 4 References: <20060329163756.GB1001@jabberwocky.com> In-Reply-To: <20060329163756.GB1001@jabberwocky.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw wrote: > Here is round four. Only little fiddle changes at this point. > > ================================== > > Section 5.2.2 (Version 3 Signature Packet Format) says: > > DSA signatures MUST use hashes with a size of 160 bits, to match q, > the size of the group generated by the DSA key's generator value. > The hash function result is treated as a 160 bit number and used > directly in the DSA signature algorithm. > > change to: > > DSA signatures MUST use hashes that are equal in size to the > number of bits of q, the group generated by the DSA key's > generator value. If the output size of the chosen hash is larger > than the number of bits of q, the hash result is truncated to fit > by taking the number of leftmost bits equal to the number of bits > of q. This (possibly truncated) hash function result is treated > as a number and used directly in the DSA signature algorithm. > > No change. Slightly late to the party here, but I should note that hash truncation is not an operation that is thoroughly approved of. In particular I would worry that if it is permitted a cunning attacker might be able to choose a new q s.t. the signature still validated on a much shorter version of the hash, and thus show a valid signature on the wrong document. I would therefore suggest that we do _not_ permit arbitrary truncation of hashes. Secondly, q is not a group, it is a prime. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2TGc3bq053235; Wed, 29 Mar 2006 09:38:03 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2TGc33O053234; Wed, 29 Mar 2006 09:38:03 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2TGc239053228 for ; Wed, 29 Mar 2006 09:38:03 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2TGc2k30776 for ; Wed, 29 Mar 2006 11:38:02 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.13.6/8.13.5) with ESMTP id k2TGc5og026681 for ; Wed, 29 Mar 2006 11:38:05 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2TGbu2n001148 for ; Wed, 29 Mar 2006 11:37:56 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2TGbuVZ001147 for ietf-openpgp@imc.org; Wed, 29 Mar 2006 11:37:56 -0500 Date: Wed, 29 Mar 2006 11:37:56 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Suggested changes for DSA2, take 4 Message-ID: <20060329163756.GB1001@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here is round four. Only little fiddle changes at this point. ================================== Section 5.2.2 (Version 3 Signature Packet Format) says: DSA signatures MUST use hashes with a size of 160 bits, to match q, the size of the group generated by the DSA key's generator value. The hash function result is treated as a 160 bit number and used directly in the DSA signature algorithm. change to: DSA signatures MUST use hashes that are equal in size to the number of bits of q, the group generated by the DSA key's generator value. If the output size of the chosen hash is larger than the number of bits of q, the hash result is truncated to fit by taking the number of leftmost bits equal to the number of bits of q. This (possibly truncated) hash function result is treated as a number and used directly in the DSA signature algorithm. No change. ================================== Section 12.5. (DSA) says: An implementation SHOULD NOT implement DSA keys of size less than 1024 bits. Note that present DSA is limited to a maximum of 1024 bit keys, which are recommended for long-term use. Also, DSA keys MUST be an even multiple of 64 bits long. change to: An implementation SHOULD NOT implement DSA keys of size less than 1024 bits or with a q size of less than 160 bits. DSA keys MUST also be a multiple of 64 bits, and the q size MUST be a multiple of 8 bits. The Digital Signature Standard (DSS) [FIPS186] specifies that DSA be used in one of the following ways: * 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384 or SHA-512 hash * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384 or SHA-512 hash * 2048-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash * 3072-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash The above key and q size pairs were chosen to best balance the strength of the key with the strength of the hash. Implementations SHOULD use one of the above key and q size pairs when generating DSA keys. If DSS compliance is desired, one of the specified SHA hashes must be used as well. [FIPS186] is the ultimate authority on DSS, and should be consulted for all questions of DSS compliance. Note that earlier versions of this standard only allowed a 160-bit q with no truncation allowed, so earlier implementations may not be able to handle signatures with a different q size or a truncated hash. Added a MUST that the q size is a multiple of 8. I don't think any of us want to deal with hashes that don't end on a byte boundary. ================================== Section 13. (Security Considerations) says: * The DSA algorithm will work with any 160-bit hash, but it is sensitive to the quality of the hash algorithm, if the hash algorithm is broken, it can leak the secret key. The Digital Signature Standard (DSS) specifies that DSA be used with SHA-1. RIPEMD-160 is considered by many cryptographers to be as strong. An implementation should take care which hash algorithms are used with DSA, as a weak hash can not only allow a signature to be forged, but could leak the secret key. change to: * The DSA algorithm will work with any hash, but is sensitive to the quality of the hash algorithm. Verifiers should be aware that even if the signer used a strong hash, an attacker could have modified the signature to use a weak one. Only signatures using acceptably strong hash algorithms should be accepted as valid. Also add: * As OpenPGP combines many different asymmetric, symmetric, and hash algorithms, each with different measures of strength, care should be taken that the weakest element of an OpenPGP message is still sufficiently strong for the purpose at hand. While consensus about the the strength of a given algorithm may evolve, at publication time, NIST Special Publication 800-57 [SP800-57] recommended the following list of equivalent strengths: Asymmetric | Hash | Symmetric key size | size | key size ------------+--------+----------- 1024 160 80 2048 224 112 3072 256 128 7680 384 192 15360 512 256 Added the key size reminder. ================================== David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2TGXXfg053037; Wed, 29 Mar 2006 09:33:33 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2TGXXxF053036; Wed, 29 Mar 2006 09:33:33 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2TGXWXH053030 for ; Wed, 29 Mar 2006 09:33:32 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2TGXVk30758; Wed, 29 Mar 2006 11:33:31 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.13.6/8.13.5) with ESMTP id k2TGXYC4026622; Wed, 29 Mar 2006 11:33:34 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2TGXPos001136; Wed, 29 Mar 2006 11:33:25 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2TGXM3b001135; Wed, 29 Mar 2006 11:33:22 -0500 Date: Wed, 29 Mar 2006 11:33:22 -0500 From: David Shaw To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-ID: <20060329163322.GA1001@jabberwocky.com> Mail-Followup-To: Hal Finney , ietf-openpgp@imc.org References: <20060328235058.9FD9857FAE@finney.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060328235058.9FD9857FAE@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Mar 28, 2006 at 03:50:58PM -0800, "Hal Finney" wrote: > David Shaw wrote: > > How about this (presumably for the Security Considerations section): > > > > As OpenPGP combines many different asymmetric, symmetric, and hash > > algorithms, each with different measures of strength, care should > > be taken that the weakest element of an OpenPGP message is still > > sufficiently strong for the purpose at hand. Implementations > > receiving messages SHOULD indicate to the user the actual strength > > of the messages. While consensus about the the strength of a given > > algorithm may evolve, at publication time, NIST Special Publication > > 800-57 [SP800-57] recommended the following list of equivalent > > strengths: > > > > [ put table here ] > > I like this general direction, but I don't think it will work to indicate > to users the actual strength of message encryptions or signatures. > There is no convenient way to express this information that will be > understandable to the layman. We could say that a DSA1 signature has 80 > bits of strength, and a 2048 bit RSA encryption using AES-256 has 112 bits > of strength, but that is too technical and also in most cases too much > information. It's also non-standard practice in crypto implementations > to provide this information, and I don't feel comfortable putting in > a requirement for something this novel, without having experience to > justify it. I actually think this may well be simpler than what we have now. Right now GPG says things like "Signature made with 4096-bit RSA key" and optionally "Hash used was SHA-1" and such. I don't have a copy of PGP handy at the moment to check, but I recall it doesn't say either. Saying something like "This signature is 80 bits strong" would actually give a single, reasonably accurate number to indicate relative strength. I doubt many users can translate "4096 bit RSA with SHA-1" into a strength value they can compare with other strength values. However, you're quite right that it is a large step to make such a thing a SHOULD without any experience to justify it first. Certainly any implementation that wants to experiment down that route can do so without any special mandate in the standard. Dropping the notification SHOULD from the change gives this (for the Security Considerations section): As OpenPGP combines many different asymmetric, symmetric, and hash algorithms, each with different measures of strength, care should be taken that the weakest element of an OpenPGP message is still sufficiently strong for the purpose at hand. While consensus about the the strength of a given algorithm may evolve, at publication time, NIST Special Publication 800-57 [SP800-57] recommended the following list of equivalent strengths: [ put table here ] This is perhaps stating the obvious, but I think still worth mentioning. > > I'm still in favor of making the NIST list a SHOULD for generating > > DSA2 keys, of course. > > Okay, well, maybe the rest of it is too complex to deal with for now. Ok. I'll roll together a change take 4 and send it to the list. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2SNqaFu001864; Tue, 28 Mar 2006 16:52:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2SNqaAx001863; Tue, 28 Mar 2006 16:52:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2SNqZ5N001857 for ; Tue, 28 Mar 2006 16:52:35 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 9FD9857FAE; Tue, 28 Mar 2006 15:50:58 -0800 (PST) To: dshaw@jabberwocky.com, hal@finney.org Subject: Re: Suggested changes for DSA2 Cc: ietf-openpgp@imc.org Message-Id: <20060328235058.9FD9857FAE@finney.org> Date: Tue, 28 Mar 2006 15:50:58 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw wrote: > On Tue, Mar 28, 2006 at 01:04:12PM -0800, "Hal Finney" wrote: > > > I support David's suggestion to include a SHOULD relating hash size to key > > size. But it makes sense to me to extend our current key size SHOULD > > recommendations to include advice regarding subgroup size, hash size, > > and symmetric cipher key size. This would correspond to Table 2 on page > > 63 of NIST's SP800-57: > > http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf > > > > The sizes from that table are: > > > > 1024 / 160 / 80 > > 2048 / 224 / 112 > > 3072 / 512 / 256 > > 7680 / 768 / 384 > > 15360 / 1024 / 512 > > > > where the 1st column is the RSA, DSA or DH modulus size, the second > > column is the hash/subgroup size, and the 3rd column is the symmetric > > cipher key size (which is also the strength in bits). > > Are you sure that table is correct? I thought it was: > > 1024 / 160 / 80 > 2048 / 224 / 112 > 3072 / 256 / 128 > 7680 / 384 / 192 > 15360 / 512 / 256 Yes, sorry, you're right. I transcribed it wrong and doubled when I should have halved. > I'm not sure this is the right way to go about it. Is balance > actually what we want, or would it be better to just remind people > that the weakest parameter constrains the level of security? There is > nothing invalid about a 8192-bit RSA key making SHA-1 signatures. It > just means that the signature has at most 80 bits of strength. The > signer could have used a 1024-bit RSA key and gotten the same 80 bits > of strength, but that doesn't make the 8192-bit signature wrong (just > large). My suggested wording was more to encourage implementors to > indicate the actual strength, rather than to force balance. > > How about this (presumably for the Security Considerations section): > > As OpenPGP combines many different asymmetric, symmetric, and hash > algorithms, each with different measures of strength, care should > be taken that the weakest element of an OpenPGP message is still > sufficiently strong for the purpose at hand. Implementations > receiving messages SHOULD indicate to the user the actual strength > of the messages. While consensus about the the strength of a given > algorithm may evolve, at publication time, NIST Special Publication > 800-57 [SP800-57] recommended the following list of equivalent > strengths: > > [ put table here ] I like this general direction, but I don't think it will work to indicate to users the actual strength of message encryptions or signatures. There is no convenient way to express this information that will be understandable to the layman. We could say that a DSA1 signature has 80 bits of strength, and a 2048 bit RSA encryption using AES-256 has 112 bits of strength, but that is too technical and also in most cases too much information. It's also non-standard practice in crypto implementations to provide this information, and I don't feel comfortable putting in a requirement for something this novel, without having experience to justify it. I can see that invalidating 2048 bit RSA key signatures that use SHA-1 is not the right thing to do either, which my earlier language proposal could be interpreted to recommend. > I'm still in favor of making the NIST list a SHOULD for generating > DSA2 keys, of course. Okay, well, maybe the rest of it is too complex to deal with for now. Hal Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2SNMwHD099500; Tue, 28 Mar 2006 16:22:58 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2SNMwtL099499; Tue, 28 Mar 2006 16:22:58 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2SNMvwn099491 for ; Tue, 28 Mar 2006 16:22:57 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2SNMtk26366; Tue, 28 Mar 2006 18:22:55 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.13.6/8.13.5) with ESMTP id k2SNMuOe015416; Tue, 28 Mar 2006 18:22:56 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2SNMno9029152; Tue, 28 Mar 2006 18:22:49 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2SNMnCL029151; Tue, 28 Mar 2006 18:22:49 -0500 Date: Tue, 28 Mar 2006 18:22:49 -0500 From: David Shaw To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-ID: <20060328232249.GC28776@jabberwocky.com> Mail-Followup-To: Hal Finney , ietf-openpgp@imc.org References: <20060328210412.631EA57FAE@finney.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060328210412.631EA57FAE@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Mar 28, 2006 at 01:04:12PM -0800, "Hal Finney" wrote: > I support David's suggestion to include a SHOULD relating hash size to key > size. But it makes sense to me to extend our current key size SHOULD > recommendations to include advice regarding subgroup size, hash size, > and symmetric cipher key size. This would correspond to Table 2 on page > 63 of NIST's SP800-57: > http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf > > The sizes from that table are: > > 1024 / 160 / 80 > 2048 / 224 / 112 > 3072 / 512 / 256 > 7680 / 768 / 384 > 15360 / 1024 / 512 > > where the 1st column is the RSA, DSA or DH modulus size, the second > column is the hash/subgroup size, and the 3rd column is the symmetric > cipher key size (which is also the strength in bits). Are you sure that table is correct? I thought it was: 1024 / 160 / 80 2048 / 224 / 112 3072 / 256 / 128 7680 / 384 / 192 15360 / 512 / 256 > Proposed language: > > In order to provide consistent levels of security for end users, > implementors SHOULD balance public key modulus size, subgroup size, > hash size, and symmetric algorithm key size. While consensus about > appropriate choices of these parameters may change with time, NIST > Special Publication 800-57 recommends the following parameter size > choices: > > [Some version of NIST's Table 2 here] > > Implementors SHOULD use and require public key and other parameters > consistent with values in this table, or updated information based > on evolving consensus in the field. I'm not sure this is the right way to go about it. Is balance actually what we want, or would it be better to just remind people that the weakest parameter constrains the level of security? There is nothing invalid about a 8192-bit RSA key making SHA-1 signatures. It just means that the signature has at most 80 bits of strength. The signer could have used a 1024-bit RSA key and gotten the same 80 bits of strength, but that doesn't make the 8192-bit signature wrong (just large). My suggested wording was more to encourage implementors to indicate the actual strength, rather than to force balance. How about this (presumably for the Security Considerations section): As OpenPGP combines many different asymmetric, symmetric, and hash algorithms, each with different measures of strength, care should be taken that the weakest element of an OpenPGP message is still sufficiently strong for the purpose at hand. Implementations receiving messages SHOULD indicate to the user the actual strength of the messages. While consensus about the the strength of a given algorithm may evolve, at publication time, NIST Special Publication 800-57 [SP800-57] recommended the following list of equivalent strengths: [ put table here ] I'm still in favor of making the NIST list a SHOULD for generating DSA2 keys, of course. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2SL5pNw092238; Tue, 28 Mar 2006 14:05:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2SL5pG6092237; Tue, 28 Mar 2006 14:05:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2SL5oZP092231 for ; Tue, 28 Mar 2006 14:05:50 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 631EA57FAE; Tue, 28 Mar 2006 13:04:12 -0800 (PST) To: dshaw@jabberwocky.com, hal@finney.org Subject: Re: Suggested changes for DSA2 Cc: ietf-openpgp@imc.org Message-Id: <20060328210412.631EA57FAE@finney.org> Date: Tue, 28 Mar 2006 13:04:12 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David writes: > Forgetting DSA2 for a moment, this isn't a new problem. We have this > same key size / hash size mismatch possibility today with DSA1 (since > DSA in 2440 could be 768-1024 bits), and again with RSA (which can use > any hash, regardless of the key size). Fixing the q sizes for DSA2 > doesn't really solve this. The problem is not so bad with DSA1 because at worst the hash and subgroup would have been stronger than the key size, so by reporting the modulus we are giving an accurate lower bound on the strength. But you're right that we have had the problem all along with RSA. In fact in the old days I don't doubt that we had many users with 8K bit RSA keys using 128 bit MD5 for signatures. Daniel is right too that there is not complete agreement about the proper balance between subgroup/hash size and modulus size, and that future cryptographic developments may change this balance. Although we have not discussed it, the same problem arises for encryption, balancing the symmetric algorithm key size with the public key size. I've heard complaints that letting people use AES-256 with a 1024 or 2048 bit RSA key gives them a false sense of security. Clearly this complexity is a challenge to deal with. However we have made attempts in the past to provide minimal security guidelines. In our section 12 Notes on Algorithms we have sections 12.4, 12.5 and 12.6 giving minimum key sizes for RSA, DSA and DH as SHOULDs. I support David's suggestion to include a SHOULD relating hash size to key size. But it makes sense to me to extend our current key size SHOULD recommendations to include advice regarding subgroup size, hash size, and symmetric cipher key size. This would correspond to Table 2 on page 63 of NIST's SP800-57: http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf The sizes from that table are: 1024 / 160 / 80 2048 / 224 / 112 3072 / 512 / 256 7680 / 768 / 384 15360 / 1024 / 512 where the 1st column is the RSA, DSA or DH modulus size, the second column is the hash/subgroup size, and the 3rd column is the symmetric cipher key size (which is also the strength in bits). We could do as David suggests and say that implementors SHOULD follow SP800-57 or whatever updates it. However this will require implementors to acquire and read through this 220 page document in order to find these five lines of information. It seems to me that it is worthwhile to include these lines, and also to refer to SP800-57 and advise implementors to check for updates. Proposed language: In order to provide consistent levels of security for end users, implementors SHOULD balance public key modulus size, subgroup size, hash size, and symmetric algorithm key size. While consensus about appropriate choices of these parameters may change with time, NIST Special Publication 800-57 recommends the following parameter size choices: [Some version of NIST's Table 2 here] Implementors SHOULD use and require public key and other parameters consistent with values in this table, or updated information based on evolving consensus in the field. We could use this to replace the current language about key sizes in section 12, since the 1024 bit minimum is implicit in the table. Hal Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S9bHW9053310; Tue, 28 Mar 2006 02:37:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2S9bHpa053309; Tue, 28 Mar 2006 02:37:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S9bFLF053303 for ; Tue, 28 Mar 2006 02:37:16 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 20BD05447; Tue, 28 Mar 2006 11:37:15 +0200 (CEST) Date: Tue, 28 Mar 2006 11:37:15 +0200 To: ietf-openpgp@imc.org Subject: General remarks on uses of OpenPGP Message-ID: <20060328093715.GA20426@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is not directly relevant for the ongoing discussions, just a few thoughts inspired by them. The short summary is that I am advocating a conservative approach, and arguing against changing anything in the minimal requirements. Historically OpenPGP (and PGP) has been designed with the hypotetical NSA as an adversary in mind. As long as being secure against extremely well-funded adversaries does not put unnecessary burden on those of us, who only have less powerful enemies to worry about, this approach is more than welcome. It is great marketing, a safe bet, etc., etc., etc. The low cost of OpenPGP-based encryption of email has made it the solution of choice for the majority of those who care at all, even in the face of the fact that S/MIME is supported out-of-the-box on all popular email clients, while adding OpenPGP support requires non-trivial effort. This feat alone justifies the general approach of OpenPGP. I am extremely greatful to this WG of IETF for your choice of MUST algorithms, as it allowed me to implement the standard on the J2SE 1.4 platform without implementing any cryptography. Even on the somewhat crypto-crippled versions of Java, it is a full-strength, interoperable implementation. It allowed me to implement java applets weighing a few dozen kilobytes(!) that perform various PGP-operations and run on the vast majority of java-enabled browsers. A full-fledged GUI-client that does everything except key management fits into 140 kilobytes, including the gui. It is precisely the 3DES, SHA1, MD5, RSA-s, DSA-s, RSA-e and ELG-e choice of alrogithms that made this possible. Requiring AES or IDEA would have made it much more difficult, although I understand that letting go of IDEA and excluding Rijndael were both controversial choices at the time. If the standard's requirements exceed the bare minimum that one can count on in all sorts of legacy systems still in wide use, just to keep everybody secure against the hypotetical NSA (not the real one, by the way -- cryptography alone cannot achieve that), it would put an unnecessary burden on all sorts of practical applications where this is not a requirement. I think, that the standard should definitely allow building heavy-duty super-secure and super-efficient cryptosystems, if someone feels like that, but _requiring_ excessive strength and efficiency would be, well, excessive. -- Daniel Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S8kO17050845; Tue, 28 Mar 2006 01:46:24 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2S8kOTc050844; Tue, 28 Mar 2006 01:46:24 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S8kNE1050838 for ; Tue, 28 Mar 2006 01:46:23 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id F30DA5440; Tue, 28 Mar 2006 10:46:21 +0200 (CEST) Date: Tue, 28 Mar 2006 10:46:21 +0200 To: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-ID: <20060328084621.GA13268@epointsystem.org> References: <20060327232215.1754257FAE@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060327232215.1754257FAE@finney.org> User-Agent: Mutt/1.5.9i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Mar 27, 2006 at 03:22:15PM -0800, "Hal Finney" wrote: > > David writes: > > For implementation of signature verification you can just take p and q > > straight from the public key. You don't need to guess since the key > > has all the information you need. > > With signatures, it is the verifier more than the signer who is vulnerable > and who needs to be protected. The problem is that as the verifying > software it is my responsibility to provide some level of assurance to > the user about how strong this signature is. Right, but it still boils down to whether or not the verifier trusts a certain public key. Thus, the decision needs to be made on a per-key, rather than per-signature basis. I am not arguing here; it is just a remark. > Right now at best we only report the key size. I'd like to make sure that > q is as strong as p. Otherwise we might see a 4096 bit key with a 160 bit > q, so it is really no stronger than a 1024 bit key. That is not quite precise, either. Increasing the size of q and the size of p protect against two different attacks. Large q's protect against (optimized) brute-force or random guessing of the discrete logarithm, while large p's protect against sieve methods. The relative strength of the two attacks is not easily assessed. Sieve methods are getting better and better. Thus, in the future it may very well happen that the balanced choice will be 4096 bits for p and 160 bits for q. As desirable as describing strength in some one-dimensional quantity is, it is hardly possible. NIST's choice of matching modulus sizes and group orders reflect the balancing of time costs of state-of-the-art attacks with no regard to memory costs. (by the way, this same approach is reflected in declaring 3DES as strong as a 112-bit cipher -- as if 2^62 bits of memory were free) This is a long-standing tradition in the main-steam crypto community, but there is no universal consensus about this. > It is hard to report > to the user how strong a signature by that key should be considered to be. Yes, it is. That is one reason not to reflect _our_ judgement (even if we could ever come to an agreement) about it in the standard. > This problem goes away if we standardize on the q sizes that go with > certain p sizes. That's what I'd like to do. Any keys that break the > rules would be considered invalid. No, it won't go away. Moreoever, why would you declare |p|=1024 |q|=160 valid, while |p|=4096 |q|=160 invalid, while the second choice is clearly no weaker than the first one? Putting lower limits on both the modulus size and the group order makes more sense, but that also does not merit more than a passing remark in the standard. IMHO, of course. -- Daniel Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S22Rc1032973; Mon, 27 Mar 2006 19:02:27 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2S22Rdq032972; Mon, 27 Mar 2006 19:02:27 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S22Q8f032966 for ; Mon, 27 Mar 2006 19:02:27 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2S22Pk20897; Mon, 27 Mar 2006 21:02:25 -0500 Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.13.6/8.13.5) with ESMTP id k2S22SWe020966; Mon, 27 Mar 2006 21:02:28 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2S22I8u026527; Mon, 27 Mar 2006 21:02:18 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2S22FGL026526; Mon, 27 Mar 2006 21:02:15 -0500 Date: Mon, 27 Mar 2006 21:02:15 -0500 From: David Shaw To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-ID: <20060328020215.GA26393@jabberwocky.com> Mail-Followup-To: Hal Finney , ietf-openpgp@imc.org References: <20060327232215.1754257FAE@finney.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060327232215.1754257FAE@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Mar 27, 2006 at 03:22:15PM -0800, "Hal Finney" wrote: > David writes: > > For implementation of signature verification you can just take p and q > > straight from the public key. You don't need to guess since the key > > has all the information you need. > > With signatures, it is the verifier more than the signer who is vulnerable > and who needs to be protected. The problem is that as the verifying > software it is my responsibility to provide some level of assurance to > the user about how strong this signature is. > > Right now at best we only report the key size. I'd like to make sure that > q is as strong as p. Otherwise we might see a 4096 bit key with a 160 bit > q, so it is really no stronger than a 1024 bit key. It is hard to report > to the user how strong a signature by that key should be considered to be. > > This problem goes away if we standardize on the q sizes that go with > certain p sizes. That's what I'd like to do. Any keys that break the > rules would be considered invalid. Maybe we don't have to just do the > FIPS ones but could extend them somewhat. Forgetting DSA2 for a moment, this isn't a new problem. We have this same key size / hash size mismatch possibility today with DSA1 (since DSA in 2440 could be 768-1024 bits), and again with RSA (which can use any hash, regardless of the key size). Fixing the q sizes for DSA2 doesn't really solve this. I do agree there is an issue here, but I have trouble seeing it in terms of something that can be fixed in the standard, especially in a reasonably future-proofed way. It just feels a bit like pushing a user or UI problem into the data specification. Implementations are free to use whatever guidelines they like in presenting signature information to the user. It would be very reasonable for a program to pop up some sort of "Warning: the hash used in this signature is weaker than the key", or "this signature has xxxx bits of assurance" or whatever sort of message is deemed most understandable. I just think that the onus is on the implementation to do this, and not the standard. That said, I would support language (perhaps in the Security Considerations or signature sections) that read something like this: When verifying a signature, it may be noted that the strength of the signing key and the strength of the hash used are not similar. In such cases, implementations MAY/SHOULD warn the user that the overall signature strength is limited by the weakest part. In extreme cases, the implementation may wish to consider the signature to be in error. While conventional wisdom may change over time as to the strength of algorithms, at publication time, one such set of guidelines is [SP800]. And add a cite for [SP800] to the NIST key length / hash length guide. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RNNuoJ025399; Mon, 27 Mar 2006 16:23:56 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RNNuNd025398; Mon, 27 Mar 2006 16:23:56 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RNNuie025392 for ; Mon, 27 Mar 2006 16:23:56 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 1754257FAE; Mon, 27 Mar 2006 15:22:15 -0800 (PST) To: dshaw@jabberwocky.com, hal@finney.org Subject: Re: Suggested changes for DSA2 Cc: ietf-openpgp@imc.org Message-Id: <20060327232215.1754257FAE@finney.org> Date: Mon, 27 Mar 2006 15:22:15 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David writes: > For implementation of signature verification you can just take p and q > straight from the public key. You don't need to guess since the key > has all the information you need. With signatures, it is the verifier more than the signer who is vulnerable and who needs to be protected. The problem is that as the verifying software it is my responsibility to provide some level of assurance to the user about how strong this signature is. Right now at best we only report the key size. I'd like to make sure that q is as strong as p. Otherwise we might see a 4096 bit key with a 160 bit q, so it is really no stronger than a 1024 bit key. It is hard to report to the user how strong a signature by that key should be considered to be. This problem goes away if we standardize on the q sizes that go with certain p sizes. That's what I'd like to do. Any keys that break the rules would be considered invalid. Maybe we don't have to just do the FIPS ones but could extend them somewhat. Hal Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RMWWSO023191; Mon, 27 Mar 2006 15:32:32 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RMWW9m023190; Mon, 27 Mar 2006 15:32:32 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RMWVcI023184 for ; Mon, 27 Mar 2006 15:32:31 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2RMWNk19287; Mon, 27 Mar 2006 17:32:23 -0500 Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.13.6/8.13.5) with ESMTP id k2RMWQ8q018805; Mon, 27 Mar 2006 17:32:26 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2RMWH7G026234; Mon, 27 Mar 2006 17:32:17 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2RMWH7V026233; Mon, 27 Mar 2006 17:32:17 -0500 Date: Mon, 27 Mar 2006 17:32:16 -0500 From: David Shaw To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-ID: <20060327223216.GA25952@jabberwocky.com> Mail-Followup-To: Hal Finney , ietf-openpgp@imc.org References: <20060327220815.2716157FAE@finney.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060327220815.2716157FAE@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Mar 27, 2006 at 02:08:15PM -0800, "Hal Finney" wrote: > > As an implementor, the question remains: when I verify a signature, what > q sizes should I allow for a given p? For example, what q is OK for a p > of 1536? What q is OK for a p of 4096? Should I just make something up? > How is that going to promote interoperability? For implementation of signature verification you can just take p and q straight from the public key. You don't need to guess since the key has all the information you need. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RM9wrS022289; Mon, 27 Mar 2006 15:09:58 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RM9w1O022288; Mon, 27 Mar 2006 15:09:58 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RM9vqg022279 for ; Mon, 27 Mar 2006 15:09:58 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 2716157FAE; Mon, 27 Mar 2006 14:08:15 -0800 (PST) To: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-Id: <20060327220815.2716157FAE@finney.org> Date: Mon, 27 Mar 2006 14:08:15 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As an implementor, the question remains: when I verify a signature, what q sizes should I allow for a given p? For example, what q is OK for a p of 1536? What q is OK for a p of 4096? Should I just make something up? How is that going to promote interoperability? Hal Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RLt9ei021568; Mon, 27 Mar 2006 14:55:09 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RLt9qM021567; Mon, 27 Mar 2006 14:55:09 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from XBOX.spatialrift.com (xbox.spatialrift.com [64.146.111.237]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RLt8QN021561 for ; Mon, 27 Mar 2006 14:55:08 -0700 (MST) (envelope-from postmaster@mypgp.com) Received: from ([127.0.0.1]) with MailEnable ESMTP; Mon, 27 Mar 2006 15:50:01 -0600 Message-ID: <44285ED5.9050505@mypgp.com> Date: Mon, 27 Mar 2006 15:53:25 -0600 From: Sean Heeger Reply-To: postmaster@mypgp.com Organization: MyPGP.Com - Public PGP Resources User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: OpenPGP X-Enigmail-Version: 0.94.0.0 OpenPGP: id=025D7C5D; url=http://www.gettrusted.com/postmaster@mypgp.com.asc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: unsubscribe Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RLSLjF018913; Mon, 27 Mar 2006 14:28:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RLSLKR018909; Mon, 27 Mar 2006 14:28:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RLSKgR018888 for ; Mon, 27 Mar 2006 14:28:20 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7) for ; Mon, 27 Mar 2006 13:28:14 -0800 Received: from [63.251.255.205] ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Mon, 27 Mar 2006 13:28:14 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 27 Mar 2006 13:28:14 -0800 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <44284CDB.9040504@algroup.co.uk> References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> <441ACF45.704@systemics.com> <87fylhdq36.fsf@wheatstone.g10code.de> <20060317174937.GC13241@jabberwocky.com> <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> <44267719.1060302@algroup.co.uk> <44284CDB.9040504@algroup.co.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <494A8BEE-97D3-4B31-92C3-D67A645D8EE0@callas.org> Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: NIST publishes new DSA draft Date: Mon, 27 Mar 2006 13:28:13 -0800 To: OpenPGP X-Mailer: Apple Mail (2.746.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 27 Mar 2006, at 12:36 PM, Ben Laurie wrote: > > I'm not going to argue with this, but it clearly ain't much more. You > would be out on a limb to argue that it provided usefully more than > 112 > bits - though I won't hesitate to agree that 2DES < 3DES. > Ben, I think we're far closer to agreeing than disagreeing. During The Crypto Wars, we crypto-proponents made a point of saying that the minimum crypto we'd live with was 128-bit. The reasons for this had as much to do with the simple mathematical fact that 128 was the next convenient power of two as anything else. So therefore, viva IDEA, viva CAST, viva Blowfish. A lot of it was also just sheer politics. But what about three-key 3DES? Collectively, we agreed to include it as a "128-bit" cipher (the quotes are there to mean quasi-, or so- called). The reasons for this were also mostly politics. It would have been unwise to say, "ooo, ick, 3DES" and in fact in this group, arguably the most political standards group of them all, we not only *accepted* 3DES as 128-bit cipher, but made it the MUST. That was also mostly a political decision. It saved us a long, acrimonious argument about Blowfish and CAST with side trips along 3DES itself, DES/X, SAFER and others. Bravi us. (Personally, I say "3DES" to mean three-key-3DES. I consider the two-key version to be some unmentioned step-down, kinda the way that Blowfish will work with 32-bit keys. It's true, but we don't even grace it with a mention.) Reality is a collective hunch, especially in the IETF. The hunch is that 3DES is as good as IDEA, CAST, Blowfish, etc. Now, a decade later, we all mostly use AES. In fact, we mostly use AES-256, and that for marketing reasons. AES-128 runs faster than single-DES, and AES-256 is only 20% slower than -128, so there is pressure to step up to 256-bit keys. People do it because all the other kids are doing it, not for security. You are right that we've *agreed* that 3DES is a "128"-bit algorithm and there's no math to back it up. As fantasies (or collective hunches) go, it's not a bad one. The strength of 3DES all revolves around how much it's not a group. It appears to be enough of a non- group that this isn't a mad thought. Better, though, to just use AES. Or Twofish. Or petition the group to put Serpent in. Nonetheless, getting back to the hash functions, the *only* reason to use SHA-224 is that you have an application where a 28-byte hash will work and a 32-byte one will not. If one person thinks that's important for engineering reasons, I'm happy to have it in. If zero people think it has engineering value, then less is more. We don't need another hash function with no obvious value because in the future there will be more hash functions. Save room on the bus for the ones that aren't born yet. Jon Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RLQSPL017924; Mon, 27 Mar 2006 14:26:28 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RLQSUB017923; Mon, 27 Mar 2006 14:26:28 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RLQRZH017916 for ; Mon, 27 Mar 2006 14:26:27 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7) for ; Mon, 27 Mar 2006 13:25:40 -0800 Received: from [63.251.255.205] ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Mon, 27 Mar 2006 13:25:40 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 27 Mar 2006 13:25:40 -0800 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <20060327154427.GC7346@epointsystem.org> References: <20060326180218.12C8057FAE@finney.org> <20060326215531.GF30637@jabberwocky.com> <4427E67A.8050202@systemics.com> <20060327150120.GA25414@jabberwocky.com> <20060327154427.GC7346@epointsystem.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <23598E55-F454-4ED8-B3C7-7B716FDC3205@callas.org> Cc: OpenPGP Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: Suggested changes for DSA2 Date: Mon, 27 Mar 2006 13:25:38 -0800 X-Mailer: Apple Mail (2.746.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 27 Mar 2006, at 7:44 AM, Daniel A. Nagy wrote: > I agree with David here. The standard's purpose is to ensure > interoperability. It should tell us the sematics behind sequences > of bytes. > It is up to the implementation to make decisions based on these > semantics. > Valid reasons to exclude certain combinations from the standard > include > ambiguity of interpretation, inherent insecurity or a wide > installed base of > incompatible implementations, but not the possibility of weird > uses, IMHO. > I agree as well with both Davids. As an observation, in 2440 one of the things we allowed was deviation from DSS because the rough consensus had a certain amount of grumpiness with the US Government. In practice, hardly anyone did anything different with DSA than DSS. We even removed hash functions. Many things have changed in the last decade, but toeing the exact NIST line or even being like them only moreso is going a bit too far. In the next decade, we're going to see a lot of advancement in hash functions. Someone is going to want to use those new hash functions with DSA, and it would be nice to be able to move faster than NIST. Let's suppose someone comes up with a new hash function that is 251 bits. (I picked 251 because it's prime and less than 256.) We don't want a constitutional crisis over using it. We want to be flexible enough that it's pretty obvious how to extend OpenPGP to use new hash functions with DSA. Jon Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RKcjcB002026; Mon, 27 Mar 2006 13:38:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RKcjgo002025; Mon, 27 Mar 2006 13:38:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RKciDa001997 for ; Mon, 27 Mar 2006 13:38:45 -0700 (MST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 3C22333C1C; Mon, 27 Mar 2006 21:38:40 +0100 (BST) Message-ID: <44284CDB.9040504@algroup.co.uk> Date: Mon, 27 Mar 2006 21:36:43 +0100 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Jon Callas CC: OpenPGP Subject: Re: NIST publishes new DSA draft References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> <441ACF45.704@systemics.com> <87fylhdq36.fsf@wheatstone.g10code.de> <20060317174937.GC13241@jabberwocky.com> <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> <44267719.1060302@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas wrote: > On 26 Mar 2006, at 3:12 AM, Ben Laurie wrote: > >> Jon Callas wrote: >>> >>> I think we ought to keep it with the same algorithm number. >>> >>> I'm happy to put in SHA-224 (meaning it's trivial work), but I don't >>> like it, myself. The reason is that SHA-224 is really a truncated >>> SHA-256. Thus, it has no advantages over SHA-256 except being smaller by >>> 32-bits with 112 bits of security. The reason it exists at all is for >>> crypto-balance with 2-key 3DES (which is not TDEA), which we don't allow >>> at all. >> >> >> >> 3-key DES also has a strength of 112 bits. >> >> >> > > There are certainly good arguments for that, but if 3-key 3DES is no > stronger than 2-key, then there shouldn't be any harm in dropping the > third key. Right? If you don't like this idea (that 2-key and 3-key are > equivalent), which I don't, then 3-key must be some stronger. It just > isn't easy to know how much more. I'm not going to argue with this, but it clearly ain't much more. You would be out on a limb to argue that it provided usefully more than 112 bits - though I won't hesitate to agree that 2DES < 3DES. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RK0TDN083228; Mon, 27 Mar 2006 13:00:29 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RK0TUD083227; Mon, 27 Mar 2006 13:00:29 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RK0T0Z083197 for ; Mon, 27 Mar 2006 13:00:29 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7); Mon, 27 Mar 2006 12:00:24 -0800 Received: from [63.251.255.205] ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Mon, 27 Mar 2006 12:00:24 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 27 Mar 2006 12:00:24 -0800 In-Reply-To: <44267719.1060302@algroup.co.uk> References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> <441ACF45.704@systemics.com> <87fylhdq36.fsf@wheatstone.g10code.de> <20060317174937.GC13241@jabberwocky.com> <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> <44267719.1060302@algroup.co.uk> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: OpenPGP Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: NIST publishes new DSA draft Date: Mon, 27 Mar 2006 12:00:20 -0800 To: Ben Laurie X-Mailer: Apple Mail (2.746.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 26 Mar 2006, at 3:12 AM, Ben Laurie wrote: > Jon Callas wrote: >> >> I think we ought to keep it with the same algorithm number. >> >> I'm happy to put in SHA-224 (meaning it's trivial work), but I don't >> like it, myself. The reason is that SHA-224 is really a truncated >> SHA-256. Thus, it has no advantages over SHA-256 except being >> smaller by >> 32-bits with 112 bits of security. The reason it exists at all is for >> crypto-balance with 2-key 3DES (which is not TDEA), which we don't >> allow >> at all. > > > > 3-key DES also has a strength of 112 bits. > > > There are certainly good arguments for that, but if 3-key 3DES is no stronger than 2-key, then there shouldn't be any harm in dropping the third key. Right? If you don't like this idea (that 2-key and 3-key are equivalent), which I don't, then 3-key must be some stronger. It just isn't easy to know how much more. I wrote a long thing on this a couple years ago at: Jon Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RFiclN093522; Mon, 27 Mar 2006 08:44:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RFicr7093521; Mon, 27 Mar 2006 08:44:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RFib10093467 for ; Mon, 27 Mar 2006 08:44:37 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id D6CDD5456; Mon, 27 Mar 2006 17:44:27 +0200 (CEST) Date: Mon, 27 Mar 2006 17:44:27 +0200 To: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-ID: <20060327154427.GC7346@epointsystem.org> References: <20060326180218.12C8057FAE@finney.org> <20060326215531.GF30637@jabberwocky.com> <4427E67A.8050202@systemics.com> <20060327150120.GA25414@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060327150120.GA25414@jabberwocky.com> User-Agent: Mutt/1.5.9i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Mar 27, 2006 at 10:01:20AM -0500, David Shaw wrote: > It is not the place of a data format standard to hold people's hands > to that extent. We (correctly) don't tell people to reject signatures > from a 512-bit RSA key. That's not our job in the standard. If an > *implementation* wants to do that, that's just fine, but it does not > need permission from the standard to do it. I agree with David here. The standard's purpose is to ensure interoperability. It should tell us the sematics behind sequences of bytes. It is up to the implementation to make decisions based on these semantics. Valid reasons to exclude certain combinations from the standard include ambiguity of interpretation, inherent insecurity or a wide installed base of incompatible implementations, but not the possibility of weird uses, IMHO. Regards, -- Daniel Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RFVPqc093064; Mon, 27 Mar 2006 08:31:25 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RFVP8N093063; Mon, 27 Mar 2006 08:31:25 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RFVO6D093057 for ; Mon, 27 Mar 2006 08:31:24 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2RFVNk17528 for ; Mon, 27 Mar 2006 10:31:23 -0500 Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.13.6/8.13.5) with ESMTP id k2RFVOF8014146 for ; Mon, 27 Mar 2006 10:31:24 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2RFVHoU025589 for ; Mon, 27 Mar 2006 10:31:17 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2RFVHIx025588 for ietf-openpgp@imc.org; Mon, 27 Mar 2006 10:31:17 -0500 Date: Mon, 27 Mar 2006 10:31:17 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Suggested changes for DSA2, take 3 Message-ID: <20060327153117.GA25534@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here is round three with suggested changes from Hal and Ben. ================================== Section 5.2.2 (Version 3 Signature Packet Format) says: DSA signatures MUST use hashes with a size of 160 bits, to match q, the size of the group generated by the DSA key's generator value. The hash function result is treated as a 160 bit number and used directly in the DSA signature algorithm. change to: DSA signatures MUST use hashes that are equal in size to the number of bits of q, the group generated by the DSA key's generator value. If the output size of the chosen hash is larger than the number of bits of q, the hash result is truncated to fit by taking the number of leftmost bits equal to the number of bits of q. This (possibly truncated) hash function result is treated as a number and used directly in the DSA signature algorithm. Changes from both Hal and Ben. ================================== Section 12.5. (DSA) says: An implementation SHOULD NOT implement DSA keys of size less than 1024 bits. Note that present DSA is limited to a maximum of 1024 bit keys, which are recommended for long-term use. Also, DSA keys MUST be an even multiple of 64 bits long. change to: An implementation SHOULD NOT implement DSA keys of size less than 1024 bits or with a q size of less than 160 bits. DSA keys MUST also be an even multiple of 64 bits long. The Digital Signature Standard (DSS) [FIPS186] specifies that DSA be used in one of the following ways: * 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384 or SHA-512 hash * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384 or SHA-512 hash * 2048-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash * 3072-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash The above key and q size pairs were chosen to best balance the strength of the key with the strength of the hash. Implementations SHOULD use one of the above key and q size pairs when generating DSA keys. If DSS compliance is desired, one of the specified SHA hashes must be used as well. [FIPS186] is the ultimate authority on DSS, and should be consulted for all questions of DSS compliance. Note that earlier versions of this standard only allowed a 160-bit q with no truncation allowed, so earlier implementations may not be able to handle signatures with a different q size or a truncated hash. Added a reminder why we really, really want people to use one of the four DSS p/q pairs, plus a change with regards to referring people to FIPS186 for the DSS spec. DSS has other requirements besides the four p/q sizes and list of SHA hashes, and the original language implied that using the right size and right hash was enough for DSS compliance. ================================== Section 13. (Security Considerations) says: * The DSA algorithm will work with any 160-bit hash, but it is sensitive to the quality of the hash algorithm, if the hash algorithm is broken, it can leak the secret key. The Digital Signature Standard (DSS) specifies that DSA be used with SHA-1. RIPEMD-160 is considered by many cryptographers to be as strong. An implementation should take care which hash algorithms are used with DSA, as a weak hash can not only allow a signature to be forged, but could leak the secret key. change to: * The DSA algorithm will work with any hash, but is sensitive to the quality of the hash algorithm. Verifiers should be aware that even if the signer used a strong hash, an attacker could have modified the signature to use a weak one. Only signatures using acceptably strong hash algorithms should be accepted as valid. Change from Hal. ================================== David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RFO6vi092599; Mon, 27 Mar 2006 08:24:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RFO6UK092598; Mon, 27 Mar 2006 08:24:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RFO1we092591 for ; Mon, 27 Mar 2006 08:24:05 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2RFO0k17499; Mon, 27 Mar 2006 10:24:00 -0500 Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.13.6/8.13.5) with ESMTP id k2RFO1GT014059; Mon, 27 Mar 2006 10:24:01 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2RFNsnB025570; Mon, 27 Mar 2006 10:23:54 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2RFNsGT025569; Mon, 27 Mar 2006 10:23:54 -0500 Date: Mon, 27 Mar 2006 10:23:54 -0500 From: David Shaw To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-ID: <20060327152354.GB25414@jabberwocky.com> Mail-Followup-To: Hal Finney , ietf-openpgp@imc.org References: <20060326180218.12C8057FAE@finney.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060326180218.12C8057FAE@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Mar 26, 2006 at 10:02:18AM -0800, "Hal Finney" wrote: > > > * The DSA algorithm will work with any hash, but it is > > > sensitive to the quality of the hash algorithm. An implementation > > > should take care which hash algorithms are used with DSA. > > > Verifiers should be aware that even if the signer used a strong > > > hash, an attacker could have modified a signature to use a > > > weak one. Only signatures issued using acceptably strong hash > > > algorithms should be accepted as valid. > > On re-reading this I have two improvements. The second sentence is > redundant. And the last sentence cautions verifiers about what hash > was used when the sig was "issued", but the verifier doesn't know this > (that is the point), it only knows what it sees: > > * The DSA algorithm will work with any hash, but it is > sensitive to the quality of the hash algorithm. Verifiers > should be aware that even if the signer used a strong hash, > an attacker could have modified a signature to use a weak one. > Only signatures using acceptably strong hash algorithms should > be accepted as valid. Yes, I made a similar change in the "round 2" changes for the same reason. I've fixed the redundant second sentence for round 3. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RF1T1F090912; Mon, 27 Mar 2006 08:01:29 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RF1TuU090911; Mon, 27 Mar 2006 08:01:29 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RF1SLm090905 for ; Mon, 27 Mar 2006 08:01:28 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2RF1Qk17454; Mon, 27 Mar 2006 10:01:26 -0500 Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.13.6/8.13.5) with ESMTP id k2RF1Rcw013654; Mon, 27 Mar 2006 10:01:27 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2RF1KPw025477; Mon, 27 Mar 2006 10:01:20 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2RF1KYG025476; Mon, 27 Mar 2006 10:01:20 -0500 Date: Mon, 27 Mar 2006 10:01:20 -0500 From: David Shaw To: Ian G Cc: Hal Finney , ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-ID: <20060327150120.GA25414@jabberwocky.com> Mail-Followup-To: Ian G , Hal Finney , ietf-openpgp@imc.org References: <20060326180218.12C8057FAE@finney.org> <20060326215531.GF30637@jabberwocky.com> <4427E67A.8050202@systemics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4427E67A.8050202@systemics.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Mar 27, 2006 at 03:19:54PM +0200, Ian G wrote: > I would vote for just allowing a subset of the NIST sizes. > That is, something like an implementation MUST accept the > NIST set, and SHOULD reject all others. If a need for a > variant comes up, the developers have to battle it out and > justify going up against the SHOULD. If there is a clear > need, then they'll work it out. It is not the place of a data format standard to hold people's hands to that extent. We (correctly) don't tell people to reject signatures from a 512-bit RSA key. That's not our job in the standard. If an *implementation* wants to do that, that's just fine, but it does not need permission from the standard to do it. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RDLxjH086420; Mon, 27 Mar 2006 06:21:59 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RDLxPF086419; Mon, 27 Mar 2006 06:21:59 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RDLwrx086413 for ; Mon, 27 Mar 2006 06:21:59 -0700 (MST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 1733C41679; Mon, 27 Mar 2006 14:21:57 +0100 (BST) Message-ID: <4427E67A.8050202@systemics.com> Date: Mon, 27 Mar 2006 15:19:54 +0200 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Shaw Cc: Hal Finney , ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 References: <20060326180218.12C8057FAE@finney.org> <20060326215531.GF30637@jabberwocky.com> In-Reply-To: <20060326215531.GF30637@jabberwocky.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw wrote: > On Sun, Mar 26, 2006 at 10:02:18AM -0800, "Hal Finney" wrote: > > >>It's always a tricky question, how much we should try to enforce >>security standards in a data-format document. We do put minimum length >>restrictions on the moduli to try to protect users against making one >>kind of mistake, using a too-short key. In the same way, I don't think >>we should allow them to use a 160-bit q for a 3072-bit p. This is the >>spirit behind my suggestion to just allow the NIST sizes. > > > I think we more or less agree on this. My only sticking point is the > idea of allowing people to do something other than the NIST sizes. > How about we make the NIST sizes a SHOULD (like the minimum length > restrictions are SHOULD NOTs), and add a sentence after that to read > something like "Caution should be taken when deviating from the above > parameters which were carefully chosen to balance the strength of the > hash with the strength of the key." ? > > That would seem to be the best of all worlds: we strongly advise > people to use the NIST sizes, tell them why we want them to use the > NIST sizes, but don't lock them down. The question is more whether a receiving implementation should / may read non-preferred sizes. My inclination is to reduce them wherever possible. I've yet to see a real case where it has been useful to have non-standard sizes, and I've seen many cases where incompatibilities have sprung from overly broad readings of what was allowed. There's also no need for the standard to say this at all. If there was a need for a variant, then the various implementations can try it out and implement it as a non- standard variant. I would vote for just allowing a subset of the NIST sizes. That is, something like an implementation MUST accept the NIST set, and SHOULD reject all others. If a need for a variant comes up, the developers have to battle it out and justify going up against the SHOULD. If there is a clear need, then they'll work it out. iang PS: was it Bernstein who said, be precise in what you output, and be precise in what you accept for input? Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QLtkJn046188; Sun, 26 Mar 2006 14:55:46 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2QLtkPR046187; Sun, 26 Mar 2006 14:55:46 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QLtjgs046181 for ; Sun, 26 Mar 2006 14:55:45 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2QLtdk13445; Sun, 26 Mar 2006 16:55:39 -0500 Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.13.6/8.13.5) with ESMTP id k2QLtbEU002855; Sun, 26 Mar 2006 16:55:37 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2QLtWCC023209; Sun, 26 Mar 2006 16:55:32 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2QLtVNm023208; Sun, 26 Mar 2006 16:55:31 -0500 Date: Sun, 26 Mar 2006 16:55:31 -0500 From: David Shaw To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-ID: <20060326215531.GF30637@jabberwocky.com> Mail-Followup-To: Hal Finney , ietf-openpgp@imc.org References: <20060326180218.12C8057FAE@finney.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060326180218.12C8057FAE@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Mar 26, 2006 at 10:02:18AM -0800, "Hal Finney" wrote: > It's always a tricky question, how much we should try to enforce > security standards in a data-format document. We do put minimum length > restrictions on the moduli to try to protect users against making one > kind of mistake, using a too-short key. In the same way, I don't think > we should allow them to use a 160-bit q for a 3072-bit p. This is the > spirit behind my suggestion to just allow the NIST sizes. I think we more or less agree on this. My only sticking point is the idea of allowing people to do something other than the NIST sizes. How about we make the NIST sizes a SHOULD (like the minimum length restrictions are SHOULD NOTs), and add a sentence after that to read something like "Caution should be taken when deviating from the above parameters which were carefully chosen to balance the strength of the hash with the strength of the key." ? That would seem to be the best of all worlds: we strongly advise people to use the NIST sizes, tell them why we want them to use the NIST sizes, but don't lock them down. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QI44kw037256; Sun, 26 Mar 2006 11:04:04 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2QI44Aq037255; Sun, 26 Mar 2006 11:04:04 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QI43t2037249 for ; Sun, 26 Mar 2006 11:04:03 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 12C8057FAE; Sun, 26 Mar 2006 10:02:18 -0800 (PST) To: dshaw@jabberwocky.com, hal@finney.org Subject: Re: Suggested changes for DSA2 Cc: ietf-openpgp@imc.org Message-Id: <20060326180218.12C8057FAE@finney.org> Date: Sun, 26 Mar 2006 10:02:18 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw writes: > On Fri, Mar 24, 2006 at 12:21:42PM -0800, "Hal Finney" wrote: > > Aside from this I think David's wording is a little unclear about "the > > appropriate number" of leftmost bits. Maybe we could say: > > > > DSA signatures MUST use hashes that are equal to or larger than the > > size of q, the group generated by the DSA key's generator value. > > If the chosen hash is larger than the size of q, the hash result > > is truncated to fit by taking a number of leftmost bits equal to > > the number of bits in q. This (possibly truncated) hash function > > result is treated as a number and used directly in the DSA signature > > algorithm. > > > > Note that this truncation (or non-truncation) could still leave the > > hash as bigger than q, but that is OK as the signature and validation > > algorithms will either explicitly or implicitly take it mod q as it > > is used. So I don't think we have to tell them to take it mod q. > > I agree with your suggested change, but I'm not sure I follow this > comment. How could the hash still be bigger than q if we're > explicitly truncating it to be the same size as q? For example, we have a 1024 bit key with a 160 bit q. We truncate a SHA-256 hash to 160 bits. But q < 2^160, hence the truncated hash can still be greater than q, i.e. q < trunc(hash) < 2^160. I see that my proposed text still has this somewhat ambiguous reference to "the size of q". It also refers to the size of the chosen hash when it should say the output size. If I fix those two it becomes: DSA signatures MUST use hashes whose output size is equal to or larger than the number of bits of q, the group generated by the DSA key's generator value. If the output size of the chosen hash is larger than the number of bits of q, the hash result is truncated to fit by taking a number of leftmost bits equal to the number of bits of q. This (possibly truncated) hash function result is treated as a number and used directly in the DSA signature algorithm. Regarding the question of whether to allow intermediate sizes: > I wasn't so much thinking about which q to use for intermediate p > sizes, but rather thinking more from the verification end: namely, we > can't stop people from generating whatever key they like, sensible or > not. So rather than defining the set of valid p/q pairs, and > presumably rejecting any p or q outside the defined set, I was > thinking of just stepping back and saying, in effect, that this isn't > our problem to solve. Give SHOULD guidance on what to generate > (i.e. the FIPS list), but don't make it a MUST to lock things down to > that list. Otherwise, a few years from now, FIPS-186-4 will come out > and define a p/q pair not on the FIPS-186-3 list and break all of our > implementations. > > The FIPS draft refers such questions to NIST publication SP800-57, > which actually does mention two larger p/q pairs: p=7680 q=384 and > p=15360 q=512 (see page 63). Not that I think that a 15360-bit DSA > key is useful in practice in 2006, but clearly there is already > consideration of other key sizes. It's always a tricky question, how much we should try to enforce security standards in a data-format document. We do put minimum length restrictions on the moduli to try to protect users against making one kind of mistake, using a too-short key. In the same way, I don't think we should allow them to use a 160-bit q for a 3072-bit p. This is the spirit behind my suggestion to just allow the NIST sizes. Allowing the bigger sizes would also be consistent with this proposal but I don't think everyone would want to support those. > > * The DSA algorithm will work with any hash, but it is > > sensitive to the quality of the hash algorithm. An implementation > > should take care which hash algorithms are used with DSA. > > Verifiers should be aware that even if the signer used a strong > > hash, an attacker could have modified a signature to use a > > weak one. Only signatures issued using acceptably strong hash > > algorithms should be accepted as valid. On re-reading this I have two improvements. The second sentence is redundant. And the last sentence cautions verifiers about what hash was used when the sig was "issued", but the verifier doesn't know this (that is the point), it only knows what it sees: * The DSA algorithm will work with any hash, but it is sensitive to the quality of the hash algorithm. Verifiers should be aware that even if the signer used a strong hash, an attacker could have modified a signature to use a weak one. Only signatures using acceptably strong hash algorithms should be accepted as valid. Hal Finney Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QHNEVi034960; Sun, 26 Mar 2006 10:23:14 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2QHNEKc034959; Sun, 26 Mar 2006 10:23:14 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QHND07034953 for ; Sun, 26 Mar 2006 10:23:13 -0700 (MST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 8CABD33C1C for ; Sun, 26 Mar 2006 18:23:12 +0100 (BST) Message-ID: <4426CD8A.4080105@algroup.co.uk> Date: Sun, 26 Mar 2006 18:21:14 +0100 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2, take 2 References: <20060326162341.GE30637@jabberwocky.com> In-Reply-To: <20060326162341.GE30637@jabberwocky.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw wrote: > Here is some revised suggested DSA2 language, taking Hal's comments > into account and adding some extra polish. While I agree with his > suggestion to reorganize the signature sections, I'm reluctant to get > into that in this mail as I think that getting general consensus on > DSA2 language would be easier if the two weren't combined. I'd be > happy to take it up separately though. > > ================================== > > Section 5.2.2 (Version 3 Signature Packet Format) says: > > DSA signatures MUST use hashes with a size of 160 bits, to match q, > the size of the group generated by the DSA key's generator value. > The hash function result is treated as a 160 bit number and used > directly in the DSA signature algorithm. > > change to: > > DSA signatures MUST use hashes that are equal to or larger than language nit: "equal in size to" > the size of q, the group generated by the DSA key's generator > value. If the chosen hash is larger than the size of q, the hash > result is truncated to fit by taking a number of leftmost bits > equal to the number of bits in q. This (possibly truncated) hash > function result is treated as a number and used directly in the > DSA signature algorithm. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QGNnln032358; Sun, 26 Mar 2006 09:23:49 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2QGNn1j032357; Sun, 26 Mar 2006 09:23:49 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QGNnQF032351 for ; Sun, 26 Mar 2006 09:23:49 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2QGNlk12030 for ; Sun, 26 Mar 2006 11:23:47 -0500 Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.13.6/8.13.5) with ESMTP id k2QGNi9P019499 for ; Sun, 26 Mar 2006 11:23:44 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2QGNfxK022185 for ; Sun, 26 Mar 2006 11:23:41 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2QGNfch022184 for ietf-openpgp@imc.org; Sun, 26 Mar 2006 11:23:41 -0500 Date: Sun, 26 Mar 2006 11:23:41 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Suggested changes for DSA2, take 2 Message-ID: <20060326162341.GE30637@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here is some revised suggested DSA2 language, taking Hal's comments into account and adding some extra polish. While I agree with his suggestion to reorganize the signature sections, I'm reluctant to get into that in this mail as I think that getting general consensus on DSA2 language would be easier if the two weren't combined. I'd be happy to take it up separately though. ================================== Section 5.2.2 (Version 3 Signature Packet Format) says: DSA signatures MUST use hashes with a size of 160 bits, to match q, the size of the group generated by the DSA key's generator value. The hash function result is treated as a 160 bit number and used directly in the DSA signature algorithm. change to: DSA signatures MUST use hashes that are equal to or larger than the size of q, the group generated by the DSA key's generator value. If the chosen hash is larger than the size of q, the hash result is truncated to fit by taking a number of leftmost bits equal to the number of bits in q. This (possibly truncated) hash function result is treated as a number and used directly in the DSA signature algorithm. ================================== Section 12.5. (DSA) says: An implementation SHOULD NOT implement DSA keys of size less than 1024 bits. Note that present DSA is limited to a maximum of 1024 bit keys, which are recommended for long-term use. Also, DSA keys MUST be an even multiple of 64 bits long. change to: An implementation SHOULD NOT implement DSA keys of size less than 1024 bits or with a q size of less than 160 bits. DSA keys MUST be an even multiple of 64 bits long. The Digital Signature Standard (DSS) specifies that DSA be used in one of the following ways: * 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384 or SHA-512 hash * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384 or SHA-512 hash * 2048-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash * 3072-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash Implementations SHOULD use one of the above key and q size pairs when generating DSA keys. For full DSS compliance, one of the specified SHA hashes must be used as well. Note that earlier versions of this standard only allowed a 160-bit q with no truncation allowed, so earlier implementations may not be able to handle signatures with a different q size or a truncated hash. The intent here is to say we really want you to use these p/q sizes, and if you want to be DSS-compliant, you need to use these hashes too. I removed the bit about how other key sizes, q sizes, and hashes were legal as it really just restates the same thing again. ================================== Section 13. (Security Considerations) says: * The DSA algorithm will work with any 160-bit hash, but it is sensitive to the quality of the hash algorithm, if the hash algorithm is broken, it can leak the secret key. The Digital Signature Standard (DSS) specifies that DSA be used with SHA-1. RIPEMD-160 is considered by many cryptographers to be as strong. An implementation should take care which hash algorithms are used with DSA, as a weak hash can not only allow a signature to be forged, but could leak the secret key. change to: * The DSA algorithm will work with any hash, but is sensitive to the quality of the hash algorithm. An implementation should take care which hash algorithms are used with DSA. Verifiers should be aware that even if the signer used a strong hash, an attacker could have modified the signature to use a weak one. Only signatures using acceptably strong hash algorithms should be accepted as valid. ================================== David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QEmdP7028514; Sun, 26 Mar 2006 07:48:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2QEmdkD028513; Sun, 26 Mar 2006 07:48:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QEmcOI028507 for ; Sun, 26 Mar 2006 07:48:38 -0700 (MST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 7D10033C1C; Sun, 26 Mar 2006 15:48:37 +0100 (BST) Message-ID: <4426A94F.6050806@algroup.co.uk> Date: Sun, 26 Mar 2006 15:46:39 +0100 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Hal Finney CC: dshaw@jabberwocky.com, ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 References: <20060324202142.8E06257FAE@finney.org> In-Reply-To: <20060324202142.8E06257FAE@finney.org> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hal Finney wrote: > DSA signatures MUST use hashes that are equal to or larger than the > size of q, the group generated by the DSA key's generator value. > If the chosen hash is larger than the size of q, the hash result > is truncated to fit by taking a number of leftmost bits equal to > the number of bits in q. This (possibly truncated) hash function > result is treated as a number and used directly in the DSA signature > algorithm. > > Note that this truncation (or non-truncation) could still leave the > hash as bigger than q, but that is OK as the signature and validation > algorithms will either explicitly or implicitly take it mod q as it > is used. So I don't think we have to tell them to take it mod q. Not sure what you mean by this - the point is that the hash should end up with the same number of bits as q. BTW, I don't believe truncation is actually required mathematically, but it is presumably more efficient to truncate. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QBEQF2020808; Sun, 26 Mar 2006 04:14:27 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2QBEQpV020807; Sun, 26 Mar 2006 04:14:26 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2QBEPKX020800 for ; Sun, 26 Mar 2006 04:14:26 -0700 (MST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 15BF233C1C; Sun, 26 Mar 2006 12:14:24 +0100 (BST) Message-ID: <44267719.1060302@algroup.co.uk> Date: Sun, 26 Mar 2006 12:12:25 +0100 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Jon Callas CC: OpenPGP Subject: Re: NIST publishes new DSA draft References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> <441ACF45.704@systemics.com> <87fylhdq36.fsf@wheatstone.g10code.de> <20060317174937.GC13241@jabberwocky.com> <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> In-Reply-To: <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas wrote: > > I think we ought to keep it with the same algorithm number. > > I'm happy to put in SHA-224 (meaning it's trivial work), but I don't > like it, myself. The reason is that SHA-224 is really a truncated > SHA-256. Thus, it has no advantages over SHA-256 except being smaller by > 32-bits with 112 bits of security. The reason it exists at all is for > crypto-balance with 2-key 3DES (which is not TDEA), which we don't allow > at all. 3-key DES also has a strength of 112 bits. > I don't think we should have it as it goes against our > principles of wanting a minimum of 128-bits of security in OpenPGP. > (Yes, yes, I know that SHA-1 doesn't meet this either, but until > SHA-256, we didn't have many options. That doesn't mean the principle is > wrong; we *have* options.) > > Jon > > -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2OLDxhp075358; Fri, 24 Mar 2006 14:13:59 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2OLDxv0075357; Fri, 24 Mar 2006 14:13:59 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2OLDwi3075351 for ; Fri, 24 Mar 2006 14:13:59 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2OLDuk00642; Fri, 24 Mar 2006 16:13:56 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id k2OLDt6c031004; Fri, 24 Mar 2006 16:13:55 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2OLDoXO025378; Fri, 24 Mar 2006 16:13:50 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2OLDoib025377; Fri, 24 Mar 2006 16:13:50 -0500 Date: Fri, 24 Mar 2006 16:13:50 -0500 From: David Shaw To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-ID: <20060324211350.GA25330@jabberwocky.com> Mail-Followup-To: Hal Finney , ietf-openpgp@imc.org References: <20060324202142.8E06257FAE@finney.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060324202142.8E06257FAE@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Mar 24, 2006 at 12:21:42PM -0800, "Hal Finney" wrote: > First, I think this needs to be moved out of 5.2.2 since it is not > specific to V3 signatures; either that, or it needs to be replicated > in 5.2.3 on V4 sigs. Actually there is a lot of stuff in 5.2.2 about > signatures that does not belong there, a bunch of rules for RSA, OIDs > and such. > > Perhaps this should all go into 5.2.4, Computing Signatures; or into a > new section, 5.2.5. Unfortunately for the readability of the document, > 5.2.3 is extremely long as it discusses each subpacket, so many people > don't necessarily notice 5.2.4 and realize how crucially important it is. > I wonder if it would make sense to move the subpackets out of 5.2.3 and > into a new 5.2.6 section, so that 5.2.4 and the new 5.2.5 would be right > up front with the other data. I agree with all this. > Aside from this I think David's wording is a little unclear about "the > appropriate number" of leftmost bits. Maybe we could say: > > DSA signatures MUST use hashes that are equal to or larger than the > size of q, the group generated by the DSA key's generator value. > If the chosen hash is larger than the size of q, the hash result > is truncated to fit by taking a number of leftmost bits equal to > the number of bits in q. This (possibly truncated) hash function > result is treated as a number and used directly in the DSA signature > algorithm. > > Note that this truncation (or non-truncation) could still leave the > hash as bigger than q, but that is OK as the signature and validation > algorithms will either explicitly or implicitly take it mod q as it > is used. So I don't think we have to tell them to take it mod q. I agree with your suggested change, but I'm not sure I follow this comment. How could the hash still be bigger than q if we're explicitly truncating it to be the same size as q? > That's a good question. I am uncomfortable permitting larger DSA > keys of sizes different than the DSS ones. The balancing of the q and > p sizes is something of an art and people tend to disagree somewhat. > What size should q be for a 1568 bit modulus? Or a 1024+64=1090 bit one? > It's very questionable. > > I would feel more comfortable restricting to the DSS key sizes even > for OpenPGP keys. Is there really much benefit to intermediate sizes? > The size of the signature is dependent only on the size of q, and I > don't know how we could legitimately scale up from 160 to 224 or 256 > as we increase p from 1024 to 2048 bits. Yes, we could come up with > some formula, but there would not be much consensus. The FIPS guys > undoubtedly faced the same problem and decided to finalize on just these > two new sizes, and I am inclined to do the same. I wasn't so much thinking about which q to use for intermediate p sizes, but rather thinking more from the verification end: namely, we can't stop people from generating whatever key they like, sensible or not. So rather than defining the set of valid p/q pairs, and presumably rejecting any p or q outside the defined set, I was thinking of just stepping back and saying, in effect, that this isn't our problem to solve. Give SHOULD guidance on what to generate (i.e. the FIPS list), but don't make it a MUST to lock things down to that list. Otherwise, a few years from now, FIPS-186-4 will come out and define a p/q pair not on the FIPS-186-3 list and break all of our implementations. The FIPS draft refers such questions to NIST publication SP800-57, which actually does mention two larger p/q pairs: p=7680 q=384 and p=15360 q=512 (see page 63). Not that I think that a 15360-bit DSA key is useful in practice in 2006, but clearly there is already consideration of other key sizes. > > Hal has expressed concern with the "weak hash can leak the secret key" > > warning in the past, so perhaps he'll comment here. > > Right, I don't believe it is true that a weak hash can leak the secret > key. Rather, a weak random choice of the "k" value in the signature > can leak the secret key, but that is a completely different issue. > > As far as this wording, it is OK but it needs to be emphasized for the > verifier as much as or more than for the signer. One problem with the > new DSS is that it does not specify a unique hash algorithm, hence if > any of them break then an attacker could take an existing signature, > modify the hash algorithm ID, and perhaps create a fake message that > works with that signature and the broken hash. There is nothing the > signer can do to prevent this. Even if he uses a strong hash, if there > is a broken hash around someone can change the signature to use that hash. > So the point is that the verifier more than the signer must make sure that > a DSA signature is signed by an acceptably strong hash. If SHA-256 breaks > but SHA-512 is still OK it needs to warn on signatures using SHA-256. > > So I would suggest something like this: > > * The DSA algorithm will work with any hash, but it is > sensitive to the quality of the hash algorithm. An implementation > should take care which hash algorithms are used with DSA. > Verifiers should be aware that even if the signer used a strong > hash, an attacker could have modified a signature to use a > weak one. Only signatures issued using acceptably strong hash > algorithms should be accepted as valid. Agreed. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2OKNauw073340; Fri, 24 Mar 2006 13:23:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2OKNaFV073339; Fri, 24 Mar 2006 13:23:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2OKNZXM073333 for ; Fri, 24 Mar 2006 13:23:35 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 8E06257FAE; Fri, 24 Mar 2006 12:21:42 -0800 (PST) To: dshaw@jabberwocky.com, ietf-openpgp@imc.org Subject: Re: Suggested changes for DSA2 Message-Id: <20060324202142.8E06257FAE@finney.org> Date: Fri, 24 Mar 2006 12:21:42 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David's suggestions are a good starting point but I have a few comments: > ================================== > > Section 5.2.2 (Version 3 Signature Packet Format) says: > > DSA signatures MUST use hashes with a size of 160 bits, to match q, > the size of the group generated by the DSA key's generator value. > The hash function result is treated as a 160 bit number and used > directly in the DSA signature algorithm. > > change to: > > DSA signatures MUST use hashes that are equal to or larger than > the size of q, the group generated by the DSA key's generator > value. If the chosen hash is larger than the size of q, the hash > result is truncated to fit by taking the appropriate number of > leftmost bits. This (possibly truncated) hash function result is > treated as a number and used directly in the DSA signature > algorithm. First, I think this needs to be moved out of 5.2.2 since it is not specific to V3 signatures; either that, or it needs to be replicated in 5.2.3 on V4 sigs. Actually there is a lot of stuff in 5.2.2 about signatures that does not belong there, a bunch of rules for RSA, OIDs and such. Perhaps this should all go into 5.2.4, Computing Signatures; or into a new section, 5.2.5. Unfortunately for the readability of the document, 5.2.3 is extremely long as it discusses each subpacket, so many people don't necessarily notice 5.2.4 and realize how crucially important it is. I wonder if it would make sense to move the subpackets out of 5.2.3 and into a new 5.2.6 section, so that 5.2.4 and the new 5.2.5 would be right up front with the other data. Aside from this I think David's wording is a little unclear about "the appropriate number" of leftmost bits. Maybe we could say: DSA signatures MUST use hashes that are equal to or larger than the size of q, the group generated by the DSA key's generator value. If the chosen hash is larger than the size of q, the hash result is truncated to fit by taking a number of leftmost bits equal to the number of bits in q. This (possibly truncated) hash function result is treated as a number and used directly in the DSA signature algorithm. Note that this truncation (or non-truncation) could still leave the hash as bigger than q, but that is OK as the signature and validation algorithms will either explicitly or implicitly take it mod q as it is used. So I don't think we have to tell them to take it mod q. > ================================== > > Section 12.5. (DSA) says: > > An implementation SHOULD NOT implement DSA keys of size less than > 1024 bits. Note that present DSA is limited to a maximum of 1024 bit > keys, which are recommended for long-term use. Also, DSA keys MUST > be an even multiple of 64 bits long. > > change to: > > An implementation SHOULD NOT implement DSA keys of size less than > 1024 bits. DSA keys MUST be an even multiple of 64 bits long. > The Digital Signature Standard (DSS) specifies that DSA be used > in one of the following ways: > > * 1024-bit key, 160-bit q, SHA-1 hash > * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384 or SHA-512 hash > * 2048-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash > * 3072-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash > > Other key size and hash combinations are usable in OpenPGP, but > would not be compliant to DSS. > > Note that earlier versions of this standard only supported a > 160-bit q, so earlier implementations may not be able to > handle a signature with a different q size. > > DSA keys are a multiple of 64 bits. Are there similar requirements > with regards to the size of q that are worth mentioning here? I don't > mean the NIST DSS requirements, but rather inherent requirements of > the algorithm. That's a good question. I am uncomfortable permitting larger DSA keys of sizes different than the DSS ones. The balancing of the q and p sizes is something of an art and people tend to disagree somewhat. What size should q be for a 1568 bit modulus? Or a 1024+64=1090 bit one? It's very questionable. I would feel more comfortable restricting to the DSS key sizes even for OpenPGP keys. Is there really much benefit to intermediate sizes? The size of the signature is dependent only on the size of q, and I don't know how we could legitimately scale up from 160 to 224 or 256 as we increase p from 1024 to 2048 bits. Yes, we could come up with some formula, but there would not be much consensus. The FIPS guys undoubtedly faced the same problem and decided to finalize on just these two new sizes, and I am inclined to do the same. > ================================== > > Section 13. (Security Considerations) says: > > * The DSA algorithm will work with any 160-bit hash, but it is > sensitive to the quality of the hash algorithm, if the hash > algorithm is broken, it can leak the secret key. The Digital > Signature Standard (DSS) specifies that DSA be used with SHA-1. > RIPEMD-160 is considered by many cryptographers to be as strong. > An implementation should take care which hash algorithms are > used with DSA, as a weak hash can not only allow a signature to > be forged, but could leak the secret key. > > change to: > > * The DSA algorithm will work with any hash, but it is > sensitive to the quality of the hash algorithm. An > implementation should take care which hash algorithms are > used with DSA, as a weak hash can not only allow a signature to > be forged, but could leak the secret key. > > Hal has expressed concern with the "weak hash can leak the secret key" > warning in the past, so perhaps he'll comment here. Right, I don't believe it is true that a weak hash can leak the secret key. Rather, a weak random choice of the "k" value in the signature can leak the secret key, but that is a completely different issue. As far as this wording, it is OK but it needs to be emphasized for the verifier as much as or more than for the signer. One problem with the new DSS is that it does not specify a unique hash algorithm, hence if any of them break then an attacker could take an existing signature, modify the hash algorithm ID, and perhaps create a fake message that works with that signature and the broken hash. There is nothing the signer can do to prevent this. Even if he uses a strong hash, if there is a broken hash around someone can change the signature to use that hash. So the point is that the verifier more than the signer must make sure that a DSA signature is signed by an acceptably strong hash. If SHA-256 breaks but SHA-512 is still OK it needs to warn on signatures using SHA-256. So I would suggest something like this: * The DSA algorithm will work with any hash, but it is sensitive to the quality of the hash algorithm. An implementation should take care which hash algorithms are used with DSA. Verifiers should be aware that even if the signer used a strong hash, an attacker could have modified a signature to use a weak one. Only signatures issued using acceptably strong hash algorithms should be accepted as valid. Hal Finney Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LNjop3095916; Tue, 21 Mar 2006 16:45:50 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2LNjoeS095915; Tue, 21 Mar 2006 16:45:50 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LNjnAp095908 for ; Tue, 21 Mar 2006 16:45:50 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2LNjdk14930 for ; Tue, 21 Mar 2006 18:45:44 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id k2LNje6c013530 for ; Tue, 21 Mar 2006 18:45:40 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2LNjXAH015637 for ; Tue, 21 Mar 2006 18:45:33 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2LNjWti015636 for ietf-openpgp@imc.org; Tue, 21 Mar 2006 18:45:32 -0500 Date: Tue, 21 Mar 2006 18:45:32 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Suggested changes for DSA2 Message-ID: <20060321234532.GA15554@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here are some suggested changes for DSA2. I'm sure this will prompt other suggestions - think of this as a starting point. ================================== Section 5.2.2 (Version 3 Signature Packet Format) says: DSA signatures MUST use hashes with a size of 160 bits, to match q, the size of the group generated by the DSA key's generator value. The hash function result is treated as a 160 bit number and used directly in the DSA signature algorithm. change to: DSA signatures MUST use hashes that are equal to or larger than the size of q, the group generated by the DSA key's generator value. If the chosen hash is larger than the size of q, the hash result is truncated to fit by taking the appropriate number of leftmost bits. This (possibly truncated) hash function result is treated as a number and used directly in the DSA signature algorithm. ================================== Section 12.5. (DSA) says: An implementation SHOULD NOT implement DSA keys of size less than 1024 bits. Note that present DSA is limited to a maximum of 1024 bit keys, which are recommended for long-term use. Also, DSA keys MUST be an even multiple of 64 bits long. change to: An implementation SHOULD NOT implement DSA keys of size less than 1024 bits. DSA keys MUST be an even multiple of 64 bits long. The Digital Signature Standard (DSS) specifies that DSA be used in one of the following ways: * 1024-bit key, 160-bit q, SHA-1 hash * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384 or SHA-512 hash * 2048-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash * 3072-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash Other key size and hash combinations are usable in OpenPGP, but would not be compliant to DSS. Note that earlier versions of this standard only supported a 160-bit q, so earlier implementations may not be able to handle a signature with a different q size. DSA keys are a multiple of 64 bits. Are there similar requirements with regards to the size of q that are worth mentioning here? I don't mean the NIST DSS requirements, but rather inherent requirements of the algorithm. ================================== Section 13. (Security Considerations) says: * The DSA algorithm will work with any 160-bit hash, but it is sensitive to the quality of the hash algorithm, if the hash algorithm is broken, it can leak the secret key. The Digital Signature Standard (DSS) specifies that DSA be used with SHA-1. RIPEMD-160 is considered by many cryptographers to be as strong. An implementation should take care which hash algorithms are used with DSA, as a weak hash can not only allow a signature to be forged, but could leak the secret key. change to: * The DSA algorithm will work with any hash, but it is sensitive to the quality of the hash algorithm. An implementation should take care which hash algorithms are used with DSA, as a weak hash can not only allow a signature to be forged, but could leak the secret key. Hal has expressed concern with the "weak hash can leak the secret key" warning in the past, so perhaps he'll comment here. ================================== David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LNbkrb095326; Tue, 21 Mar 2006 16:37:46 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2LNbkKV095325; Tue, 21 Mar 2006 16:37:46 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2LNbjS8095318 for ; Tue, 21 Mar 2006 16:37:45 -0700 (MST) (envelope-from vedaal@hush.com) Received: from smtp3.hushmail.com (localhost.hushmail.com [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id B96B7A32BF for ; Tue, 21 Mar 2006 15:37:44 -0800 (PST) Received: from mailserver2.hushmail.com (mailserver2.hushmail.com [65.39.178.21]) by smtp3.hushmail.com (Postfix) with ESMTP for ; Tue, 21 Mar 2006 15:37:44 -0800 (PST) Received: from mailserver2.hushmail.com (localhost.hushmail.com [127.0.0.1]) by mailserver2.hushmail.com (8.12.6/8.12.3) with ESMTP id k2LNbiZ3015585 for ; Tue, 21 Mar 2006 15:37:44 -0800 (PST) (envelope-from vedaal@hush.com) Received: (from nobody@localhost) by mailserver2.hushmail.com (8.12.6/8.12.3/Submit) id k2LNbhfv015584 for ; Tue, 21 Mar 2006 18:37:43 -0500 (GMT) Message-Id: <200603212337.k2LNbhfv015584@mailserver2.hushmail.com> Date: Tue, 21 Mar 2006 18:37:43 -0500 To: Cc: Subject: Re: NIST publishes new DSA draft // larger DSA signing keys ? From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: until now the discussion has centered on the larger SHA hash sizes in section 4.2 of the NIST draft, the following recommendation about key sizes is listed, and seems to imply that DSA signing key sizes should be the same as DH encryption key sizes: =====[ begin quote ]===== It is recommended that the security strength of the (L, N) pair and the hash function be the same unless an agreement has been made between participating entities to use a stronger hash function; a hash function that provides a lower security strength than the (L,N) pair shall not be used. If the output of the hash function is greater than N (i.e., the bit length of q), then the leftmost N bits of the hash function output block shall be used in any calculation using the hash function output during the generation or verification of a digital signature. Special Publication (SP) 800-57 provides information about the selection of the appropriate (L,N) pair in accordance with a desired security strength for a given time period. An (L, N) pair shall be chosen that protects the signed information during the entire expected lifetime of that information. For example, if a digital signature is generated in 2008 for information that needs to be protected for five years, and a particular (L, N) pair is invalid after 2010, then a larger (L, N)pair shall be used that remains valid for the entire period of time that the information needs to be protected. A Federal Government entity other than a Certification Authority (CA) should use only the first three (L, N) pairs (i.e., the (1024, 160), (2048, 224) and (2048, 256) pairs). A CA shall use an (L,N) pair that is equal to or greater than the (L, N) pairs used by its subscribers. For example, if subscribers are using the (2048, 224) pair, then the CA shall use either the (2048, 224), (2048,256) or (3072, 256) pair. Possible exceptions to this rule include cross certification between CAs, certifying keys for purposes other than digital signatures and transitioning from one key size or algorithm to another. See SP 800- 57 for further guidance. =====[ end quote ]===== can increasing the size of a DSA signing key to equal a the size of a DH encryption key be done, and still be a valid V4 key, with larger SHA signatures verifiable by existing open-pgp implementations, or does it need a new key type before it can be done? vedaal Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KLZWlV030022; Mon, 20 Mar 2006 14:35:32 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2KLZWvK030021; Mon, 20 Mar 2006 14:35:32 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KLZVwU030014 for ; Mon, 20 Mar 2006 14:35:32 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2KLZUk08791; Mon, 20 Mar 2006 16:35:30 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id k2KLZS6c007309; Mon, 20 Mar 2006 16:35:28 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2KLZOis004182; Mon, 20 Mar 2006 16:35:24 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2KLZNtX004181; Mon, 20 Mar 2006 16:35:23 -0500 Date: Mon, 20 Mar 2006 16:35:23 -0500 From: David Shaw To: Tony Hansen Cc: OpenPGP Subject: Re: NIST publishes new DSA draft Message-ID: <20060320213523.GB3994@jabberwocky.com> Mail-Followup-To: Tony Hansen , OpenPGP References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> <441ACF45.704@systemics.com> <87fylhdq36.fsf@wheatstone.g10code.de> <20060317174937.GC13241@jabberwocky.com> <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> <20060320202841.GA3994@jabberwocky.com> <441F19CC.9080004@att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <441F19CC.9080004@att.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: No, it is not the same output, but it is the same amount of security. Which hash and which IV doesn't matter here - just that the end result is 224 bits long. David On Mon, Mar 20, 2006 at 04:08:28PM -0500, Tony Hansen wrote: > > Just a quibble. Truncating sha-256 down to 224 bits does not give the > same output as sha-224, as sha-256 and sha-224 use different > initialization vectors. So "truncated sha-256" and "sha-224" really > would be totally different hash values. > > No comment on the rest of what you say. > > Tony Hansen > tony@att.com > > David Shaw wrote: > > I understand the argument about wanting 128 bits of security, but > > since the new DSA allows a 224 bit q, there just isn't room for 128 > > bits of security. Whether we truncate SHA-256 and call it "truncated > > SHA-256" or truncate SHA-256 and call it "SHA-224", we have to > > truncate. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KL8feR028977; Mon, 20 Mar 2006 14:08:41 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2KL8f4T028975; Mon, 20 Mar 2006 14:08:41 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k2KL8eYI028933 for ; Mon, 20 Mar 2006 14:08:40 -0700 (MST) (envelope-from tony@att.com) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-7.tower-120.messagelabs.com!1142888912!10043411!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 24426 invoked from network); 20 Mar 2006 21:08:32 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-7.tower-120.messagelabs.com with SMTP; 20 Mar 2006 21:08:32 -0000 Received: from [135.70.80.181] (unknown[135.70.80.181](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060320210832gw100100dee> (Authid: tony); Mon, 20 Mar 2006 21:08:32 +0000 Message-ID: <441F19CC.9080004@att.com> Date: Mon, 20 Mar 2006 16:08:28 -0500 From: Tony Hansen User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: OpenPGP Subject: Re: NIST publishes new DSA draft References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> <441ACF45.704@systemics.com> <87fylhdq36.fsf@wheatstone.g10code.de> <20060317174937.GC13241@jabberwocky.com> <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> <20060320202841.GA3994@jabberwocky.com> In-Reply-To: <20060320202841.GA3994@jabberwocky.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Just a quibble. Truncating sha-256 down to 224 bits does not give the same output as sha-224, as sha-256 and sha-224 use different initialization vectors. So "truncated sha-256" and "sha-224" really would be totally different hash values. No comment on the rest of what you say. Tony Hansen tony@att.com David Shaw wrote: > I understand the argument about wanting 128 bits of security, but > since the new DSA allows a 224 bit q, there just isn't room for 128 > bits of security. Whether we truncate SHA-256 and call it "truncated > SHA-256" or truncate SHA-256 and call it "SHA-224", we have to > truncate. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KKSovJ027375; Mon, 20 Mar 2006 13:28:50 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2KKSoDX027374; Mon, 20 Mar 2006 13:28:50 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KKSndh027368 for ; Mon, 20 Mar 2006 13:28:49 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2KKSlk08116 for ; Mon, 20 Mar 2006 15:28:47 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id k2KKSk6c006824 for ; Mon, 20 Mar 2006 15:28:46 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2KKSfCT004087 for ; Mon, 20 Mar 2006 15:28:41 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2KKSfWg004086 for ietf-openpgp@imc.org; Mon, 20 Mar 2006 15:28:41 -0500 Date: Mon, 20 Mar 2006 15:28:41 -0500 From: David Shaw To: OpenPGP Subject: Re: NIST publishes new DSA draft Message-ID: <20060320202841.GA3994@jabberwocky.com> Mail-Followup-To: OpenPGP References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> <441ACF45.704@systemics.com> <87fylhdq36.fsf@wheatstone.g10code.de> <20060317174937.GC13241@jabberwocky.com> <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Mar 19, 2006 at 11:51:17AM -0800, Jon Callas wrote: > I'm happy to put in SHA-224 (meaning it's trivial work), but I don't > like it, myself. The reason is that SHA-224 is really a truncated > SHA-256. Thus, it has no advantages over SHA-256 except being smaller > by 32-bits with 112 bits of security. The reason it exists at all is > for crypto-balance with 2-key 3DES (which is not TDEA), which we > don't allow at all. I don't think we should have it as it goes > against our principles of wanting a minimum of 128-bits of security > in OpenPGP. (Yes, yes, I know that SHA-1 doesn't meet this either, > but until SHA-256, we didn't have many options. That doesn't mean the > principle is wrong; we *have* options.) I understand the argument about wanting 128 bits of security, but since the new DSA allows a 224 bit q, there just isn't room for 128 bits of security. Whether we truncate SHA-256 and call it "truncated SHA-256" or truncate SHA-256 and call it "SHA-224", we have to truncate. We support DSA now, with a note saying that if someone wants DSS, they need to use SHA-1. I suspect we'll end up in a similar place with DSA2 allowing whatever key size and q size that people want to use and a note that if they want DSS they need to use one of the four NIST-blessed key size / q size pairs. I lean towards adding SHA-224 as one of those four pairs has a 224-bit q, and NIST suggests SHA-224 for this size. It's only a lean towards adding it as NIST also suggests truncated 256, 384, or 512 as valid options, so 224 is not the only game in town. (384 seems a little silly as it would be a truncation of a truncation, but it's an option.) It's really a feeling that we currently support 4 out of the 5 FIPS-approved hash functions (SHA-1, 256, 384, 512), and since supporting the 5th (224) is so trivial, we may as well be complete. I'll defer to someone who feels more strongly about this than I do. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KJejPt025405; Mon, 20 Mar 2006 12:40:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2KJejo6025404; Mon, 20 Mar 2006 12:40:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2KJeibK025398 for ; Mon, 20 Mar 2006 12:40:45 -0700 (MST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 2384451D85; Mon, 20 Mar 2006 19:40:41 +0000 (GMT) Message-ID: <441F04C7.1060909@systemics.com> Date: Mon, 20 Mar 2006 20:38:47 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Callas Cc: OpenPGP Subject: Re: NIST publishes new DSA draft References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> <441ACF45.704@systemics.com> <87fylhdq36.fsf@wheatstone.g10code.de> <20060317174937.GC13241@jabberwocky.com> <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> In-Reply-To: <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas wrote: > > I think we ought to keep it with the same algorithm number. > > I'm happy to put in SHA-224 (meaning it's trivial work), but I don't > like it, myself. The reason is that SHA-224 is really a truncated > SHA-256. Thus, it has no advantages over SHA-256 except being smaller > by 32-bits with 112 bits of security. The reason it exists at all is > for crypto-balance with 2-key 3DES (which is not TDEA), which we don't > allow at all. I don't think we should have it as it goes against our > principles of wanting a minimum of 128-bits of security in OpenPGP. > (Yes, yes, I know that SHA-1 doesn't meet this either, but until > SHA-256, we didn't have many options. That doesn't mean the principle > is wrong; we *have* options.) In general I'd agree that the less algorithms/lengths the better. I'd certainly be keen to drop SHA-224 if there is no good reason for it. iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2JK2HP5073179; Sun, 19 Mar 2006 13:02:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2JK2HIC073178; Sun, 19 Mar 2006 13:02:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2JK2GMt073171 for ; Sun, 19 Mar 2006 13:02:16 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7) for ; Sun, 19 Mar 2006 12:02:13 -0800 Received: from [130.129.130.213] ([130.129.130.213]) by keys.merrymeet.com (PGP Universal service); Sun, 19 Mar 2006 12:02:13 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Sun, 19 Mar 2006 12:02:13 -0800 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <200603151914.k2FJE45H081897@mailserver2.hushmail.com> References: <200603151914.k2FJE45H081897@mailserver2.hushmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5BA6C174-0734-48CA-8D66-325081E5AEFF@callas.org> Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: NIST publishes new DSA draft Date: Sun, 19 Mar 2006 12:02:11 -0800 To: OpenPGP X-Mailer: Apple Mail (2.746.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > note that 3-DES is now referred to as TDEA > should this perhaps be included in rfc 2440 when 3-DES is > mentioned? > i.e. > when 3-DES is first mentioned, > it should be referred to as 3-DES(also known as TDEA) They're not the same. There is DES and DEA, just as there is DSA and DSS. In each pair, there is an Algorithm and a Standard. The standard is the algorithm plus other stuff. In the case of DES, it specifies that the low bit of each byte (excuse me, octet) of the key is a parity bit (and possibly other stuff I don't remember). Everyone uses DES, not DEA. What we use is 3DES, not TDEA. In the case of DSS, we *do* mean DSA because there were people who wanted (for example) to use RIPE-MD/160 with DSA, not SHA-1, as DSS. I suppose we could call it "TDES," but it's been called "3DES" or "Triple-DES" for ages. If all of a sudden we start calling it TDES, there will be many people who will rightly mutter, "TDES? What the % $@! is TDES? Oh, *3DES*, why didn't you say so?" Jon Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2JJpLVZ072894; Sun, 19 Mar 2006 12:51:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2JJpL8l072893; Sun, 19 Mar 2006 12:51:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2JJpKrI072886 for ; Sun, 19 Mar 2006 12:51:21 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7) for ; Sun, 19 Mar 2006 11:51:18 -0800 Received: from [130.129.130.213] ([130.129.130.213]) by keys.merrymeet.com (PGP Universal service); Sun, 19 Mar 2006 11:51:18 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Sun, 19 Mar 2006 11:51:18 -0800 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <20060317174937.GC13241@jabberwocky.com> References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> <441ACF45.704@systemics.com> <87fylhdq36.fsf@wheatstone.g10code.de> <20060317174937.GC13241@jabberwocky.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: NIST publishes new DSA draft Date: Sun, 19 Mar 2006 11:51:17 -0800 To: OpenPGP X-Mailer: Apple Mail (2.746.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think we ought to keep it with the same algorithm number. I'm happy to put in SHA-224 (meaning it's trivial work), but I don't like it, myself. The reason is that SHA-224 is really a truncated SHA-256. Thus, it has no advantages over SHA-256 except being smaller by 32-bits with 112 bits of security. The reason it exists at all is for crypto-balance with 2-key 3DES (which is not TDEA), which we don't allow at all. I don't think we should have it as it goes against our principles of wanting a minimum of 128-bits of security in OpenPGP. (Yes, yes, I know that SHA-1 doesn't meet this either, but until SHA-256, we didn't have many options. That doesn't mean the principle is wrong; we *have* options.) Jon Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2HHnoLi070981; Fri, 17 Mar 2006 10:49:50 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2HHno5H070980; Fri, 17 Mar 2006 10:49:50 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2HHnnI5070972 for ; Fri, 17 Mar 2006 10:49:49 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2HHnhk23159; Fri, 17 Mar 2006 12:49:43 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id k2HHni6c014653; Fri, 17 Mar 2006 12:49:44 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2HHnbwh013529; Fri, 17 Mar 2006 12:49:37 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2HHnbAn013528; Fri, 17 Mar 2006 12:49:37 -0500 Date: Fri, 17 Mar 2006 12:49:37 -0500 From: David Shaw To: Werner Koch Cc: Ian G , Hal Finney , ietf-openpgp@imc.org Subject: Re: NIST publishes new DSA draft Message-ID: <20060317174937.GC13241@jabberwocky.com> Mail-Followup-To: Werner Koch , Ian G , Hal Finney , ietf-openpgp@imc.org References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> <441ACF45.704@systemics.com> <87fylhdq36.fsf@wheatstone.g10code.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87fylhdq36.fsf@wheatstone.g10code.de> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Mar 17, 2006 at 04:54:21PM +0100, Werner Koch wrote: > > On Fri, 17 Mar 2006 16:01:25 +0100, Ian G said: > > >> right answer. Now that we have actual information about DSA2, perhaps > >> it would be worth revisiting that question. A new algorithm ID for > >> DSA2 resolves a number of problems in one fell swoop as there is no > >> expectation of interoperability. SHA-256 is always usable > >> (effectively the default) for DSA2, and there is no problem with > >> knowing when it is possible to use truncation (always). > > > Sounds good to me. > > I support this too. The majority of keys are DSA keys q=160 bit. > Having a new algorithm indentifier will help more than harm. Even though I originally brought it up, I've given this a good bit of additional thought while mailing with Hal on the list yesterday, and I think it really does come down to something as simple as a question of error messages. I'm not for a new algorithm ID. It breaks down like this: 1) a q==160 signature without truncation (hash size matches q exactly) 2) a q==160 signature with truncation (hash left-truncated to match q) 3) a q!=160 signature without truncation (hash size matches q exactly) 4) a q!=160 signature with truncation (hash left-truncated to match q) I'm not mentioning the larger key size in DSA2 as I believe that deployed code will handle larger DSA key sizes correctly. Obviously #1 isn't a problem, as it is what DSA is today. I think PGP can actually do #2, but for the sake of argument, let's say that nobody can do #2, #3, or #4 on current code. If we don't assign a new algo ID for DSA2, #3 and #4 will fail because of the wrong q size, and #2 will fail because of the truncation. If we do assign the new ID, as before #2, #3, and #4 will fail - but so will #1! Even though the signatures are compatible, the new algo ID will cause the signature to fail on the older implementation. This argues against a new algo ID. Even if we don't create DSA2 q=160 keys (internally changing them to DSA1 keys), this just returns the question to neutral, and the extra code complexity and questions (will it break any keyservers? It will certainly break pksd) of assigning the new algo ID argue against it. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2HFvl4v066691; Fri, 17 Mar 2006 08:57:47 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2HFvlYX066690; Fri, 17 Mar 2006 08:57:47 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2HFvkgc066684 for ; Fri, 17 Mar 2006 08:57:47 -0700 (MST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1FKHSq-0000Zu-27 for ; Fri, 17 Mar 2006 17:06:08 +0100 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1FKHHR-0007Ws-58; Fri, 17 Mar 2006 16:54:21 +0100 From: Werner Koch To: Ian G Cc: David Shaw , Hal Finney , ietf-openpgp@imc.org Subject: Re: NIST publishes new DSA draft References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> <441ACF45.704@systemics.com> Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Fri, 17 Mar 2006 16:54:21 +0100 In-Reply-To: <441ACF45.704@systemics.com> (Ian G.'s message of "Fri, 17 Mar 2006 16:01:25 +0100") Message-ID: <87fylhdq36.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 17 Mar 2006 16:01:25 +0100, Ian G said: >> right answer. Now that we have actual information about DSA2, perhaps >> it would be worth revisiting that question. A new algorithm ID for >> DSA2 resolves a number of problems in one fell swoop as there is no >> expectation of interoperability. SHA-256 is always usable >> (effectively the default) for DSA2, and there is no problem with >> knowing when it is possible to use truncation (always). > Sounds good to me. I support this too. The majority of keys are DSA keys q=160 bit. Having a new algorithm indentifier will help more than harm. Salam-Shalom, Werner Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2HF3U8b063928; Fri, 17 Mar 2006 08:03:30 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2HF3US0063927; Fri, 17 Mar 2006 08:03:30 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2HF3SXZ063920 for ; Fri, 17 Mar 2006 08:03:29 -0700 (MST) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 361EE4137A; Fri, 17 Mar 2006 15:03:23 +0000 (GMT) Message-ID: <441ACF45.704@systemics.com> Date: Fri, 17 Mar 2006 16:01:25 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Shaw Cc: Hal Finney , ietf-openpgp@imc.org Subject: Re: NIST publishes new DSA draft References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> In-Reply-To: <20060316192823.GA9945@jabberwocky.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw wrote: >>We might want to think about making SHA-256 be another MUST algorithm. >>The only MUST hash now is SHA-1. Making SHA-256 be a MUST would make >>these new key sizes be more useful, and also give us an easier fallback >>if SHA-1 should be broken. > > > Unless DSA2 is also a MUST, I wonder what the practical advantage to > that would be (beyond making the social point that we really, really > want people to move away from SHA-1). I think this is pretty much all of the point. Any new DSA signing method or other usage will likely be non-obligatory, but pushing the implementations into that direction seems useful. > right answer. Now that we have actual information about DSA2, perhaps > it would be worth revisiting that question. A new algorithm ID for > DSA2 resolves a number of problems in one fell swoop as there is no > expectation of interoperability. SHA-256 is always usable > (effectively the default) for DSA2, and there is no problem with > knowing when it is possible to use truncation (always). Sounds good to me. iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2GKpArU018960; Thu, 16 Mar 2006 13:51:10 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2GKpA9p018959; Thu, 16 Mar 2006 13:51:10 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2GKp9vN018953 for ; Thu, 16 Mar 2006 13:51:10 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2GKp8k17729; Thu, 16 Mar 2006 15:51:08 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id k2GKp76c009560; Thu, 16 Mar 2006 15:51:07 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2GKp2tb010073; Thu, 16 Mar 2006 15:51:02 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2GKp2Px010072; Thu, 16 Mar 2006 15:51:02 -0500 Date: Thu, 16 Mar 2006 15:51:02 -0500 From: David Shaw To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: NIST publishes new DSA draft Message-ID: <20060316205102.GB9834@jabberwocky.com> Mail-Followup-To: Hal Finney , ietf-openpgp@imc.org References: <20060316201951.3A87557FB0@finney.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060316201951.3A87557FB0@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 16, 2006 at 12:19:51PM -0800, "Hal Finney" wrote: > David Shaw writes: > > Unless DSA2 is also a MUST, I wonder what the practical advantage to > > that would be (beyond making the social point that we really, really > > want people to move away from SHA-1). Since an OpenPGP program would > > not necessarily know whether the recipient could handle SHA-256 > > (SHA-256 dates from around 2004, implementation-wise), it would have > > to use SHA-1 in many or most cases anyway. Obviously a DSA2 signature > > wouldn't be expected to work, but an RSA signature would have this > > problem, and DSA1 (using a truncated SHA-256) would have the problem > > as well for both truncation and SHA-256 reasons. > > OK, but maybe a "SHOULD" like Werner suggested, then? Absolutely. I'm in favor of SHOULD. This implies that DSA with 160-bit q is a MUST (as it is now), and DSA with >160-bit q is not a MUST (though an implementation must at least know that DSA might have a larger q and not blow up). > At this point I like the idea of keeping the same algorithm ID. All the > code and algorithms are the same, so using a different alg ID just > for different key sizes doesn't really make sense. Using a different > algorithm ID will be, from the future perspective, a historical artifact. > And I don't see that it really helps interoperability to use a new ID. > Either way, the bottom line is that old code won't work with the new > keys and new code will. Plus it makes implementation of the change a > lot easier - granted, a minor point, but on top of everything else I > see this as the preferable strategy. While I agree that the bottom line is that the old code won't work and the new code will, using a different algorithm ID potentially gives a better (and more user-comprehensible) error than using the same algorithm ID does when the old code doesn't work. That is to say, it may fail "prettier" (it does in the GPG case). I don't think it's that big of a deal, and I'm not arguing for it. On a related issue, do you think a feature flag to indicate the ability to handle a truncated hash would be a good idea? I'm leaning towards no, as it would only be really useful in the sign+encrypt case (where the implementation knows who the recipient(s) are and can thus consult feature flags), but perhaps that's enough to justify it. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2GKDkvg017500; Thu, 16 Mar 2006 13:13:46 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2GKDkek017499; Thu, 16 Mar 2006 13:13:46 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2GKDjiv017493 for ; Thu, 16 Mar 2006 13:13:45 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 3A87557FB0; Thu, 16 Mar 2006 12:19:51 -0800 (PST) To: dshaw@jabberwocky.com, hal@finney.org Subject: Re: NIST publishes new DSA draft Cc: ietf-openpgp@imc.org Message-Id: <20060316201951.3A87557FB0@finney.org> Date: Thu, 16 Mar 2006 12:19:51 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw writes: > On Tue, Mar 14, 2006 at 11:44:47AM -0800, "Hal Finney" wrote: > > We might want to think about making SHA-256 be another MUST algorithm. > > The only MUST hash now is SHA-1. Making SHA-256 be a MUST would make > > these new key sizes be more useful, and also give us an easier fallback > > if SHA-1 should be broken. > > Unless DSA2 is also a MUST, I wonder what the practical advantage to > that would be (beyond making the social point that we really, really > want people to move away from SHA-1). Since an OpenPGP program would > not necessarily know whether the recipient could handle SHA-256 > (SHA-256 dates from around 2004, implementation-wise), it would have > to use SHA-1 in many or most cases anyway. Obviously a DSA2 signature > wouldn't be expected to work, but an RSA signature would have this > problem, and DSA1 (using a truncated SHA-256) would have the problem > as well for both truncation and SHA-256 reasons. OK, but maybe a "SHOULD" like Werner suggested, then? > A few months back you asked the question whether new DSAs would best > be supported by extending the definition of the current DSA, or by > assigning a new algorithm ID for DSA2. At the time, most people > (myself included) felt that extending the current DSA would be the > right answer. Now that we have actual information about DSA2, perhaps > it would be worth revisiting that question. A new algorithm ID for > DSA2 resolves a number of problems in one fell swoop as there is no > expectation of interoperability. SHA-256 is always usable > (effectively the default) for DSA2, and there is no problem with > knowing when it is possible to use truncation (always). At this point I like the idea of keeping the same algorithm ID. All the code and algorithms are the same, so using a different alg ID just for different key sizes doesn't really make sense. Using a different algorithm ID will be, from the future perspective, a historical artifact. And I don't see that it really helps interoperability to use a new ID. Either way, the bottom line is that old code won't work with the new keys and new code will. Plus it makes implementation of the change a lot easier - granted, a minor point, but on top of everything else I see this as the preferable strategy. > > I also think we should change the names of SHA256 etc to use dashes > > as in SHA-256; those are the official names. > > To be clear here: are you referring to changing the descriptive text > in the draft or changing the hash name strings as used in clearsigned > message "Hash:" headers? The first is easy and I agree should be > done, the second has compatibility implications. Just in the draft, then. I guess we're stuck with the name strings. It's not a big deal either way. Hal Finney Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2GJSXNZ015826; Thu, 16 Mar 2006 12:28:33 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2GJSX5D015825; Thu, 16 Mar 2006 12:28:33 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2GJSWPM015813 for ; Thu, 16 Mar 2006 12:28:33 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2GJSTk17364; Thu, 16 Mar 2006 14:28:29 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id k2GJSR6c009284; Thu, 16 Mar 2006 14:28:27 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2GJSNP1009978; Thu, 16 Mar 2006 14:28:23 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2GJSNRi009977; Thu, 16 Mar 2006 14:28:23 -0500 Date: Thu, 16 Mar 2006 14:28:23 -0500 From: David Shaw To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: NIST publishes new DSA draft Message-ID: <20060316192823.GA9945@jabberwocky.com> Mail-Followup-To: Hal Finney , ietf-openpgp@imc.org References: <20060314194447.4D59A57FB0@finney.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060314194447.4D59A57FB0@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Mar 14, 2006 at 11:44:47AM -0800, "Hal Finney" wrote: > The main question is whether we want to change the current draft to make > these changes. That would probably require backing it out of "last > call" status. Personally I think this makes sense. There is no one > waiting urgently for this draft to be finalized AFAIK. The alternative > will be to immediately amend the RFC with another RFC. But for the sake > of future implementors I think it would be better to wait a few months > more and put it all into one draft. I agree with this. It is unfortunate, but will ultimately result in a better RFC. > We do not have an algorithm ID for SHA-224. SHA-224 is the same > algorithm as SHA-256 but uses different initial values internally, > and then truncates the result to 224 bits. I don't see any advantage > in this case to using SHA-224 over using SHA-256 truncated to 224 bits. > However we might want to add an ID for it in case an implementor wanted > to follow the new DSS spec very closely. Given that the main alternative is truncated SHA-256, which implies SHA-256 support in the first place, and the code difference between SHA-256 and 224 is simple to say the least (as you say, same algorithm), I think we should add the ID (#7 ?) for SHA-224. It's a checkbox item that we can trivially support. > The simplest change we could make would be to allow that DSA keys can > use modulus "p" and subgroup "q" values of the specified sizes, based > on the table above. Hashes should be equal in size or larger than the > "q" size. Hashes larger than the "q" size should be left-truncated. > Then we could note that for DSS compliance the hashes must be taken from > the SHA family, either SHA-1 or one of the larger SHA's. > > We might want to think about making SHA-256 be another MUST algorithm. > The only MUST hash now is SHA-1. Making SHA-256 be a MUST would make > these new key sizes be more useful, and also give us an easier fallback > if SHA-1 should be broken. Unless DSA2 is also a MUST, I wonder what the practical advantage to that would be (beyond making the social point that we really, really want people to move away from SHA-1). Since an OpenPGP program would not necessarily know whether the recipient could handle SHA-256 (SHA-256 dates from around 2004, implementation-wise), it would have to use SHA-1 in many or most cases anyway. Obviously a DSA2 signature wouldn't be expected to work, but an RSA signature would have this problem, and DSA1 (using a truncated SHA-256) would have the problem as well for both truncation and SHA-256 reasons. A few months back you asked the question whether new DSAs would best be supported by extending the definition of the current DSA, or by assigning a new algorithm ID for DSA2. At the time, most people (myself included) felt that extending the current DSA would be the right answer. Now that we have actual information about DSA2, perhaps it would be worth revisiting that question. A new algorithm ID for DSA2 resolves a number of problems in one fell swoop as there is no expectation of interoperability. SHA-256 is always usable (effectively the default) for DSA2, and there is no problem with knowing when it is possible to use truncation (always). > I also think we should change the names of SHA256 etc to use dashes > as in SHA-256; those are the official names. To be clear here: are you referring to changing the descriptive text in the draft or changing the hash name strings as used in clearsigned message "Hash:" headers? The first is easy and I agree should be done, the second has compatibility implications. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2GEcxtH001749; Thu, 16 Mar 2006 07:38:59 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2GEcxOo001748; Thu, 16 Mar 2006 07:38:59 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.okiok.com (host70.okiok.com [207.61.238.70] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2GEcwW8001741 for ; Thu, 16 Mar 2006 07:38:59 -0700 (MST) (envelope-from astiglic@okiok.com) Received: from P1038Mobile (unknown [70.82.189.188]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.okiok.com (Postfix) with ESMTP id 7E6961683D3 for ; Wed, 15 Mar 2006 21:46:48 -0500 (EST) From: "Anton Stiglic" To: Subject: RE: NIST publishes new DSA draft Date: Wed, 15 Mar 2006 21:40:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <44182299.2010507@algroup.co.uk> Thread-Index: AcZIQD3ijlagomLPTr6kHg5G5VtN5AAYJAlg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20060316024648.7E6961683D3@mail.okiok.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I haven't participated in this list so far but I have been lurking here for some time. I agree with the phasing out of SHA1, as soon as possible! Indeed there have been some vulnerabilities demonstrated, collisions on arbitrary inputs (as this has already been discussed before, this is not as strong attack as 2nd pre-image attack which would directly affect digital signatures based on SHA1 for example, but still an indication of weakness in the hash algorithm). Also governments have plans of phasing SHA1 out soon. CSE in Canada plans to take it out of commission by 2008 for the protection of certain types of information, see for example http://www.cse-cst.gc.ca/services/crypto-services/crypto-algorithms-e.html --Anton -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 268.1.2/274 - Release Date: 03/03/2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FJE705061951; Wed, 15 Mar 2006 12:14:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2FJE7KU061950; Wed, 15 Mar 2006 12:14:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FJE6RC061943 for ; Wed, 15 Mar 2006 12:14:06 -0700 (MST) (envelope-from vedaal@hush.com) Received: from smtp3.hushmail.com (localhost.hushmail.com [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 9B0B1A3305 for ; Wed, 15 Mar 2006 11:14:05 -0800 (PST) Received: from mailserver2.hushmail.com (mailserver2.hushmail.com [65.39.178.21]) by smtp3.hushmail.com (Postfix) with ESMTP for ; Wed, 15 Mar 2006 11:14:05 -0800 (PST) Received: from mailserver2.hushmail.com (localhost.hushmail.com [127.0.0.1]) by mailserver2.hushmail.com (8.12.6/8.12.3) with ESMTP id k2FJE5Z3081898 for ; Wed, 15 Mar 2006 11:14:05 -0800 (PST) (envelope-from vedaal@hush.com) Received: (from nobody@localhost) by mailserver2.hushmail.com (8.12.6/8.12.3/Submit) id k2FJE45H081897 for ; Wed, 15 Mar 2006 14:14:04 -0500 (GMT) Message-Id: <200603151914.k2FJE45H081897@mailserver2.hushmail.com> Date: Wed, 15 Mar 2006 14:14:02 -0500 To: Cc: Subject: Re: NIST publishes new DSA draft From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 14 Mar 2006 10:58:39 -0500 David Shaw wrote: >In the OpenPGP context, probably the most interesting bit is that >the >160-bit hash limit has been removed. The sizes supported are: > >* 1024-bit key, 160-bit hash (the current DSA) >* 2048-bit key, 224-bit hash (presumably aimed at SHA-224) >* 2048-bit key, 256-bit hash (presumably aimed at SHA-256) >* 3072-bit key, 256-bit hash (presumably aimed at SHA-256) > >It also adds the concept of using a larger hash than will fit by >taking the leftmost bits. > >http://csrc.nist.gov/publications/drafts.html the draft also refers to a previous draft of August/2005 (SP 800- 57) which publishes a table of comparable strengths: http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57- Part1.pdf p.63 note that 3-DES is now referred to as TDEA should this perhaps be included in rfc 2440 when 3-DES is mentioned? i.e. when 3-DES is first mentioned, it should be referred to as 3-DES(also known as TDEA) vedaal Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FEK3NV051322; Wed, 15 Mar 2006 07:20:03 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2FEK3Tc051321; Wed, 15 Mar 2006 07:20:03 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FEK1Dv051314 for ; Wed, 15 Mar 2006 07:20:02 -0700 (MST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id F2ED333C1C; Wed, 15 Mar 2006 14:20:00 +0000 (GMT) Message-ID: <44182299.2010507@algroup.co.uk> Date: Wed, 15 Mar 2006 14:20:09 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Hal Finney CC: dshaw@jabberwocky.com, ietf-openpgp@imc.org Subject: Re: NIST publishes new DSA draft References: <20060314194447.4D59A57FB0@finney.org> In-Reply-To: <20060314194447.4D59A57FB0@finney.org> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hal Finney wrote: > David Shaw writes: >> In the OpenPGP context, probably the most interesting bit is that the >> 160-bit hash limit has been removed. The sizes supported are: >> >> * 1024-bit key, 160-bit hash (the current DSA) >> * 2048-bit key, 224-bit hash (presumably aimed at SHA-224) >> * 2048-bit key, 256-bit hash (presumably aimed at SHA-256) >> * 3072-bit key, 256-bit hash (presumably aimed at SHA-256) >> >> It also adds the concept of using a larger hash than will fit by >> taking the leftmost bits. > > The main question is whether we want to change the current draft to make > these changes. That would probably require backing it out of "last > call" status. Personally I think this makes sense. There is no one > waiting urgently for this draft to be finalized AFAIK. The alternative > will be to immediately amend the RFC with another RFC. But for the sake > of future implementors I think it would be better to wait a few months > more and put it all into one draft. > > In two places in RFC2440-bis, we mention that DSA signatures must use > a 160 bit hash. The main one is in section 5.2.2, Version 3 Signature > Packet Format. This is not a good location as it is not information > that is specific to V3 signature packets. It applies to V4 signatures > as well. This information should probably be in 5.5.2 on public key > packet formats, or at least should be repeated in 5.2.3 for V4 sigs. > > It is also mentioned in section 13, Security Considerations, where we > state explicitly that RIPEMD-160 can be used, but that "DSS" as compared > to "DSA" requires SHA-1. > > One of the implications of the changes in the new draft is that 1024 bit > DSA keys can use SHA-256 (truncated to 160 bits). We should probably > allow that as an alternative to SHA-1, although it raises backwards > compatibility issues. > > For 2048 bit keys they allow either 224 or 256 bit hashes. This also > means allowing a subgroup "q" size of either 224 or 256 bits, I think. > The hash then must either match "q" or be larger, in which case it is > left-truncated. > > We do not have an algorithm ID for SHA-224. SHA-224 is the same > algorithm as SHA-256 but uses different initial values internally, > and then truncates the result to 224 bits. I don't see any advantage > in this case to using SHA-224 over using SHA-256 truncated to 224 bits. > However we might want to add an ID for it in case an implementor wanted > to follow the new DSS spec very closely. > > The simplest change we could make would be to allow that DSA keys can > use modulus "p" and subgroup "q" values of the specified sizes, based > on the table above. Hashes should be equal in size or larger than the > "q" size. Hashes larger than the "q" size should be left-truncated. > Then we could note that for DSS compliance the hashes must be taken from > the SHA family, either SHA-1 or one of the larger SHA's. > > We might want to think about making SHA-256 be another MUST algorithm. > The only MUST hash now is SHA-1. Making SHA-256 be a MUST would make > these new key sizes be more useful, and also give us an easier fallback > if SHA-1 should be broken. > > I also think we should change the names of SHA256 etc to use dashes > as in SHA-256; those are the official names. I'm in favour of making these changes now rather than waiting for the next version. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FBv7pV045266; Wed, 15 Mar 2006 04:57:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2FBv7cg045265; Wed, 15 Mar 2006 04:57:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FBv6TD045259 for ; Wed, 15 Mar 2006 04:57:07 -0700 (MST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 2BD7C33C1C; Wed, 15 Mar 2006 11:57:06 +0000 (GMT) Message-ID: <4418011B.2020708@algroup.co.uk> Date: Wed, 15 Mar 2006 11:57:15 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Hal Finney CC: james.couzens@electricmail.com, ietf-openpgp@imc.org Subject: Re: NIST publishes new DSA draft References: <20060314233108.1B3AF57FB0@finney.org> In-Reply-To: <20060314233108.1B3AF57FB0@finney.org> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hal Finney wrote: > James Couzens writes: >> I had thought it a bit strange that someone writing so comprehensively >> about something related to digital signatures and to then make the >> statement as you did at the end of the paragraph I quoted. Did you have >> some other intended meaning, such as broken by draft explicit >> prohibition or otherwise declared deprecated in a future draft? > > Yes, sorry, my language was not as precise as it might have been. > I said we should be ready in case SHA-1 were broken, but as you note > it has been officially "broken" for over a year. However that is just > a theoretical break and no actual examples of SHA-1 message collisions > have yet been published. So at this point SHA-1 is in a bit of a limbo > state, theoretically broken but still in widespread use. Its also worth noting that reducing the collision resistance to 2^69 still leaves it stronger than unbroken MD5 and is still well within the realms of hardness we require. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FBWmAD044550; Wed, 15 Mar 2006 04:32:48 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2FBWmA4044543; Wed, 15 Mar 2006 04:32:48 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FBWkli044514 for ; Wed, 15 Mar 2006 04:32:47 -0700 (MST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1FJUNH-0003ZD-Sd for ; Wed, 15 Mar 2006 12:41:07 +0100 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1FJUBu-0008Tj-22; Wed, 15 Mar 2006 12:29:22 +0100 From: Werner Koch To: iang@systemics.com Cc: ietf-openpgp@imc.org Subject: Re: NIST publishes new DSA draft References: <20060314233108.1B3AF57FB0@finney.org> <61223.84.131.251.69.1142414950.squirrel@webmail2.pair.com> Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Wed, 15 Mar 2006 12:29:21 +0100 In-Reply-To: <61223.84.131.251.69.1142414950.squirrel@webmail2.pair.com> (Ian Grigg's message of "Wed, 15 Mar 2006 04:29:10 -0500 (EST)") Message-ID: <87fylk6j5a.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 15 Mar 2006 04:29:10 -0500 (EST), Ian Grigg said: > Yes, it's a concern. FTR, I agree with Hal that > we should seriously consider taking the draft out > of last call (dammit!) ... hopefully it won't take I agree. However, SHA-256 should not be a MUST but a SHOULD. Otherwise many OpenPGP applications won't be compliant anymore. In particular applications on small devices may only support the MUST algorithms. A remark that this SHOULD will be changed to a MUST algorithm in the future will help to explain that we really want SHA-256. Salam-Shalom, Werner Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2F9TEG1040195; Wed, 15 Mar 2006 02:29:14 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2F9TEWn040194; Wed, 15 Mar 2006 02:29:14 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wbm2.pair.net (wbm2.pair.net [209.68.3.43]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2F9TDv8040186 for ; Wed, 15 Mar 2006 02:29:14 -0700 (MST) (envelope-from iang@systemics.com) Received: by wbm2.pair.net (Postfix, from userid 65534) id 3F95811725; Wed, 15 Mar 2006 04:29:10 -0500 (EST) Received: from 84.131.251.69 ([84.131.251.69]) (SquirrelMail authenticated user john@systemics.com) by webmail2.pair.com with HTTP; Wed, 15 Mar 2006 04:29:10 -0500 (EST) Message-ID: <61223.84.131.251.69.1142414950.squirrel@webmail2.pair.com> In-Reply-To: <20060314233108.1B3AF57FB0@finney.org> References: <20060314233108.1B3AF57FB0@finney.org> Date: Wed, 15 Mar 2006 04:29:10 -0500 (EST) Subject: Re: NIST publishes new DSA draft From: "Ian Grigg" To: ietf-openpgp@imc.org Reply-To: iang@systemics.com User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > James Couzens writes: >> I had thought it a bit strange that someone writing so comprehensively >> about something related to digital signatures and to then make the >> statement as you did at the end of the paragraph I quoted. Did you have >> some other intended meaning, such as broken by draft explicit >> prohibition or otherwise declared deprecated in a future draft? > > Yes, sorry, my language was not as precise as it might have been. > I said we should be ready in case SHA-1 were broken, but as you note > it has been officially "broken" for over a year. However that is just > a theoretical break and no actual examples of SHA-1 message collisions > have yet been published. So at this point SHA-1 is in a bit of a limbo > state, theoretically broken but still in widespread use. The problem lies in the use of the term "broken" which sounds great in the popular press, but is insufficiently precise for serious forums and serious protocol work. A more appropriate term is that SHA1 is weakened - from 80 bits to 69 bits - for some uses. Analysis in this forum in the past has indicated that - approximately - SHA1 is still good, but we should move over as and when we can select good alternatives. NIST's new DSA announcement I think makes the case that SHA256 is going to be around a lot longer than some of us earlier speculated, so that looks like the target for now. > If the attack should get worse so that SHA-1 collisions could be found > in a practical amount of time, then we would have a much more urgent > need to switch to another hash. That is what I really meant when I > said we should be ready if SHA-1 should be broken. Yes, it's a concern. FTR, I agree with Hal that we should seriously consider taking the draft out of last call (dammit!) ... hopefully it won't take too long to get enough consensus and some rough working code? iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2ENPEb4019847; Tue, 14 Mar 2006 16:25:14 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2ENPEdl019846; Tue, 14 Mar 2006 16:25:14 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2ENPC4B019840 for ; Tue, 14 Mar 2006 16:25:12 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 1B3AF57FB0; Tue, 14 Mar 2006 15:31:08 -0800 (PST) To: james.couzens@electricmail.com Subject: Re: NIST publishes new DSA draft Cc: ietf-openpgp@imc.org Message-Id: <20060314233108.1B3AF57FB0@finney.org> Date: Tue, 14 Mar 2006 15:31:08 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: James Couzens writes: > I had thought it a bit strange that someone writing so comprehensively > about something related to digital signatures and to then make the > statement as you did at the end of the paragraph I quoted. Did you have > some other intended meaning, such as broken by draft explicit > prohibition or otherwise declared deprecated in a future draft? Yes, sorry, my language was not as precise as it might have been. I said we should be ready in case SHA-1 were broken, but as you note it has been officially "broken" for over a year. However that is just a theoretical break and no actual examples of SHA-1 message collisions have yet been published. So at this point SHA-1 is in a bit of a limbo state, theoretically broken but still in widespread use. If the attack should get worse so that SHA-1 collisions could be found in a practical amount of time, then we would have a much more urgent need to switch to another hash. That is what I really meant when I said we should be ready if SHA-1 should be broken. Hal Finney Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EMxUlV018640; Tue, 14 Mar 2006 15:59:30 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2EMxUTS018639; Tue, 14 Mar 2006 15:59:30 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from herring.electric.net (herring.electric.net [216.129.90.28]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EMxTXW018619 for ; Tue, 14 Mar 2006 15:59:29 -0700 (MST) (envelope-from james.couzens@electricmail.com) Received: from root by herring.electric.net with emc1-ok (Exim 4.60) (envelope-from ) id 1FJIUB-0007Iw-Vz; Tue, 14 Mar 2006 14:59:27 -0800 Received: by emcmailer; Tue, 14 Mar 2006 14:59:27 -0800 Received: from [199.175.137.27] (helo=antitrust.electric.net) by herring.electric.net with esmtpsa (SSL 3.0:RSA_ARCFOUR_MD5:16) (Exim 4.60) (envelope-from ) id 1FJIUB-0007Ie-Tr; Tue, 14 Mar 2006 14:59:27 -0800 Subject: Re: NIST publishes new DSA draft From: James Couzens Reply-To: james.couzens@electricmail.com To: ietf-openpgp@imc.org Cc: hal@finney.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-iOvAS1f9XE6vu/PuqDYZ" Organization: Electric Mail Inc. Date: Tue, 14 Mar 2006 15:00:07 -0800 Message-Id: <1142377207.25875.10.camel@antitrust.electric.net> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-Outbound-IP: 199.175.137.27 X-Env-From: james.couzens@electricmail.com X-Virus-Status: Scanned by VirusSMART (s) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-iOvAS1f9XE6vu/PuqDYZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > Hi, James - I'm afraid you are off by a year on that. Those reports > were from 2005, not 2006. They have been intensively discussed here and > elsewhere in the cryptographic community. Indeed, those findings are a > good part of why I was proposing making SHA-256 a MUST, along with the > fact that this hash will now be able to be used with DSS signatures. My apologies, you are quite correct. I recently joined the list a few months ago, and haven't reviewed it historically, and as such I wasn't present for the referenced discussion(s) intense or otherwise :-) =20 I had thought it a bit strange that someone writing so comprehensively about something related to digital signatures and to then make the statement as you did at the end of the paragraph I quoted. Did you have some other intended meaning, such as broken by draft explicit prohibition or otherwise declared deprecated in a future draft? Cheers, James --=20 James Couzens, Programmer ___ __ __ ___=20 | __| \/ |/ __| The Electric Mail Company | _|| |\/| | (__ Managed, Secure Email Services |___|_| |_|\___| http://www.electricmail.com Direct Line: 604.482.1111 x152 -------------------------------------------------- PGP Key Fingerprint: B2EF B741 1807 2F24 8B70 F89B 03D2 6CFF C52F 0052 --=-iOvAS1f9XE6vu/PuqDYZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.7 (GNU/Linux) iD8DBQBEF0r3A9Js/8UvAFIRAmTQAJsGjuPpL/DDDmzlxcRMKU6n7xRhRgCgiJe2 gpu3cOjx6ykGwu+ibwrUxwA= =tSJP -----END PGP SIGNATURE----- --=-iOvAS1f9XE6vu/PuqDYZ-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EME6Hd016364; Tue, 14 Mar 2006 15:14:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2EME6hv016363; Tue, 14 Mar 2006 15:14:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EME3Sm016356 for ; Tue, 14 Mar 2006 15:14:06 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 38E3857FB0; Tue, 14 Mar 2006 14:19:59 -0800 (PST) To: james.couzens@electricmail.com Subject: Re: NIST publishes new DSA draft Cc: ietf-openpgp@imc.org Message-Id: <20060314221959.38E3857FB0@finney.org> Date: Tue, 14 Mar 2006 14:19:59 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, James - I'm afraid you are off by a year on that. Those reports were from 2005, not 2006. They have been intensively discussed here and elsewhere in the cryptographic community. Indeed, those findings are a good part of why I was proposing making SHA-256 a MUST, along with the fact that this hash will now be able to be used with DSS signatures. Hal Finney > > We might want to think about making SHA-256 be another MUST algorithm. > > The only MUST hash now is SHA-1. Making SHA-256 be a MUST would make > > these new key sizes be more useful, and also give us an easier fallback > > if SHA-1 should be broken. > > SHA-1 was broken, last month by three Chinese cryptographers as reported > by Bruce Schneier through is website. On February 15, 2006 he wrote of > a new cryptographic result, an attack faster than brute-force against > SHA-1. Two days later he wrote an update to his original post and a > quote from within it: > > > Earlier this week, three Chinese cryptographers showed that SHA-1 is not > > collision-free. That is, they developed an algorithm for finding collisions > > faster than brute force. > > > > ... > > > > They can find collisions in SHA-1 in 2^69 calculations, about 2,000 times > > faster than brute force. Right now, that is just on the far edge of > > feasibility with current technology. Two comparable massive computations > > illustrate that point. > > Reference URL (02/18/2006): http://tinyurl.com/4rl78 > Original post (02/15/2006): http://tinyurl.com/4bmcc > > With respect to your suggestion about thinking about making SHA-256 a MUST > algorithm I couldn't agree more. > > Cheers, > > James > > -- > James Couzens, > Programmer > ___ __ __ ___ > | __| \/ |/ __| The Electric Mail Company > | _|| |\/| | (__ Managed, Secure Email Services > |___|_| |_|\___| http://www.electricmail.com > Direct Line: 604.482.1111 x152 > -------------------------------------------------- > PGP Key Fingerprint: > B2EF B741 1807 2F24 8B70 F89B 03D2 6CFF C52F 0052 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2ELVNUg013856; Tue, 14 Mar 2006 14:31:23 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2ELVNNs013855; Tue, 14 Mar 2006 14:31:23 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sarge.electric.net (sarge.electric.net [216.129.90.31]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2ELVN4w013849 for ; Tue, 14 Mar 2006 14:31:23 -0700 (MST) (envelope-from james.couzens@electricmail.com) Received: from root by sarge.electric.net with emc1-ok (Exim 4.60) (envelope-from ) id 1FJH6t-000443-Vw; Tue, 14 Mar 2006 13:31:20 -0800 Received: by emcmailer; Tue, 14 Mar 2006 13:31:19 -0800 Received: from [199.175.137.27] (helo=antitrust.electric.net) by sarge.electric.net with esmtpsa (SSL 3.0:RSA_ARCFOUR_MD5:16) (Exim 4.60) (envelope-from ) id 1FJH6s-00042x-Vc; Tue, 14 Mar 2006 13:31:19 -0800 Subject: Re: NIST publishes new DSA draft From: James Couzens Reply-To: james.couzens@electricmail.com To: ietf-openpgp@imc.org Cc: hal@finney.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2oR8HVwpzkCvBwce15wZ" Organization: Electric Mail Inc. Date: Tue, 14 Mar 2006 13:31:57 -0800 Message-Id: <1142371918.23097.19.camel@antitrust.electric.net> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-Origin-IP: 199.175.137.27 X-Env-From: james.couzens@electricmail.com X-Virus-Status: Scanned by VirusSMART (s) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-2oR8HVwpzkCvBwce15wZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > We might want to think about making SHA-256 be another MUST algorithm. > The only MUST hash now is SHA-1. Making SHA-256 be a MUST would make > these new key sizes be more useful, and also give us an easier fallback > if SHA-1 should be broken. SHA-1 was broken, last month by three Chinese cryptographers as reported=20 by Bruce Schneier through is website. On February 15, 2006 he wrote of=20 a new cryptographic result, an attack faster than brute-force against=20 SHA-1. Two days later he wrote an update to his original post and a=20 quote from within it: > Earlier this week, three Chinese cryptographers showed that SHA-1 is not=20 > collision-free. That is, they developed an algorithm for finding collisio= ns > faster than brute force. >=20 > ... >=20 > They can find collisions in SHA-1 in 2^69 calculations, about 2,000 times > faster than brute force. Right now, that is just on the far edge of=20 > feasibility with current technology. Two comparable massive computations=20 > illustrate that point. Reference URL (02/18/2006): http://tinyurl.com/4rl78 Original post (02/15/2006): http://tinyurl.com/4bmcc With respect to your suggestion about thinking about making SHA-256 a MUST=20 algorithm I couldn't agree more. Cheers, James --=20 James Couzens, Programmer ___ __ __ ___=20 | __| \/ |/ __| The Electric Mail Company | _|| |\/| | (__ Managed, Secure Email Services |___|_| |_|\___| http://www.electricmail.com Direct Line: 604.482.1111 x152 -------------------------------------------------- PGP Key Fingerprint: B2EF B741 1807 2F24 8B70 F89B 03D2 6CFF C52F 0052 --=-2oR8HVwpzkCvBwce15wZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.7 (GNU/Linux) iD8DBQBEFzZNA9Js/8UvAFIRArrwAKCWc+RkFHF/JI1k69y8XC3j4kZwSACeIiGv dU828YLmJjhKzFjaPFrUgow= =b9fr -----END PGP SIGNATURE----- --=-2oR8HVwpzkCvBwce15wZ-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EJcuAc008404; Tue, 14 Mar 2006 12:38:56 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2EJcurl008403; Tue, 14 Mar 2006 12:38:56 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EJcpbJ008396 for ; Tue, 14 Mar 2006 12:38:54 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 4D59A57FB0; Tue, 14 Mar 2006 11:44:47 -0800 (PST) To: dshaw@jabberwocky.com, ietf-openpgp@imc.org Subject: Re: NIST publishes new DSA draft Message-Id: <20060314194447.4D59A57FB0@finney.org> Date: Tue, 14 Mar 2006 11:44:47 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw writes: > In the OpenPGP context, probably the most interesting bit is that the > 160-bit hash limit has been removed. The sizes supported are: > > * 1024-bit key, 160-bit hash (the current DSA) > * 2048-bit key, 224-bit hash (presumably aimed at SHA-224) > * 2048-bit key, 256-bit hash (presumably aimed at SHA-256) > * 3072-bit key, 256-bit hash (presumably aimed at SHA-256) > > It also adds the concept of using a larger hash than will fit by > taking the leftmost bits. The main question is whether we want to change the current draft to make these changes. That would probably require backing it out of "last call" status. Personally I think this makes sense. There is no one waiting urgently for this draft to be finalized AFAIK. The alternative will be to immediately amend the RFC with another RFC. But for the sake of future implementors I think it would be better to wait a few months more and put it all into one draft. In two places in RFC2440-bis, we mention that DSA signatures must use a 160 bit hash. The main one is in section 5.2.2, Version 3 Signature Packet Format. This is not a good location as it is not information that is specific to V3 signature packets. It applies to V4 signatures as well. This information should probably be in 5.5.2 on public key packet formats, or at least should be repeated in 5.2.3 for V4 sigs. It is also mentioned in section 13, Security Considerations, where we state explicitly that RIPEMD-160 can be used, but that "DSS" as compared to "DSA" requires SHA-1. One of the implications of the changes in the new draft is that 1024 bit DSA keys can use SHA-256 (truncated to 160 bits). We should probably allow that as an alternative to SHA-1, although it raises backwards compatibility issues. For 2048 bit keys they allow either 224 or 256 bit hashes. This also means allowing a subgroup "q" size of either 224 or 256 bits, I think. The hash then must either match "q" or be larger, in which case it is left-truncated. We do not have an algorithm ID for SHA-224. SHA-224 is the same algorithm as SHA-256 but uses different initial values internally, and then truncates the result to 224 bits. I don't see any advantage in this case to using SHA-224 over using SHA-256 truncated to 224 bits. However we might want to add an ID for it in case an implementor wanted to follow the new DSS spec very closely. The simplest change we could make would be to allow that DSA keys can use modulus "p" and subgroup "q" values of the specified sizes, based on the table above. Hashes should be equal in size or larger than the "q" size. Hashes larger than the "q" size should be left-truncated. Then we could note that for DSS compliance the hashes must be taken from the SHA family, either SHA-1 or one of the larger SHA's. We might want to think about making SHA-256 be another MUST algorithm. The only MUST hash now is SHA-1. Making SHA-256 be a MUST would make these new key sizes be more useful, and also give us an easier fallback if SHA-1 should be broken. I also think we should change the names of SHA256 etc to use dashes as in SHA-256; those are the official names. Hal Finney Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EFwv9U097067; Tue, 14 Mar 2006 08:58:57 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2EFwvUd097066; Tue, 14 Mar 2006 08:58:57 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2EFwu6p097058 for ; Tue, 14 Mar 2006 08:58:57 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2EFwjk04292 for ; Tue, 14 Mar 2006 10:58:45 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id k2EFwf6c030341 for ; Tue, 14 Mar 2006 10:58:41 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2EFwdmM001159 for ; Tue, 14 Mar 2006 10:58:39 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2EFwdmJ001158 for ietf-openpgp@imc.org; Tue, 14 Mar 2006 10:58:39 -0500 Date: Tue, 14 Mar 2006 10:58:39 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: NIST publishes new DSA draft Message-ID: <20060314155839.GA1029@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.11 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In the OpenPGP context, probably the most interesting bit is that the 160-bit hash limit has been removed. The sizes supported are: * 1024-bit key, 160-bit hash (the current DSA) * 2048-bit key, 224-bit hash (presumably aimed at SHA-224) * 2048-bit key, 256-bit hash (presumably aimed at SHA-256) * 3072-bit key, 256-bit hash (presumably aimed at SHA-256) It also adds the concept of using a larger hash than will fit by taking the leftmost bits. http://csrc.nist.gov/publications/drafts.html David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2BMCYVD034072; Sat, 11 Mar 2006 15:12:34 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2BMCYOR034071; Sat, 11 Mar 2006 15:12:34 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2BMCVlF034064 for ; Sat, 11 Mar 2006 15:12:32 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 2B66357FAE; Sat, 11 Mar 2006 14:18:18 -0800 (PST) To: ietf-openpgp@imc.org Subject: GnuPG does not detect injection of unsigned data Message-Id: <20060311221818.2B66357FAE@finney.org> Date: Sat, 11 Mar 2006 14:18:18 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: There has been much discussion on the net of a GnuPG bug reported by Werner Koch on Thursday: http://lists.gnupg.org/pipermail/gnupg-announce/2006q1/000216.html The problem is that a sequence of OpenPGP packets, some signed and some unsigned, was being output with the different types of data concatenated and no indication of what part was signed and what part wasn't. (This is my understanding from reading the report, apologies if I am misstating it.) Ironically I described a similar problem last month when we were talking about packet formats for exchanging public keys. I mentioned that I was not sure our PGP software would always work well with arbitrary sequences of OpenPGP packets, and that such messages raise difficult issues. Here is what I wrote on Feb 7, replying to Ben Laurie: > > Hmm. My implementation will eat _any_ sequence of packets. > > So what do you do if you decrypt a file and find a sequence of encrypted > packets? Or perhaps some packets signed, some encrypted, some both, all > concatenated? Do you concatenate the results into a single output file > (erasing the boundaries between the plaintexts, as well as information > about what was signed and what wasn't); do you concatenate them along > with some header information to identify where each piece starts and ends > (which won't be reliable due to spoofing); do you output each piece to > separate output files? Or ask the user what he wants to do? It appears that this was a case of exactly what I described as the first possibility, concatenating the results, with the problem of losing the information about what was signed and what wasn't. As usual the GnuPG guys have done a good job of publicizing this problem and quickly getting a bug fix out. It appears that the new version will only allow signed messages that have a simple format and will intentionally _not_ eat any sequence of packets. This is a good lesson for other implementors, to be aware of user information issues when dealing with complex cryptographic operations. Our OpenPGP packet format is extremely flexible, but that flexibility may not be appropriate for exposure directly to end users. Here is how I concluded my Feb 7 message: > This kind of operation introduces considerable complexity in terms of > providing a reasonable interface. We generally assume we are dealing > with a single message consisting of one or more PKESK/SKESK packets with > an encrypted packet, or a similar signed message. Once you go beyond > this and try to deal with arbitrary sequences of packets it becomes > highly problematic to make sure the user is getting the full benefit > from the cryptography. If you have a custom program which is using this > for internal, program-to-program communication, then go ahead and knock > yourself out, use the data structures as you wish. But for person to > person communication I think it is difficult and often unwise to try to > deal with arbitrary sequences. Hal Finney Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k22Bsjh8088326; Thu, 2 Mar 2006 04:54:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k22Bsj2s088325; Thu, 2 Mar 2006 04:54:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k22BsiRX088318 for ; Thu, 2 Mar 2006 04:54:44 -0700 (MST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id A106F33C1C; Thu, 2 Mar 2006 11:54:43 +0000 (GMT) Message-ID: <4406DD0A.4010103@algroup.co.uk> Date: Thu, 02 Mar 2006 11:54:50 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Hal Finney CC: ietf-openpgp@imc.org Subject: Re: Utterly Confused by Resync References: <20060301173527.D665657FAF@finney.org> In-Reply-To: <20060301173527.D665657FAF@finney.org> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hal Finney wrote: > Ben Laurie writes: >> I just implemented the Symmetrically Encrypted Data packet. >> >> It also does a "resync" after the first blocksize+2 bytes. However, I >> find that, unlike the MPI resync for v3 keys, as well as wiggling around >> the IV I have to encrypt it. >> >> That is, the resync operation for MPI looks like this: >> >> 1. Set the IV to the last blocksize bytes of ciphertext >> 2. Set the offset within the IV to zero. >> >> Whereas for the Symmetrically Encrypted Data resync looks like: >> >> 1. Set the IV to the last blocksize bytes of ciphertext >> 2. Encrypt the IV >> 3. Set the offset within the IV to zero. >> >> Can this possibly be right? Does the spec explain this at all? > > The resync operation is the same for encrypted data packets as for > V3 keys. There is a difference between the two cases, but it doesn't > involve the resync. The difference is that V3 keys use a regular IV, > while encrypted data packets use an IV of 0 and then discard the first > blocksize+2 bytes. But that does not affect the resync; the resync is > done exactly in the same way. > > CFB works like this. Encrypting plaintext block N starts with the > ciphertext of block N-1. Encrypt that ciphertext and then XOR the result > with plaintext block N to get ciphertext block N. For the 1st block, > where there is no previous ciphertext block, the IV is used. Encrypt the > IV and XOR with the 1st plaintext block to get the 1st ciphertext block. > > The resync operation can be though of as setting the IV to the previous > blocksize bytes of ciphertext, and starting this process from the > beginning. Encrypt the IV, XOR with the 1st bytes of the plaintext, > and you get your ciphertext. > > This will work for both encrypted data packets and for V3 private keys. > Your description fo the data packet case says as step 2, encrypt the IV. > I don't know how to interpret that. Of course you encrypt the IV, it > is part of the CFB process as I just described. Is that all you mean? > Or do you think you encrypt the IV twice? Is that what you are implying? > That would not work. > > The details of encryption for data packets are described in RFC2440bis > in section 12.8. It's a cumbersome and wordy description but if you read > it carefully it will hopefully shed light on what you need to do. I'm hesitant to say definitively I'm right, after the previous debacle, but... my resync function does _not_ perform an encryption, all it does is wriggle around the previous and current IVs, and it works fine with V3 keys. After I have called resync for the symmetric encrypted data packet, I have to encrypt the new IV, or it doesn't work. If I add the encrypt step to the resync, it breaks V3 keys. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k21HUOaQ062287; Wed, 1 Mar 2006 10:30:24 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k21HUO4e062286; Wed, 1 Mar 2006 10:30:24 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k21HUMdQ062248 for ; Wed, 1 Mar 2006 10:30:23 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id D665657FAF; Wed, 1 Mar 2006 09:35:27 -0800 (PST) To: ben@algroup.co.uk, ietf-openpgp@imc.org Subject: Re: Utterly Confused by Resync Message-Id: <20060301173527.D665657FAF@finney.org> Date: Wed, 1 Mar 2006 09:35:27 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ben Laurie writes: > I just implemented the Symmetrically Encrypted Data packet. > > It also does a "resync" after the first blocksize+2 bytes. However, I > find that, unlike the MPI resync for v3 keys, as well as wiggling around > the IV I have to encrypt it. > > That is, the resync operation for MPI looks like this: > > 1. Set the IV to the last blocksize bytes of ciphertext > 2. Set the offset within the IV to zero. > > Whereas for the Symmetrically Encrypted Data resync looks like: > > 1. Set the IV to the last blocksize bytes of ciphertext > 2. Encrypt the IV > 3. Set the offset within the IV to zero. > > Can this possibly be right? Does the spec explain this at all? The resync operation is the same for encrypted data packets as for V3 keys. There is a difference between the two cases, but it doesn't involve the resync. The difference is that V3 keys use a regular IV, while encrypted data packets use an IV of 0 and then discard the first blocksize+2 bytes. But that does not affect the resync; the resync is done exactly in the same way. CFB works like this. Encrypting plaintext block N starts with the ciphertext of block N-1. Encrypt that ciphertext and then XOR the result with plaintext block N to get ciphertext block N. For the 1st block, where there is no previous ciphertext block, the IV is used. Encrypt the IV and XOR with the 1st plaintext block to get the 1st ciphertext block. The resync operation can be though of as setting the IV to the previous blocksize bytes of ciphertext, and starting this process from the beginning. Encrypt the IV, XOR with the 1st bytes of the plaintext, and you get your ciphertext. This will work for both encrypted data packets and for V3 private keys. Your description fo the data packet case says as step 2, encrypt the IV. I don't know how to interpret that. Of course you encrypt the IV, it is part of the CFB process as I just described. Is that all you mean? Or do you think you encrypt the IV twice? Is that what you are implying? That would not work. The details of encryption for data packets are described in RFC2440bis in section 12.8. It's a cumbersome and wordy description but if you read it carefully it will hopefully shed light on what you need to do. Hal Finney Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k21DlTr8076821; Wed, 1 Mar 2006 06:47:29 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k21DlTpE076820; Wed, 1 Mar 2006 06:47:29 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k21DlSTM076814 for ; Wed, 1 Mar 2006 06:47:29 -0700 (MST) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id AA0EB33C3F for ; Wed, 1 Mar 2006 13:47:27 +0000 (GMT) Message-ID: <4405A5F4.5000108@algroup.co.uk> Date: Wed, 01 Mar 2006 13:47:32 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: OpenPGP Subject: Utterly Confused by Resync X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I just implemented the Symmetrically Encrypted Data packet. It also does a "resync" after the first blocksize+2 bytes. However, I find that, unlike the MPI resync for v3 keys, as well as wiggling around the IV I have to encrypt it. That is, the resync operation for MPI looks like this: 1. Set the IV to the last blocksize bytes of ciphertext 2. Set the offset within the IV to zero. Whereas for the Symmetrically Encrypted Data resync looks like: 1. Set the IV to the last blocksize bytes of ciphertext 2. Encrypt the IV 3. Set the offset within the IV to zero. Can this possibly be right? Does the spec explain this at all? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff