From owner-ietf-openpgp@mail.imc.org Sat Apr 2 09:25:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24816 for ; Sat, 2 Apr 2005 09:25:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j32E8EEr008430; Sat, 2 Apr 2005 06:08:14 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j32E8E7V008429; Sat, 2 Apr 2005 06:08:14 -0800 (PST) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j32E8DBI008422 for ; Sat, 2 Apr 2005 06:08:14 -0800 (PST) (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 2B65533C45 for ; Sat, 2 Apr 2005 15:08:12 +0100 (BST) Message-ID: <424EA6D3.1050301@algroup.co.uk> Date: Sat, 02 Apr 2005 15:06:11 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OpenPGP Subject: Version hashed twice? X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: Content-Transfer-Encoding: 7bit In a v4 signature packet, the packet version number is hashed twice, once in the hash of the packet data, and again in the trailer. Why? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 Sat Apr 2 12:13:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05709 for ; Sat, 2 Apr 2005 12:13:36 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j32GpsbQ018635; Sat, 2 Apr 2005 08:51:54 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j32GprkB018634; Sat, 2 Apr 2005 08:51:53 -0800 (PST) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j32GpqKv018628 for ; Sat, 2 Apr 2005 08:51:53 -0800 (PST) (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 DE63E33C73 for ; Sat, 2 Apr 2005 17:51:51 +0100 (BST) Message-ID: <424ECD2F.1090601@algroup.co.uk> Date: Sat, 02 Apr 2005 17:49:51 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OpenPGP Subject: How to Calculate Signatures? X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: Content-Transfer-Encoding: 7bit Once more referring to 2440bis-12... The sections on calculating signatures are really confusing. I can't currently suggest alternate text for most of it because its far from clear to me what the actual algorithms are. If someone explains, I'll do my best to write clarifying text. Firstly: 5.2.2 says: The signature calculation is based on a hash of the signed data, as described above. Until I wrote this email, I though this sentence meant the signature calculation was described above. I've just realised it means that the hash is described above. I suggest instead: The signature calculation is based on the hash of the signed data described above. Though since the hash is described much more usefully in 5.2.4, perhaps it should simply refer to that instead? It then goes on to say: The details of the calculation are different for DSA signature than for RSA signatures. The hash h is PKCS-1 padded exactly the same way as for the above described RSA signatures. For the life of me, I can't see an "above described RSA signature" - where is that? PKCS-1 is mentioned before, but for encryption, not signing. It then goes on to describe truly revolting nastiness about PKCS-1 (shouldn't that be written PKCS#1, incidentally?) for doing RSA signatures, but never, as far as I can see, says how to do a DSA signature. From experiment, it seems to me that a DSA signature is done directly on the hash, without any manipulation at all. Correct? Then in 5.2.3: The algorithms for converting the hash function result to a signature are described in a section below. Firstly, it would be much more friendly to say _which_ section below, rather than leaving the reader to guess. I'd fill that in if I could find the section, but I can't. The nearest I can get is 5.2.4, which says: After all this has been hashed in a single hash context the resulting hash field is used in the signature algorithm, and placed at the end of the signature packet. And that appears to be it, as far as signature algorithms are concerned. Reading between the lines, I'm assuming that what this really means is that the algorithms used are exactly what I'd expect, i.e. DSA directly on the hash, and RSA with PKCS#1 padding and the, err, other stuff. But references to further descriptions that I can't find leave me in doubt! Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 Sat Apr 2 15:01:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16327 for ; Sat, 2 Apr 2005 15:01:45 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j32JlP8B031780; Sat, 2 Apr 2005 11:47:25 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j32JlOMe031779; Sat, 2 Apr 2005 11:47:24 -0800 (PST) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j32JlOvl031773 for ; Sat, 2 Apr 2005 11:47:24 -0800 (PST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 1B39F57EE9; Sat, 2 Apr 2005 12:00:46 -0800 (PST) To: ietf-openpgp@imc.org Subject: Re: Version hashed twice? Message-Id: <20050402200046.1B39F57EE9@finney.org> Date: Sat, 2 Apr 2005 12:00:46 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The reason for the trailer in V4 sigs is to address a security weakness in V3 sigs and their relation with V4. The problem is that V3 key sigs do not hash the length of the userid field, and neither version hashes the length of the data when signing a document. This would mean that, if we did not have a V4 trailer, it might be possible to get someone to V3 sign a properly constructed userid or document, and then turn that into a V4 signature on something else. To prevent that, we want the sequence of bytes hashed in a V4 signature to be (a) uniquely parseable; and (b) unable to match the same sequence of bytes hashed in any other signature version. Uniquely parseable means that given the sequence of bytes that were hashed, and with no other information, you can determine with 100% reliability what the parsing is of the data into signature packets and other packets. V3 document signatures hash n random bytes, where n is not hashed, and then 1 byte of signature type and 4 bytes of signature creation time. V3 key signatures hash bytes starting with the key packet, which is uniquely parseable because it includes the length; then the user id, which does not include the length; then 1 byte of signature type and 4 bytes of signature creation time. We want to make sure that no V4 signature could hash a sequence of bytes that matches the same sequence of bytes in a V3 signature. This is why we force the 4th byte from the end in the V4 sequence of hashed bytes to be 0xff. The 4th byte from the end in a V3 sequence of hashed bytes will always be signature type, and 0xff is not a legal signature type. So that will ensure that V3 signatures cannot be re-packaged as V4 signatures. The reason we include the version number and length of hashed packets is to ensure unique parseability. Without the length of hashed packets at the end, you could create a document whose V4 signature could be applied to a different document with different subpackets in a modified V4 signature. By including the length of hashed packets we make it unambiguous where the document ends and the V4 signature packet begins. And the reason we include the version there is in case we change this for future versions, we will have an unambiguous place where the version number can be found, 6 bytes from the end. The other location of version number might not be uniquely parseable once we create new versions. This will give us more flexibility in the future and we won't have to worry about repackaging attacks as we did with the V3 to V4 transition. Hal Finney From owner-ietf-openpgp@mail.imc.org Sat Apr 2 15:19:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22916 for ; Sat, 2 Apr 2005 15:19:05 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j32K2qx4032526; Sat, 2 Apr 2005 12:02:52 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j32K2qL2032525; Sat, 2 Apr 2005 12:02:52 -0800 (PST) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j32K2qta032519 for ; Sat, 2 Apr 2005 12:02:52 -0800 (PST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 31E9157EE9; Sat, 2 Apr 2005 12:16:14 -0800 (PST) To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? Message-Id: <20050402201614.31E9157EE9@finney.org> Date: Sat, 2 Apr 2005 12:16:14 -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: > The sections on calculating signatures are really confusing. I can't > currently suggest alternate text for most of it because its far from > clear to me what the actual algorithms are. If someone explains, I'll do > my best to write clarifying text. You're right, this is really messed up. The authoritative section on what to hash is 5.2.4. We should refer forward to that section and not include detailed information about what is hashed in the sections on V3 and V4 signature packets. We should make it clear that the DSA signature algorithm works directly on the hash value that results from 5.2.4. We should say that RSA signatures use that hash and prepend the sequence of bytes identified as the "full hash prefixes". We could probably remove the hexadecimal equivalents to the ASN.1 OIDs; if someone understands ASN.1 well then the OIDs are enough, and if not then they can just follow the rule to prepend the proper byte sequences and that will work. This then gets padded as in PKCS#1 v1.5 signatures. We should have a sentence clarifying that this is what gives us the value "m" used in the signature calculation. Hal From owner-ietf-openpgp@mail.imc.org Sat Apr 2 22:10:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17002 for ; Sat, 2 Apr 2005 22:10:33 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j332tToB052964; Sat, 2 Apr 2005 18:55:29 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j332tT9s052963; Sat, 2 Apr 2005 18:55:29 -0800 (PST) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j332tRe9052956 for ; Sat, 2 Apr 2005 18:55:28 -0800 (PST) (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 CB29F33C45; Sun, 3 Apr 2005 03:55:26 +0100 (BST) Message-ID: <424F5AA6.1060001@algroup.co.uk> Date: Sun, 03 Apr 2005 03:53:26 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? References: <20050402201614.31E9157EE9@finney.org> In-Reply-To: <20050402201614.31E9157EE9@finney.org> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: Content-Transfer-Encoding: 7bit Hal Finney wrote: > Ben Laurie writes: > > >>The sections on calculating signatures are really confusing. I can't >>currently suggest alternate text for most of it because its far from >>clear to me what the actual algorithms are. If someone explains, I'll do >>my best to write clarifying text. > > > You're right, this is really messed up. > > The authoritative section on what to hash is 5.2.4. We should refer > forward to that section and not include detailed information about > what is hashed in the sections on V3 and V4 signature packets. > > We should make it clear that the DSA signature algorithm works directly > on the hash value that results from 5.2.4. > > We should say that RSA signatures use that hash and prepend the sequence > of bytes identified as the "full hash prefixes". We could probably remove > the hexadecimal equivalents to the ASN.1 OIDs; if someone understands > ASN.1 well then the OIDs are enough, and if not then they can just > follow the rule to prepend the proper byte sequences and that will work. > This then gets padded as in PKCS#1 v1.5 signatures. We should have a > sentence clarifying that this is what gives us the value "m" used in > the signature calculation. We also need to specify emLen, which I presume (by logic and experiment) is equal to the RSA key size. I will send diffs soon. Thanks for the clarification. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 Apr 3 11:23:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02734 for ; Sun, 3 Apr 2005 11:23:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33F5D3U035951; Sun, 3 Apr 2005 08:05:13 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33F5Dih035950; Sun, 3 Apr 2005 08:05:13 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j33F5BEK035942 for ; Sun, 3 Apr 2005 08:05:12 -0700 (PDT) (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 096FD33C33 for ; Sun, 3 Apr 2005 16:05:10 +0100 (BST) Message-ID: <425005AE.5030105@algroup.co.uk> Date: Sun, 03 Apr 2005 16:03:10 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? References: <20050402201614.31E9157EE9@finney.org> <424F5AA6.1060001@algroup.co.uk> In-Reply-To: <424F5AA6.1060001@algroup.co.uk> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------050504080006000107060205" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------050504080006000107060205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Here are proposed diffs. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 --------------050504080006000107060205 Content-Type: text/plain; name="id.diff" Content-Disposition: inline; filename="id.diff" Content-Transfer-Encoding: 7bit --- draft-ietf-openpgp-rfc2440bis-12.txt Tue Nov 23 18:36:41 2004 +++ draft-ietf-openpgp-rfc2440bis-12-ben.txt Sun Apr 3 15:29:31 2005 @@ -1137,13 +1137,6 @@ - One or more multiprecision integers comprising the signature. This portion is algorithm specific, as described below. - The data being signed is hashed, and then the signature type and - creation time from the signature packet are hashed (5 additional - octets). The resulting hash value is used in the signature - algorithm. The high 16 bits (first two octets) of the hash are - included in the signature packet to provide a quick test to reject - some invalid signatures. - Algorithm Specific Fields for RSA signatures: - multiprecision integer (MPI) of RSA signature value m**d mod n. @@ -1154,80 +1147,10 @@ - MPI of DSA value s. - The signature calculation is based on a hash of the signed data, as - described above. The details of the calculation are different for - DSA signature than for RSA signatures. - - The hash h is PKCS-1 padded exactly the same way as for the above - described RSA signatures. - - With RSA signatures, the hash value is encoded as described in - PKCS-1 section 9.2.1 encoded using PKCS-1 encoding type - EMSA-PKCS1-v1_5 [RFC2437]. This requires inserting the hash value - as an octet string into an ASN.1 structure. The object identifier - for the type of hash being used is included in the structure. The - hexadecimal representations for the currently defined hash - algorithms are: - - - MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05 - - - -Callas, et al. Expires May 23, 2005 [Page 21] -INTERNET-DRAFT OpenPGP Message Format Nov 23, 2004 - - - RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01 - - - SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A - - - SHA256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01 - - - SHA384: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02 - - - SHA512: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03 - - The ASN.1 OIDs are: - - - MD5: 1.2.840.113549.2.5 - - - RIPEMD-160: 1.3.36.3.2.1 - - - SHA-1: 1.3.14.3.2.26 - - - SHA256: 2.16.840.1.101.3.4.2.1 - - - SHA384: 2.16.840.1.101.3.4.2.2 - - - SHA512: 2.16.840.1.101.3.4.2.3 - - The full hash prefixes for these are: - - MD5: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, - 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00, - 0x04, 0x10 - - RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24, - 0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14 - - SHA-1: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E, - 0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14 - - SHA256: 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, - 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05, - 0x00, 0x04, 0x20 - - SHA384: 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, - 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05, - 0x00, 0x04, 0x30 - - SHA512: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, - 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05, - 0x00, 0x04, 0x40 - - 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. + The signature calculation is based on a hash of the signed + data. This is described in detail in section 5.2.4. The high 16 + bits (first two octets) of the hash are included in the signature + packet to provide a quick test to reject some invalid signatures. Callas, et al. Expires May 23, 2005 [Page 22] INTERNET-DRAFT OpenPGP Message Format Nov 23, 2004 @@ -1263,20 +1186,16 @@ - One or more multiprecision integers comprising the signature. This portion is algorithm specific, as described above. - The data being signed is hashed, and then the signature data from - the version number through the hashed subpacket data (inclusive) is - hashed. The resulting hash value is what is signed. The left 16 - bits of the hash are included in the signature packet to provide a - quick test to reject some invalid signatures. - There are two fields consisting of signature subpackets. The first field is hashed with the rest of the signature data, while the second is unhashed. The second set of subpackets is not cryptographically protected by the signature and should include only advisory information. - The algorithms for converting the hash function result to a - signature are described in a section below. + The algorithms for calculating the hash and converting the result + to a signature are described in section 5.2.4. The left 16 bits of + the hash are included in the signature packet to provide a quick + test to reject some invalid signatures. 5.2.3.1. Signature Subpacket Specification @@ -1936,7 +1855,72 @@ resulting hash field is used in the signature algorithm, and placed at the end of the signature packet. -5.2.4.1. Subpacket Hints +5.2.4.1. Signature Algorithms + +5.2.4.1.1. DSA Signatures + + A DSA signature is performed as specified in [FIPS-186-2] on the + value of the hash, calculated as above. + + 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. + +5.2.4.1.2. RSA Signatures + + With RSA signatures, the hash value is encoded as described in + PKCS #1 section 9.2.1 encoded using PKCS #1 encoding type + EMSA-PKCS1-v1_5 [RFC2437]. This requires inserting the hash value + as an octet string into an ASN.1 structure. The object identifier + for the type of hash being used is included in the structure. + + The ASN.1 OIDs are: + + - MD5: 1.2.840.113549.2.5 + + - RIPEMD-160: 1.3.36.3.2.1 + + - SHA-1: 1.3.14.3.2.26 + + - SHA256: 2.16.840.1.101.3.4.2.1 + + - SHA384: 2.16.840.1.101.3.4.2.2 + + - SHA512: 2.16.840.1.101.3.4.2.3 + + In practice this amounts to prefixing the hash with one of the + following, then padding as described in PKCS #1: + + MD5: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, + 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00, + 0x04, 0x10 + + RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24, + 0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14 + + SHA-1: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E, + 0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14 + + SHA256: 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, + 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05, + 0x00, 0x04, 0x20 + + SHA384: 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, + 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05, + 0x00, 0x04, 0x30 + + SHA512: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, + 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05, + 0x00, 0x04, 0x40 + + The value emLen needed for the padding is equal to the length in + bytes of the RSA public modulus, n. + + Once the hash has been encoded and padded, the resulting string is + encrypted with the RSA private key as described in [RSA]. + +5.2.4.2. Subpacket Hints It is certainly possible for a signature to contain conflicting information in subpackets. For example, a signature may contain @@ -3084,7 +3068,7 @@ 2 - RSA Encrypt-Only 3 - RSA Sign-Only 16 - Elgamal (Encrypt-Only), see [ELGAMAL] - 17 - DSA (Digital Signature Algorithm) [SCHNEIER] + 17 - DSA (Digital Signature Algorithm) [DSA] 18 - Reserved for Elliptic Curve 19 - Reserved for ECDSA 20 - Reserved (formerly Elgamal Encrypt or Sign) @@ -3946,6 +3930,10 @@ 1983, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997. + [FIPS186-2] "Digital Signature Standard", FIPS 186-2, January + 2000. + [RSA] Menezes, A., et al. "Handbook of Applied + Cryptography", Section 8.2., October 1996. --------------050504080006000107060205-- From owner-ietf-openpgp@mail.imc.org Sun Apr 3 12:59:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08687 for ; Sun, 3 Apr 2005 12:59:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33Gi1Si043243; Sun, 3 Apr 2005 09:44:01 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33Gi1RM043242; Sun, 3 Apr 2005 09:44:01 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j33Gi0oB043236 for ; Sun, 3 Apr 2005 09:44:01 -0700 (PDT) (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 410D833C33; Sun, 3 Apr 2005 17:43:59 +0100 (BST) Message-ID: <42501CD7.4070005@algroup.co.uk> Date: Sun, 03 Apr 2005 17:41:59 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Laurie Cc: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? References: <20050402201614.31E9157EE9@finney.org> <424F5AA6.1060001@algroup.co.uk> <425005AE.5030105@algroup.co.uk> In-Reply-To: <425005AE.5030105@algroup.co.uk> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: Content-Transfer-Encoding: 7bit Ben Laurie wrote: > Here are proposed diffs. Oh, yes. This left me with an unresolved issue: how does one use SHA{256,384,512} with DSA (which requires a 160 bit hash). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 Apr 3 14:04:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14975 for ; Sun, 3 Apr 2005 14:04:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33HmUaC047323; Sun, 3 Apr 2005 10:48:30 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33HmUu3047322; Sun, 3 Apr 2005 10:48:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from p15139323.pureserver.info (silmor.de [217.160.219.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33HmTFe047313 for ; Sun, 3 Apr 2005 10:48:29 -0700 (PDT) (envelope-from konrad@silmor.de) Received: from p548c9f4c.dip.t-dialin.net ([84.140.159.76] helo=zaphod.local) by p15139323.pureserver.info with asmtp (Exim 3.35 #1 (Debian)) id 1DI9Cx-0000Ls-00 for ; Sun, 03 Apr 2005 19:48:23 +0200 From: Konrad Rosenbaum To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? Date: Sun, 3 Apr 2005 19:48:18 +0200 User-Agent: KMail/1.7.2 References: <20050402201614.31E9157EE9@finney.org> <425005AE.5030105@algroup.co.uk> <42501CD7.4070005@algroup.co.uk> In-Reply-To: <42501CD7.4070005@algroup.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1268253.Hopp9c9hf8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504031948.22079@zaphod.konrad.silmor.de> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --nextPart1268253.Hopp9c9hf8 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sunday 03 April 2005 18:41, Ben Laurie wrote: > Oh, yes. This left me with an unresolved issue: how does one use > SHA{256,384,512} with DSA (which requires a 160 bit hash). Simple: you don't. DSA was designed to be used with SHA-1, which is 160 bit= =2E=20 Since SHA-1 is theoretically broken (practically will probably follow in a= =20 few months) one should see what the NIST makes of it. Supplanting a broken= =20 hash with another hash doesn't make much sense with DSA, since it does not= =20 contain the ID of the hash (as PKCS#1 does for RSA) - so any attacker could= =20 find a collission with the broken hash and then simply change the hash ID=20 in the signature packet. Konrad --nextPart1268253.Hopp9c9hf8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBCUCxmClt766LaIH0RAiBeAJ4goq0kmPn8yJcNWuJYUITKoRVZ1gCeMS/o r7S9RYDYjg4/H6v8Qsb+NKY= =LHGA -----END PGP SIGNATURE----- --nextPart1268253.Hopp9c9hf8-- From owner-ietf-openpgp@mail.imc.org Sun Apr 3 15:01:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18539 for ; Sun, 3 Apr 2005 15:01:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33IbGDB050976; Sun, 3 Apr 2005 11:37:16 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33IbGt6050975; Sun, 3 Apr 2005 11:37:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33IbECN050969 for ; Sun, 3 Apr 2005 11:37:15 -0700 (PDT) (envelope-from iang@systemics.com) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j33IaqU02903 for ; Sun, 3 Apr 2005 19:37:08 +0100 X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol Message-ID: <4250389F.4050301@systemics.com> Date: Sun, 03 Apr 2005 19:40:31 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0 (X11/20050219) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? References: <20050402201614.31E9157EE9@finney.org> <425005AE.5030105@algroup.co.uk> <42501CD7.4070005@algroup.co.uk> <200504031948.22079@zaphod.konrad.silmor.de> In-Reply-To: <200504031948.22079@zaphod.konrad.silmor.de> 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: Content-Transfer-Encoding: 7bit Konrad Rosenbaum wrote: > On Sunday 03 April 2005 18:41, Ben Laurie wrote: > >>Oh, yes. This left me with an unresolved issue: how does one use >>SHA{256,384,512} with DSA (which requires a 160 bit hash). > > > Simple: you don't. DSA was designed to be used with SHA-1, which is 160 bit. > Since SHA-1 is theoretically broken (practically will probably follow in a > few months) one should see what the NIST makes of it. Supplanting a broken > hash with another hash doesn't make much sense with DSA, since it does not > contain the ID of the hash (as PKCS#1 does for RSA) - so any attacker could > find a collission with the broken hash and then simply change the hash ID > in the signature packet. I would agree with that. There was some discussion on the user's list about an attempt at producing a code path to use SHA256... which seemed to confuse the issue. Would it be a good idea to put in a statement explicitly limiting OpenPGP's view of DSS to be SHA1 only? And add a comment perhaps that in the light of weaknesses in SHA1, that RSA with a fatter digest be used instead as a workaround? (SHA1 will remain a current issue until "something is done". When it was debated a month back, did we reach a consensus to do something about it? I got the feeling that we didn't, but I might be just remembering one side.) iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ From owner-ietf-openpgp@mail.imc.org Sun Apr 3 15:04:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18798 for ; Sun, 3 Apr 2005 15:04:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33Iqp1X051927; Sun, 3 Apr 2005 11:52:51 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33Iqpqp051926; Sun, 3 Apr 2005 11:52:51 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j33IqobL051915 for ; Sun, 3 Apr 2005 11:52:50 -0700 (PDT) (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 61DA233C33; Sun, 3 Apr 2005 19:52:49 +0100 (BST) Message-ID: <42503B09.8090608@algroup.co.uk> Date: Sun, 03 Apr 2005 19:50:49 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Konrad Rosenbaum Cc: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? References: <20050402201614.31E9157EE9@finney.org> <425005AE.5030105@algroup.co.uk> <42501CD7.4070005@algroup.co.uk> <200504031948.22079@zaphod.konrad.silmor.de> In-Reply-To: <200504031948.22079@zaphod.konrad.silmor.de> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: Content-Transfer-Encoding: 7bit Konrad Rosenbaum wrote: > On Sunday 03 April 2005 18:41, Ben Laurie wrote: > >>Oh, yes. This left me with an unresolved issue: how does one use >>SHA{256,384,512} with DSA (which requires a 160 bit hash). > > > Simple: you don't. DSA was designed to be used with SHA-1, which is 160 bit. > Since SHA-1 is theoretically broken (practically will probably follow in a > few months) one should see what the NIST makes of it. Supplanting a broken > hash with another hash doesn't make much sense with DSA, since it does not > contain the ID of the hash (as PKCS#1 does for RSA) - so any attacker could > find a collission with the broken hash and then simply change the hash ID > in the signature packet. The hash does include the ID of the hash, and hence the signature does. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 Apr 3 15:04:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18846 for ; Sun, 3 Apr 2005 15:04:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33IsuwK052014; Sun, 3 Apr 2005 11:54:56 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33IsuCb052013; Sun, 3 Apr 2005 11:54:56 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j33IstXm052006 for ; Sun, 3 Apr 2005 11:54:55 -0700 (PDT) (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 D99EA33C33; Sun, 3 Apr 2005 19:54:54 +0100 (BST) Message-ID: <42503B87.4090509@algroup.co.uk> Date: Sun, 03 Apr 2005 19:52:55 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian G Cc: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? References: <20050402201614.31E9157EE9@finney.org> <425005AE.5030105@algroup.co.uk> <42501CD7.4070005@algroup.co.uk> <200504031948.22079@zaphod.konrad.silmor.de> <4250389F.4050301@systemics.com> In-Reply-To: <4250389F.4050301@systemics.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: Content-Transfer-Encoding: 7bit Ian G wrote: > > Konrad Rosenbaum wrote: > >> On Sunday 03 April 2005 18:41, Ben Laurie wrote: >> >>> Oh, yes. This left me with an unresolved issue: how does one use >>> SHA{256,384,512} with DSA (which requires a 160 bit hash). >> >> >> >> Simple: you don't. DSA was designed to be used with SHA-1, which is >> 160 bit. Since SHA-1 is theoretically broken (practically will >> probably follow in a few months) one should see what the NIST makes of >> it. Supplanting a broken hash with another hash doesn't make much >> sense with DSA, since it does not contain the ID of the hash (as >> PKCS#1 does for RSA) - so any attacker could find a collission with >> the broken hash and then simply change the hash ID in the signature >> packet. > > > > I would agree with that. There was some discussion > on the user's list about an attempt at producing a > code path to use SHA256... which seemed to confuse > the issue. > > Would it be a good idea to put in a statement > explicitly limiting OpenPGP's view of DSS to be > SHA1 only? And add a comment perhaps that in the > light of weaknesses in SHA1, that RSA with a fatter > digest be used instead as a workaround? The cost of that is that anyone with a DSA key is screwed. Seems like a last resort to me. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 Apr 3 15:40:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21764 for ; Sun, 3 Apr 2005 15:40:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33JQ3kr054063; Sun, 3 Apr 2005 12:26:03 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33JQ3lH054062; Sun, 3 Apr 2005 12:26:03 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j33JQ34C054056 for ; Sun, 3 Apr 2005 12:26:03 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 0812057EBA; Sun, 3 Apr 2005 12:39:29 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? Message-Id: <20050403193929.0812057EBA@finney.org> Date: Sun, 3 Apr 2005 12:39:29 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Konrad Rosenbaum writes: > On Sunday 03 April 2005 18:41, Ben Laurie wrote: > > Oh, yes. This left me with an unresolved issue: how does one use > > SHA{256,384,512} with DSA (which requires a 160 bit hash). > > Simple: you don't. DSA was designed to be used with SHA-1, which is 160 bit. > Since SHA-1 is theoretically broken (practically will probably follow in a > few months) one should see what the NIST makes of it. Supplanting a broken > hash with another hash doesn't make much sense with DSA, since it does not > contain the ID of the hash (as PKCS#1 does for RSA) - so any attacker could > find a collission with the broken hash and then simply change the hash ID > in the signature packet. I have mixed feelings on this issue. The situation is complex: - RFC 2440 has always allowed hashes other than SHA-1 if they matched the size of q. The only one that fit was RIPEMD-160. This already opens the attack Konrad describes. If RIPEMD-160 were badly broken, you could substitute it into a DSA signature using SHA-1. - If a hash were broken, recipients can defend against this attack by not trusting signatures made with that hash. That's not all that bad. We are already in a similar situation with regard to other cryptographic components. If a signature algorithm were broken, people would have to distrust signatures made with that algorithm. Same with an encryption algorithm, people would have to know not to use it. Even with RSA, you'd have to know not to trust signatures made with a broken hash. The specific risk raised by the hash substitution attack is that a signer can't protect his signature against substitution with a broken hash, he has to rely on the verifier to know that the hash is broken and not to trust it. - The current hash breaks only allow for collisions and not preimage attacks. It is still not possible, even with MD5, to create a hash that matches a target value. Hashes would have to be broken much more severely than they are now before this would become a threat. - NIST is dragging their feet on incorporating SHA-2 into a new DSS. They have been talking about this for years. Hopefully the new results will motivate them to speed things up, but "fast" in a bureaucracy could still mean a year or more. - How can we update the replacement for RFC-2440 to incorporate a new DSS-2 or whatever it will be called? Do we need to update the base document, or can we create a separate RFC that just documents the new format? Will it be a new algorithm ID, or will we overload the DSA algorithm ID? These issues may slow down the incorporation of DSS-2 into OpenPGP even once it is announced. For all of these reasons, I am tempted to allow the SHA-2 family with current DSA keys, as an interim measure pending the move to DSS-2. FIPS 180, which defines the SHA family, had a change notice to add SHA-224, a truncated form of SHA-256. This document, , describes truncation of hash algorithms on page 73: "Some applications may require a hash function with an output size (i.e., message digest size) different than those provided by the hash functions in this Standard. In such cases, a truncated hash output may be used, whereby a hash function with a larger output size is applied to the data to be hashed, and the resulting output (i.e., message digest) is truncated by selecting an appropriate number of the leftmost bits. For example, if an output of 96 bits is desired, the SHA256 hash function could be used (e.g., because it is available to the application), and the leftmost 96 bits of the output are selected as the message digest, discarding the rightmost 160 bits of the SHA-256 output." On this basis, if we did want to support the larger SHA hashes, we should truncate them and keep the left 160 bits for use with existing DSA keys. Hal Finney From owner-ietf-openpgp@mail.imc.org Sun Apr 3 15:50:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22346 for ; Sun, 3 Apr 2005 15:50:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33JWFWs054390; Sun, 3 Apr 2005 12:32:15 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33JWFBR054389; Sun, 3 Apr 2005 12:32:15 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j33JWEsd054380 for ; Sun, 3 Apr 2005 12:32:14 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 2563D57EBA; Sun, 3 Apr 2005 12:45:40 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? Message-Id: <20050403194540.2563D57EBA@finney.org> Date: Sun, 3 Apr 2005 12:45:40 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ben Laurie writes: > The hash does include the ID of the hash, and hence the signature does. Unfortunately, that doesn't protect against the attack. The ID of SHA-1 is 2 and the ID of RIPEMD-160 is 3. If SHA-1 were broken badly enough it's entirely possible that we could find m1 and m2 such that: SHA1 (2 || m1) == RIPEMD160 (3 || m2). The mere fact that you feed the hash algorithm ID into the hash algorithm doesn't stop you from finding collisions with a different, broken hash algorithm. The situation is different with RSA, where you do: RSA_Sign (Alg ID || Hash). Now, it is impossible to get collisions using two different algorithm ID's because the algorithm ID is outside the hash. Hal From owner-ietf-openpgp@mail.imc.org Sun Apr 3 16:16:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23864 for ; Sun, 3 Apr 2005 16:16:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33JxXd9055904; Sun, 3 Apr 2005 12:59:35 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33JxXM4055903; Sun, 3 Apr 2005 12:59:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33JxVLD055896 for ; Sun, 3 Apr 2005 12:59:32 -0700 (PDT) (envelope-from iang@systemics.com) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j33JxEU03221 for ; Sun, 3 Apr 2005 20:59:25 +0100 X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol Message-ID: <42504BEE.9000303@systemics.com> Date: Sun, 03 Apr 2005 21:02:54 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0 (X11/20050219) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? References: <20050402201614.31E9157EE9@finney.org> <425005AE.5030105@algroup.co.uk> <42501CD7.4070005@algroup.co.uk> <200504031948.22079@zaphod.konrad.silmor.de> <4250389F.4050301@systemics.com> <42503B87.4090509@algroup.co.uk> In-Reply-To: <42503B87.4090509@algroup.co.uk> 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: Content-Transfer-Encoding: 7bit Ben Laurie wrote: > >> Would it be a good idea to put in a statement >> explicitly limiting OpenPGP's view of DSS to be >> SHA1 only? And add a comment perhaps that in the >> light of weaknesses in SHA1, that RSA with a fatter >> digest be used instead as a workaround? > > > The cost of that is that anyone with a DSA key is screwed. Seems like a > last resort to me. Anyone who has a DSA key now is screwed if: * the SHA1 hash is shown to be breached for: - pre-images, or - they have a collision-sensitive signature system, and, * the attacks are within reach by their attackers, and * they cannot change their document format, and * they cannot change to RSA, and * they cannot simply repudiate any false dox, and * they actually use DSA sigs for something important. Seems like a tough list to me. My systems use OpenPGP sigs for real stuff (as opposed to just signing mail because it exists there) and none of the above are even remotely a threat that I can see. Maybe I am screwed, but seeing as I don't see how, I'm willing to run that risk and maybe I'll find out :) I personally don't see much merit in changing the situation until something decent comes along. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ From owner-ietf-openpgp@mail.imc.org Sun Apr 3 16:41:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25099 for ; Sun, 3 Apr 2005 16:41:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33KSHCP057539; Sun, 3 Apr 2005 13:28:17 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33KSHSa057538; Sun, 3 Apr 2005 13:28:17 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j33KSFtZ057527 for ; Sun, 3 Apr 2005 13:28:16 -0700 (PDT) (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 254E733C33; Sun, 3 Apr 2005 21:28:12 +0100 (BST) Message-ID: <42505164.7040807@algroup.co.uk> Date: Sun, 03 Apr 2005 21:26:12 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? References: <20050403193929.0812057EBA@finney.org> In-Reply-To: <20050403193929.0812057EBA@finney.org> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: Content-Transfer-Encoding: 7bit Hal Finney wrote: > On this basis, if we did want to support the larger SHA hashes, we should > truncate them and keep the left 160 bits for use with existing DSA keys. Yes, please. And "doh!" on the downgrade attack. Must think before posting. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 Apr 3 17:36:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28392 for ; Sun, 3 Apr 2005 17:36:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33LMn8e061413; Sun, 3 Apr 2005 14:22:49 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33LMn6X061412; Sun, 3 Apr 2005 14:22:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33LMlRT061403 for ; Sun, 3 Apr 2005 14:22:48 -0700 (PDT) (envelope-from iang@systemics.com) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j33LMVU03537 for ; Sun, 3 Apr 2005 22:22:41 +0100 X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol Message-ID: <42505F72.902@systemics.com> Date: Sun, 03 Apr 2005 22:26:10 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0 (X11/20050219) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? References: <20050403194540.2563D57EBA@finney.org> In-Reply-To: <20050403194540.2563D57EBA@finney.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: Content-Transfer-Encoding: 7bit Hal Finney wrote: > Unfortunately, that doesn't protect against the attack. The ID of SHA-1 > is 2 and the ID of RIPEMD-160 is 3. If SHA-1 were broken badly enough > it's entirely possible that we could find m1 and m2 such that: > > SHA1 (2 || m1) == RIPEMD160 (3 || m2). > > The mere fact that you feed the hash algorithm ID into the hash algorithm > doesn't stop you from finding collisions with a different, broken hash > algorithm. Which would seem to be mildly supportive of locking DSA with SHA1? > The situation is different with RSA, where you do: > > RSA_Sign (Alg ID || Hash). > > Now, it is impossible to get collisions using two different algorithm ID's > because the algorithm ID is outside the hash. And this would seem to suggest that rather than tinkering with DSA, we should prefer a completely new signature algorithm? iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ From owner-ietf-openpgp@mail.imc.org Sun Apr 3 17:37:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28507 for ; Sun, 3 Apr 2005 17:37:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33LP4hB061573; Sun, 3 Apr 2005 14:25:05 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33LP45S061572; Sun, 3 Apr 2005 14:25:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33LP3Y1061566 for ; Sun, 3 Apr 2005 14:25:04 -0700 (PDT) (envelope-from iang@systemics.com) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j33LOeU03545; Sun, 3 Apr 2005 22:24:50 +0100 X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol Message-ID: <42505FF3.7030409@systemics.com> Date: Sun, 03 Apr 2005 22:28:19 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0 (X11/20050219) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Laurie CC: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? References: <20050403193929.0812057EBA@finney.org> <42505164.7040807@algroup.co.uk> In-Reply-To: <42505164.7040807@algroup.co.uk> 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: Content-Transfer-Encoding: 7bit Ben Laurie wrote: > > Hal Finney wrote: > >> On this basis, if we did want to support the larger SHA hashes, we should >> truncate them and keep the left 160 bits for use with existing DSA keys. > > > Yes, please. I'm curious on this point. Other than the fact that "it's broken" why is it that you see it important to repair the DSA in OpenPGP? iang PS: As a point of notation for the RFC, isn't it DSS? Or are we saying that DSA is implemented because it is not quite DSS? -- News and views on what matters in finance+crypto: http://financialcryptography.com/ From owner-ietf-openpgp@mail.imc.org Mon Apr 4 00:37:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26400 for ; Mon, 4 Apr 2005 00:37:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j344NBpY041925; Sun, 3 Apr 2005 21:23:11 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j344NB0o041923; Sun, 3 Apr 2005 21:23:11 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j344NAqi041916 for ; Sun, 3 Apr 2005 21:23:11 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 42B3F57EBA; Sun, 3 Apr 2005 21:36:38 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? Message-Id: <20050404043638.42B3F57EBA@finney.org> Date: Sun, 3 Apr 2005 21:36:38 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ian G writes: > I'm curious on this point. Other than the fact that > "it's broken" why is it that you see it important to > repair the DSA in OpenPGP? I'm not sure if you are asking why we worry about using SHA-1 at all given that the attack is theoretical, or why we don't just abandon DSA keys. For the first question, my main concern is that the SHA-1 attack may get worse so that it becomes computationally feasible to find collisions. If that happens we could be vulnerable to attacks like http://eprint.iacr.org/2005/067 which showed two X.509 certificates with the same hash. The attacks could become even stronger to where different userids could collide. For the second, DSA key users do not presently have the options RSA key users do to move to other hashes. As I argued, the additional risk of giving DSA users more options is not that large. Letting them use other hashes would allow them to continue to use their existing keys and benefit from the signatures they have acquired on those keys. Hal From owner-ietf-openpgp@mail.imc.org Mon Apr 4 10:29:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12805 for ; Mon, 4 Apr 2005 10:29:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34E9RVk030785; Mon, 4 Apr 2005 07:09:27 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34E9RHb030784; Mon, 4 Apr 2005 07:09:27 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j34E9QZU030775 for ; Mon, 4 Apr 2005 07:09:26 -0700 (PDT) (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.6); Mon, 4 Apr 2005 06:42:54 -0700 Received: from [172.16.1.2] ([12.111.6.59]) by keys.merrymeet.com (PGP Universal service); Mon, 04 Apr 2005 06:42:54 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 04 Apr 2005 06:42:54 -0700 In-Reply-To: <20050403193929.0812057EBA@finney.org> References: <20050403193929.0812057EBA@finney.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ietf-openpgp@imc.org From: Jon Callas Subject: Re: How to Calculate Signatures? Date: Mon, 4 Apr 2005 06:44:21 -0700 To: hal@finney.org ("Hal Finney") X-Mailer: Apple Mail (2.619.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 3 Apr 2005, at 12:39 PM, Hal Finney wrote: > For all of these reasons, I am tempted to allow the SHA-2 family with > current DSA keys, as an interim measure pending the move to DSS-2. > > FIPS 180, which defines the SHA family, had a change notice to add > SHA-224, > a truncated form of SHA-256. This document, > -2withchangenotice.pdf>, > describes truncation of hash algorithms on page 73: > > "Some applications may require a hash function with an output size > (i.e., > message digest size) different than those provided by the hash > functions > in this Standard. In such cases, a truncated hash output may be used, > whereby a hash function with a larger output size is applied to the > data to be hashed, and the resulting output (i.e., message digest) is > truncated by selecting an appropriate number of the leftmost bits. For > example, if an output of 96 bits is desired, the SHA256 hash function > could be used (e.g., because it is available to the application), and > the leftmost 96 bits of the output are selected as the message digest, > discarding the rightmost 160 bits of the SHA-256 output." > This is the reason that Beta 1 of PGP 9.0 allowed SHA-256, and did precisely that. However, we decided that that was pushing things, and it's not going to be in Beta 2. Jon From owner-ietf-openpgp@mail.imc.org Mon Apr 4 10:29:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12818 for ; Mon, 4 Apr 2005 10:29:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34E9R5h030791; Mon, 4 Apr 2005 07:09:27 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34E9RbR030790; Mon, 4 Apr 2005 07:09:27 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j34E9QZS030775 for ; Mon, 4 Apr 2005 07:09:26 -0700 (PDT) (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.6); Mon, 4 Apr 2005 06:39:23 -0700 Received: from [172.16.1.2] ([12.111.6.59]) by keys.merrymeet.com (PGP Universal service); Mon, 04 Apr 2005 06:39:23 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 04 Apr 2005 06:39:23 -0700 In-Reply-To: <42505FF3.7030409@systemics.com> References: <20050403193929.0812057EBA@finney.org> <42505164.7040807@algroup.co.uk> <42505FF3.7030409@systemics.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <489a97f77e8d6f130c30363b9bf05f45@callas.org> Content-Transfer-Encoding: 7bit Cc: ietf-openpgp@imc.org, Ben Laurie From: Jon Callas Subject: Re: How to Calculate Signatures? Date: Mon, 4 Apr 2005 06:40:21 -0700 To: Ian G X-Mailer: Apple Mail (2.619.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 3 Apr 2005, at 2:28 PM, Ian G wrote: > PS: As a point of notation for the RFC, isn't it DSS? > Or are we saying that DSA is implemented because it > is not quite DSS? > DSA is the Digital Signature Algorithm. DSS is the Digital Signature Standard. DSS specifies DSA+SHA1 plus operational whatsits. If you use DSA with RIPE/MD-160, for example, it's not DSS. 2440 does cover all of this. Jon From owner-ietf-openpgp@mail.imc.org Mon Apr 4 11:33:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19035 for ; Mon, 4 Apr 2005 11:33:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34FCkxO036867; Mon, 4 Apr 2005 08:12:46 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34FCkJo036866; Mon, 4 Apr 2005 08:12:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34FCg8l036852 for ; Mon, 4 Apr 2005 08:12:43 -0700 (PDT) (envelope-from iang@systemics.com) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j34FCKU08395; Mon, 4 Apr 2005 16:12:31 +0100 X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol Message-ID: <42515A30.3060204@systemics.com> Date: Mon, 04 Apr 2005 16:16:00 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0 (X11/20050219) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: Hal Finney Subject: Re: How to Calculate Signatures? References: <20050404043638.42B3F57EBA@finney.org> In-Reply-To: <20050404043638.42B3F57EBA@finney.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: Content-Transfer-Encoding: 7bit Hal Finney wrote: > Ian G writes: > >>I'm curious on this point. Other than the fact that >>"it's broken" why is it that you see it important to >>repair the DSA in OpenPGP? > > > I'm not sure if you are asking why we worry about using SHA-1 at all given > that the attack is theoretical, or why we don't just abandon DSA keys. I'd say it is an open question, so either or both. > For the first question, my main concern is that the SHA-1 attack > may get worse so that it becomes computationally feasible to find > collisions. If that happens we could be vulnerable to attacks like > http://eprint.iacr.org/2005/067 which showed two X.509 certificates > with the same hash. The attacks could become even stronger to where > different userids could collide. I think now I understand this as more an issue for WoT than documents - is that right? (I think I'm deriving that from the last sentance above...) In that people who have DSA keys and have lots of sigs are faced with losing their 'investment'. OK, I agree that is potentially a larger concern than document sigs as key signing represents something of an institution. > For the second, DSA key users do not presently have the options RSA > key users do to move to other hashes. As I argued, the additional risk > of giving DSA users more options is not that large. Letting them use > other hashes would allow them to continue to use their existing keys > and benefit from the signatures they have acquired on those keys. OK. In risk terms it might not be that high. But in cost terms, it is significant. Any changes to the way signatures have to be dealt with would have to be promulgated through the community, as, if the signature verification wasn't standard and acceptable to all code bases, it loses its value rapidly. So the analysis needs to question not only the risks but also the costs and benefits. The number of people who need to have DSA and keep using their existing keys for signatures seems to be quite small. In order for these people to benefit, they must be able to create the sigs, and everyone else must be able to at least read the sigs. So any change will take a year or two to filter through until there is wide enough distribution of verification, and during that time, I suspect the slow uptake will be over taken by events. To me, I don't see the cost-benefit analysis coming out as favourable; far better to suggest that people use RSA keys if they are really very keen to have the best security in signatures, until the DSS-2 situation settles out. (in the 90s, this would have been a very different situation, as RSA faced patent and cryptoexport problems, so there would have been a group that might have been limited to using DSA.) All IMHO of course! iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ From owner-ietf-openpgp@mail.imc.org Mon Apr 4 11:42:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19778 for ; Mon, 4 Apr 2005 11:42:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34FQ8k8038227; Mon, 4 Apr 2005 08:26:08 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34FQ8ch038226; Mon, 4 Apr 2005 08:26:08 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j34FQ7YC038219 for ; Mon, 4 Apr 2005 08:26:07 -0700 (PDT) (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.6) for ; Mon, 4 Apr 2005 08:26:06 -0700 Received: from [172.16.1.2] ([12.111.6.59]) by keys.merrymeet.com (PGP Universal service); Mon, 04 Apr 2005 08:26:06 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 04 Apr 2005 08:26:06 -0700 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: OpenPGP From: Jon Callas Subject: New Encrypted Data Packet? Date: Mon, 4 Apr 2005 08:27:32 -0700 X-Mailer: Apple Mail (2.619.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit When the Mister-Zuccherato attack came out at the beginning of the year, one of the suggestions that we had was to re-do the encrypted data packet and MDC. It seems that there's not really a lot of consensus to fix it, that merely working around the problem seems to be adequate? Am I right in that perception? Do we want to upgrade it? I still think it's a good idea, myself, particularly since if you want wide deployment of such a thing for the future getting on it now is a good idea. But I would also like to really close out 2440bis, too. (However, the two are not mutually exclusive. We could close out 2440bis and put the upgrades into a followon RFC.) Jon From owner-ietf-openpgp@mail.imc.org Mon Apr 4 12:04:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21810 for ; Mon, 4 Apr 2005 12:04:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34FlL82039987; Mon, 4 Apr 2005 08:47:21 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34FlLLe039986; Mon, 4 Apr 2005 08:47:21 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j34FlKE2039978 for ; Mon, 4 Apr 2005 08:47:20 -0700 (PDT) (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.6); Mon, 4 Apr 2005 08:47:18 -0700 Received: from [172.16.1.2] ([12.111.6.59]) by keys.merrymeet.com (PGP Universal service); Mon, 04 Apr 2005 08:47:18 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 04 Apr 2005 08:47:18 -0700 In-Reply-To: <42515A30.3060204@systemics.com> References: <20050404043638.42B3F57EBA@finney.org> <42515A30.3060204@systemics.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3f5a429b03ed3a28992f269562b05eff@callas.org> Content-Transfer-Encoding: 7bit Cc: ietf-openpgp@imc.org, Hal Finney From: Jon Callas Subject: Re: How to Calculate Signatures? Date: Mon, 4 Apr 2005 08:48:35 -0700 To: Ian G X-Mailer: Apple Mail (2.619.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > So the analysis needs to question not only the risks > but also the costs and benefits. > > The number of people who need to have DSA and keep > using their existing keys for signatures seems to be > quite small. In order for these people to benefit, > they must be able to create the sigs, and everyone > else must be able to at least read the sigs. So > any change will take a year or two to filter through > until there is wide enough distribution of verification, > and during that time, I suspect the slow uptake will > be over taken by events. > > Yup. And the same thing applies to V3 keys as well. I've had vocal complaints from people about their V3 key and how they're upset about losing whatever trust issues there are from it being a decade or more old. I'm not so worried about DSS that I'm going to dump my older key. But I might recommend to someone creating a new key that today, RSA is a better choice because of SHA-1 issues and lack of wide-DSS. But that could change tomorrow or next week. Jon From owner-ietf-openpgp@mail.imc.org Mon Apr 4 12:25:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24281 for ; Mon, 4 Apr 2005 12:25:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34G96RW041468; Mon, 4 Apr 2005 09:09:06 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34G96rJ041467; Mon, 4 Apr 2005 09:09:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtpq1.home.nl (smtpq1.home.nl [213.51.128.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34G95Ho041459 for ; Mon, 4 Apr 2005 09:09:06 -0700 (PDT) (envelope-from edwin@woudt.nl) Received: from [213.51.128.135] (port=44697 helo=smtp4.home.nl) by smtpq1.home.nl with esmtp (Exim 4.30) id 1DIU8N-00059C-Qk; Mon, 04 Apr 2005 18:09:03 +0200 Received: from cc718542-a.ensch1.ov.home.nl ([82.75.235.211]:2952 helo=[10.24.64.4]) by smtp4.home.nl with esmtp (Exim 4.30) id 1DIU8M-0007Ta-Di; Mon, 04 Apr 2005 18:09:02 +0200 Date: Mon, 04 Apr 2005 18:09:02 +0200 From: Edwin Woudt To: Jon Callas , OpenPGP Subject: Re: New Encrypted Data Packet? Message-ID: <657710228390B0569A1FC1D1@[10.24.64.4]> In-Reply-To: References: X-Mailer: Mulberry/4.0.0a7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-AtHome-MailScanner-Information: Neem contact op met support@home.nl voor meer informatie X-AtHome-MailScanner: Found to be clean Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On 4-4-2005 8:27 -0700 Jon Callas wrote: > > When the Mister-Zuccherato attack came out at the beginning of the year, > one of the suggestions that we had was to re-do the encrypted data packet > and MDC. It seems that there's not really a lot of consensus to fix it, > that merely working around the problem seems to be adequate? Am I right > in that perception? Do we want to upgrade it? > > I still think it's a good idea, myself, particularly since if you want > wide deployment of such a thing for the future getting on it now is a > good idea. But I would also like to really close out 2440bis, too. > (However, the two are not mutually exclusive. We could close out 2440bis > and put the upgrades into a followon RFC.) I agree it is a good idea, but not for 2440bis. As there is a workaround, I would say: add a note about the attack and the workaround to 2440bis and get it finished. Redoing the encrypted data packet can then be implemented together with v5 keys and any other hash related changes. This also solves the problem of deciding which implementations support such a new encrypted data packet: just use the new packet for v5 keys, and the old ones for v4 and below. -- Edwin From owner-ietf-openpgp@mail.imc.org Mon Apr 4 12:54:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27709 for ; Mon, 4 Apr 2005 12:54:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34GY17c044352; Mon, 4 Apr 2005 09:34:01 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34GY0C4044351; Mon, 4 Apr 2005 09:34:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34GXxiN044339 for ; Mon, 4 Apr 2005 09:34:00 -0700 (PDT) (envelope-from iang@systemics.com) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j34GXVU09214; Mon, 4 Apr 2005 17:33:42 +0100 X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol Message-ID: <42516D37.5000504@systemics.com> Date: Mon, 04 Apr 2005 17:37:11 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0 (X11/20050219) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Callas CC: OpenPGP Subject: Re: New Encrypted Data Packet? References: In-Reply-To: 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: Content-Transfer-Encoding: 7bit Jon Callas wrote: > > When the Mister-Zuccherato attack came out at the beginning of the year, > one of the suggestions that we had was to re-do the encrypted data > packet and MDC. It seems that there's not really a lot of consensus to > fix it, that merely working around the problem seems to be adequate? Am > I right in that perception? Do we want to upgrade it? > > I still think it's a good idea, myself, particularly since if you want > wide deployment of such a thing for the future getting on it now is a > good idea. But I would also like to really close out 2440bis, too. > (However, the two are not mutually exclusive. We could close out 2440bis > and put the upgrades into a followon RFC.) Close out 2440bis, with no more changes. I think we are well past the point where fiddling around improving things is worth anything. Unless we have a major major break, nothing should change in the protocol, would be my call. (Which would not be to say that Ben's observations over the weekend didn't look extremely useful.) (As to future revisions, I recall in prior times it has been discussed that we wouldn't talk about future changes until 2440bis was closed out.) iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ From owner-ietf-openpgp@mail.imc.org Mon Apr 4 13:04:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28601 for ; Mon, 4 Apr 2005 13:04:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34Ga8qp044526; Mon, 4 Apr 2005 09:36:08 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34Ga8pl044525; Mon, 4 Apr 2005 09:36:08 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j34Ga7bL044518 for ; Mon, 4 Apr 2005 09:36:07 -0700 (PDT) (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 2061233C45; Mon, 4 Apr 2005 17:36:06 +0100 (BST) Message-ID: <42516C7F.3050307@algroup.co.uk> Date: Mon, 04 Apr 2005 17:34:07 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Callas Cc: Ian G , ietf-openpgp@imc.org, Hal Finney Subject: Re: How to Calculate Signatures? References: <20050404043638.42B3F57EBA@finney.org> <42515A30.3060204@systemics.com> <3f5a429b03ed3a28992f269562b05eff@callas.org> In-Reply-To: <3f5a429b03ed3a28992f269562b05eff@callas.org> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: Content-Transfer-Encoding: 7bit Jon Callas wrote: > >> >> So the analysis needs to question not only the risks >> but also the costs and benefits. >> >> The number of people who need to have DSA and keep >> using their existing keys for signatures seems to be >> quite small. In order for these people to benefit, >> they must be able to create the sigs, and everyone >> else must be able to at least read the sigs. So >> any change will take a year or two to filter through >> until there is wide enough distribution of verification, >> and during that time, I suspect the slow uptake will >> be over taken by events. >> >> > > Yup. And the same thing applies to V3 keys as well. I've had vocal > complaints from people about their V3 key and how they're upset about > losing whatever trust issues there are from it being a decade or more old. So what's wrong with signing your V4 key with your V3 key and moving on? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 Apr 4 14:05:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05878 for ; Mon, 4 Apr 2005 14:05:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34HsaGL052023; Mon, 4 Apr 2005 10:54:36 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34Hsa2K052022; Mon, 4 Apr 2005 10:54:36 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j34HsZpF052015 for ; Mon, 4 Apr 2005 10:54:35 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id A9E9F57EBA; Mon, 4 Apr 2005 11:08:05 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? Message-Id: <20050404180805.A9E9F57EBA@finney.org> Date: Mon, 4 Apr 2005 11:08:05 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ian G wrote: > >>I'm curious on this point. Other than the fact that > >>"it's broken" why is it that you see it important to > >>repair the DSA in OpenPGP? > > > Hal Finney wrote: > > I'm not sure if you are asking why we worry about using SHA-1 at all given > > that the attack is theoretical, or why we don't just abandon DSA keys. Ian replied: > I'd say it is an open question, so either or both. > > Hal Finney wrote: > > For the first question, my main concern is that the SHA-1 attack > > may get worse so that it becomes computationally feasible to find > > collisions. If that happens we could be vulnerable to attacks like > > http://eprint.iacr.org/2005/067 which showed two X.509 certificates > > with the same hash. The attacks could become even stronger to where > > different userids could collide. > > I think now I understand this as more an issue for > WoT than documents - is that right? (I think I'm > deriving that from the last sentance above...) In > that people who have DSA keys and have lots of sigs > are faced with losing their 'investment'. The WoT issue related to the 2nd question about maintaining usability of DSA keys. The paragraph above related to the 1st question which was, why are we worrying about the SHA-1 attack at all, given that it is purely theoretical and no one has even exhibited a SHA-1 collision. In the context of that question, it would apply to other situations than just key signatures. Ordinary document signatures could be vulnerable. Alice could prepare a document for Bob to sign, arranging it that there are two versions. It could also apply to RSA users who are continuing to use SHA-1. If the attack worsened, they could be invited to sign someone's key, and then the data being signed could change. Again, keep in mind that these paragraphs answer the question, why are we worried about the attack at all. Focus on that question in reading the paragraphs above. > > For the second, DSA key users do not presently have the options RSA > > key users do to move to other hashes. As I argued, the additional risk > > of giving DSA users more options is not that large. Letting them use > > other hashes would allow them to continue to use their existing keys > > and benefit from the signatures they have acquired on those keys. > > > OK. In risk terms it might not be that high. But > in cost terms, it is significant. Any changes to > the way signatures have to be dealt with would have > to be promulgated through the community, as, if the > signature verification wasn't standard and acceptable > to all code bases, it loses its value rapidly. I agree that if it takes that long for the change to propagate, we are probably better off waiting for NIST to come up with FIPS 186-3 which will specify how to use SHA-2 with DSS. I have a faint hope that they may do something about including a hash algorithm specifier that would make the standard more robust against hash breaks. Even a one octet hash ID similar to what we use in PGP would greatly improve the flexibility. The only reason I hold out this hope is that otherwise I don't see what is taking them so long in releasing this spec. It's been something like two years since they announced that it was imminent. If all they are going to do is to come up with a few (p, q) size recommendations then it shouldn't take that long. If they don't do it, maybe we should think about doing this ourselves, for next gen DSA keys. We could include a one byte hash octet ID at the front of the hash, and make the q size 8 bits bigger. It would mean that we are not fully DSS compliant but as Jon points out we are not quite that way now. Hal From owner-ietf-openpgp@mail.imc.org Mon Apr 4 15:44:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16861 for ; Mon, 4 Apr 2005 15:44:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34JOs2X060003; Mon, 4 Apr 2005 12:24:54 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34JOsJJ060002; Mon, 4 Apr 2005 12:24:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34JOrEI059972 for ; Mon, 4 Apr 2005 12:24:54 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (rwcrmhc14) with ESMTP id <2005040419244901400ahcjse>; Mon, 4 Apr 2005 19:24:49 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j34JOlQr006906 for ; Mon, 4 Apr 2005 15:24:47 -0400 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 j34JOjSh022550 for ; Mon, 4 Apr 2005 15:24:45 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j34JOj9T022549 for ietf-openpgp@imc.org; Mon, 4 Apr 2005 15:24:45 -0400 Date: Mon, 4 Apr 2005 15:24:45 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? Message-ID: <20050404192445.GD22111@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20050404180805.A9E9F57EBA@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050404180805.A9E9F57EBA@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Apr 04, 2005 at 11:08:05AM -0700, "Hal Finney" wrote: > I agree that if it takes that long for the change to propagate, we > are probably better off waiting for NIST to come up with FIPS 186-3 > which will specify how to use SHA-2 with DSS. I think it would take a good long while for the change to propagate. I don't know about other implementations, but there is no support for this in GnuPG. Adding support is trivial, to be sure, but getting however many GnuPG installations to upgrade (with no compatibility with many DSA signatures in the meantime) would be a pretty substantial problem. David From owner-ietf-openpgp@mail.imc.org Mon Apr 4 16:43:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04578 for ; Mon, 4 Apr 2005 16:43:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34KQKFq065125; Mon, 4 Apr 2005 13:26:20 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34KQKOl065123; Mon, 4 Apr 2005 13:26:20 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j34KQJf2065117 for ; Mon, 4 Apr 2005 13:26:19 -0700 (PDT) (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.6); Mon, 4 Apr 2005 13:26:18 -0700 Received: from [12.111.6.63] ([12.111.6.63]) by keys.merrymeet.com (PGP Universal service); Mon, 04 Apr 2005 13:26:18 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 04 Apr 2005 13:26:18 -0700 In-Reply-To: <42516D37.5000504@systemics.com> References: <42516D37.5000504@systemics.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: OpenPGP From: Jon Callas Subject: Re: New Encrypted Data Packet? Date: Mon, 4 Apr 2005 13:27:37 -0700 To: Ian G X-Mailer: Apple Mail (2.619.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > (Which would not be to say that Ben's observations over the > weekend didn't look extremely useful.) > I'm going to look through Ben's suggestions and fold them into a new draft. > (As to future revisions, I recall in prior times it has been > discussed that we wouldn't talk about future changes until > 2440bis was closed out.) > Yeah, but security-related cryptographic changes are always the obvious exception. Jon From owner-ietf-openpgp@mail.imc.org Mon Apr 4 16:50:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06556 for ; Mon, 4 Apr 2005 16:50:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34KVGcT065571; Mon, 4 Apr 2005 13:31:16 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34KVG5J065570; Mon, 4 Apr 2005 13:31:16 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j34KVGOL065564 for ; Mon, 4 Apr 2005 13:31:16 -0700 (PDT) (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.6); Mon, 4 Apr 2005 13:31:15 -0700 Received: from [12.111.6.63] ([12.111.6.63]) by keys.merrymeet.com (PGP Universal service); Mon, 04 Apr 2005 13:31:15 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 04 Apr 2005 13:31:15 -0700 In-Reply-To: <42516C7F.3050307@algroup.co.uk> References: <20050404043638.42B3F57EBA@finney.org> <42515A30.3060204@systemics.com> <3f5a429b03ed3a28992f269562b05eff@callas.org> <42516C7F.3050307@algroup.co.uk> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <10ff14b4c7011f115972f028d0488a6c@callas.org> Content-Transfer-Encoding: 7bit Cc: OpenPGP From: Jon Callas Subject: Re: How to Calculate Signatures? Date: Mon, 4 Apr 2005 13:32:39 -0700 To: Ben Laurie X-Mailer: Apple Mail (2.619.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4 Apr 2005, at 9:34 AM, Ben Laurie wrote: > > So what's wrong with signing your V4 key with your V3 key and moving > on? > > Beats me. People get attached to things. Attachments to things cause all sorts of irrational behavior. I suspect in a lot of cases, people get attached to an old key because of the number or quality of certs. It's similar to the, "I'll never wash that hand again!" response to shaking hands with a celeb. Jon From owner-ietf-openpgp@mail.imc.org Mon Apr 4 17:14:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11602 for ; Mon, 4 Apr 2005 17:14:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34KoFZn067184; Mon, 4 Apr 2005 13:50:15 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34KoFYM067183; Mon, 4 Apr 2005 13:50:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.202.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34KoFSH067170 for ; Mon, 4 Apr 2005 13:50:15 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (sccrmhc14) with ESMTP id <2005040420500701400dlu8ie>; Mon, 4 Apr 2005 20:50:07 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j34KoAQr007276 for ; Mon, 4 Apr 2005 16:50:10 -0400 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 j34Ko7ZC022703 for ; Mon, 4 Apr 2005 16:50:07 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j34Ko7ZJ022702 for ietf-openpgp@imc.org; Mon, 4 Apr 2005 16:50:07 -0400 Date: Mon, 4 Apr 2005 16:50:07 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? Message-ID: <20050404205007.GA22676@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20050404043638.42B3F57EBA@finney.org> <42515A30.3060204@systemics.com> <3f5a429b03ed3a28992f269562b05eff@callas.org> <42516C7F.3050307@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42516C7F.3050307@algroup.co.uk> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Apr 04, 2005 at 05:34:07PM +0100, Ben Laurie wrote: > >Yup. And the same thing applies to V3 keys as well. I've had vocal > >complaints from people about their V3 key and how they're upset about > >losing whatever trust issues there are from it being a decade or more old. > > So what's wrong with signing your V4 key with your V3 key and moving on? Because that would make the V4 key One More Hop Away, of course. ;) David From owner-ietf-openpgp@mail.imc.org Tue Apr 5 08:23:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13963 for ; Tue, 5 Apr 2005 08:23:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35C4wUR053328; Tue, 5 Apr 2005 05:04:58 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35C4wCl053327; Tue, 5 Apr 2005 05:04:58 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j35C4uGO053307 for ; Tue, 5 Apr 2005 05:04:57 -0700 (PDT) (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 21F9D33C33; Tue, 5 Apr 2005 13:04:55 +0100 (BST) Message-ID: <42527EE7.2040503@algroup.co.uk> Date: Tue, 05 Apr 2005 13:04:55 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Callas Cc: OpenPGP Subject: Re: New Encrypted Data Packet? References: In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: Content-Transfer-Encoding: 7bit Jon Callas wrote: > > When the Mister-Zuccherato attack came out at the beginning of the year, > one of the suggestions that we had was to re-do the encrypted data > packet and MDC. It seems that there's not really a lot of consensus to > fix it, that merely working around the problem seems to be adequate? Am > I right in that perception? Do we want to upgrade it? I missed this discussion, I think, and can't seem to find it in the archives. Do you have a refrence? > I still think it's a good idea, myself, particularly since if you want > wide deployment of such a thing for the future getting on it now is a > good idea. But I would also like to really close out 2440bis, too. > (However, the two are not mutually exclusive. We could close out 2440bis > and put the upgrades into a followon RFC.) That sounds like a plan. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 Apr 6 16:39:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02174 for ; Wed, 6 Apr 2005 16:39:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33JYETm054483; Sun, 3 Apr 2005 12:34:14 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33JYEE6054482; Sun, 3 Apr 2005 12:34:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from p15139323.pureserver.info (silmor.de [217.160.219.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33JYDY7054471 for ; Sun, 3 Apr 2005 12:34:13 -0700 (PDT) (envelope-from konrad@silmor.de) Received: from p548c9f4c.dip.t-dialin.net ([84.140.159.76] helo=zaphod.local) by p15139323.pureserver.info with asmtp (Exim 3.35 #1 (Debian)) id 1DIAr5-0000a9-00; Sun, 03 Apr 2005 21:33:56 +0200 From: Konrad Rosenbaum To: Ben Laurie Subject: Re: How to Calculate Signatures? Date: Sun, 3 Apr 2005 21:33:50 +0200 User-Agent: KMail/1.7.2 References: <20050402201614.31E9157EE9@finney.org> <200504031948.22079@zaphod.konrad.silmor.de> <42503B09.8090608@algroup.co.uk> In-Reply-To: <42503B09.8090608@algroup.co.uk> Cc: ietf-openpgp@imc.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1781299.3IFMXeiy2q"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504032133.54375@zaphod.konrad.silmor.de> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --nextPart1781299.3IFMXeiy2q Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sunday 03 April 2005 20:50, Ben Laurie wrote: > Konrad Rosenbaum wrote: > > Simple: you don't. DSA was designed to be used with SHA-1, which is 160 > > bit. Since SHA-1 is theoretically broken (practically will probably > > follow in a few months) one should see what the NIST makes of it. > > Supplanting a broken hash with another hash doesn't make much sense > > with DSA, since it does not contain the ID of the hash (as PKCS#1 does > > for RSA) - so any attacker could find a collission with the broken hash > > and then simply change the hash ID in the signature packet. > > The hash does include the ID of the hash, and hence the signature does. That does not prevent a downgrade attack. Presume the following scenario: The signature S is under Text A with hash algorithm H. The hash is deemed=20 secure. So s contains the number of H and the content of A. The structure looks lik= e=20 this: Text packet A Signature packet S Hash number H signed(Hash_H(H_number || A)) # or something very similiar Now we want the signature to refer to Text B and we know that hash algorith= m=20 X is insecure (and we know how to use that). What we need to do now is we=20 need to find a text C that consists of the the number of X, and B plus some= =20 "random" that is chosen in a way that does not distort the meaning (eg. a=20 "geek code block" below the actual eMail text). The structure will look=20 like: Text packet C ( =3D B || "random") Signature packet S' Hash number X signed(Hash_H(H_number || A)) =3D=3D signed(Hash_X(X_number || C)) =2E..and that all because a weak Hash X will enable us to find a text that= =20 creates the same hash sum in X that we want to supplant for a hash sum of H= =20 =2D regardless of whether we hash the hash number, a "magic" code or my gra= nd=20 mothers birthday into it. MD5 is already beaten down to 33 bit, it is only a question of time till=20 SHA-1 is there as well (granted, we'll probably have some months left).=20 Currently we are only save because there is no 160-bit Hash in OpenPGP that= =20 is vulnerable enough to make the attack worthwhile. The days of DSA with a 160-bit p are counted. Period. Konrad PS.: please view my DSA signature on this mail as my last action of respect= =20 to DSA. It was a good fellow... ;-) --nextPart1781299.3IFMXeiy2q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBCUEUiClt766LaIH0RAhpRAJ9lasC4YLMj6JEH189fdwKlqbZNtACfbwCY 7hPM24b+qlIBOpvOY6ub7Mo= =4hJF -----END PGP SIGNATURE----- --nextPart1781299.3IFMXeiy2q-- From email.annuaire@tiscali.fr Mon Apr 11 13:15:45 2005 Received: from mail.libertysurf.net (mx-out.tiscali.fr [213.36.80.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01174 for ; Mon, 11 Apr 2005 13:15:45 -0400 (EDT) From: email.annuaire@tiscali.fr Received: from acps-dhsenyia71 (212.83.172.27) by mail.libertysurf.net (7.1.026) id 41A46BF5024A977F; Mon, 11 Apr 2005 19:13:29 +0200 Message-ID: <41A46BF5024A977F@mail08.pds.libertysurf.fr> (added by postmaster@libertysurf.fr) To: Reply-To: Subject: 2005 Date: Mon, 11 apr 2005 17:39:12 +0200 Importance: normal Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--=9373-svsh-1342-vhmd" ----=9373-svsh-1342-vhmd Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Multiply your customers by contacting the good address: CD DOCTORS Version 2005: to find your future customers: 14 directories o= n CD Europe US Asie (1.708.093 e-mail address 388.265 adress posta= l) 14 Directories on CD email.medecin1@tiscali.fr Version 2005: Pour trouver vos futurs clients: 14 annuaires sur = 1 cd Annuaire Email M=E9decins CD DOCTORS Europe US Asie (1.708.093 email adresses 388.265 adresses postal= es) 14 Annuaires sur 1 CD email.medecin1@tiscali.fr ----=9373-svsh-1342-vhmd Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: Quoted-Printable

Multiply your custome= rs by contacting the good address:
CD DOCTORS
Version 2005: to find your future customers: 14 directories on CD
Europe US Asie (1.708.093 e-mail address 388.265 adress postal)
14 Directories on CD

email.medecin1@tiscali.fr

Version 2005: Pour tr= ouver vos futurs clients: 14 annuaires sur 1 cd
Annuaire Email Médecins CD DOCTORS
Europe US Asie (1.708.093 email adresses = 388.265 adresses postales)
14 Annuaires sur 1 CD

email.medecin1@tiscali.fr

 

 

----=9373-svsh-1342-vhmd-- From owner-ietf-openpgp@mail.imc.org Tue Apr 12 19:03:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22063 for ; Tue, 12 Apr 2005 19:03:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3CMliH5062452; Tue, 12 Apr 2005 15:47:44 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3CMliJ9062451; Tue, 12 Apr 2005 15:47:44 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3CMlgEY062443 for ; Tue, 12 Apr 2005 15:47:42 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id AABE557EE8; Tue, 12 Apr 2005 14:58:27 -0700 (PDT) To: ietf-openpgp@imc.org Subject: OpenPGP Signatures Incorporating X.509 Certificates Message-Id: <20050412215827.AABE557EE8@finney.org> Date: Tue, 12 Apr 2005 14:58:27 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: OpenPGP Signatures Incorporating X.509 Certificates Copyright 2005 by PGP Corporation. All Rights Reserved. Abstract This document is published to document the procedure used by commercial PGP [PGP] products up through version 9 for incorporating X.509 [X.509-00] certificates into OpenPGP [RFC2440] format signatures, and for cryptographically validating such signatures. It describes only the format and methods needed to import X.509 certificates, and to validate key signature packets containing such certificates. It does not deal with storage and implementation questions. 1. Introduction The OpenPGP [RFC2440] specification describes data formats for representing public keys, userids, and key signatures that cryptographically bind keys, userids, and fields from signature packets. It further describes the cryptographic procedures used to sign and verify the signature packets which comply with that specification. An alternative set of standards and formats is widely used in network applications for communicating cryptographic bindings of public keys and associated name data, based on the X.509 [X.509-00] certificate format. X.509 certificates communicate similar information to OpenPGP key, userid and signature packets. However, the details of the data formats are incompatible and it is not possible to transform X.509 certificates into sequences of OpenPGP packets that can be cryptographically validated by the mechanisms described in RFC2440. This document presents an alternative mechanism to allow X.509 certificates to be imported into OpenPGP data formats and cryptographically validated. It describes both the detailed data formats used to import and represent X.509 data in OpenPGP packets, and the procedures necessary to cryptographically validate such X.509 based OpenPGP signatures. These mechanisms allow the cryptographic infrastructure based on X.509 certificates to be imported and used in the context of OpenPGP messages and data. 1.1. Overview of Importing Certificates X.509 certificates are imported into OpenPGP signature packets in three steps, which will be described in more detail in section 2. [Page 1] -2- First, the numeric key material (the RSA modulus and exponent, and corresponding values for other key types) is used to construct an OpenPGP key packet. Second, the name field(s) of the X.509 certificate are used to construct an OpenPGP userid packet. And third, an OpenPGP signature packet is constructed from the certificate. Some fields of the OpenPGP signature packet are set from corresponding fields in the certificate. In addition, the certificate itself is inserted as a whole into the OpenPGP signature packet, in a signature subpacket. During the import process, the keyring is searched for a pre-existing OpenPGP key which matches the numeric key material being imported. If so, the userid and signature are added to the existing key. This also requires checking to see whether there is already a userid on the key matching the userid constructed by the import process; if so, the new signature packet is added to the pre-existing userid. This allows OpenPGP keys to hold a combination of X.509 based signatures and regular OpenPGP signatures. Once the X.509 certificate has been imported, the resulting OpenPGP keys and userids can be used interchangeably with regular OpenPGP keys. The only difference is in the format of the X.509 signatures. 1.2. Validating Certificates Cryptographically validating an X.509 signature packet requires a special process. It is not possible to use the normal OpenPGP signature validation process because no cryptographically valid signature exists over the OpenPGP data. Instead, a two step process is used. First, the X.509 certificate is tested for consistency with the OpenPGP packets. This requires extracting the X.509 certificate from the OpenPGP signature packet. It is then put through a process similar to when it was first imported into the OpenPGP format per this specification, to create temporary OpenPGP key, userid and signature packets from the certificate data. These temporary packets are compared with the OpenPGP key, userid and signature packets from the OpenPGP key holding the X.509 certificate signature. There must be an exact, byte-for-byte match between the two sets of packets for this step of the validation to be considered successful. This guarantees that the material in the OpenPGP packets is consistent with the contents of the X.509 certificate. Second, the X.509 certificate is itself cryptographically validated. This is a straightforward matter of computing the hash over the "to be signed" portion of the certificate and running the cryptographic signature verification algorithm using that hash and using the [Page 2] -3- signature field of the certificate. This step requires that the cryptographic key material of the issuing certificate must be present; for example, it may be available on the keyring as an OpenPGP key if it was previously imported into the OpenPGP format. Together, these two steps assure that the issuing key issued the certificate, and that the resulting OpenPGP key, userid and signature packets faithfully reflect the information put into the certificate by the issuer. On this basis the X.509 certificate signature is considered to be valid. 1.3. Identifying Signing Keys The OpenPGP specification uses keyids to link signatures to the keys which issued them. X.509 uses a different method, based on the issuer name. As a result, X.509 signature packets do not have keyid subpackets. Instead, to find the key which issued an X.509 signature packet it is necessary to extract the X.509 certificate, parse it to extract the issuer field, and then to search the other X.509 signature packets on the keyring for an X.509 certificate whose subject name matches. The key to which that certificate signature is attached is the one which issued the X.509 signature being validated. 2. Importing X.509 Certificates Note that the rules and procedures below for importing an X.509 certificate must be followed precisely by any compatible implementation. This is because checking the cryptographic validity of an X.509 signature requires extracting the certificate from the X.509 signature and repeating the import process, comparing the results byte for byte with the OpenPGP key, userid and signature packets. Any variation between implementations, even seemingly inconsequential ones like changing the order of various subpackets or userid fields, will cause this bytewise comparison to fail and cause the signature to be treated as invalid. 2.1. Creating the Key Packet The first step in importing an X.509 certificate into OpenPGP is to create an OpenPGP key packet which includes the numeric key material from the certificate. X.509 certificates holding RSA, DSS or ElGamal keys may be imported. The data is extracted from the SubjectPublicKeyInfo field of the certificate and converted into OpenPGP public key format. OpenPGP public key packets contain four additional pieces of information. First, they have a version number. Version 3 and 4 packets are presently in use. Second, they have a creation date [Page 3] -4- field. Third, version 3 packets have a field encoding the duration until key expiration. And fourth, they hold an algorithm identifier for the public key algorithm the key represents. In importing the key, the keyring should be searched for an existing key whose numeric key material matches that of the certificate being imported. If a match is found, that key packet is used as the basis for filling in these other fields. This uses the version number, creation date and expiration period fields from the pre-existing key. If no matching key exists, the new OpenPGP packet is created with version 4, and the public key algorithm field is set from the type of public key in the X.509 certificate. V4 keys do not have expiration periods, so that leaves only the creation date. X.509 certificates normally do not specify a key creation date, only a certificate creation date. A somewhat complicated mechanism is available to facilitate setting a reliable key creation date field in the OpenPGP public key packet. This mechanism is intended to facilitate allowing pre-existing OpenPGP keys to acquire X.509 certificates on their key material. These X.509 certificates could then be distributed and imported into other users' OpenPGP compatible software. In order to keep the resulting OpenPGP keys compatible with the ones which were certified, OpenPGP encodes the key creation date into the X.509 certificate request which is sent to be certified. With a cooperative certificate issuing authority (CA), the key creation date is then embedded in the certificate in a special format. This ensures that when other users import the X.509 certificate, they will create the OpenPGP key with the same creation date that the original key had. This is especially important in case the importing user did not previously have a copy of the original OpenPGP key, but acquired it by importing the X.509 certificate; and then he later imports the original OpenPGP key as a conventional-format OpenPGP key, rather than as a certificate. Without the special mechanism for handling creation dates, the creation dates wouldn't match, and the keyids of the two keys would be different, making them appear to be two different keys. Putting the key creation date into the X.509 certificate helps to insure that importing the certificate will correctly reconstruct the OpenPGP key. Two alternative mechanisms are available for encoding this information into the X.509 certificate. The preferred mechanism is a custom extension created for this purpose. The OID for this extension is (1 3 6 1 4 1 3401 8 1 1), encoded as the octet string {0x06, 0x0a, 0x2b, 0x06, 0x01, 0x04, 0x01, 0x9a, 0x49, 0x08, 0x01, [Page 4] -5- 0x01}. The data for the extension is defined as: PGPExtension ::= SEQUENCE { version Version DEFAULT v1, keyCreation Time } The OpenPGP key creation data is stored in X.509 Time format, the same format used for the notBefore and notAfter subfields of the certificate validity field. This is converted to the four byte OpenPGP time format specified in RFC2440 and used as the key creation field in the new OpenPGP key packet. The second method for encoding the OpenPGP creation date into an X.509 certificate is used if the custom extension is not supported by the CA. It stores the OpenPGP creation date in a field in the subject Distinguished Name. It uses either an Organizational Unit or Description field in the subject name. The creation date is stored in one of these field types, with associated data in the format "PGPKeyCreation=0x........" where the dots are replaced by 8 hex digits that encode the creation date in OpenPGP time format. If such a field is found, the hex value after "0x" is converted to binary data and used as the creation date in the OpenPGP key packet. On import, the certificate is searched sequentially for these two possible encodings of creation date. The first match is used, although typically there would not be more than one such encoding present in a certificate. Because subject name comes before extensions, the subject name fields are checked first, then the extensions. If none of these methods work to find an OpenPGP creation date, as will typically be the case on a certificate which was created via X.509 mechanisms and not by certifying an OpenPGP key, the certificate notBefore field is converted to OpenPGP time format and used as the key creation date. 2.2. Creating the UserID Packet Two alternative methods are available to create an OpenPGP UserID packet from an X.509 certificate, the short name format and the long name format. The short name format is used if the conditions described below are met, otherwise the long name format is used. The short name format for the userid is of the form "common_name ", a widely used format for OpenPGP userids. For this format to be used it must be possible to extract a common name and email address from the certificate. The common name must come from [Page 5] -6- the subject name field. The email address may come from either the subject name, where its OID is (1 2 840 113549 1 9 1), or from a SubjectAlternativeName field in an extension, where the choice type is rfc822Name. As a special case, the short name format is also used if the subject name has only a single field, which is an email address, but there is no common name. In that case the userid is created as "". If it is not possible to satisfy these conditions for creating the userid in the short format, a long format is used. This is a slight modification of "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names" [RFC2253], applied to the subject name field of the certificate. RFC2253 puts the DN fields into reverse order, but this specification modifies that rule somewhat. The common name field (if present) is always output first, before the other fields, to improve readability. Also, any name field corresponding to the special OpenPGP key creation date field described in the section 2.1, if present, is skipped and is not output. The only DN field names which get converted into printable form for the userid are CN, C, L, ST, STREET, O, OU and EMAIL. Other fields in the DN are ignored when converting to an OpenPGP userid. Note that any SubjectAlternativeName extensions are not used when outputting a long format name. Only the fields from the subject name of the certificate are put into the OpenPGP userid packet. If no fields from the list above are found in the DN, the userid packet is created with the text "(Unknown X509 name)". 2.3. Creating the Signature Packet Creating the OpenPGP signature packet from an X.509 certificate involves two steps. The first is to include the certificate itself, in total, into a new subpacket of the OpenPGP signature packet. The second is to set up the various signature packet fields and subpackets which encode the supported semantics of the X.509 certificate. 2.3.1. X.509 Signature Subpacket Format This specification defines a new OpenPGP subpacket type. It uses subpacket type 100, defined in RFC2440 as within the private range of subpackets. The first byte of the subpacket is 1, indicating that the type of the private-range subpacket is an X.509 certificate. The [Page 6] -7- next two bytes are major and minor version numbers. The major version is 1 for all compatible implementations of this specification. The minor version reflects changes in the detailed rules for how X.509 certificates are converted to OpenPGP keys. The current minor version is 4, and this value should be used in newly created certificate subpackets. When verifying an X.509 certificate signature, the minor version number must be parsed and used to guide the conversion process. Since part of the verification involves checking for consistency between the X.509 certificate and the OpenPGP packets, any differences would cause the signature to be treated as invalid. When changes are made for how this conversion is done, the minor version must be upgraded. The only operational difference at this point is between minor version 4 vs. earlier minor version numbers of 3 or less. There is a change to the public key algorithm field used in the signature packet, as described below. No other changes presently exist based on minor version number, for importing signature, userid or key packets. The remaining data in the certificate subpacket is the X.509 certificate itself. Its length is determined implicitly by the subpacket length minus the fields already described. X.509 certificates are self-delimiting, and the certificate must end at the end of the data range in the subpacket allocated to hold it. 2.3.2. Other Signature Fields In addition to inserting the certificate bodily into a new subpacket, other fields of the OpenPGP signature packet are created to be consistent with the data from the certificate. Note that it is necessary to follow the description in this section precisely in order to create X.509 signature packets which will interoperate with other software implementing this specification. No flexibility is possible in the set of signature packets created, the contents of the packet, or the ordering of the packets. This consistency is necessary in order for the byte-for-byte packet comparison to succeed when signatures are verified. OpenPGP signature packets created from X.509 certificates are version 4 packets. The signature type field is 0x10, "generic certification of a user id and public key packet". The next field is the public key algorithm, which guides the signature verification process. As described in the introduction, X.509 signature packets cannot be cryptographically verified by the normal OpenPGP verification rules. To flag this fact and make sure an OpenPGP implementation of this [Page 7] -8- specification does not try to verify the packet, a reserved value is used for the public key algorithm field. This is the one place the minor version number from the certificate subpacket is used. For minor versions 0-3, the reserved value is 0. For minor version 4, the reserved value is 100, which is in the reserved range for RFC2440. In either case, it is meant to indicate that the regular OpenPGP certificate verification process will not work, and to prevent noncompliant OpenPGP implementations from attempting to verify signatures created by this specification. The next field in the V4 signature packet is the hash algorithm ID, which is set to the hash algorithm from the X.509 certificate. If a certificate uses a public key or hash algorithm not recognized by RFC2440, it is not allowed to be imported per this specification. The next part of the signature packet contains the so-called hashed subpackets. Note that these subpackets are not actually hashed, in an X.509 signature packet; rather, their validity is verified based on comparison with the X.509 certificate, which does get cryptographically hashed and verified. Several such subpackets are created, based on X.509 certificate data. The order of these subpackets is significant in that the certificate verification process described in section 1.2 will attempt to re-convert the X.509 certificate into an OpenPGP signature packet and do a byte-for-byte match between the re-converted data and the original signature data. The packets must be identical for the X.509 signature to be considered valid. The first subpacket is signature creation time, subpacket ID 2. This is taken from the notBefore subfield of the validity field in the certificate, and converted to OpenPGP time format. The second subpacket is signature expiration time, subpacket ID 3. This is taken from the notAfter subfield of the validity field in the certificate, and converted to OpenPGP time format. The signature creation time is then subtracted, because OpenPGP actually stores the signature validity duration in seconds in the expiration time subpacket. Next is an optional trust signature subpacket, ID 5. It is used if the imported certificate has a BasicConstraints extension with the boolean cA field being true, representing a CA certificate. The trust signature subpacket holds two bytes. The first is the trust "level", which means the depth to which trust is delegated. This is set based on any PathLenConstraint field of the BasicConstraints extension. If there is no PathLenConstraint, the level value stored in the trust packet is the maximum value of 255. If there is a [Page 8] -9- PathLenConstraint value in the certificate, the trust level stored is equal to that integer value, plus one (then truncated to one byte). The trust packet also has a second byte representing the validity of the trust being extended, which is set to 120, meaning complete validity. Next there is an optional a key flags subpacket, ID 27. It is used if there is a KeyUsage extension in the imported certificate, to encode any key usage restrictions. Not all bits in the KeyUsage extension are recognized and converted by this specification, but the key flags subpacket is created even if none of the bits are recognized, in which case the key flags subpacket will be output with a flag value of zero. The bits which are recognized, and the corresponding OpenPGP key flags values, are as follows: keyCertSign ---> flag 0x01, key can certify other keys cRLSign ---> flag 0x01, key can certify other keys digitalSignature ---> flag 0x02, key can sign data nonRepudiation ---> flag 0x02, key can sign data keyEncipherment ---> flags 0x14, key can encrypt communications and key can encrypt storage dataEncipherment ---> flags 0x14, key can encrypt communications and key can encrypt storage keyAgreement ---> flags 0x14, key can encrypt communications and key can encrypt storage All other key flag bits in the four byte field are output as zero. The last subpacket output is the X.509 certificate subpacket, ID 100, as described in section 2.3.1. above. Following the hashed data subpackets in the signature packet are the unhashed packets. No such packets are used when importing an X.509 signature, so the length of the unhashed region must be zero. Note in particular that X.509 signature packets do not have an issuing keyid field. This is because X.509 certificates refer to their issuer by name, rather than by keyid, as discussed in section 1.3. Next comes a two byte checksum, which is set to two bytes of zero. Finally there is the MPI data for the OpenPGP signature. No MPI data is used for signatures in this specification, so a dummy MPI value of 1 is stored, represented as the three byte sequence 0, 1, 1. That ends the OpenPGP signature packet. [Page 9] -10- 3. References [PGP] PGP Corporation, http://www.pgp.com. [RFC2253] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December, 1997. [RFC2440] J. Callas, L. Donnerhacke, H. Finney, R. Thayer, "OpenPGP Message Format", RFC 2440, November, 1998. [X.509-00] ITU-T. Recommendation X.509: The Directory - Authentication Framework. 2000. [Page 10] From owner-ietf-openpgp@mail.imc.org Wed Apr 13 17:32:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08840 for ; Wed, 13 Apr 2005 17:32:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DL3RG4094850; Wed, 13 Apr 2005 14:03:27 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DL3RKB094849; Wed, 13 Apr 2005 14:03:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DL3Q7t094843 for ; Wed, 13 Apr 2005 14:03:26 -0700 (PDT) (envelope-from iang@systemics.com) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j3DL3EU25929 for ; Wed, 13 Apr 2005 22:03:19 +0100 X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol Message-ID: <425D89E7.2000705@systemics.com> Date: Wed, 13 Apr 2005 22:06:47 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OpenPGP Subject: AES/SHA1/Must/Should 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: Content-Transfer-Encoding: 7bit Is the draft 12 the current working text? I noticed it expires in another month. Did we resolve the question of whether to make changes to the MUST / SHOULD algorithms? I'm all in favour of saying AES-128 is now the MUST and triple DES becomes the SHOULD. In practice, most implementations would be there already as they will have done both (Cryptix Java is, and so is Perl's Crypt::OpenPGP). SHA is harder as we've discussed. If we agree to leave matters lie, then here's one potential addition to 13 (I cribbed the wording from the other points, but any wording could be considered....): 13. Security Considerations - suggested addition * In October 2004, the Shandong university team of Wang, Yin, Yu announced attacks on reduced rounds of SHA1. Collisions are predicted in 2^69 steps rather than the full 2^80 steps. For this reason SHA1 is widely expected to be deprecated in coming years. Implementors may prefer to move to wider length SHA algorithms as appropriate. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ From owner-ietf-openpgp@mail.imc.org Wed Apr 13 18:03:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10718 for ; Wed, 13 Apr 2005 18:03:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DLqFpl098125; Wed, 13 Apr 2005 14:52:15 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DLqFuc098124; Wed, 13 Apr 2005 14:52:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DLqFku098116 for ; Wed, 13 Apr 2005 14:52:15 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (sccrmhc11) with ESMTP id <2005041321520901100251l9e>; Wed, 13 Apr 2005 21:52:09 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j3DLqTQr030003 for ; Wed, 13 Apr 2005 17:52:29 -0400 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 j3DLpjwf013743 for ; Wed, 13 Apr 2005 17:51:45 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j3DLpjiB013742 for ietf-openpgp@imc.org; Wed, 13 Apr 2005 17:51:45 -0400 Date: Wed, 13 Apr 2005 17:51:45 -0400 From: David Shaw To: OpenPGP Subject: Re: AES/SHA1/Must/Should Message-ID: <20050413215144.GB13198@jabberwocky.com> Mail-Followup-To: OpenPGP References: <425D89E7.2000705@systemics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425D89E7.2000705@systemics.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Apr 13, 2005 at 10:06:47PM +0100, Ian G wrote: > > Is the draft 12 the current working text? I noticed it > expires in another month. > > Did we resolve the question of whether to make changes > to the MUST / SHOULD algorithms? > > I'm all in favour of saying AES-128 is now the MUST and > triple DES becomes the SHOULD. In practice, most > implementations would be there already as they will have > done both (Cryptix Java is, and so is Perl's Crypt::OpenPGP). I don't have a very strong feeling one way or another on making AES-128 a MUST. However, I have a very strong feeling against changing the status of 3DES. There are too many years and too many implementations where 3DES is the algorithm of last resort, and changing 3DES to a SHOULD necessitates a different algorithm of last resort. We cannot change that overnight. By all means, add some new MUSTs to start the algorithm changing process, but 3DES needs to stay as MUST as well for a good long time. I recommend not making any change in default algorithms for 2440bis. If and when we take up v5 keys, we can easily set the cipher of last resort for v5 keys to something other than 3DES. David From owner-ietf-openpgp@mail.imc.org Fri Apr 15 14:13:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27990 for ; Fri, 15 Apr 2005 14:13:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FHdakb093970; Fri, 15 Apr 2005 10:39:36 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FHdaku093969; Fri, 15 Apr 2005 10:39:36 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3FHdZ7U093956 for ; Fri, 15 Apr 2005 10:39:35 -0700 (PDT) (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.6) for ; Fri, 15 Apr 2005 10:39:33 -0700 Received: from [63.73.97.189] ([63.73.97.189]) by keys.merrymeet.com (PGP Universal service); Fri, 15 Apr 2005 10:39:33 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 15 Apr 2005 10:39:33 -0700 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <20050413215144.GB13198@jabberwocky.com> References: <425D89E7.2000705@systemics.com> <20050413215144.GB13198@jabberwocky.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <548be0d06c065c0b94d1843f25afe9f3@callas.org> Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: AES/SHA1/Must/Should Date: Fri, 15 Apr 2005 10:41:12 -0700 To: OpenPGP X-Mailer: Apple Mail (2.619.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 13 Apr 2005, at 2:51 PM, David Shaw wrote: > There are too many years and too many implementations where 3DES is > the algorithm of last resort, and changing 3DES to a SHOULD > necessitates a different algorithm of last resort. We cannot change > that overnight. > > By all means, add some new MUSTs to start the algorithm changing > process, but 3DES needs to stay as MUST as well for a good long time. > I understand how you feel. I feel the same way. However, I have a question to ask: When? How long is "a good long time"? Forever? The counter-argument is that there is no better time than now. The reasons to keep 3DES there only get stronger as time goes on. This problem becomes worse with time, not better. Jon From owner-ietf-openpgp@mail.imc.org Fri Apr 15 15:22:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06755 for ; Fri, 15 Apr 2005 15:22:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FJ6CGS099741; Fri, 15 Apr 2005 12:06:12 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FJ6CFv099740; Fri, 15 Apr 2005 12:06:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FJ6BOR099733 for ; Fri, 15 Apr 2005 12:06:11 -0700 (PDT) (envelope-from iang@systemics.com) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j3FJ5nU07666 for ; Fri, 15 Apr 2005 20:06:05 +0100 X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol Message-ID: <42601158.7040908@systemics.com> Date: Fri, 15 Apr 2005 20:09:12 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OpenPGP Subject: Re: AES/SHA1/Must/Should References: <425D89E7.2000705@systemics.com> <20050413215144.GB13198@jabberwocky.com> <548be0d06c065c0b94d1843f25afe9f3@callas.org> In-Reply-To: <548be0d06c065c0b94d1843f25afe9f3@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: Content-Transfer-Encoding: 7bit > On 13 Apr 2005, at 2:51 PM, David Shaw wrote: > >> There are too many years and too many implementations where 3DES is >> the algorithm of last resort, and changing 3DES to a SHOULD >> necessitates a different algorithm of last resort. We cannot change >> that overnight. I think there is a big difference between what the implementations do, and what the standard says. If there is an issue in the short term, then implementations are free to ignore the standard. It's not as if anyone ever lost a contract because they couldn't prove absolute compliance with the standard. In this happy state of affairs, I am not sure why we cannot (as a standards body) wiggle our fingers with fierceness about 3DES and have the implementations broadly ignore us for many months or even years... Is the "algorithm of last resort" actually specified in the draft RFC, is it? If an implementation chooses 3DES as its algorithm of last resort, that doesn't need to change. It just seems likely that in a couple of years or so, AES would make more sense for that decision. > I recommend not making any change in default algorithms for 2440bis. > If and when we take up v5 keys, we can easily set the cipher of last > resort for v5 keys to something other than 3DES. The issue I see with that is that this group has been working for ... 8 years? and hasn't got a standard out. I'd love to see some action on a v5 key layout, but I don't have much hope. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ From owner-ietf-openpgp@mail.imc.org Fri Apr 15 16:59:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24652 for ; Fri, 15 Apr 2005 16:59:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FKX8PE007241; Fri, 15 Apr 2005 13:33:08 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FKX8Lu007240; Fri, 15 Apr 2005 13:33:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FKX8mV007232 for ; Fri, 15 Apr 2005 13:33:08 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (sccrmhc12) with ESMTP id <200504152033020120052fkfe>; Fri, 15 Apr 2005 20:33:02 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j3FKXRQr007871 for ; Fri, 15 Apr 2005 16:33:27 -0400 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 j3FKWWjL028321 for ; Fri, 15 Apr 2005 16:32:32 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j3FKWW9u028320 for ietf-openpgp@imc.org; Fri, 15 Apr 2005 16:32:32 -0400 Date: Fri, 15 Apr 2005 16:32:32 -0400 From: David Shaw To: OpenPGP Subject: Re: AES/SHA1/Must/Should Message-ID: <20050415203232.GB28006@jabberwocky.com> Mail-Followup-To: OpenPGP References: <425D89E7.2000705@systemics.com> <20050413215144.GB13198@jabberwocky.com> <548be0d06c065c0b94d1843f25afe9f3@callas.org> <42601158.7040908@systemics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42601158.7040908@systemics.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Apr 15, 2005 at 08:09:12PM +0100, Ian G wrote: > > > >On 13 Apr 2005, at 2:51 PM, David Shaw wrote: > > > >>There are too many years and too many implementations where 3DES is > >>the algorithm of last resort, and changing 3DES to a SHOULD > >>necessitates a different algorithm of last resort. We cannot change > >>that overnight. > > > I think there is a big difference between what the > implementations do, and what the standard says. If > there is an issue in the short term, then implementations > are free to ignore the standard. It's not as if anyone > ever lost a contract because they couldn't prove absolute > compliance with the standard. > > In this happy state of affairs, I am not sure why we > cannot (as a standards body) wiggle our fingers with > fierceness about 3DES and have the implementations > broadly ignore us for many months or even years... If we mean it, put it in the standard. If we don't, then don't put it in the standard. No need for wink-wink with implementations. This is a pretty straightforward issue. Even before 2440, in 2440, and until today, 3DES has been the algorithm of last resort. There are a significant number of deployed systems that base their behavior on that design. You can't declare a flag day after which the algorithm of last resort is different without causing incompatibility. Where comes this desire to remove 3DES? Are there any new attacks that raise the desire to dispose of it? The only complaint I can see with 3DES is that it's *slow*. Not that it's insecure. > Is the "algorithm of last resort" actually specified > in the draft RFC, is it? Section 12.1: Since TripleDES is the MUST-implement algorithm, if it is not explicitly in the list, it is tacitly at the end. However, it is good form to place it there explicitly. Note also that if an implementation does not implement the preference, then it is implicitly a TripleDES-only implementation. An implementation MUST NOT use a symmetric algorithm that is not in the recipient's preference list. When encrypting to more than one recipient, the implementation finds a suitable algorithm by taking the intersection of the preferences of the recipients. Note that the MUST-implement algorithm, TripleDES, ensures that the intersection is not null. The implementation may use any mechanism to pick an algorithm in the intersection. > If an implementation > chooses 3DES as its algorithm of last resort, that doesn't > need to change. It just seems likely that in a couple > of years or so, AES would make more sense for that decision. So add AES as a MUST implement to get it out there, and then in a few years we can revisit what the algorithm of last resort is. Just leave poor 3DES alone. David From owner-ietf-openpgp@mail.imc.org Fri Apr 15 17:18:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26906 for ; Fri, 15 Apr 2005 17:18:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FL2tTG009318; Fri, 15 Apr 2005 14:02:55 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FL2tWK009317; Fri, 15 Apr 2005 14:02:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FL2tUK009305 for ; Fri, 15 Apr 2005 14:02:55 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (rwcrmhc14) with ESMTP id <2005041521024701400hh043e>; Fri, 15 Apr 2005 21:02:47 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j3FL33Qr007982 for ; Fri, 15 Apr 2005 17:03:03 -0400 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 j3FL28Af028369 for ; Fri, 15 Apr 2005 17:02:08 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j3FL28Ma028368 for ietf-openpgp@imc.org; Fri, 15 Apr 2005 17:02:08 -0400 Date: Fri, 15 Apr 2005 17:02:08 -0400 From: David Shaw To: OpenPGP Subject: Re: AES/SHA1/Must/Should Message-ID: <20050415210208.GC28006@jabberwocky.com> Mail-Followup-To: OpenPGP References: <425D89E7.2000705@systemics.com> <20050413215144.GB13198@jabberwocky.com> <548be0d06c065c0b94d1843f25afe9f3@callas.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <548be0d06c065c0b94d1843f25afe9f3@callas.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Apr 15, 2005 at 10:41:12AM -0700, Jon Callas wrote: > > On 13 Apr 2005, at 2:51 PM, David Shaw wrote: > > >There are too many years and too many implementations where 3DES is > >the algorithm of last resort, and changing 3DES to a SHOULD > >necessitates a different algorithm of last resort. We cannot change > >that overnight. > > > >By all means, add some new MUSTs to start the algorithm changing > >process, but 3DES needs to stay as MUST as well for a good long time. > > > > I understand how you feel. I feel the same way. However, I have a > question to ask: > > When? How long is "a good long time"? Forever? I'd say "a good long time" is more than 2, but less than 5 years. I base this on the surprising number of requests I still get to help get GnuPG working with PGP 5 and PGP 6. There are people using these old programs every day, (naturally installed years earlier, by someone who no longer works there), and making this change would wreak all sorts of havoc for these poor folks. A AES-is-default program can pretty easily send them a message they cannot decrypt. Changing the algorithm of last resort from 3DES sets up some cases of incompatibility with PGP 6 and earlier, and GnuPG 1.0.3 and earlier on one side, and modern versions on the other. It's easy to say that people shouldn't be using these versions any longer (and I say that often), but they are. > The counter-argument is that there is no better time than now. The > reasons to keep 3DES there only get stronger as time goes on. This > problem becomes worse with time, not better. I agree. That's why I'd like to sidestep the problem and change the algorithm of last resort as part of a v5 key. There are no compatibility problems then, as we're changing new keys, and not retroactively changing the meaning of old keys. Basically, I'm thinking this: given that it'll take a few years to change from 3DES, and given that we must change the default hash away from SHA-1 within the next few years, and given the Mister/Zuccherato attack, and given the desire to publish 2440bis already, why not kill a whole bunch of birds with one stone? Finish up 2440bis, publish it, then sit down and design v5. I'd probably feel differently about all this if 3DES was broken in some way, but it's not broken. It's just slow. David From owner-ietf-openpgp@mail.imc.org Fri Apr 15 17:47:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02114 for ; Fri, 15 Apr 2005 17:47:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FLUqxg011252; Fri, 15 Apr 2005 14:30:52 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FLUqj3011251; Fri, 15 Apr 2005 14:30:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FLUo0V011242 for ; Fri, 15 Apr 2005 14:30:51 -0700 (PDT) (envelope-from iang@systemics.com) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j3FLUdU08325 for ; Fri, 15 Apr 2005 22:30:44 +0100 X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol Message-ID: <4260334A.1000000@systemics.com> Date: Fri, 15 Apr 2005 22:34:02 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OpenPGP Subject: Re: AES/SHA1/Must/Should References: <425D89E7.2000705@systemics.com> <20050413215144.GB13198@jabberwocky.com> <548be0d06c065c0b94d1843f25afe9f3@callas.org> <42601158.7040908@systemics.com> <20050415203232.GB28006@jabberwocky.com> In-Reply-To: <20050415203232.GB28006@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: Content-Transfer-Encoding: 7bit David Shaw wrote: > On Fri, Apr 15, 2005 at 08:09:12PM +0100, Ian G wrote: > Where comes this desire to remove 3DES? Are there any new attacks > that raise the desire to dispose of it? The only complaint I can see > with 3DES is that it's *slow*. Not that it's insecure. Well, it is not "remove 3DES" but rather move over to AES. The attacks that were mentioned are the ones based on the birthday attack, I do not know the details, but it is based on the block size being too small. This is not a validated threat but it is a signal to start moving to a bigger block size, being 16 bytes. >>Is the "algorithm of last resort" actually specified >>in the draft RFC, is it? > > > Section 12.1: > > Since TripleDES is the MUST-implement algorithm, if it is not > explicitly in the list, it is tacitly at the end. However, it is > good form to place it there explicitly. Note also that if an > implementation does not implement the preference, then it is > implicitly a TripleDES-only implementation. OK, so if we add AES as a MUST algorithm, leaving TripleDES in place as a MUST also, then that paragraph needs to be clarified. Possibly: Since TripleDES and AES are MUST-implement algorithms, if they are not explicitly in the list, they are implied to be at the end. However, it is good form to place the algorithms there explicitly, and as algorithms may be reduced in status from MUST to SHOULD in the future, this is highly recommended. Note also that if an implementation does not implement the preference, then it implicitly implements the MUST algorithms. Hmmm... that's getting clumsy. I'd say that such a default should be deprecated, if possible: Is there any good reason why implementations shouldn't implement the preference? Are there any implementations that do not implement the preference? Also, is there any good reason to imply the MUST algorithms into the list? Obviously there are implementations that do this. But why not just deprecate that implication and say that implementations MUST include all their preferences, with a footnote that older implementations may implicitly assume TripleDES at the end of the list? How about: At least one MUST-implement algorithm SHOULD be in the list. Older implementations may deliver an empty list, and may imply TripleDES at the end of the list. This behaviour is deprecated. > An implementation MUST NOT use a symmetric algorithm that is not in > the recipient's preference list. When encrypting to more than one > recipient, the implementation finds a suitable algorithm by taking > the intersection of the preferences of the recipients. Note that > the MUST-implement algorithm, TripleDES, ensures that the intersection > is not null. The implementation may use any mechanism to pick an > algorithm in the intersection. > > >>If an implementation >>chooses 3DES as its algorithm of last resort, that doesn't >>need to change. It just seems likely that in a couple >>of years or so, AES would make more sense for that decision. > > > So add AES as a MUST implement to get it out there, and then in a few > years we can revisit what the algorithm of last resort is. Just leave > poor 3DES alone. OK, so at least we seem to have consensus on adding AES as a MUST algorithm. Anyone else demur? iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ From owner-ietf-openpgp@mail.imc.org Fri Apr 15 23:08:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24491 for ; Fri, 15 Apr 2005 23:08:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3G2pJ3s033290; Fri, 15 Apr 2005 19:51:19 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3G2pJYT033289; Fri, 15 Apr 2005 19:51:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3G2pJY8033282 for ; Fri, 15 Apr 2005 19:51:19 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (sccrmhc11) with ESMTP id <2005041602511301100honote>; Sat, 16 Apr 2005 02:51:13 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j3G2pcQr008905 for ; Fri, 15 Apr 2005 22:51:38 -0400 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 j3G2ogSn028666 for ; Fri, 15 Apr 2005 22:50:42 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j3G2og8O028665 for ietf-openpgp@imc.org; Fri, 15 Apr 2005 22:50:42 -0400 Date: Fri, 15 Apr 2005 22:50:42 -0400 From: David Shaw To: OpenPGP Subject: Re: AES/SHA1/Must/Should Message-ID: <20050416025042.GA28565@jabberwocky.com> Mail-Followup-To: OpenPGP References: <425D89E7.2000705@systemics.com> <20050413215144.GB13198@jabberwocky.com> <548be0d06c065c0b94d1843f25afe9f3@callas.org> <42601158.7040908@systemics.com> <20050415203232.GB28006@jabberwocky.com> <4260334A.1000000@systemics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4260334A.1000000@systemics.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Apr 15, 2005 at 10:34:02PM +0100, Ian G wrote: > How about: > > At least one MUST-implement algorithm SHOULD be in the > list. > > Older implementations may deliver an empty list, and may > imply TripleDES at the end of the list. This behaviour > is deprecated. I think this is overcomplicated. There is no way to phrase this that is safe for old implementations - if a new implementation uses AES instead of 3DES, older implementations lose. Here is what I propose. It doesn't really matter right now whether AES becomes the default in a v5 key format or by a future revision to v4. Either way, this change is safe: 1) In section 9.2, change AES from a SHOULD to a MUST. 2) In section 12.1, change this: Since TripleDES is the MUST-implement algorithm, if it is not explicitly in the list, it is tacitly at the end. to this: TripleDES is the current default OpenPGP algorithm, so if it is not explicitly in the list, it is tacitly at the end. and this: Note that the MUST-implement algorithm, TripleDES, ensures that the intersection is not null. to this: Note that the current default algorithm, TripleDES, ensures that the intersection is not null. or other text amounting to the same thing. The reason for this change is that the current text refers to TripleDES as the only MUST-implement algorithm. If we add AES as another MUST, this text is no longer correct. End result is to leave 3DES as the default, and make AES a MUST. In n years, we'll either have v5 keys or can just redefine v4. Either way, we've laid the groundwork. David From owner-ietf-openpgp@mail.imc.org Sat Apr 16 05:53:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08497 for ; Sat, 16 Apr 2005 05:53:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3G9a3MN048367; Sat, 16 Apr 2005 02:36:03 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3G9a3Vc048366; Sat, 16 Apr 2005 02:36:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3G9Zx7C048337 for ; Sat, 16 Apr 2005 02:36:00 -0700 (PDT) (envelope-from iang@systemics.com) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j3G9ZVU11926; Sat, 16 Apr 2005 10:35:46 +0100 X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol Message-ID: <4260DD2D.2080507@systemics.com> Date: Sat, 16 Apr 2005 10:38:53 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Shaw CC: OpenPGP Subject: Re: AES/SHA1/Must/Should References: <425D89E7.2000705@systemics.com> <20050413215144.GB13198@jabberwocky.com> <548be0d06c065c0b94d1843f25afe9f3@callas.org> <42601158.7040908@systemics.com> <20050415203232.GB28006@jabberwocky.com> <4260334A.1000000@systemics.com> <20050416025042.GA28565@jabberwocky.com> In-Reply-To: <20050416025042.GA28565@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: Content-Transfer-Encoding: 7bit David Shaw wrote: > On Fri, Apr 15, 2005 at 10:34:02PM +0100, Ian G wrote: > >>How about: >> >> At least one MUST-implement algorithm SHOULD be in the >> list. >> >> Older implementations may deliver an empty list, and may >> imply TripleDES at the end of the list. This behaviour >> is deprecated. > > > I think this is overcomplicated. There is no way to phrase this that > is safe for old implementations - if a new implementation uses AES > instead of 3DES, older implementations lose. Exactly, this is the problem with having both a list of algorithms and also implicit defaults. One should have one or the other, IMHO, not both, unless one is seeking revenge on coders for unimaginable crimes long past. > Here is what I propose. It doesn't really matter right now whether > AES becomes the default in a v5 key format or by a future revision to > v4. Either way, this change is safe: > > 1) In section 9.2, change AES from a SHOULD to a MUST. > > 2) In section 12.1, change > > this: > Since TripleDES is the MUST-implement algorithm, if it is not > explicitly in the list, it is tacitly at the end. > > to this: > TripleDES is the current default OpenPGP algorithm, so if it is not > explicitly in the list, it is tacitly at the end. Right, so TripleDES remains a default, but the status of default is delinked from the MUST status. AES becomes a MUST, but is not a default. > and this: > Note that the MUST-implement algorithm, TripleDES, ensures > that the intersection is not null. > > to this: > Note that the current default algorithm, TripleDES, ensures that the > intersection is not null. Looks good. The only question I would have is whether (in v4) we would continue to assume the presence of a default algorithm. If we are agreed that defaults are a bad thing, then some warning should be put in there to suggest all new keys should include their full list. Alternatively, I suggest we bite the bullet and state that TripleDES is the default and that will never change (in v4). > or other text amounting to the same thing. The reason for this change > is that the current text refers to TripleDES as the only > MUST-implement algorithm. If we add AES as another MUST, this text is > no longer correct. > > End result is to leave 3DES as the default, and make AES a MUST. In n > years, we'll either have v5 keys or can just redefine v4. Either way, > we've laid the groundwork. OK, so your view would be "in v4, TripleDES is a default and a MUST and that should not change." Fair enough. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ From owner-ietf-openpgp@mail.imc.org Fri Apr 22 00:04:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17149 for ; Fri, 22 Apr 2005 00:04:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3M3tvWD075750; Thu, 21 Apr 2005 20:55:57 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3M3tvmO075749; Thu, 21 Apr 2005 20:55:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.202.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3M3tvnK075708 for ; Thu, 21 Apr 2005 20:55:57 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (sccrmhc14) with ESMTP id <2005042203555101400odfo5e>; Fri, 22 Apr 2005 03:55:51 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j3M3uUQr016195 for ; Thu, 21 Apr 2005 23:56:30 -0400 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 j3M3tmko027765 for ; Thu, 21 Apr 2005 23:55:48 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j3M3tmZu027764 for ietf-openpgp@imc.org; Thu, 21 Apr 2005 23:55:48 -0400 Date: Thu, 21 Apr 2005 23:55:48 -0400 From: David Shaw To: OpenPGP Subject: Re: AES/SHA1/Must/Should Message-ID: <20050422035548.GC23517@jabberwocky.com> Mail-Followup-To: OpenPGP References: <425D89E7.2000705@systemics.com> <20050413215144.GB13198@jabberwocky.com> <548be0d06c065c0b94d1843f25afe9f3@callas.org> <42601158.7040908@systemics.com> <20050415203232.GB28006@jabberwocky.com> <4260334A.1000000@systemics.com> <20050416025042.GA28565@jabberwocky.com> <4260DD2D.2080507@systemics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4260DD2D.2080507@systemics.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Apr 16, 2005 at 10:38:53AM +0100, Ian G wrote: > OK, so your view would be "in v4, TripleDES is a > default and a MUST and that should not change." Not exactly what I'm saying, but close. What I'm saying is, "Don't change it overnight. If we can do this as part of a v5 key, great. If we must do it in v4, then give warning about the upcoming for the change for a year or three first." My suggested change for 2440bis works with either of those two cases. David From owner-ietf-openpgp@mail.imc.org Tue Apr 26 08:53:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05126 for ; Tue, 26 Apr 2005 08:53:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QCd3R5063932; Tue, 26 Apr 2005 05:39:03 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QCd34d063931; Tue, 26 Apr 2005 05:39:03 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3QCd2Bi063914 for ; Tue, 26 Apr 2005 05:39:03 -0700 (PDT) (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 1FF0033C5F for ; Tue, 26 Apr 2005 13:39:01 +0100 (BST) Message-ID: <426E366B.4030806@algroup.co.uk> Date: Tue, 26 Apr 2005 13:39:07 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OpenPGP Subject: Editorial Nit X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: Content-Transfer-Encoding: 7bit 5.2.3.7. Preferred symmetric algorithms (sequence of one-octet values) 5.2.3.8. Preferred hash algorithms (array of one-octet values) It seems these (and others) should all either say "sequence" or "array". -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 Tue Apr 26 13:52:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00176 for ; Tue, 26 Apr 2005 13:52:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QHbmxn019328; Tue, 26 Apr 2005 10:37:48 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QHbmEZ019327; Tue, 26 Apr 2005 10:37:48 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3QHbjaQ019316 for ; Tue, 26 Apr 2005 10:37:48 -0700 (PDT) (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 BA8D033C79 for ; Tue, 26 Apr 2005 18:37:43 +0100 (BST) Message-ID: <426E7C6E.3070108@algroup.co.uk> Date: Tue, 26 Apr 2005 18:37:50 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OpenPGP Subject: Tag 11 unclear X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: Content-Transfer-Encoding: 7bit In 5.9: " - File name as a string (one-octet length, followed by file name), if the encrypted data should be saved as a file." but no mention of what if it shouldn't be saved as a file. 0 length, perhaps? Then: " - A four-octet number that indicates the modification date of the file, or the creation time of the packet, or a zero that indicates the present time." I would _guess_ that it means modification date of the file if there's a filename, the creation time if there isn't. I have no idea what zero is supposed to mean. Nothing, would be the obvious interpretation - "the present time" is nonsensical. Once more, when I know what its supposed to mean, I'll suggest wording. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 Tue Apr 26 16:06:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12774 for ; Tue, 26 Apr 2005 16:06:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QJqMPd043631; Tue, 26 Apr 2005 12:52:23 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QJqMYe043630; Tue, 26 Apr 2005 12:52:22 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3QJqLwo043613 for ; Tue, 26 Apr 2005 12:52:21 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 2DA7B57EE7; Tue, 26 Apr 2005 12:02:23 -0700 (PDT) To: ben@algroup.co.uk, ietf-openpgp@imc.org Subject: Re: Tag 11 unclear Message-Id: <20050426190223.2DA7B57EE7@finney.org> Date: Tue, 26 Apr 2005 12:02:23 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ben Laurie writes regarding literal packet headers: > In 5.9: > > " - File name as a string (one-octet length, followed by file name), > if the encrypted data should be saved as a file." > > but no mention of what if it shouldn't be saved as a file. 0 length, > perhaps? Yes, I think 0 is the right length in that case. The language about "if it should be saved as a file" is from the perspective of the decryptor and is perhaps too functionally oriented. It might be better simply to document this as a filename which can be optionally associated with the encrypted data. We can recommend that decryptors MAY use this as a default file name if the data is being saved as a file. We might also want to note here that literal packet headers are not signed, unless the literal packet is first wrapped in another packet such as a compressed packet. Only the body of a literal packet is signed in a message which consists of sig-packet, literal-packet. (Or sig1-packet, literal-packet, sig-packet) > Then: > > " - A four-octet number that indicates the modification date of the > file, or the creation time of the packet, or a zero that > indicates the present time." > > I would _guess_ that it means modification date of the file if there's > a filename, the creation time if there isn't. I have no idea what zero > is supposed to mean. Nothing, would be the obvious interpretation - > "the present time" is nonsensical. Yes, I agree, zero means simply an unspecified time. Hal Finney Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QJqMPd043631; Tue, 26 Apr 2005 12:52:23 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QJqMYe043630; Tue, 26 Apr 2005 12:52:22 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3QJqLwo043613 for ; Tue, 26 Apr 2005 12:52:21 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 2DA7B57EE7; Tue, 26 Apr 2005 12:02:23 -0700 (PDT) To: ben@algroup.co.uk, ietf-openpgp@imc.org Subject: Re: Tag 11 unclear Message-Id: <20050426190223.2DA7B57EE7@finney.org> Date: Tue, 26 Apr 2005 12:02:23 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ben Laurie writes regarding literal packet headers: > In 5.9: > > " - File name as a string (one-octet length, followed by file name), > if the encrypted data should be saved as a file." > > but no mention of what if it shouldn't be saved as a file. 0 length, > perhaps? Yes, I think 0 is the right length in that case. The language about "if it should be saved as a file" is from the perspective of the decryptor and is perhaps too functionally oriented. It might be better simply to document this as a filename which can be optionally associated with the encrypted data. We can recommend that decryptors MAY use this as a default file name if the data is being saved as a file. We might also want to note here that literal packet headers are not signed, unless the literal packet is first wrapped in another packet such as a compressed packet. Only the body of a literal packet is signed in a message which consists of sig-packet, literal-packet. (Or sig1-packet, literal-packet, sig-packet) > Then: > > " - A four-octet number that indicates the modification date of the > file, or the creation time of the packet, or a zero that > indicates the present time." > > I would _guess_ that it means modification date of the file if there's > a filename, the creation time if there isn't. I have no idea what zero > is supposed to mean. Nothing, would be the obvious interpretation - > "the present time" is nonsensical. Yes, I agree, zero means simply an unspecified time. Hal Finney Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QHbmxn019328; Tue, 26 Apr 2005 10:37:48 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QHbmEZ019327; Tue, 26 Apr 2005 10:37:48 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3QHbjaQ019316 for ; Tue, 26 Apr 2005 10:37:48 -0700 (PDT) (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 BA8D033C79 for ; Tue, 26 Apr 2005 18:37:43 +0100 (BST) Message-ID: <426E7C6E.3070108@algroup.co.uk> Date: Tue, 26 Apr 2005 18:37:50 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OpenPGP Subject: Tag 11 unclear X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: In 5.9: " - File name as a string (one-octet length, followed by file name), if the encrypted data should be saved as a file." but no mention of what if it shouldn't be saved as a file. 0 length, perhaps? Then: " - A four-octet number that indicates the modification date of the file, or the creation time of the packet, or a zero that indicates the present time." I would _guess_ that it means modification date of the file if there's a filename, the creation time if there isn't. I have no idea what zero is supposed to mean. Nothing, would be the obvious interpretation - "the present time" is nonsensical. Once more, when I know what its supposed to mean, I'll suggest wording. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QCd3R5063932; Tue, 26 Apr 2005 05:39:03 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QCd34d063931; Tue, 26 Apr 2005 05:39:03 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3QCd2Bi063914 for ; Tue, 26 Apr 2005 05:39:03 -0700 (PDT) (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 1FF0033C5F for ; Tue, 26 Apr 2005 13:39:01 +0100 (BST) Message-ID: <426E366B.4030806@algroup.co.uk> Date: Tue, 26 Apr 2005 13:39:07 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OpenPGP Subject: Editorial Nit X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 5.2.3.7. Preferred symmetric algorithms (sequence of one-octet values) 5.2.3.8. Preferred hash algorithms (array of one-octet values) It seems these (and others) should all either say "sequence" or "array". -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3M3tvWD075750; Thu, 21 Apr 2005 20:55:57 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3M3tvmO075749; Thu, 21 Apr 2005 20:55:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.202.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3M3tvnK075708 for ; Thu, 21 Apr 2005 20:55:57 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (sccrmhc14) with ESMTP id <2005042203555101400odfo5e>; Fri, 22 Apr 2005 03:55:51 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j3M3uUQr016195 for ; Thu, 21 Apr 2005 23:56:30 -0400 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 j3M3tmko027765 for ; Thu, 21 Apr 2005 23:55:48 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j3M3tmZu027764 for ietf-openpgp@imc.org; Thu, 21 Apr 2005 23:55:48 -0400 Date: Thu, 21 Apr 2005 23:55:48 -0400 From: David Shaw To: OpenPGP Subject: Re: AES/SHA1/Must/Should Message-ID: <20050422035548.GC23517@jabberwocky.com> Mail-Followup-To: OpenPGP References: <425D89E7.2000705@systemics.com> <20050413215144.GB13198@jabberwocky.com> <548be0d06c065c0b94d1843f25afe9f3@callas.org> <42601158.7040908@systemics.com> <20050415203232.GB28006@jabberwocky.com> <4260334A.1000000@systemics.com> <20050416025042.GA28565@jabberwocky.com> <4260DD2D.2080507@systemics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4260DD2D.2080507@systemics.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Apr 16, 2005 at 10:38:53AM +0100, Ian G wrote: > OK, so your view would be "in v4, TripleDES is a > default and a MUST and that should not change." Not exactly what I'm saying, but close. What I'm saying is, "Don't change it overnight. If we can do this as part of a v5 key, great. If we must do it in v4, then give warning about the upcoming for the change for a year or three first." My suggested change for 2440bis works with either of those two cases. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3G9a3MN048367; Sat, 16 Apr 2005 02:36:03 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3G9a3Vc048366; Sat, 16 Apr 2005 02:36:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3G9Zx7C048337 for ; Sat, 16 Apr 2005 02:36:00 -0700 (PDT) (envelope-from iang@systemics.com) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j3G9ZVU11926; Sat, 16 Apr 2005 10:35:46 +0100 X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol Message-ID: <4260DD2D.2080507@systemics.com> Date: Sat, 16 Apr 2005 10:38:53 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Shaw CC: OpenPGP Subject: Re: AES/SHA1/Must/Should References: <425D89E7.2000705@systemics.com> <20050413215144.GB13198@jabberwocky.com> <548be0d06c065c0b94d1843f25afe9f3@callas.org> <42601158.7040908@systemics.com> <20050415203232.GB28006@jabberwocky.com> <4260334A.1000000@systemics.com> <20050416025042.GA28565@jabberwocky.com> In-Reply-To: <20050416025042.GA28565@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 Fri, Apr 15, 2005 at 10:34:02PM +0100, Ian G wrote: > >>How about: >> >> At least one MUST-implement algorithm SHOULD be in the >> list. >> >> Older implementations may deliver an empty list, and may >> imply TripleDES at the end of the list. This behaviour >> is deprecated. > > > I think this is overcomplicated. There is no way to phrase this that > is safe for old implementations - if a new implementation uses AES > instead of 3DES, older implementations lose. Exactly, this is the problem with having both a list of algorithms and also implicit defaults. One should have one or the other, IMHO, not both, unless one is seeking revenge on coders for unimaginable crimes long past. > Here is what I propose. It doesn't really matter right now whether > AES becomes the default in a v5 key format or by a future revision to > v4. Either way, this change is safe: > > 1) In section 9.2, change AES from a SHOULD to a MUST. > > 2) In section 12.1, change > > this: > Since TripleDES is the MUST-implement algorithm, if it is not > explicitly in the list, it is tacitly at the end. > > to this: > TripleDES is the current default OpenPGP algorithm, so if it is not > explicitly in the list, it is tacitly at the end. Right, so TripleDES remains a default, but the status of default is delinked from the MUST status. AES becomes a MUST, but is not a default. > and this: > Note that the MUST-implement algorithm, TripleDES, ensures > that the intersection is not null. > > to this: > Note that the current default algorithm, TripleDES, ensures that the > intersection is not null. Looks good. The only question I would have is whether (in v4) we would continue to assume the presence of a default algorithm. If we are agreed that defaults are a bad thing, then some warning should be put in there to suggest all new keys should include their full list. Alternatively, I suggest we bite the bullet and state that TripleDES is the default and that will never change (in v4). > or other text amounting to the same thing. The reason for this change > is that the current text refers to TripleDES as the only > MUST-implement algorithm. If we add AES as another MUST, this text is > no longer correct. > > End result is to leave 3DES as the default, and make AES a MUST. In n > years, we'll either have v5 keys or can just redefine v4. Either way, > we've laid the groundwork. OK, so your view would be "in v4, TripleDES is a default and a MUST and that should not change." Fair enough. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3G2pJ3s033290; Fri, 15 Apr 2005 19:51:19 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3G2pJYT033289; Fri, 15 Apr 2005 19:51:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3G2pJY8033282 for ; Fri, 15 Apr 2005 19:51:19 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (sccrmhc11) with ESMTP id <2005041602511301100honote>; Sat, 16 Apr 2005 02:51:13 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j3G2pcQr008905 for ; Fri, 15 Apr 2005 22:51:38 -0400 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 j3G2ogSn028666 for ; Fri, 15 Apr 2005 22:50:42 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j3G2og8O028665 for ietf-openpgp@imc.org; Fri, 15 Apr 2005 22:50:42 -0400 Date: Fri, 15 Apr 2005 22:50:42 -0400 From: David Shaw To: OpenPGP Subject: Re: AES/SHA1/Must/Should Message-ID: <20050416025042.GA28565@jabberwocky.com> Mail-Followup-To: OpenPGP References: <425D89E7.2000705@systemics.com> <20050413215144.GB13198@jabberwocky.com> <548be0d06c065c0b94d1843f25afe9f3@callas.org> <42601158.7040908@systemics.com> <20050415203232.GB28006@jabberwocky.com> <4260334A.1000000@systemics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4260334A.1000000@systemics.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Apr 15, 2005 at 10:34:02PM +0100, Ian G wrote: > How about: > > At least one MUST-implement algorithm SHOULD be in the > list. > > Older implementations may deliver an empty list, and may > imply TripleDES at the end of the list. This behaviour > is deprecated. I think this is overcomplicated. There is no way to phrase this that is safe for old implementations - if a new implementation uses AES instead of 3DES, older implementations lose. Here is what I propose. It doesn't really matter right now whether AES becomes the default in a v5 key format or by a future revision to v4. Either way, this change is safe: 1) In section 9.2, change AES from a SHOULD to a MUST. 2) In section 12.1, change this: Since TripleDES is the MUST-implement algorithm, if it is not explicitly in the list, it is tacitly at the end. to this: TripleDES is the current default OpenPGP algorithm, so if it is not explicitly in the list, it is tacitly at the end. and this: Note that the MUST-implement algorithm, TripleDES, ensures that the intersection is not null. to this: Note that the current default algorithm, TripleDES, ensures that the intersection is not null. or other text amounting to the same thing. The reason for this change is that the current text refers to TripleDES as the only MUST-implement algorithm. If we add AES as another MUST, this text is no longer correct. End result is to leave 3DES as the default, and make AES a MUST. In n years, we'll either have v5 keys or can just redefine v4. Either way, we've laid the groundwork. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FLUqxg011252; Fri, 15 Apr 2005 14:30:52 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FLUqj3011251; Fri, 15 Apr 2005 14:30:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FLUo0V011242 for ; Fri, 15 Apr 2005 14:30:51 -0700 (PDT) (envelope-from iang@systemics.com) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j3FLUdU08325 for ; Fri, 15 Apr 2005 22:30:44 +0100 X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol Message-ID: <4260334A.1000000@systemics.com> Date: Fri, 15 Apr 2005 22:34:02 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OpenPGP Subject: Re: AES/SHA1/Must/Should References: <425D89E7.2000705@systemics.com> <20050413215144.GB13198@jabberwocky.com> <548be0d06c065c0b94d1843f25afe9f3@callas.org> <42601158.7040908@systemics.com> <20050415203232.GB28006@jabberwocky.com> In-Reply-To: <20050415203232.GB28006@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 Fri, Apr 15, 2005 at 08:09:12PM +0100, Ian G wrote: > Where comes this desire to remove 3DES? Are there any new attacks > that raise the desire to dispose of it? The only complaint I can see > with 3DES is that it's *slow*. Not that it's insecure. Well, it is not "remove 3DES" but rather move over to AES. The attacks that were mentioned are the ones based on the birthday attack, I do not know the details, but it is based on the block size being too small. This is not a validated threat but it is a signal to start moving to a bigger block size, being 16 bytes. >>Is the "algorithm of last resort" actually specified >>in the draft RFC, is it? > > > Section 12.1: > > Since TripleDES is the MUST-implement algorithm, if it is not > explicitly in the list, it is tacitly at the end. However, it is > good form to place it there explicitly. Note also that if an > implementation does not implement the preference, then it is > implicitly a TripleDES-only implementation. OK, so if we add AES as a MUST algorithm, leaving TripleDES in place as a MUST also, then that paragraph needs to be clarified. Possibly: Since TripleDES and AES are MUST-implement algorithms, if they are not explicitly in the list, they are implied to be at the end. However, it is good form to place the algorithms there explicitly, and as algorithms may be reduced in status from MUST to SHOULD in the future, this is highly recommended. Note also that if an implementation does not implement the preference, then it implicitly implements the MUST algorithms. Hmmm... that's getting clumsy. I'd say that such a default should be deprecated, if possible: Is there any good reason why implementations shouldn't implement the preference? Are there any implementations that do not implement the preference? Also, is there any good reason to imply the MUST algorithms into the list? Obviously there are implementations that do this. But why not just deprecate that implication and say that implementations MUST include all their preferences, with a footnote that older implementations may implicitly assume TripleDES at the end of the list? How about: At least one MUST-implement algorithm SHOULD be in the list. Older implementations may deliver an empty list, and may imply TripleDES at the end of the list. This behaviour is deprecated. > An implementation MUST NOT use a symmetric algorithm that is not in > the recipient's preference list. When encrypting to more than one > recipient, the implementation finds a suitable algorithm by taking > the intersection of the preferences of the recipients. Note that > the MUST-implement algorithm, TripleDES, ensures that the intersection > is not null. The implementation may use any mechanism to pick an > algorithm in the intersection. > > >>If an implementation >>chooses 3DES as its algorithm of last resort, that doesn't >>need to change. It just seems likely that in a couple >>of years or so, AES would make more sense for that decision. > > > So add AES as a MUST implement to get it out there, and then in a few > years we can revisit what the algorithm of last resort is. Just leave > poor 3DES alone. OK, so at least we seem to have consensus on adding AES as a MUST algorithm. Anyone else demur? iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FL2tTG009318; Fri, 15 Apr 2005 14:02:55 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FL2tWK009317; Fri, 15 Apr 2005 14:02:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FL2tUK009305 for ; Fri, 15 Apr 2005 14:02:55 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (rwcrmhc14) with ESMTP id <2005041521024701400hh043e>; Fri, 15 Apr 2005 21:02:47 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j3FL33Qr007982 for ; Fri, 15 Apr 2005 17:03:03 -0400 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 j3FL28Af028369 for ; Fri, 15 Apr 2005 17:02:08 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j3FL28Ma028368 for ietf-openpgp@imc.org; Fri, 15 Apr 2005 17:02:08 -0400 Date: Fri, 15 Apr 2005 17:02:08 -0400 From: David Shaw To: OpenPGP Subject: Re: AES/SHA1/Must/Should Message-ID: <20050415210208.GC28006@jabberwocky.com> Mail-Followup-To: OpenPGP References: <425D89E7.2000705@systemics.com> <20050413215144.GB13198@jabberwocky.com> <548be0d06c065c0b94d1843f25afe9f3@callas.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <548be0d06c065c0b94d1843f25afe9f3@callas.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Apr 15, 2005 at 10:41:12AM -0700, Jon Callas wrote: > > On 13 Apr 2005, at 2:51 PM, David Shaw wrote: > > >There are too many years and too many implementations where 3DES is > >the algorithm of last resort, and changing 3DES to a SHOULD > >necessitates a different algorithm of last resort. We cannot change > >that overnight. > > > >By all means, add some new MUSTs to start the algorithm changing > >process, but 3DES needs to stay as MUST as well for a good long time. > > > > I understand how you feel. I feel the same way. However, I have a > question to ask: > > When? How long is "a good long time"? Forever? I'd say "a good long time" is more than 2, but less than 5 years. I base this on the surprising number of requests I still get to help get GnuPG working with PGP 5 and PGP 6. There are people using these old programs every day, (naturally installed years earlier, by someone who no longer works there), and making this change would wreak all sorts of havoc for these poor folks. A AES-is-default program can pretty easily send them a message they cannot decrypt. Changing the algorithm of last resort from 3DES sets up some cases of incompatibility with PGP 6 and earlier, and GnuPG 1.0.3 and earlier on one side, and modern versions on the other. It's easy to say that people shouldn't be using these versions any longer (and I say that often), but they are. > The counter-argument is that there is no better time than now. The > reasons to keep 3DES there only get stronger as time goes on. This > problem becomes worse with time, not better. I agree. That's why I'd like to sidestep the problem and change the algorithm of last resort as part of a v5 key. There are no compatibility problems then, as we're changing new keys, and not retroactively changing the meaning of old keys. Basically, I'm thinking this: given that it'll take a few years to change from 3DES, and given that we must change the default hash away from SHA-1 within the next few years, and given the Mister/Zuccherato attack, and given the desire to publish 2440bis already, why not kill a whole bunch of birds with one stone? Finish up 2440bis, publish it, then sit down and design v5. I'd probably feel differently about all this if 3DES was broken in some way, but it's not broken. It's just slow. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FKX8PE007241; Fri, 15 Apr 2005 13:33:08 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FKX8Lu007240; Fri, 15 Apr 2005 13:33:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FKX8mV007232 for ; Fri, 15 Apr 2005 13:33:08 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (sccrmhc12) with ESMTP id <200504152033020120052fkfe>; Fri, 15 Apr 2005 20:33:02 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j3FKXRQr007871 for ; Fri, 15 Apr 2005 16:33:27 -0400 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 j3FKWWjL028321 for ; Fri, 15 Apr 2005 16:32:32 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j3FKWW9u028320 for ietf-openpgp@imc.org; Fri, 15 Apr 2005 16:32:32 -0400 Date: Fri, 15 Apr 2005 16:32:32 -0400 From: David Shaw To: OpenPGP Subject: Re: AES/SHA1/Must/Should Message-ID: <20050415203232.GB28006@jabberwocky.com> Mail-Followup-To: OpenPGP References: <425D89E7.2000705@systemics.com> <20050413215144.GB13198@jabberwocky.com> <548be0d06c065c0b94d1843f25afe9f3@callas.org> <42601158.7040908@systemics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42601158.7040908@systemics.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Apr 15, 2005 at 08:09:12PM +0100, Ian G wrote: > > > >On 13 Apr 2005, at 2:51 PM, David Shaw wrote: > > > >>There are too many years and too many implementations where 3DES is > >>the algorithm of last resort, and changing 3DES to a SHOULD > >>necessitates a different algorithm of last resort. We cannot change > >>that overnight. > > > I think there is a big difference between what the > implementations do, and what the standard says. If > there is an issue in the short term, then implementations > are free to ignore the standard. It's not as if anyone > ever lost a contract because they couldn't prove absolute > compliance with the standard. > > In this happy state of affairs, I am not sure why we > cannot (as a standards body) wiggle our fingers with > fierceness about 3DES and have the implementations > broadly ignore us for many months or even years... If we mean it, put it in the standard. If we don't, then don't put it in the standard. No need for wink-wink with implementations. This is a pretty straightforward issue. Even before 2440, in 2440, and until today, 3DES has been the algorithm of last resort. There are a significant number of deployed systems that base their behavior on that design. You can't declare a flag day after which the algorithm of last resort is different without causing incompatibility. Where comes this desire to remove 3DES? Are there any new attacks that raise the desire to dispose of it? The only complaint I can see with 3DES is that it's *slow*. Not that it's insecure. > Is the "algorithm of last resort" actually specified > in the draft RFC, is it? Section 12.1: Since TripleDES is the MUST-implement algorithm, if it is not explicitly in the list, it is tacitly at the end. However, it is good form to place it there explicitly. Note also that if an implementation does not implement the preference, then it is implicitly a TripleDES-only implementation. An implementation MUST NOT use a symmetric algorithm that is not in the recipient's preference list. When encrypting to more than one recipient, the implementation finds a suitable algorithm by taking the intersection of the preferences of the recipients. Note that the MUST-implement algorithm, TripleDES, ensures that the intersection is not null. The implementation may use any mechanism to pick an algorithm in the intersection. > If an implementation > chooses 3DES as its algorithm of last resort, that doesn't > need to change. It just seems likely that in a couple > of years or so, AES would make more sense for that decision. So add AES as a MUST implement to get it out there, and then in a few years we can revisit what the algorithm of last resort is. Just leave poor 3DES alone. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FJ6CGS099741; Fri, 15 Apr 2005 12:06:12 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FJ6CFv099740; Fri, 15 Apr 2005 12:06:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FJ6BOR099733 for ; Fri, 15 Apr 2005 12:06:11 -0700 (PDT) (envelope-from iang@systemics.com) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j3FJ5nU07666 for ; Fri, 15 Apr 2005 20:06:05 +0100 X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol Message-ID: <42601158.7040908@systemics.com> Date: Fri, 15 Apr 2005 20:09:12 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OpenPGP Subject: Re: AES/SHA1/Must/Should References: <425D89E7.2000705@systemics.com> <20050413215144.GB13198@jabberwocky.com> <548be0d06c065c0b94d1843f25afe9f3@callas.org> In-Reply-To: <548be0d06c065c0b94d1843f25afe9f3@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: > On 13 Apr 2005, at 2:51 PM, David Shaw wrote: > >> There are too many years and too many implementations where 3DES is >> the algorithm of last resort, and changing 3DES to a SHOULD >> necessitates a different algorithm of last resort. We cannot change >> that overnight. I think there is a big difference between what the implementations do, and what the standard says. If there is an issue in the short term, then implementations are free to ignore the standard. It's not as if anyone ever lost a contract because they couldn't prove absolute compliance with the standard. In this happy state of affairs, I am not sure why we cannot (as a standards body) wiggle our fingers with fierceness about 3DES and have the implementations broadly ignore us for many months or even years... Is the "algorithm of last resort" actually specified in the draft RFC, is it? If an implementation chooses 3DES as its algorithm of last resort, that doesn't need to change. It just seems likely that in a couple of years or so, AES would make more sense for that decision. > I recommend not making any change in default algorithms for 2440bis. > If and when we take up v5 keys, we can easily set the cipher of last > resort for v5 keys to something other than 3DES. The issue I see with that is that this group has been working for ... 8 years? and hasn't got a standard out. I'd love to see some action on a v5 key layout, but I don't have much hope. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FHdakb093970; Fri, 15 Apr 2005 10:39:36 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FHdaku093969; Fri, 15 Apr 2005 10:39:36 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3FHdZ7U093956 for ; Fri, 15 Apr 2005 10:39:35 -0700 (PDT) (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.6) for ; Fri, 15 Apr 2005 10:39:33 -0700 Received: from [63.73.97.189] ([63.73.97.189]) by keys.merrymeet.com (PGP Universal service); Fri, 15 Apr 2005 10:39:33 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 15 Apr 2005 10:39:33 -0700 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <20050413215144.GB13198@jabberwocky.com> References: <425D89E7.2000705@systemics.com> <20050413215144.GB13198@jabberwocky.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <548be0d06c065c0b94d1843f25afe9f3@callas.org> Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: AES/SHA1/Must/Should Date: Fri, 15 Apr 2005 10:41:12 -0700 To: OpenPGP X-Mailer: Apple Mail (2.619.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 13 Apr 2005, at 2:51 PM, David Shaw wrote: > There are too many years and too many implementations where 3DES is > the algorithm of last resort, and changing 3DES to a SHOULD > necessitates a different algorithm of last resort. We cannot change > that overnight. > > By all means, add some new MUSTs to start the algorithm changing > process, but 3DES needs to stay as MUST as well for a good long time. > I understand how you feel. I feel the same way. However, I have a question to ask: When? How long is "a good long time"? Forever? The counter-argument is that there is no better time than now. The reasons to keep 3DES there only get stronger as time goes on. This problem becomes worse with time, not better. Jon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DLqFpl098125; Wed, 13 Apr 2005 14:52:15 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DLqFuc098124; Wed, 13 Apr 2005 14:52:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DLqFku098116 for ; Wed, 13 Apr 2005 14:52:15 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (sccrmhc11) with ESMTP id <2005041321520901100251l9e>; Wed, 13 Apr 2005 21:52:09 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j3DLqTQr030003 for ; Wed, 13 Apr 2005 17:52:29 -0400 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 j3DLpjwf013743 for ; Wed, 13 Apr 2005 17:51:45 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j3DLpjiB013742 for ietf-openpgp@imc.org; Wed, 13 Apr 2005 17:51:45 -0400 Date: Wed, 13 Apr 2005 17:51:45 -0400 From: David Shaw To: OpenPGP Subject: Re: AES/SHA1/Must/Should Message-ID: <20050413215144.GB13198@jabberwocky.com> Mail-Followup-To: OpenPGP References: <425D89E7.2000705@systemics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425D89E7.2000705@systemics.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Apr 13, 2005 at 10:06:47PM +0100, Ian G wrote: > > Is the draft 12 the current working text? I noticed it > expires in another month. > > Did we resolve the question of whether to make changes > to the MUST / SHOULD algorithms? > > I'm all in favour of saying AES-128 is now the MUST and > triple DES becomes the SHOULD. In practice, most > implementations would be there already as they will have > done both (Cryptix Java is, and so is Perl's Crypt::OpenPGP). I don't have a very strong feeling one way or another on making AES-128 a MUST. However, I have a very strong feeling against changing the status of 3DES. There are too many years and too many implementations where 3DES is the algorithm of last resort, and changing 3DES to a SHOULD necessitates a different algorithm of last resort. We cannot change that overnight. By all means, add some new MUSTs to start the algorithm changing process, but 3DES needs to stay as MUST as well for a good long time. I recommend not making any change in default algorithms for 2440bis. If and when we take up v5 keys, we can easily set the cipher of last resort for v5 keys to something other than 3DES. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DL3RG4094850; Wed, 13 Apr 2005 14:03:27 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DL3RKB094849; Wed, 13 Apr 2005 14:03:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DL3Q7t094843 for ; Wed, 13 Apr 2005 14:03:26 -0700 (PDT) (envelope-from iang@systemics.com) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j3DL3EU25929 for ; Wed, 13 Apr 2005 22:03:19 +0100 X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol Message-ID: <425D89E7.2000705@systemics.com> Date: Wed, 13 Apr 2005 22:06:47 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OpenPGP Subject: AES/SHA1/Must/Should 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: Is the draft 12 the current working text? I noticed it expires in another month. Did we resolve the question of whether to make changes to the MUST / SHOULD algorithms? I'm all in favour of saying AES-128 is now the MUST and triple DES becomes the SHOULD. In practice, most implementations would be there already as they will have done both (Cryptix Java is, and so is Perl's Crypt::OpenPGP). SHA is harder as we've discussed. If we agree to leave matters lie, then here's one potential addition to 13 (I cribbed the wording from the other points, but any wording could be considered....): 13. Security Considerations - suggested addition * In October 2004, the Shandong university team of Wang, Yin, Yu announced attacks on reduced rounds of SHA1. Collisions are predicted in 2^69 steps rather than the full 2^80 steps. For this reason SHA1 is widely expected to be deprecated in coming years. Implementors may prefer to move to wider length SHA algorithms as appropriate. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3CMliH5062452; Tue, 12 Apr 2005 15:47:44 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3CMliJ9062451; Tue, 12 Apr 2005 15:47:44 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j3CMlgEY062443 for ; Tue, 12 Apr 2005 15:47:42 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id AABE557EE8; Tue, 12 Apr 2005 14:58:27 -0700 (PDT) To: ietf-openpgp@imc.org Subject: OpenPGP Signatures Incorporating X.509 Certificates Message-Id: <20050412215827.AABE557EE8@finney.org> Date: Tue, 12 Apr 2005 14:58:27 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: OpenPGP Signatures Incorporating X.509 Certificates Copyright 2005 by PGP Corporation. All Rights Reserved. Abstract This document is published to document the procedure used by commercial PGP [PGP] products up through version 9 for incorporating X.509 [X.509-00] certificates into OpenPGP [RFC2440] format signatures, and for cryptographically validating such signatures. It describes only the format and methods needed to import X.509 certificates, and to validate key signature packets containing such certificates. It does not deal with storage and implementation questions. 1. Introduction The OpenPGP [RFC2440] specification describes data formats for representing public keys, userids, and key signatures that cryptographically bind keys, userids, and fields from signature packets. It further describes the cryptographic procedures used to sign and verify the signature packets which comply with that specification. An alternative set of standards and formats is widely used in network applications for communicating cryptographic bindings of public keys and associated name data, based on the X.509 [X.509-00] certificate format. X.509 certificates communicate similar information to OpenPGP key, userid and signature packets. However, the details of the data formats are incompatible and it is not possible to transform X.509 certificates into sequences of OpenPGP packets that can be cryptographically validated by the mechanisms described in RFC2440. This document presents an alternative mechanism to allow X.509 certificates to be imported into OpenPGP data formats and cryptographically validated. It describes both the detailed data formats used to import and represent X.509 data in OpenPGP packets, and the procedures necessary to cryptographically validate such X.509 based OpenPGP signatures. These mechanisms allow the cryptographic infrastructure based on X.509 certificates to be imported and used in the context of OpenPGP messages and data. 1.1. Overview of Importing Certificates X.509 certificates are imported into OpenPGP signature packets in three steps, which will be described in more detail in section 2. [Page 1] -2- First, the numeric key material (the RSA modulus and exponent, and corresponding values for other key types) is used to construct an OpenPGP key packet. Second, the name field(s) of the X.509 certificate are used to construct an OpenPGP userid packet. And third, an OpenPGP signature packet is constructed from the certificate. Some fields of the OpenPGP signature packet are set from corresponding fields in the certificate. In addition, the certificate itself is inserted as a whole into the OpenPGP signature packet, in a signature subpacket. During the import process, the keyring is searched for a pre-existing OpenPGP key which matches the numeric key material being imported. If so, the userid and signature are added to the existing key. This also requires checking to see whether there is already a userid on the key matching the userid constructed by the import process; if so, the new signature packet is added to the pre-existing userid. This allows OpenPGP keys to hold a combination of X.509 based signatures and regular OpenPGP signatures. Once the X.509 certificate has been imported, the resulting OpenPGP keys and userids can be used interchangeably with regular OpenPGP keys. The only difference is in the format of the X.509 signatures. 1.2. Validating Certificates Cryptographically validating an X.509 signature packet requires a special process. It is not possible to use the normal OpenPGP signature validation process because no cryptographically valid signature exists over the OpenPGP data. Instead, a two step process is used. First, the X.509 certificate is tested for consistency with the OpenPGP packets. This requires extracting the X.509 certificate from the OpenPGP signature packet. It is then put through a process similar to when it was first imported into the OpenPGP format per this specification, to create temporary OpenPGP key, userid and signature packets from the certificate data. These temporary packets are compared with the OpenPGP key, userid and signature packets from the OpenPGP key holding the X.509 certificate signature. There must be an exact, byte-for-byte match between the two sets of packets for this step of the validation to be considered successful. This guarantees that the material in the OpenPGP packets is consistent with the contents of the X.509 certificate. Second, the X.509 certificate is itself cryptographically validated. This is a straightforward matter of computing the hash over the "to be signed" portion of the certificate and running the cryptographic signature verification algorithm using that hash and using the [Page 2] -3- signature field of the certificate. This step requires that the cryptographic key material of the issuing certificate must be present; for example, it may be available on the keyring as an OpenPGP key if it was previously imported into the OpenPGP format. Together, these two steps assure that the issuing key issued the certificate, and that the resulting OpenPGP key, userid and signature packets faithfully reflect the information put into the certificate by the issuer. On this basis the X.509 certificate signature is considered to be valid. 1.3. Identifying Signing Keys The OpenPGP specification uses keyids to link signatures to the keys which issued them. X.509 uses a different method, based on the issuer name. As a result, X.509 signature packets do not have keyid subpackets. Instead, to find the key which issued an X.509 signature packet it is necessary to extract the X.509 certificate, parse it to extract the issuer field, and then to search the other X.509 signature packets on the keyring for an X.509 certificate whose subject name matches. The key to which that certificate signature is attached is the one which issued the X.509 signature being validated. 2. Importing X.509 Certificates Note that the rules and procedures below for importing an X.509 certificate must be followed precisely by any compatible implementation. This is because checking the cryptographic validity of an X.509 signature requires extracting the certificate from the X.509 signature and repeating the import process, comparing the results byte for byte with the OpenPGP key, userid and signature packets. Any variation between implementations, even seemingly inconsequential ones like changing the order of various subpackets or userid fields, will cause this bytewise comparison to fail and cause the signature to be treated as invalid. 2.1. Creating the Key Packet The first step in importing an X.509 certificate into OpenPGP is to create an OpenPGP key packet which includes the numeric key material from the certificate. X.509 certificates holding RSA, DSS or ElGamal keys may be imported. The data is extracted from the SubjectPublicKeyInfo field of the certificate and converted into OpenPGP public key format. OpenPGP public key packets contain four additional pieces of information. First, they have a version number. Version 3 and 4 packets are presently in use. Second, they have a creation date [Page 3] -4- field. Third, version 3 packets have a field encoding the duration until key expiration. And fourth, they hold an algorithm identifier for the public key algorithm the key represents. In importing the key, the keyring should be searched for an existing key whose numeric key material matches that of the certificate being imported. If a match is found, that key packet is used as the basis for filling in these other fields. This uses the version number, creation date and expiration period fields from the pre-existing key. If no matching key exists, the new OpenPGP packet is created with version 4, and the public key algorithm field is set from the type of public key in the X.509 certificate. V4 keys do not have expiration periods, so that leaves only the creation date. X.509 certificates normally do not specify a key creation date, only a certificate creation date. A somewhat complicated mechanism is available to facilitate setting a reliable key creation date field in the OpenPGP public key packet. This mechanism is intended to facilitate allowing pre-existing OpenPGP keys to acquire X.509 certificates on their key material. These X.509 certificates could then be distributed and imported into other users' OpenPGP compatible software. In order to keep the resulting OpenPGP keys compatible with the ones which were certified, OpenPGP encodes the key creation date into the X.509 certificate request which is sent to be certified. With a cooperative certificate issuing authority (CA), the key creation date is then embedded in the certificate in a special format. This ensures that when other users import the X.509 certificate, they will create the OpenPGP key with the same creation date that the original key had. This is especially important in case the importing user did not previously have a copy of the original OpenPGP key, but acquired it by importing the X.509 certificate; and then he later imports the original OpenPGP key as a conventional-format OpenPGP key, rather than as a certificate. Without the special mechanism for handling creation dates, the creation dates wouldn't match, and the keyids of the two keys would be different, making them appear to be two different keys. Putting the key creation date into the X.509 certificate helps to insure that importing the certificate will correctly reconstruct the OpenPGP key. Two alternative mechanisms are available for encoding this information into the X.509 certificate. The preferred mechanism is a custom extension created for this purpose. The OID for this extension is (1 3 6 1 4 1 3401 8 1 1), encoded as the octet string {0x06, 0x0a, 0x2b, 0x06, 0x01, 0x04, 0x01, 0x9a, 0x49, 0x08, 0x01, [Page 4] -5- 0x01}. The data for the extension is defined as: PGPExtension ::= SEQUENCE { version Version DEFAULT v1, keyCreation Time } The OpenPGP key creation data is stored in X.509 Time format, the same format used for the notBefore and notAfter subfields of the certificate validity field. This is converted to the four byte OpenPGP time format specified in RFC2440 and used as the key creation field in the new OpenPGP key packet. The second method for encoding the OpenPGP creation date into an X.509 certificate is used if the custom extension is not supported by the CA. It stores the OpenPGP creation date in a field in the subject Distinguished Name. It uses either an Organizational Unit or Description field in the subject name. The creation date is stored in one of these field types, with associated data in the format "PGPKeyCreation=0x........" where the dots are replaced by 8 hex digits that encode the creation date in OpenPGP time format. If such a field is found, the hex value after "0x" is converted to binary data and used as the creation date in the OpenPGP key packet. On import, the certificate is searched sequentially for these two possible encodings of creation date. The first match is used, although typically there would not be more than one such encoding present in a certificate. Because subject name comes before extensions, the subject name fields are checked first, then the extensions. If none of these methods work to find an OpenPGP creation date, as will typically be the case on a certificate which was created via X.509 mechanisms and not by certifying an OpenPGP key, the certificate notBefore field is converted to OpenPGP time format and used as the key creation date. 2.2. Creating the UserID Packet Two alternative methods are available to create an OpenPGP UserID packet from an X.509 certificate, the short name format and the long name format. The short name format is used if the conditions described below are met, otherwise the long name format is used. The short name format for the userid is of the form "common_name ", a widely used format for OpenPGP userids. For this format to be used it must be possible to extract a common name and email address from the certificate. The common name must come from [Page 5] -6- the subject name field. The email address may come from either the subject name, where its OID is (1 2 840 113549 1 9 1), or from a SubjectAlternativeName field in an extension, where the choice type is rfc822Name. As a special case, the short name format is also used if the subject name has only a single field, which is an email address, but there is no common name. In that case the userid is created as "". If it is not possible to satisfy these conditions for creating the userid in the short format, a long format is used. This is a slight modification of "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names" [RFC2253], applied to the subject name field of the certificate. RFC2253 puts the DN fields into reverse order, but this specification modifies that rule somewhat. The common name field (if present) is always output first, before the other fields, to improve readability. Also, any name field corresponding to the special OpenPGP key creation date field described in the section 2.1, if present, is skipped and is not output. The only DN field names which get converted into printable form for the userid are CN, C, L, ST, STREET, O, OU and EMAIL. Other fields in the DN are ignored when converting to an OpenPGP userid. Note that any SubjectAlternativeName extensions are not used when outputting a long format name. Only the fields from the subject name of the certificate are put into the OpenPGP userid packet. If no fields from the list above are found in the DN, the userid packet is created with the text "(Unknown X509 name)". 2.3. Creating the Signature Packet Creating the OpenPGP signature packet from an X.509 certificate involves two steps. The first is to include the certificate itself, in total, into a new subpacket of the OpenPGP signature packet. The second is to set up the various signature packet fields and subpackets which encode the supported semantics of the X.509 certificate. 2.3.1. X.509 Signature Subpacket Format This specification defines a new OpenPGP subpacket type. It uses subpacket type 100, defined in RFC2440 as within the private range of subpackets. The first byte of the subpacket is 1, indicating that the type of the private-range subpacket is an X.509 certificate. The [Page 6] -7- next two bytes are major and minor version numbers. The major version is 1 for all compatible implementations of this specification. The minor version reflects changes in the detailed rules for how X.509 certificates are converted to OpenPGP keys. The current minor version is 4, and this value should be used in newly created certificate subpackets. When verifying an X.509 certificate signature, the minor version number must be parsed and used to guide the conversion process. Since part of the verification involves checking for consistency between the X.509 certificate and the OpenPGP packets, any differences would cause the signature to be treated as invalid. When changes are made for how this conversion is done, the minor version must be upgraded. The only operational difference at this point is between minor version 4 vs. earlier minor version numbers of 3 or less. There is a change to the public key algorithm field used in the signature packet, as described below. No other changes presently exist based on minor version number, for importing signature, userid or key packets. The remaining data in the certificate subpacket is the X.509 certificate itself. Its length is determined implicitly by the subpacket length minus the fields already described. X.509 certificates are self-delimiting, and the certificate must end at the end of the data range in the subpacket allocated to hold it. 2.3.2. Other Signature Fields In addition to inserting the certificate bodily into a new subpacket, other fields of the OpenPGP signature packet are created to be consistent with the data from the certificate. Note that it is necessary to follow the description in this section precisely in order to create X.509 signature packets which will interoperate with other software implementing this specification. No flexibility is possible in the set of signature packets created, the contents of the packet, or the ordering of the packets. This consistency is necessary in order for the byte-for-byte packet comparison to succeed when signatures are verified. OpenPGP signature packets created from X.509 certificates are version 4 packets. The signature type field is 0x10, "generic certification of a user id and public key packet". The next field is the public key algorithm, which guides the signature verification process. As described in the introduction, X.509 signature packets cannot be cryptographically verified by the normal OpenPGP verification rules. To flag this fact and make sure an OpenPGP implementation of this [Page 7] -8- specification does not try to verify the packet, a reserved value is used for the public key algorithm field. This is the one place the minor version number from the certificate subpacket is used. For minor versions 0-3, the reserved value is 0. For minor version 4, the reserved value is 100, which is in the reserved range for RFC2440. In either case, it is meant to indicate that the regular OpenPGP certificate verification process will not work, and to prevent noncompliant OpenPGP implementations from attempting to verify signatures created by this specification. The next field in the V4 signature packet is the hash algorithm ID, which is set to the hash algorithm from the X.509 certificate. If a certificate uses a public key or hash algorithm not recognized by RFC2440, it is not allowed to be imported per this specification. The next part of the signature packet contains the so-called hashed subpackets. Note that these subpackets are not actually hashed, in an X.509 signature packet; rather, their validity is verified based on comparison with the X.509 certificate, which does get cryptographically hashed and verified. Several such subpackets are created, based on X.509 certificate data. The order of these subpackets is significant in that the certificate verification process described in section 1.2 will attempt to re-convert the X.509 certificate into an OpenPGP signature packet and do a byte-for-byte match between the re-converted data and the original signature data. The packets must be identical for the X.509 signature to be considered valid. The first subpacket is signature creation time, subpacket ID 2. This is taken from the notBefore subfield of the validity field in the certificate, and converted to OpenPGP time format. The second subpacket is signature expiration time, subpacket ID 3. This is taken from the notAfter subfield of the validity field in the certificate, and converted to OpenPGP time format. The signature creation time is then subtracted, because OpenPGP actually stores the signature validity duration in seconds in the expiration time subpacket. Next is an optional trust signature subpacket, ID 5. It is used if the imported certificate has a BasicConstraints extension with the boolean cA field being true, representing a CA certificate. The trust signature subpacket holds two bytes. The first is the trust "level", which means the depth to which trust is delegated. This is set based on any PathLenConstraint field of the BasicConstraints extension. If there is no PathLenConstraint, the level value stored in the trust packet is the maximum value of 255. If there is a [Page 8] -9- PathLenConstraint value in the certificate, the trust level stored is equal to that integer value, plus one (then truncated to one byte). The trust packet also has a second byte representing the validity of the trust being extended, which is set to 120, meaning complete validity. Next there is an optional a key flags subpacket, ID 27. It is used if there is a KeyUsage extension in the imported certificate, to encode any key usage restrictions. Not all bits in the KeyUsage extension are recognized and converted by this specification, but the key flags subpacket is created even if none of the bits are recognized, in which case the key flags subpacket will be output with a flag value of zero. The bits which are recognized, and the corresponding OpenPGP key flags values, are as follows: keyCertSign ---> flag 0x01, key can certify other keys cRLSign ---> flag 0x01, key can certify other keys digitalSignature ---> flag 0x02, key can sign data nonRepudiation ---> flag 0x02, key can sign data keyEncipherment ---> flags 0x14, key can encrypt communications and key can encrypt storage dataEncipherment ---> flags 0x14, key can encrypt communications and key can encrypt storage keyAgreement ---> flags 0x14, key can encrypt communications and key can encrypt storage All other key flag bits in the four byte field are output as zero. The last subpacket output is the X.509 certificate subpacket, ID 100, as described in section 2.3.1. above. Following the hashed data subpackets in the signature packet are the unhashed packets. No such packets are used when importing an X.509 signature, so the length of the unhashed region must be zero. Note in particular that X.509 signature packets do not have an issuing keyid field. This is because X.509 certificates refer to their issuer by name, rather than by keyid, as discussed in section 1.3. Next comes a two byte checksum, which is set to two bytes of zero. Finally there is the MPI data for the OpenPGP signature. No MPI data is used for signatures in this specification, so a dummy MPI value of 1 is stored, represented as the three byte sequence 0, 1, 1. That ends the OpenPGP signature packet. [Page 9] -10- 3. References [PGP] PGP Corporation, http://www.pgp.com. [RFC2253] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December, 1997. [RFC2440] J. Callas, L. Donnerhacke, H. Finney, R. Thayer, "OpenPGP Message Format", RFC 2440, November, 1998. [X.509-00] ITU-T. Recommendation X.509: The Directory - Authentication Framework. 2000. [Page 10] Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33JYETm054483; Sun, 3 Apr 2005 12:34:14 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33JYEE6054482; Sun, 3 Apr 2005 12:34:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from p15139323.pureserver.info (silmor.de [217.160.219.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33JYDY7054471 for ; Sun, 3 Apr 2005 12:34:13 -0700 (PDT) (envelope-from konrad@silmor.de) Received: from p548c9f4c.dip.t-dialin.net ([84.140.159.76] helo=zaphod.local) by p15139323.pureserver.info with asmtp (Exim 3.35 #1 (Debian)) id 1DIAr5-0000a9-00; Sun, 03 Apr 2005 21:33:56 +0200 From: Konrad Rosenbaum To: Ben Laurie Subject: Re: How to Calculate Signatures? Date: Sun, 3 Apr 2005 21:33:50 +0200 User-Agent: KMail/1.7.2 References: <20050402201614.31E9157EE9@finney.org> <200504031948.22079@zaphod.konrad.silmor.de> <42503B09.8090608@algroup.co.uk> In-Reply-To: <42503B09.8090608@algroup.co.uk> Cc: ietf-openpgp@imc.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1781299.3IFMXeiy2q"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504032133.54375@zaphod.konrad.silmor.de> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --nextPart1781299.3IFMXeiy2q Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 03 April 2005 20:50, Ben Laurie wrote: > Konrad Rosenbaum wrote: > > Simple: you don't. DSA was designed to be used with SHA-1, which is 160 > > bit. Since SHA-1 is theoretically broken (practically will probably > > follow in a few months) one should see what the NIST makes of it. > > Supplanting a broken hash with another hash doesn't make much sense > > with DSA, since it does not contain the ID of the hash (as PKCS#1 does > > for RSA) - so any attacker could find a collission with the broken hash > > and then simply change the hash ID in the signature packet. > > The hash does include the ID of the hash, and hence the signature does. That does not prevent a downgrade attack. Presume the following scenario: The signature S is under Text A with hash algorithm H. The hash is deemed=20 secure. So s contains the number of H and the content of A. The structure looks lik= e=20 this: Text packet A Signature packet S Hash number H signed(Hash_H(H_number || A)) # or something very similiar Now we want the signature to refer to Text B and we know that hash algorith= m=20 X is insecure (and we know how to use that). What we need to do now is we=20 need to find a text C that consists of the the number of X, and B plus some= =20 "random" that is chosen in a way that does not distort the meaning (eg. a=20 "geek code block" below the actual eMail text). The structure will look=20 like: Text packet C ( =3D B || "random") Signature packet S' Hash number X signed(Hash_H(H_number || A)) =3D=3D signed(Hash_X(X_number || C)) =2E..and that all because a weak Hash X will enable us to find a text that= =20 creates the same hash sum in X that we want to supplant for a hash sum of H= =20 =2D regardless of whether we hash the hash number, a "magic" code or my gra= nd=20 mothers birthday into it. MD5 is already beaten down to 33 bit, it is only a question of time till=20 SHA-1 is there as well (granted, we'll probably have some months left).=20 Currently we are only save because there is no 160-bit Hash in OpenPGP that= =20 is vulnerable enough to make the attack worthwhile. The days of DSA with a 160-bit p are counted. Period. Konrad PS.: please view my DSA signature on this mail as my last action of respect= =20 to DSA. It was a good fellow... ;-) --nextPart1781299.3IFMXeiy2q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBCUEUiClt766LaIH0RAhpRAJ9lasC4YLMj6JEH189fdwKlqbZNtACfbwCY 7hPM24b+qlIBOpvOY6ub7Mo= =4hJF -----END PGP SIGNATURE----- --nextPart1781299.3IFMXeiy2q-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35C4wUR053328; Tue, 5 Apr 2005 05:04:58 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35C4wCl053327; Tue, 5 Apr 2005 05:04:58 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j35C4uGO053307 for ; Tue, 5 Apr 2005 05:04:57 -0700 (PDT) (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 21F9D33C33; Tue, 5 Apr 2005 13:04:55 +0100 (BST) Message-ID: <42527EE7.2040503@algroup.co.uk> Date: Tue, 05 Apr 2005 13:04:55 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Callas Cc: OpenPGP Subject: Re: New Encrypted Data Packet? References: In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: > > When the Mister-Zuccherato attack came out at the beginning of the year, > one of the suggestions that we had was to re-do the encrypted data > packet and MDC. It seems that there's not really a lot of consensus to > fix it, that merely working around the problem seems to be adequate? Am > I right in that perception? Do we want to upgrade it? I missed this discussion, I think, and can't seem to find it in the archives. Do you have a refrence? > I still think it's a good idea, myself, particularly since if you want > wide deployment of such a thing for the future getting on it now is a > good idea. But I would also like to really close out 2440bis, too. > (However, the two are not mutually exclusive. We could close out 2440bis > and put the upgrades into a followon RFC.) That sounds like a plan. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34KoFZn067184; Mon, 4 Apr 2005 13:50:15 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34KoFYM067183; Mon, 4 Apr 2005 13:50:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.202.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34KoFSH067170 for ; Mon, 4 Apr 2005 13:50:15 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (sccrmhc14) with ESMTP id <2005040420500701400dlu8ie>; Mon, 4 Apr 2005 20:50:07 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j34KoAQr007276 for ; Mon, 4 Apr 2005 16:50:10 -0400 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 j34Ko7ZC022703 for ; Mon, 4 Apr 2005 16:50:07 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j34Ko7ZJ022702 for ietf-openpgp@imc.org; Mon, 4 Apr 2005 16:50:07 -0400 Date: Mon, 4 Apr 2005 16:50:07 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? Message-ID: <20050404205007.GA22676@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20050404043638.42B3F57EBA@finney.org> <42515A30.3060204@systemics.com> <3f5a429b03ed3a28992f269562b05eff@callas.org> <42516C7F.3050307@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42516C7F.3050307@algroup.co.uk> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Apr 04, 2005 at 05:34:07PM +0100, Ben Laurie wrote: > >Yup. And the same thing applies to V3 keys as well. I've had vocal > >complaints from people about their V3 key and how they're upset about > >losing whatever trust issues there are from it being a decade or more old. > > So what's wrong with signing your V4 key with your V3 key and moving on? Because that would make the V4 key One More Hop Away, of course. ;) David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34KVGcT065571; Mon, 4 Apr 2005 13:31:16 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34KVG5J065570; Mon, 4 Apr 2005 13:31:16 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j34KVGOL065564 for ; Mon, 4 Apr 2005 13:31:16 -0700 (PDT) (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.6); Mon, 4 Apr 2005 13:31:15 -0700 Received: from [12.111.6.63] ([12.111.6.63]) by keys.merrymeet.com (PGP Universal service); Mon, 04 Apr 2005 13:31:15 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 04 Apr 2005 13:31:15 -0700 In-Reply-To: <42516C7F.3050307@algroup.co.uk> References: <20050404043638.42B3F57EBA@finney.org> <42515A30.3060204@systemics.com> <3f5a429b03ed3a28992f269562b05eff@callas.org> <42516C7F.3050307@algroup.co.uk> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <10ff14b4c7011f115972f028d0488a6c@callas.org> Content-Transfer-Encoding: 7bit Cc: OpenPGP From: Jon Callas Subject: Re: How to Calculate Signatures? Date: Mon, 4 Apr 2005 13:32:39 -0700 To: Ben Laurie X-Mailer: Apple Mail (2.619.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 4 Apr 2005, at 9:34 AM, Ben Laurie wrote: > > So what's wrong with signing your V4 key with your V3 key and moving > on? > > Beats me. People get attached to things. Attachments to things cause all sorts of irrational behavior. I suspect in a lot of cases, people get attached to an old key because of the number or quality of certs. It's similar to the, "I'll never wash that hand again!" response to shaking hands with a celeb. Jon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34KQKFq065125; Mon, 4 Apr 2005 13:26:20 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34KQKOl065123; Mon, 4 Apr 2005 13:26:20 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j34KQJf2065117 for ; Mon, 4 Apr 2005 13:26:19 -0700 (PDT) (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.6); Mon, 4 Apr 2005 13:26:18 -0700 Received: from [12.111.6.63] ([12.111.6.63]) by keys.merrymeet.com (PGP Universal service); Mon, 04 Apr 2005 13:26:18 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 04 Apr 2005 13:26:18 -0700 In-Reply-To: <42516D37.5000504@systemics.com> References: <42516D37.5000504@systemics.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: OpenPGP From: Jon Callas Subject: Re: New Encrypted Data Packet? Date: Mon, 4 Apr 2005 13:27:37 -0700 To: Ian G X-Mailer: Apple Mail (2.619.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > (Which would not be to say that Ben's observations over the > weekend didn't look extremely useful.) > I'm going to look through Ben's suggestions and fold them into a new draft. > (As to future revisions, I recall in prior times it has been > discussed that we wouldn't talk about future changes until > 2440bis was closed out.) > Yeah, but security-related cryptographic changes are always the obvious exception. Jon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34JOs2X060003; Mon, 4 Apr 2005 12:24:54 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34JOsJJ060002; Mon, 4 Apr 2005 12:24:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34JOrEI059972 for ; Mon, 4 Apr 2005 12:24:54 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (rwcrmhc14) with ESMTP id <2005040419244901400ahcjse>; Mon, 4 Apr 2005 19:24:49 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j34JOlQr006906 for ; Mon, 4 Apr 2005 15:24:47 -0400 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 j34JOjSh022550 for ; Mon, 4 Apr 2005 15:24:45 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j34JOj9T022549 for ietf-openpgp@imc.org; Mon, 4 Apr 2005 15:24:45 -0400 Date: Mon, 4 Apr 2005 15:24:45 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? Message-ID: <20050404192445.GD22111@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20050404180805.A9E9F57EBA@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050404180805.A9E9F57EBA@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Apr 04, 2005 at 11:08:05AM -0700, "Hal Finney" wrote: > I agree that if it takes that long for the change to propagate, we > are probably better off waiting for NIST to come up with FIPS 186-3 > which will specify how to use SHA-2 with DSS. I think it would take a good long while for the change to propagate. I don't know about other implementations, but there is no support for this in GnuPG. Adding support is trivial, to be sure, but getting however many GnuPG installations to upgrade (with no compatibility with many DSA signatures in the meantime) would be a pretty substantial problem. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34HsaGL052023; Mon, 4 Apr 2005 10:54:36 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34Hsa2K052022; Mon, 4 Apr 2005 10:54:36 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j34HsZpF052015 for ; Mon, 4 Apr 2005 10:54:35 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id A9E9F57EBA; Mon, 4 Apr 2005 11:08:05 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? Message-Id: <20050404180805.A9E9F57EBA@finney.org> Date: Mon, 4 Apr 2005 11:08:05 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ian G wrote: > >>I'm curious on this point. Other than the fact that > >>"it's broken" why is it that you see it important to > >>repair the DSA in OpenPGP? > > > Hal Finney wrote: > > I'm not sure if you are asking why we worry about using SHA-1 at all given > > that the attack is theoretical, or why we don't just abandon DSA keys. Ian replied: > I'd say it is an open question, so either or both. > > Hal Finney wrote: > > For the first question, my main concern is that the SHA-1 attack > > may get worse so that it becomes computationally feasible to find > > collisions. If that happens we could be vulnerable to attacks like > > http://eprint.iacr.org/2005/067 which showed two X.509 certificates > > with the same hash. The attacks could become even stronger to where > > different userids could collide. > > I think now I understand this as more an issue for > WoT than documents - is that right? (I think I'm > deriving that from the last sentance above...) In > that people who have DSA keys and have lots of sigs > are faced with losing their 'investment'. The WoT issue related to the 2nd question about maintaining usability of DSA keys. The paragraph above related to the 1st question which was, why are we worrying about the SHA-1 attack at all, given that it is purely theoretical and no one has even exhibited a SHA-1 collision. In the context of that question, it would apply to other situations than just key signatures. Ordinary document signatures could be vulnerable. Alice could prepare a document for Bob to sign, arranging it that there are two versions. It could also apply to RSA users who are continuing to use SHA-1. If the attack worsened, they could be invited to sign someone's key, and then the data being signed could change. Again, keep in mind that these paragraphs answer the question, why are we worried about the attack at all. Focus on that question in reading the paragraphs above. > > For the second, DSA key users do not presently have the options RSA > > key users do to move to other hashes. As I argued, the additional risk > > of giving DSA users more options is not that large. Letting them use > > other hashes would allow them to continue to use their existing keys > > and benefit from the signatures they have acquired on those keys. > > > OK. In risk terms it might not be that high. But > in cost terms, it is significant. Any changes to > the way signatures have to be dealt with would have > to be promulgated through the community, as, if the > signature verification wasn't standard and acceptable > to all code bases, it loses its value rapidly. I agree that if it takes that long for the change to propagate, we are probably better off waiting for NIST to come up with FIPS 186-3 which will specify how to use SHA-2 with DSS. I have a faint hope that they may do something about including a hash algorithm specifier that would make the standard more robust against hash breaks. Even a one octet hash ID similar to what we use in PGP would greatly improve the flexibility. The only reason I hold out this hope is that otherwise I don't see what is taking them so long in releasing this spec. It's been something like two years since they announced that it was imminent. If all they are going to do is to come up with a few (p, q) size recommendations then it shouldn't take that long. If they don't do it, maybe we should think about doing this ourselves, for next gen DSA keys. We could include a one byte hash octet ID at the front of the hash, and make the q size 8 bits bigger. It would mean that we are not fully DSS compliant but as Jon points out we are not quite that way now. Hal Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34Ga8qp044526; Mon, 4 Apr 2005 09:36:08 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34Ga8pl044525; Mon, 4 Apr 2005 09:36:08 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j34Ga7bL044518 for ; Mon, 4 Apr 2005 09:36:07 -0700 (PDT) (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 2061233C45; Mon, 4 Apr 2005 17:36:06 +0100 (BST) Message-ID: <42516C7F.3050307@algroup.co.uk> Date: Mon, 04 Apr 2005 17:34:07 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Callas Cc: Ian G , ietf-openpgp@imc.org, Hal Finney Subject: Re: How to Calculate Signatures? References: <20050404043638.42B3F57EBA@finney.org> <42515A30.3060204@systemics.com> <3f5a429b03ed3a28992f269562b05eff@callas.org> In-Reply-To: <3f5a429b03ed3a28992f269562b05eff@callas.org> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: > >> >> So the analysis needs to question not only the risks >> but also the costs and benefits. >> >> The number of people who need to have DSA and keep >> using their existing keys for signatures seems to be >> quite small. In order for these people to benefit, >> they must be able to create the sigs, and everyone >> else must be able to at least read the sigs. So >> any change will take a year or two to filter through >> until there is wide enough distribution of verification, >> and during that time, I suspect the slow uptake will >> be over taken by events. >> >> > > Yup. And the same thing applies to V3 keys as well. I've had vocal > complaints from people about their V3 key and how they're upset about > losing whatever trust issues there are from it being a decade or more old. So what's wrong with signing your V4 key with your V3 key and moving on? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34GY17c044352; Mon, 4 Apr 2005 09:34:01 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34GY0C4044351; Mon, 4 Apr 2005 09:34:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34GXxiN044339 for ; Mon, 4 Apr 2005 09:34:00 -0700 (PDT) (envelope-from iang@systemics.com) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j34GXVU09214; Mon, 4 Apr 2005 17:33:42 +0100 X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol Message-ID: <42516D37.5000504@systemics.com> Date: Mon, 04 Apr 2005 17:37:11 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0 (X11/20050219) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Callas CC: OpenPGP Subject: Re: New Encrypted Data Packet? References: In-Reply-To: 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: > > When the Mister-Zuccherato attack came out at the beginning of the year, > one of the suggestions that we had was to re-do the encrypted data > packet and MDC. It seems that there's not really a lot of consensus to > fix it, that merely working around the problem seems to be adequate? Am > I right in that perception? Do we want to upgrade it? > > I still think it's a good idea, myself, particularly since if you want > wide deployment of such a thing for the future getting on it now is a > good idea. But I would also like to really close out 2440bis, too. > (However, the two are not mutually exclusive. We could close out 2440bis > and put the upgrades into a followon RFC.) Close out 2440bis, with no more changes. I think we are well past the point where fiddling around improving things is worth anything. Unless we have a major major break, nothing should change in the protocol, would be my call. (Which would not be to say that Ben's observations over the weekend didn't look extremely useful.) (As to future revisions, I recall in prior times it has been discussed that we wouldn't talk about future changes until 2440bis was closed out.) iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34G96RW041468; Mon, 4 Apr 2005 09:09:06 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34G96rJ041467; Mon, 4 Apr 2005 09:09:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtpq1.home.nl (smtpq1.home.nl [213.51.128.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34G95Ho041459 for ; Mon, 4 Apr 2005 09:09:06 -0700 (PDT) (envelope-from edwin@woudt.nl) Received: from [213.51.128.135] (port=44697 helo=smtp4.home.nl) by smtpq1.home.nl with esmtp (Exim 4.30) id 1DIU8N-00059C-Qk; Mon, 04 Apr 2005 18:09:03 +0200 Received: from cc718542-a.ensch1.ov.home.nl ([82.75.235.211]:2952 helo=[10.24.64.4]) by smtp4.home.nl with esmtp (Exim 4.30) id 1DIU8M-0007Ta-Di; Mon, 04 Apr 2005 18:09:02 +0200 Date: Mon, 04 Apr 2005 18:09:02 +0200 From: Edwin Woudt To: Jon Callas , OpenPGP Subject: Re: New Encrypted Data Packet? Message-ID: <657710228390B0569A1FC1D1@[10.24.64.4]> In-Reply-To: References: X-Mailer: Mulberry/4.0.0a7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-AtHome-MailScanner-Information: Neem contact op met support@home.nl voor meer informatie X-AtHome-MailScanner: Found to be clean Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --On 4-4-2005 8:27 -0700 Jon Callas wrote: > > When the Mister-Zuccherato attack came out at the beginning of the year, > one of the suggestions that we had was to re-do the encrypted data packet > and MDC. It seems that there's not really a lot of consensus to fix it, > that merely working around the problem seems to be adequate? Am I right > in that perception? Do we want to upgrade it? > > I still think it's a good idea, myself, particularly since if you want > wide deployment of such a thing for the future getting on it now is a > good idea. But I would also like to really close out 2440bis, too. > (However, the two are not mutually exclusive. We could close out 2440bis > and put the upgrades into a followon RFC.) I agree it is a good idea, but not for 2440bis. As there is a workaround, I would say: add a note about the attack and the workaround to 2440bis and get it finished. Redoing the encrypted data packet can then be implemented together with v5 keys and any other hash related changes. This also solves the problem of deciding which implementations support such a new encrypted data packet: just use the new packet for v5 keys, and the old ones for v4 and below. -- Edwin Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34FlL82039987; Mon, 4 Apr 2005 08:47:21 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34FlLLe039986; Mon, 4 Apr 2005 08:47:21 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j34FlKE2039978 for ; Mon, 4 Apr 2005 08:47:20 -0700 (PDT) (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.6); Mon, 4 Apr 2005 08:47:18 -0700 Received: from [172.16.1.2] ([12.111.6.59]) by keys.merrymeet.com (PGP Universal service); Mon, 04 Apr 2005 08:47:18 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 04 Apr 2005 08:47:18 -0700 In-Reply-To: <42515A30.3060204@systemics.com> References: <20050404043638.42B3F57EBA@finney.org> <42515A30.3060204@systemics.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3f5a429b03ed3a28992f269562b05eff@callas.org> Content-Transfer-Encoding: 7bit Cc: ietf-openpgp@imc.org, Hal Finney From: Jon Callas Subject: Re: How to Calculate Signatures? Date: Mon, 4 Apr 2005 08:48:35 -0700 To: Ian G X-Mailer: Apple Mail (2.619.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > So the analysis needs to question not only the risks > but also the costs and benefits. > > The number of people who need to have DSA and keep > using their existing keys for signatures seems to be > quite small. In order for these people to benefit, > they must be able to create the sigs, and everyone > else must be able to at least read the sigs. So > any change will take a year or two to filter through > until there is wide enough distribution of verification, > and during that time, I suspect the slow uptake will > be over taken by events. > > Yup. And the same thing applies to V3 keys as well. I've had vocal complaints from people about their V3 key and how they're upset about losing whatever trust issues there are from it being a decade or more old. I'm not so worried about DSS that I'm going to dump my older key. But I might recommend to someone creating a new key that today, RSA is a better choice because of SHA-1 issues and lack of wide-DSS. But that could change tomorrow or next week. Jon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34FQ8k8038227; Mon, 4 Apr 2005 08:26:08 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34FQ8ch038226; Mon, 4 Apr 2005 08:26:08 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j34FQ7YC038219 for ; Mon, 4 Apr 2005 08:26:07 -0700 (PDT) (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.6) for ; Mon, 4 Apr 2005 08:26:06 -0700 Received: from [172.16.1.2] ([12.111.6.59]) by keys.merrymeet.com (PGP Universal service); Mon, 04 Apr 2005 08:26:06 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 04 Apr 2005 08:26:06 -0700 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: OpenPGP From: Jon Callas Subject: New Encrypted Data Packet? Date: Mon, 4 Apr 2005 08:27:32 -0700 X-Mailer: Apple Mail (2.619.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: When the Mister-Zuccherato attack came out at the beginning of the year, one of the suggestions that we had was to re-do the encrypted data packet and MDC. It seems that there's not really a lot of consensus to fix it, that merely working around the problem seems to be adequate? Am I right in that perception? Do we want to upgrade it? I still think it's a good idea, myself, particularly since if you want wide deployment of such a thing for the future getting on it now is a good idea. But I would also like to really close out 2440bis, too. (However, the two are not mutually exclusive. We could close out 2440bis and put the upgrades into a followon RFC.) Jon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34FCkxO036867; Mon, 4 Apr 2005 08:12:46 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34FCkJo036866; Mon, 4 Apr 2005 08:12:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34FCg8l036852 for ; Mon, 4 Apr 2005 08:12:43 -0700 (PDT) (envelope-from iang@systemics.com) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j34FCKU08395; Mon, 4 Apr 2005 16:12:31 +0100 X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol Message-ID: <42515A30.3060204@systemics.com> Date: Mon, 04 Apr 2005 16:16:00 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0 (X11/20050219) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: Hal Finney Subject: Re: How to Calculate Signatures? References: <20050404043638.42B3F57EBA@finney.org> In-Reply-To: <20050404043638.42B3F57EBA@finney.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: Hal Finney wrote: > Ian G writes: > >>I'm curious on this point. Other than the fact that >>"it's broken" why is it that you see it important to >>repair the DSA in OpenPGP? > > > I'm not sure if you are asking why we worry about using SHA-1 at all given > that the attack is theoretical, or why we don't just abandon DSA keys. I'd say it is an open question, so either or both. > For the first question, my main concern is that the SHA-1 attack > may get worse so that it becomes computationally feasible to find > collisions. If that happens we could be vulnerable to attacks like > http://eprint.iacr.org/2005/067 which showed two X.509 certificates > with the same hash. The attacks could become even stronger to where > different userids could collide. I think now I understand this as more an issue for WoT than documents - is that right? (I think I'm deriving that from the last sentance above...) In that people who have DSA keys and have lots of sigs are faced with losing their 'investment'. OK, I agree that is potentially a larger concern than document sigs as key signing represents something of an institution. > For the second, DSA key users do not presently have the options RSA > key users do to move to other hashes. As I argued, the additional risk > of giving DSA users more options is not that large. Letting them use > other hashes would allow them to continue to use their existing keys > and benefit from the signatures they have acquired on those keys. OK. In risk terms it might not be that high. But in cost terms, it is significant. Any changes to the way signatures have to be dealt with would have to be promulgated through the community, as, if the signature verification wasn't standard and acceptable to all code bases, it loses its value rapidly. So the analysis needs to question not only the risks but also the costs and benefits. The number of people who need to have DSA and keep using their existing keys for signatures seems to be quite small. In order for these people to benefit, they must be able to create the sigs, and everyone else must be able to at least read the sigs. So any change will take a year or two to filter through until there is wide enough distribution of verification, and during that time, I suspect the slow uptake will be over taken by events. To me, I don't see the cost-benefit analysis coming out as favourable; far better to suggest that people use RSA keys if they are really very keen to have the best security in signatures, until the DSS-2 situation settles out. (in the 90s, this would have been a very different situation, as RSA faced patent and cryptoexport problems, so there would have been a group that might have been limited to using DSA.) All IMHO of course! iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34E9R5h030791; Mon, 4 Apr 2005 07:09:27 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34E9RbR030790; Mon, 4 Apr 2005 07:09:27 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j34E9QZS030775 for ; Mon, 4 Apr 2005 07:09:26 -0700 (PDT) (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.6); Mon, 4 Apr 2005 06:39:23 -0700 Received: from [172.16.1.2] ([12.111.6.59]) by keys.merrymeet.com (PGP Universal service); Mon, 04 Apr 2005 06:39:23 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 04 Apr 2005 06:39:23 -0700 In-Reply-To: <42505FF3.7030409@systemics.com> References: <20050403193929.0812057EBA@finney.org> <42505164.7040807@algroup.co.uk> <42505FF3.7030409@systemics.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <489a97f77e8d6f130c30363b9bf05f45@callas.org> Content-Transfer-Encoding: 7bit Cc: ietf-openpgp@imc.org, Ben Laurie From: Jon Callas Subject: Re: How to Calculate Signatures? Date: Mon, 4 Apr 2005 06:40:21 -0700 To: Ian G X-Mailer: Apple Mail (2.619.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 3 Apr 2005, at 2:28 PM, Ian G wrote: > PS: As a point of notation for the RFC, isn't it DSS? > Or are we saying that DSA is implemented because it > is not quite DSS? > DSA is the Digital Signature Algorithm. DSS is the Digital Signature Standard. DSS specifies DSA+SHA1 plus operational whatsits. If you use DSA with RIPE/MD-160, for example, it's not DSS. 2440 does cover all of this. Jon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34E9RVk030785; Mon, 4 Apr 2005 07:09:27 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34E9RHb030784; Mon, 4 Apr 2005 07:09:27 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j34E9QZU030775 for ; Mon, 4 Apr 2005 07:09:26 -0700 (PDT) (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.6); Mon, 4 Apr 2005 06:42:54 -0700 Received: from [172.16.1.2] ([12.111.6.59]) by keys.merrymeet.com (PGP Universal service); Mon, 04 Apr 2005 06:42:54 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 04 Apr 2005 06:42:54 -0700 In-Reply-To: <20050403193929.0812057EBA@finney.org> References: <20050403193929.0812057EBA@finney.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ietf-openpgp@imc.org From: Jon Callas Subject: Re: How to Calculate Signatures? Date: Mon, 4 Apr 2005 06:44:21 -0700 To: hal@finney.org ("Hal Finney") X-Mailer: Apple Mail (2.619.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 3 Apr 2005, at 12:39 PM, Hal Finney wrote: > For all of these reasons, I am tempted to allow the SHA-2 family with > current DSA keys, as an interim measure pending the move to DSS-2. > > FIPS 180, which defines the SHA family, had a change notice to add > SHA-224, > a truncated form of SHA-256. This document, > -2withchangenotice.pdf>, > describes truncation of hash algorithms on page 73: > > "Some applications may require a hash function with an output size > (i.e., > message digest size) different than those provided by the hash > functions > in this Standard. In such cases, a truncated hash output may be used, > whereby a hash function with a larger output size is applied to the > data to be hashed, and the resulting output (i.e., message digest) is > truncated by selecting an appropriate number of the leftmost bits. For > example, if an output of 96 bits is desired, the SHA256 hash function > could be used (e.g., because it is available to the application), and > the leftmost 96 bits of the output are selected as the message digest, > discarding the rightmost 160 bits of the SHA-256 output." > This is the reason that Beta 1 of PGP 9.0 allowed SHA-256, and did precisely that. However, we decided that that was pushing things, and it's not going to be in Beta 2. Jon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j344NBpY041925; Sun, 3 Apr 2005 21:23:11 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j344NB0o041923; Sun, 3 Apr 2005 21:23:11 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j344NAqi041916 for ; Sun, 3 Apr 2005 21:23:11 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 42B3F57EBA; Sun, 3 Apr 2005 21:36:38 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? Message-Id: <20050404043638.42B3F57EBA@finney.org> Date: Sun, 3 Apr 2005 21:36:38 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ian G writes: > I'm curious on this point. Other than the fact that > "it's broken" why is it that you see it important to > repair the DSA in OpenPGP? I'm not sure if you are asking why we worry about using SHA-1 at all given that the attack is theoretical, or why we don't just abandon DSA keys. For the first question, my main concern is that the SHA-1 attack may get worse so that it becomes computationally feasible to find collisions. If that happens we could be vulnerable to attacks like http://eprint.iacr.org/2005/067 which showed two X.509 certificates with the same hash. The attacks could become even stronger to where different userids could collide. For the second, DSA key users do not presently have the options RSA key users do to move to other hashes. As I argued, the additional risk of giving DSA users more options is not that large. Letting them use other hashes would allow them to continue to use their existing keys and benefit from the signatures they have acquired on those keys. Hal Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33LP4hB061573; Sun, 3 Apr 2005 14:25:05 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33LP45S061572; Sun, 3 Apr 2005 14:25:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33LP3Y1061566 for ; Sun, 3 Apr 2005 14:25:04 -0700 (PDT) (envelope-from iang@systemics.com) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j33LOeU03545; Sun, 3 Apr 2005 22:24:50 +0100 X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol Message-ID: <42505FF3.7030409@systemics.com> Date: Sun, 03 Apr 2005 22:28:19 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0 (X11/20050219) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Laurie CC: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? References: <20050403193929.0812057EBA@finney.org> <42505164.7040807@algroup.co.uk> In-Reply-To: <42505164.7040807@algroup.co.uk> 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: Ben Laurie wrote: > > Hal Finney wrote: > >> On this basis, if we did want to support the larger SHA hashes, we should >> truncate them and keep the left 160 bits for use with existing DSA keys. > > > Yes, please. I'm curious on this point. Other than the fact that "it's broken" why is it that you see it important to repair the DSA in OpenPGP? iang PS: As a point of notation for the RFC, isn't it DSS? Or are we saying that DSA is implemented because it is not quite DSS? -- News and views on what matters in finance+crypto: http://financialcryptography.com/ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33LMn8e061413; Sun, 3 Apr 2005 14:22:49 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33LMn6X061412; Sun, 3 Apr 2005 14:22:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33LMlRT061403 for ; Sun, 3 Apr 2005 14:22:48 -0700 (PDT) (envelope-from iang@systemics.com) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j33LMVU03537 for ; Sun, 3 Apr 2005 22:22:41 +0100 X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol Message-ID: <42505F72.902@systemics.com> Date: Sun, 03 Apr 2005 22:26:10 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0 (X11/20050219) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? References: <20050403194540.2563D57EBA@finney.org> In-Reply-To: <20050403194540.2563D57EBA@finney.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: Hal Finney wrote: > Unfortunately, that doesn't protect against the attack. The ID of SHA-1 > is 2 and the ID of RIPEMD-160 is 3. If SHA-1 were broken badly enough > it's entirely possible that we could find m1 and m2 such that: > > SHA1 (2 || m1) == RIPEMD160 (3 || m2). > > The mere fact that you feed the hash algorithm ID into the hash algorithm > doesn't stop you from finding collisions with a different, broken hash > algorithm. Which would seem to be mildly supportive of locking DSA with SHA1? > The situation is different with RSA, where you do: > > RSA_Sign (Alg ID || Hash). > > Now, it is impossible to get collisions using two different algorithm ID's > because the algorithm ID is outside the hash. And this would seem to suggest that rather than tinkering with DSA, we should prefer a completely new signature algorithm? iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33KSHCP057539; Sun, 3 Apr 2005 13:28:17 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33KSHSa057538; Sun, 3 Apr 2005 13:28:17 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j33KSFtZ057527 for ; Sun, 3 Apr 2005 13:28:16 -0700 (PDT) (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 254E733C33; Sun, 3 Apr 2005 21:28:12 +0100 (BST) Message-ID: <42505164.7040807@algroup.co.uk> Date: Sun, 03 Apr 2005 21:26:12 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? References: <20050403193929.0812057EBA@finney.org> In-Reply-To: <20050403193929.0812057EBA@finney.org> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: Hal Finney wrote: > On this basis, if we did want to support the larger SHA hashes, we should > truncate them and keep the left 160 bits for use with existing DSA keys. Yes, please. And "doh!" on the downgrade attack. Must think before posting. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33JxXd9055904; Sun, 3 Apr 2005 12:59:35 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33JxXM4055903; Sun, 3 Apr 2005 12:59:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33JxVLD055896 for ; Sun, 3 Apr 2005 12:59:32 -0700 (PDT) (envelope-from iang@systemics.com) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j33JxEU03221 for ; Sun, 3 Apr 2005 20:59:25 +0100 X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol Message-ID: <42504BEE.9000303@systemics.com> Date: Sun, 03 Apr 2005 21:02:54 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0 (X11/20050219) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? References: <20050402201614.31E9157EE9@finney.org> <425005AE.5030105@algroup.co.uk> <42501CD7.4070005@algroup.co.uk> <200504031948.22079@zaphod.konrad.silmor.de> <4250389F.4050301@systemics.com> <42503B87.4090509@algroup.co.uk> In-Reply-To: <42503B87.4090509@algroup.co.uk> 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: Ben Laurie wrote: > >> Would it be a good idea to put in a statement >> explicitly limiting OpenPGP's view of DSS to be >> SHA1 only? And add a comment perhaps that in the >> light of weaknesses in SHA1, that RSA with a fatter >> digest be used instead as a workaround? > > > The cost of that is that anyone with a DSA key is screwed. Seems like a > last resort to me. Anyone who has a DSA key now is screwed if: * the SHA1 hash is shown to be breached for: - pre-images, or - they have a collision-sensitive signature system, and, * the attacks are within reach by their attackers, and * they cannot change their document format, and * they cannot change to RSA, and * they cannot simply repudiate any false dox, and * they actually use DSA sigs for something important. Seems like a tough list to me. My systems use OpenPGP sigs for real stuff (as opposed to just signing mail because it exists there) and none of the above are even remotely a threat that I can see. Maybe I am screwed, but seeing as I don't see how, I'm willing to run that risk and maybe I'll find out :) I personally don't see much merit in changing the situation until something decent comes along. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33JWFWs054390; Sun, 3 Apr 2005 12:32:15 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33JWFBR054389; Sun, 3 Apr 2005 12:32:15 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j33JWEsd054380 for ; Sun, 3 Apr 2005 12:32:14 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 2563D57EBA; Sun, 3 Apr 2005 12:45:40 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? Message-Id: <20050403194540.2563D57EBA@finney.org> Date: Sun, 3 Apr 2005 12:45:40 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ben Laurie writes: > The hash does include the ID of the hash, and hence the signature does. Unfortunately, that doesn't protect against the attack. The ID of SHA-1 is 2 and the ID of RIPEMD-160 is 3. If SHA-1 were broken badly enough it's entirely possible that we could find m1 and m2 such that: SHA1 (2 || m1) == RIPEMD160 (3 || m2). The mere fact that you feed the hash algorithm ID into the hash algorithm doesn't stop you from finding collisions with a different, broken hash algorithm. The situation is different with RSA, where you do: RSA_Sign (Alg ID || Hash). Now, it is impossible to get collisions using two different algorithm ID's because the algorithm ID is outside the hash. Hal Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33JQ3kr054063; Sun, 3 Apr 2005 12:26:03 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33JQ3lH054062; Sun, 3 Apr 2005 12:26:03 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j33JQ34C054056 for ; Sun, 3 Apr 2005 12:26:03 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 0812057EBA; Sun, 3 Apr 2005 12:39:29 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? Message-Id: <20050403193929.0812057EBA@finney.org> Date: Sun, 3 Apr 2005 12:39:29 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Konrad Rosenbaum writes: > On Sunday 03 April 2005 18:41, Ben Laurie wrote: > > Oh, yes. This left me with an unresolved issue: how does one use > > SHA{256,384,512} with DSA (which requires a 160 bit hash). > > Simple: you don't. DSA was designed to be used with SHA-1, which is 160 bit. > Since SHA-1 is theoretically broken (practically will probably follow in a > few months) one should see what the NIST makes of it. Supplanting a broken > hash with another hash doesn't make much sense with DSA, since it does not > contain the ID of the hash (as PKCS#1 does for RSA) - so any attacker could > find a collission with the broken hash and then simply change the hash ID > in the signature packet. I have mixed feelings on this issue. The situation is complex: - RFC 2440 has always allowed hashes other than SHA-1 if they matched the size of q. The only one that fit was RIPEMD-160. This already opens the attack Konrad describes. If RIPEMD-160 were badly broken, you could substitute it into a DSA signature using SHA-1. - If a hash were broken, recipients can defend against this attack by not trusting signatures made with that hash. That's not all that bad. We are already in a similar situation with regard to other cryptographic components. If a signature algorithm were broken, people would have to distrust signatures made with that algorithm. Same with an encryption algorithm, people would have to know not to use it. Even with RSA, you'd have to know not to trust signatures made with a broken hash. The specific risk raised by the hash substitution attack is that a signer can't protect his signature against substitution with a broken hash, he has to rely on the verifier to know that the hash is broken and not to trust it. - The current hash breaks only allow for collisions and not preimage attacks. It is still not possible, even with MD5, to create a hash that matches a target value. Hashes would have to be broken much more severely than they are now before this would become a threat. - NIST is dragging their feet on incorporating SHA-2 into a new DSS. They have been talking about this for years. Hopefully the new results will motivate them to speed things up, but "fast" in a bureaucracy could still mean a year or more. - How can we update the replacement for RFC-2440 to incorporate a new DSS-2 or whatever it will be called? Do we need to update the base document, or can we create a separate RFC that just documents the new format? Will it be a new algorithm ID, or will we overload the DSA algorithm ID? These issues may slow down the incorporation of DSS-2 into OpenPGP even once it is announced. For all of these reasons, I am tempted to allow the SHA-2 family with current DSA keys, as an interim measure pending the move to DSS-2. FIPS 180, which defines the SHA family, had a change notice to add SHA-224, a truncated form of SHA-256. This document, , describes truncation of hash algorithms on page 73: "Some applications may require a hash function with an output size (i.e., message digest size) different than those provided by the hash functions in this Standard. In such cases, a truncated hash output may be used, whereby a hash function with a larger output size is applied to the data to be hashed, and the resulting output (i.e., message digest) is truncated by selecting an appropriate number of the leftmost bits. For example, if an output of 96 bits is desired, the SHA256 hash function could be used (e.g., because it is available to the application), and the leftmost 96 bits of the output are selected as the message digest, discarding the rightmost 160 bits of the SHA-256 output." On this basis, if we did want to support the larger SHA hashes, we should truncate them and keep the left 160 bits for use with existing DSA keys. Hal Finney Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33IsuwK052014; Sun, 3 Apr 2005 11:54:56 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33IsuCb052013; Sun, 3 Apr 2005 11:54:56 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j33IstXm052006 for ; Sun, 3 Apr 2005 11:54:55 -0700 (PDT) (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 D99EA33C33; Sun, 3 Apr 2005 19:54:54 +0100 (BST) Message-ID: <42503B87.4090509@algroup.co.uk> Date: Sun, 03 Apr 2005 19:52:55 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian G Cc: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? References: <20050402201614.31E9157EE9@finney.org> <425005AE.5030105@algroup.co.uk> <42501CD7.4070005@algroup.co.uk> <200504031948.22079@zaphod.konrad.silmor.de> <4250389F.4050301@systemics.com> In-Reply-To: <4250389F.4050301@systemics.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: Ian G wrote: > > Konrad Rosenbaum wrote: > >> On Sunday 03 April 2005 18:41, Ben Laurie wrote: >> >>> Oh, yes. This left me with an unresolved issue: how does one use >>> SHA{256,384,512} with DSA (which requires a 160 bit hash). >> >> >> >> Simple: you don't. DSA was designed to be used with SHA-1, which is >> 160 bit. Since SHA-1 is theoretically broken (practically will >> probably follow in a few months) one should see what the NIST makes of >> it. Supplanting a broken hash with another hash doesn't make much >> sense with DSA, since it does not contain the ID of the hash (as >> PKCS#1 does for RSA) - so any attacker could find a collission with >> the broken hash and then simply change the hash ID in the signature >> packet. > > > > I would agree with that. There was some discussion > on the user's list about an attempt at producing a > code path to use SHA256... which seemed to confuse > the issue. > > Would it be a good idea to put in a statement > explicitly limiting OpenPGP's view of DSS to be > SHA1 only? And add a comment perhaps that in the > light of weaknesses in SHA1, that RSA with a fatter > digest be used instead as a workaround? The cost of that is that anyone with a DSA key is screwed. Seems like a last resort to me. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33Iqp1X051927; Sun, 3 Apr 2005 11:52:51 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33Iqpqp051926; Sun, 3 Apr 2005 11:52:51 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j33IqobL051915 for ; Sun, 3 Apr 2005 11:52:50 -0700 (PDT) (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 61DA233C33; Sun, 3 Apr 2005 19:52:49 +0100 (BST) Message-ID: <42503B09.8090608@algroup.co.uk> Date: Sun, 03 Apr 2005 19:50:49 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Konrad Rosenbaum Cc: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? References: <20050402201614.31E9157EE9@finney.org> <425005AE.5030105@algroup.co.uk> <42501CD7.4070005@algroup.co.uk> <200504031948.22079@zaphod.konrad.silmor.de> In-Reply-To: <200504031948.22079@zaphod.konrad.silmor.de> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: Konrad Rosenbaum wrote: > On Sunday 03 April 2005 18:41, Ben Laurie wrote: > >>Oh, yes. This left me with an unresolved issue: how does one use >>SHA{256,384,512} with DSA (which requires a 160 bit hash). > > > Simple: you don't. DSA was designed to be used with SHA-1, which is 160 bit. > Since SHA-1 is theoretically broken (practically will probably follow in a > few months) one should see what the NIST makes of it. Supplanting a broken > hash with another hash doesn't make much sense with DSA, since it does not > contain the ID of the hash (as PKCS#1 does for RSA) - so any attacker could > find a collission with the broken hash and then simply change the hash ID > in the signature packet. The hash does include the ID of the hash, and hence the signature does. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33IbGDB050976; Sun, 3 Apr 2005 11:37:16 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33IbGt6050975; Sun, 3 Apr 2005 11:37:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33IbECN050969 for ; Sun, 3 Apr 2005 11:37:15 -0700 (PDT) (envelope-from iang@systemics.com) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j33IaqU02903 for ; Sun, 3 Apr 2005 19:37:08 +0100 X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol Message-ID: <4250389F.4050301@systemics.com> Date: Sun, 03 Apr 2005 19:40:31 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0 (X11/20050219) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? References: <20050402201614.31E9157EE9@finney.org> <425005AE.5030105@algroup.co.uk> <42501CD7.4070005@algroup.co.uk> <200504031948.22079@zaphod.konrad.silmor.de> In-Reply-To: <200504031948.22079@zaphod.konrad.silmor.de> 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: Konrad Rosenbaum wrote: > On Sunday 03 April 2005 18:41, Ben Laurie wrote: > >>Oh, yes. This left me with an unresolved issue: how does one use >>SHA{256,384,512} with DSA (which requires a 160 bit hash). > > > Simple: you don't. DSA was designed to be used with SHA-1, which is 160 bit. > Since SHA-1 is theoretically broken (practically will probably follow in a > few months) one should see what the NIST makes of it. Supplanting a broken > hash with another hash doesn't make much sense with DSA, since it does not > contain the ID of the hash (as PKCS#1 does for RSA) - so any attacker could > find a collission with the broken hash and then simply change the hash ID > in the signature packet. I would agree with that. There was some discussion on the user's list about an attempt at producing a code path to use SHA256... which seemed to confuse the issue. Would it be a good idea to put in a statement explicitly limiting OpenPGP's view of DSS to be SHA1 only? And add a comment perhaps that in the light of weaknesses in SHA1, that RSA with a fatter digest be used instead as a workaround? (SHA1 will remain a current issue until "something is done". When it was debated a month back, did we reach a consensus to do something about it? I got the feeling that we didn't, but I might be just remembering one side.) iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33HmUaC047323; Sun, 3 Apr 2005 10:48:30 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33HmUu3047322; Sun, 3 Apr 2005 10:48:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from p15139323.pureserver.info (silmor.de [217.160.219.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33HmTFe047313 for ; Sun, 3 Apr 2005 10:48:29 -0700 (PDT) (envelope-from konrad@silmor.de) Received: from p548c9f4c.dip.t-dialin.net ([84.140.159.76] helo=zaphod.local) by p15139323.pureserver.info with asmtp (Exim 3.35 #1 (Debian)) id 1DI9Cx-0000Ls-00 for ; Sun, 03 Apr 2005 19:48:23 +0200 From: Konrad Rosenbaum To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? Date: Sun, 3 Apr 2005 19:48:18 +0200 User-Agent: KMail/1.7.2 References: <20050402201614.31E9157EE9@finney.org> <425005AE.5030105@algroup.co.uk> <42501CD7.4070005@algroup.co.uk> In-Reply-To: <42501CD7.4070005@algroup.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1268253.Hopp9c9hf8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504031948.22079@zaphod.konrad.silmor.de> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --nextPart1268253.Hopp9c9hf8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 03 April 2005 18:41, Ben Laurie wrote: > Oh, yes. This left me with an unresolved issue: how does one use > SHA{256,384,512} with DSA (which requires a 160 bit hash). Simple: you don't. DSA was designed to be used with SHA-1, which is 160 bit= =2E=20 Since SHA-1 is theoretically broken (practically will probably follow in a= =20 few months) one should see what the NIST makes of it. Supplanting a broken= =20 hash with another hash doesn't make much sense with DSA, since it does not= =20 contain the ID of the hash (as PKCS#1 does for RSA) - so any attacker could= =20 find a collission with the broken hash and then simply change the hash ID=20 in the signature packet. Konrad --nextPart1268253.Hopp9c9hf8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBCUCxmClt766LaIH0RAiBeAJ4goq0kmPn8yJcNWuJYUITKoRVZ1gCeMS/o r7S9RYDYjg4/H6v8Qsb+NKY= =LHGA -----END PGP SIGNATURE----- --nextPart1268253.Hopp9c9hf8-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33Gi1Si043243; Sun, 3 Apr 2005 09:44:01 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33Gi1RM043242; Sun, 3 Apr 2005 09:44:01 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j33Gi0oB043236 for ; Sun, 3 Apr 2005 09:44:01 -0700 (PDT) (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 410D833C33; Sun, 3 Apr 2005 17:43:59 +0100 (BST) Message-ID: <42501CD7.4070005@algroup.co.uk> Date: Sun, 03 Apr 2005 17:41:59 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Laurie Cc: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? References: <20050402201614.31E9157EE9@finney.org> <424F5AA6.1060001@algroup.co.uk> <425005AE.5030105@algroup.co.uk> In-Reply-To: <425005AE.5030105@algroup.co.uk> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: Ben Laurie wrote: > Here are proposed diffs. Oh, yes. This left me with an unresolved issue: how does one use SHA{256,384,512} with DSA (which requires a 160 bit hash). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33F5D3U035951; Sun, 3 Apr 2005 08:05:13 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33F5Dih035950; Sun, 3 Apr 2005 08:05:13 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j33F5BEK035942 for ; Sun, 3 Apr 2005 08:05:12 -0700 (PDT) (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 096FD33C33 for ; Sun, 3 Apr 2005 16:05:10 +0100 (BST) Message-ID: <425005AE.5030105@algroup.co.uk> Date: Sun, 03 Apr 2005 16:03:10 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? References: <20050402201614.31E9157EE9@finney.org> <424F5AA6.1060001@algroup.co.uk> In-Reply-To: <424F5AA6.1060001@algroup.co.uk> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------050504080006000107060205" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------050504080006000107060205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Here are proposed diffs. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 --------------050504080006000107060205 Content-Type: text/plain; name="id.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="id.diff" --- draft-ietf-openpgp-rfc2440bis-12.txt Tue Nov 23 18:36:41 2004 +++ draft-ietf-openpgp-rfc2440bis-12-ben.txt Sun Apr 3 15:29:31 2005 @@ -1137,13 +1137,6 @@ - One or more multiprecision integers comprising the signature. This portion is algorithm specific, as described below. - The data being signed is hashed, and then the signature type and - creation time from the signature packet are hashed (5 additional - octets). The resulting hash value is used in the signature - algorithm. The high 16 bits (first two octets) of the hash are - included in the signature packet to provide a quick test to reject - some invalid signatures. - Algorithm Specific Fields for RSA signatures: - multiprecision integer (MPI) of RSA signature value m**d mod n. @@ -1154,80 +1147,10 @@ - MPI of DSA value s. - The signature calculation is based on a hash of the signed data, as - described above. The details of the calculation are different for - DSA signature than for RSA signatures. - - The hash h is PKCS-1 padded exactly the same way as for the above - described RSA signatures. - - With RSA signatures, the hash value is encoded as described in - PKCS-1 section 9.2.1 encoded using PKCS-1 encoding type - EMSA-PKCS1-v1_5 [RFC2437]. This requires inserting the hash value - as an octet string into an ASN.1 structure. The object identifier - for the type of hash being used is included in the structure. The - hexadecimal representations for the currently defined hash - algorithms are: - - - MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05 - - - -Callas, et al. Expires May 23, 2005 [Page 21] -INTERNET-DRAFT OpenPGP Message Format Nov 23, 2004 - - - RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01 - - - SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A - - - SHA256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01 - - - SHA384: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02 - - - SHA512: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03 - - The ASN.1 OIDs are: - - - MD5: 1.2.840.113549.2.5 - - - RIPEMD-160: 1.3.36.3.2.1 - - - SHA-1: 1.3.14.3.2.26 - - - SHA256: 2.16.840.1.101.3.4.2.1 - - - SHA384: 2.16.840.1.101.3.4.2.2 - - - SHA512: 2.16.840.1.101.3.4.2.3 - - The full hash prefixes for these are: - - MD5: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, - 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00, - 0x04, 0x10 - - RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24, - 0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14 - - SHA-1: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E, - 0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14 - - SHA256: 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, - 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05, - 0x00, 0x04, 0x20 - - SHA384: 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, - 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05, - 0x00, 0x04, 0x30 - - SHA512: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, - 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05, - 0x00, 0x04, 0x40 - - 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. + The signature calculation is based on a hash of the signed + data. This is described in detail in section 5.2.4. The high 16 + bits (first two octets) of the hash are included in the signature + packet to provide a quick test to reject some invalid signatures. Callas, et al. Expires May 23, 2005 [Page 22] INTERNET-DRAFT OpenPGP Message Format Nov 23, 2004 @@ -1263,20 +1186,16 @@ - One or more multiprecision integers comprising the signature. This portion is algorithm specific, as described above. - The data being signed is hashed, and then the signature data from - the version number through the hashed subpacket data (inclusive) is - hashed. The resulting hash value is what is signed. The left 16 - bits of the hash are included in the signature packet to provide a - quick test to reject some invalid signatures. - There are two fields consisting of signature subpackets. The first field is hashed with the rest of the signature data, while the second is unhashed. The second set of subpackets is not cryptographically protected by the signature and should include only advisory information. - The algorithms for converting the hash function result to a - signature are described in a section below. + The algorithms for calculating the hash and converting the result + to a signature are described in section 5.2.4. The left 16 bits of + the hash are included in the signature packet to provide a quick + test to reject some invalid signatures. 5.2.3.1. Signature Subpacket Specification @@ -1936,7 +1855,72 @@ resulting hash field is used in the signature algorithm, and placed at the end of the signature packet. -5.2.4.1. Subpacket Hints +5.2.4.1. Signature Algorithms + +5.2.4.1.1. DSA Signatures + + A DSA signature is performed as specified in [FIPS-186-2] on the + value of the hash, calculated as above. + + 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. + +5.2.4.1.2. RSA Signatures + + With RSA signatures, the hash value is encoded as described in + PKCS #1 section 9.2.1 encoded using PKCS #1 encoding type + EMSA-PKCS1-v1_5 [RFC2437]. This requires inserting the hash value + as an octet string into an ASN.1 structure. The object identifier + for the type of hash being used is included in the structure. + + The ASN.1 OIDs are: + + - MD5: 1.2.840.113549.2.5 + + - RIPEMD-160: 1.3.36.3.2.1 + + - SHA-1: 1.3.14.3.2.26 + + - SHA256: 2.16.840.1.101.3.4.2.1 + + - SHA384: 2.16.840.1.101.3.4.2.2 + + - SHA512: 2.16.840.1.101.3.4.2.3 + + In practice this amounts to prefixing the hash with one of the + following, then padding as described in PKCS #1: + + MD5: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, + 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00, + 0x04, 0x10 + + RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24, + 0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14 + + SHA-1: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E, + 0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14 + + SHA256: 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, + 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05, + 0x00, 0x04, 0x20 + + SHA384: 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, + 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05, + 0x00, 0x04, 0x30 + + SHA512: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, + 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05, + 0x00, 0x04, 0x40 + + The value emLen needed for the padding is equal to the length in + bytes of the RSA public modulus, n. + + Once the hash has been encoded and padded, the resulting string is + encrypted with the RSA private key as described in [RSA]. + +5.2.4.2. Subpacket Hints It is certainly possible for a signature to contain conflicting information in subpackets. For example, a signature may contain @@ -3084,7 +3068,7 @@ 2 - RSA Encrypt-Only 3 - RSA Sign-Only 16 - Elgamal (Encrypt-Only), see [ELGAMAL] - 17 - DSA (Digital Signature Algorithm) [SCHNEIER] + 17 - DSA (Digital Signature Algorithm) [DSA] 18 - Reserved for Elliptic Curve 19 - Reserved for ECDSA 20 - Reserved (formerly Elgamal Encrypt or Sign) @@ -3946,6 +3930,10 @@ 1983, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997. + [FIPS186-2] "Digital Signature Standard", FIPS 186-2, January + 2000. + [RSA] Menezes, A., et al. "Handbook of Applied + Cryptography", Section 8.2., October 1996. --------------050504080006000107060205-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j332tToB052964; Sat, 2 Apr 2005 18:55:29 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j332tT9s052963; Sat, 2 Apr 2005 18:55:29 -0800 (PST) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j332tRe9052956 for ; Sat, 2 Apr 2005 18:55:28 -0800 (PST) (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 CB29F33C45; Sun, 3 Apr 2005 03:55:26 +0100 (BST) Message-ID: <424F5AA6.1060001@algroup.co.uk> Date: Sun, 03 Apr 2005 03:53:26 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? References: <20050402201614.31E9157EE9@finney.org> In-Reply-To: <20050402201614.31E9157EE9@finney.org> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: Hal Finney wrote: > Ben Laurie writes: > > >>The sections on calculating signatures are really confusing. I can't >>currently suggest alternate text for most of it because its far from >>clear to me what the actual algorithms are. If someone explains, I'll do >>my best to write clarifying text. > > > You're right, this is really messed up. > > The authoritative section on what to hash is 5.2.4. We should refer > forward to that section and not include detailed information about > what is hashed in the sections on V3 and V4 signature packets. > > We should make it clear that the DSA signature algorithm works directly > on the hash value that results from 5.2.4. > > We should say that RSA signatures use that hash and prepend the sequence > of bytes identified as the "full hash prefixes". We could probably remove > the hexadecimal equivalents to the ASN.1 OIDs; if someone understands > ASN.1 well then the OIDs are enough, and if not then they can just > follow the rule to prepend the proper byte sequences and that will work. > This then gets padded as in PKCS#1 v1.5 signatures. We should have a > sentence clarifying that this is what gives us the value "m" used in > the signature calculation. We also need to specify emLen, which I presume (by logic and experiment) is equal to the RSA key size. I will send diffs soon. Thanks for the clarification. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j32K2qx4032526; Sat, 2 Apr 2005 12:02:52 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j32K2qL2032525; Sat, 2 Apr 2005 12:02:52 -0800 (PST) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j32K2qta032519 for ; Sat, 2 Apr 2005 12:02:52 -0800 (PST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 31E9157EE9; Sat, 2 Apr 2005 12:16:14 -0800 (PST) To: ietf-openpgp@imc.org Subject: Re: How to Calculate Signatures? Message-Id: <20050402201614.31E9157EE9@finney.org> Date: Sat, 2 Apr 2005 12:16:14 -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: > The sections on calculating signatures are really confusing. I can't > currently suggest alternate text for most of it because its far from > clear to me what the actual algorithms are. If someone explains, I'll do > my best to write clarifying text. You're right, this is really messed up. The authoritative section on what to hash is 5.2.4. We should refer forward to that section and not include detailed information about what is hashed in the sections on V3 and V4 signature packets. We should make it clear that the DSA signature algorithm works directly on the hash value that results from 5.2.4. We should say that RSA signatures use that hash and prepend the sequence of bytes identified as the "full hash prefixes". We could probably remove the hexadecimal equivalents to the ASN.1 OIDs; if someone understands ASN.1 well then the OIDs are enough, and if not then they can just follow the rule to prepend the proper byte sequences and that will work. This then gets padded as in PKCS#1 v1.5 signatures. We should have a sentence clarifying that this is what gives us the value "m" used in the signature calculation. Hal Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j32JlP8B031780; Sat, 2 Apr 2005 11:47:25 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j32JlOMe031779; Sat, 2 Apr 2005 11:47:24 -0800 (PST) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j32JlOvl031773 for ; Sat, 2 Apr 2005 11:47:24 -0800 (PST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 1B39F57EE9; Sat, 2 Apr 2005 12:00:46 -0800 (PST) To: ietf-openpgp@imc.org Subject: Re: Version hashed twice? Message-Id: <20050402200046.1B39F57EE9@finney.org> Date: Sat, 2 Apr 2005 12:00:46 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The reason for the trailer in V4 sigs is to address a security weakness in V3 sigs and their relation with V4. The problem is that V3 key sigs do not hash the length of the userid field, and neither version hashes the length of the data when signing a document. This would mean that, if we did not have a V4 trailer, it might be possible to get someone to V3 sign a properly constructed userid or document, and then turn that into a V4 signature on something else. To prevent that, we want the sequence of bytes hashed in a V4 signature to be (a) uniquely parseable; and (b) unable to match the same sequence of bytes hashed in any other signature version. Uniquely parseable means that given the sequence of bytes that were hashed, and with no other information, you can determine with 100% reliability what the parsing is of the data into signature packets and other packets. V3 document signatures hash n random bytes, where n is not hashed, and then 1 byte of signature type and 4 bytes of signature creation time. V3 key signatures hash bytes starting with the key packet, which is uniquely parseable because it includes the length; then the user id, which does not include the length; then 1 byte of signature type and 4 bytes of signature creation time. We want to make sure that no V4 signature could hash a sequence of bytes that matches the same sequence of bytes in a V3 signature. This is why we force the 4th byte from the end in the V4 sequence of hashed bytes to be 0xff. The 4th byte from the end in a V3 sequence of hashed bytes will always be signature type, and 0xff is not a legal signature type. So that will ensure that V3 signatures cannot be re-packaged as V4 signatures. The reason we include the version number and length of hashed packets is to ensure unique parseability. Without the length of hashed packets at the end, you could create a document whose V4 signature could be applied to a different document with different subpackets in a modified V4 signature. By including the length of hashed packets we make it unambiguous where the document ends and the V4 signature packet begins. And the reason we include the version there is in case we change this for future versions, we will have an unambiguous place where the version number can be found, 6 bytes from the end. The other location of version number might not be uniquely parseable once we create new versions. This will give us more flexibility in the future and we won't have to worry about repackaging attacks as we did with the V3 to V4 transition. Hal Finney Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j32GpsbQ018635; Sat, 2 Apr 2005 08:51:54 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j32GprkB018634; Sat, 2 Apr 2005 08:51:53 -0800 (PST) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j32GpqKv018628 for ; Sat, 2 Apr 2005 08:51:53 -0800 (PST) (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 DE63E33C73 for ; Sat, 2 Apr 2005 17:51:51 +0100 (BST) Message-ID: <424ECD2F.1090601@algroup.co.uk> Date: Sat, 02 Apr 2005 17:49:51 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OpenPGP Subject: How to Calculate Signatures? X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: Once more referring to 2440bis-12... The sections on calculating signatures are really confusing. I can't currently suggest alternate text for most of it because its far from clear to me what the actual algorithms are. If someone explains, I'll do my best to write clarifying text. Firstly: 5.2.2 says: The signature calculation is based on a hash of the signed data, as described above. Until I wrote this email, I though this sentence meant the signature calculation was described above. I've just realised it means that the hash is described above. I suggest instead: The signature calculation is based on the hash of the signed data described above. Though since the hash is described much more usefully in 5.2.4, perhaps it should simply refer to that instead? It then goes on to say: The details of the calculation are different for DSA signature than for RSA signatures. The hash h is PKCS-1 padded exactly the same way as for the above described RSA signatures. For the life of me, I can't see an "above described RSA signature" - where is that? PKCS-1 is mentioned before, but for encryption, not signing. It then goes on to describe truly revolting nastiness about PKCS-1 (shouldn't that be written PKCS#1, incidentally?) for doing RSA signatures, but never, as far as I can see, says how to do a DSA signature. From experiment, it seems to me that a DSA signature is done directly on the hash, without any manipulation at all. Correct? Then in 5.2.3: The algorithms for converting the hash function result to a signature are described in a section below. Firstly, it would be much more friendly to say _which_ section below, rather than leaving the reader to guess. I'd fill that in if I could find the section, but I can't. The nearest I can get is 5.2.4, which says: After all this has been hashed in a single hash context the resulting hash field is used in the signature algorithm, and placed at the end of the signature packet. And that appears to be it, as far as signature algorithms are concerned. Reading between the lines, I'm assuming that what this really means is that the algorithms used are exactly what I'd expect, i.e. DSA directly on the hash, and RSA with PKCS#1 padding and the, err, other stuff. But references to further descriptions that I can't find leave me in doubt! Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j32E8EEr008430; Sat, 2 Apr 2005 06:08:14 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j32E8E7V008429; Sat, 2 Apr 2005 06:08:14 -0800 (PST) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j32E8DBI008422 for ; Sat, 2 Apr 2005 06:08:14 -0800 (PST) (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 2B65533C45 for ; Sat, 2 Apr 2005 15:08:12 +0100 (BST) Message-ID: <424EA6D3.1050301@algroup.co.uk> Date: Sat, 02 Apr 2005 15:06:11 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OpenPGP Subject: Version hashed twice? X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: In a v4 signature packet, the packet version number is hashed twice, once in the hash of the packet data, and again in the trailer. Why? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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