From owner-ietf-open-pgp@imc.org Mon Apr 5 16:50:33 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15348 for ; Mon, 5 Apr 1999 16:50:33 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA07693 for ietf-open-pgp-bks; Mon, 5 Apr 1999 13:09:27 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA07689 for ; Mon, 5 Apr 1999 13:09:25 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id WAA10097 for ietf-open-pgp@imc.org; Mon, 5 Apr 1999 22:09:49 +0200 (MET DST) Received: (qmail 11734 invoked from network); 5 Apr 1999 20:00:19 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 5 Apr 1999 20:00:19 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10UFUQ-0003yo-00; Mon, 5 Apr 1999 21:56:58 +0200 Date: Mon, 5 Apr 1999 21:56:58 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Sample Twofish message Message-ID: <19990405215658.I14996@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199903292241.OAA04352@hal.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <199903292241.OAA04352@hal.sb.rain.org>; from hal@rain.org on Mon, Mar 29, 1999 at 02:41:39PM -0800 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: hal@rain.org writes: > Note also that the special CFB "sync" operation (after processing these 10 > bytes) is not to be done with block ciphers whose block size is greater > than 8 bytes, hence is not done for Twofish. Hmmm, section 5.7 states that encryption is done in PGP's special CFB mode and there is no exception mentioned. If I remember correct, we discussed this 128 bit block cipher issue last year and changed the draft accordingly. -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Mon Apr 5 17:30:37 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16045 for ; Mon, 5 Apr 1999 17:30:36 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA08028 for ietf-open-pgp-bks; Mon, 5 Apr 1999 13:53:35 -0700 (PDT) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA08024 for ; Mon, 5 Apr 1999 13:53:34 -0700 (PDT) Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.3/8.9.3) with ESMTP id NAA04441; Mon, 5 Apr 1999 13:53:55 -0700 (PDT) Received: (from hal@localhost) by hal.sb.rain.org (8.8.7/8.8.7) id NAA25365; Mon, 5 Apr 1999 13:44:40 -0700 Date: Mon, 5 Apr 1999 13:44:40 -0700 From: hal@rain.org Message-Id: <199904052044.NAA25365@hal.sb.rain.org> To: ietf-open-pgp@imc.org, wk@isil.d.shuttle.de Subject: Re: Sample Twofish message Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Werner Koch, , writes: > > hal@rain.org writes: > > > Note also that the special CFB "sync" operation (after processing these 10 > > bytes) is not to be done with block ciphers whose block size is greater > > than 8 bytes, hence is not done for Twofish. > > Hmmm, section 5.7 states that encryption is done in PGP's special CFB > mode and there is no exception mentioned. > > If I remember correct, we discussed this 128 bit block cipher issue > last year and changed the draft accordingly. The relevant paragraph from section 5.7 is: The data is encrypted in CFB mode, with a CFB shift size equal to the cipher's block size. The Initial Vector (IV) is specified as all zeros. Instead of using an IV, OpenPGP prefixes a 10-octet string to the data before it is encrypted. The first eight octets are random, and the 9th and 10th octets are copies of the 7th and 8th octets, respectively. After encrypting the first 10 octets, the CFB state is resynchronized if the cipher block size is 8 octets or less. The last 8 octets of ciphertext are passed through the cipher and the block boundary is reset. It only resynchronizes the CFB state if the cipher block size is 8 octets or less. Twofish has a block size of 16 octets, hence the CFB state does not get resynchronized. Hal From owner-ietf-open-pgp@imc.org Tue Apr 6 14:53:09 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15194 for ; Tue, 6 Apr 1999 14:53:09 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA20420 for ietf-open-pgp-bks; Tue, 6 Apr 1999 11:01:45 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA20416 for ; Tue, 6 Apr 1999 11:01:44 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id UAA01308 for ietf-open-pgp@imc.org; Tue, 6 Apr 1999 20:02:21 +0200 (MET DST) Received: (qmail 13318 invoked from network); 6 Apr 1999 17:50:20 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 6 Apr 1999 17:50:20 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10UZwM-0004Qb-00; Tue, 6 Apr 1999 19:47:10 +0200 Date: Tue, 6 Apr 1999 19:47:10 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Sample Twofish message Message-ID: <19990406194710.E16314@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904052044.NAA25365@hal.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <199904052044.NAA25365@hal.sb.rain.org>; from hal@rain.org on Mon, Apr 05, 1999 at 01:44:40PM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: hal@rain.org writes: > The relevant paragraph from section 5.7 is: [...] > resynchronized if the cipher block size is 8 octets or less. The ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Ooops, I really missed that. I only remembered from the discussion, that we keep the special CFB mode. Many thanks - I hope I can decipher your mail in a few days. Werner -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Wed Apr 7 00:37:26 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24266 for ; Wed, 7 Apr 1999 00:37:25 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA08334 for ietf-open-pgp-bks; Tue, 6 Apr 1999 21:02:58 -0700 (PDT) Received: from ixpres.com (AM3-10-53-206.ixpres.com [209.75.53.206]) by mail.proper.com (8.8.8/8.8.5) with SMTP id UAA07726; Tue, 6 Apr 1999 20:53:14 -0700 (PDT) Date: Tue, 6 Apr 1999 20:53:14 -0700 (PDT) From: bizusa@ixpres.com Message-Id: <199904070353.UAA07726@mail.proper.com> Reply-To: bizusa@ixpres.com To: bizusa@ixpres.com Subject: Organize Web Info... Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% This message is sent in compliance of the new Email bill: SECTION 301. Sender: INFOtrepreneur, 11012 Avenida De Los Lobos, San Diego, California, CA 92127 - Fax: (619) 672-1000 Email: webmaster@infotrepreneur.com Per Section 301, Paragraph (a)(2)(C) of S.1618, further transmissions to you by the sender of this email may be stopped at no cost to you by ending a reply to this email address with the word "remove" in the subject line. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% NO MORE! BACKTRACKING OF LOST AND CONFUSING WEB BOOKMARKS AND TEXT DATA FILES... Based upon your Internet interests, I thought that you would be interesed in Web Info Catcher which allows you to capture and store text data from various sources, index, categorize and edit it instantly on screen while online. Access all your reference and source material instantly at a click of a button, while you are working, browsing, searching or offline. It's the fastest, up-to-date, and most efficient means to "RECALL" your data. * No need... to bookmark a multitude of web sites * No need... to search for misplaced or lost text files * No need... to print out endless reports * No need... for a web browser to reference data - Perfect for academics, researchers, business, info junkies, etc. - Create your own projects, reports, topics, favorites, research, etc. - Open numerous projects and setup your own index references - Attach and Capture text information from various sources - Edit your projects - Effectively organize your information - Categorize your information - Add custom indexes - Automatic alpha indexing - Searchable index - Scrollable index - View information on screen while working - A Stand alone program - Add and delete information - Print out data in your own time WHY BOOKMARK OR SAVE YOUR TEXT FILES? DON'T DELAY!  Visit INFOtrepreneur today and discover a whole new way to capture and store your information sources, we will be happy to assist you. DOWNLOAD your software demo: ftp://ftp.infotrepreneur.com/pub/wicdemo.exe OR for more info: http://www.infotrepreneur.com/webcth.htm Sincerely Gail van der Merwe From owner-ietf-open-pgp@imc.org Wed Apr 7 17:22:36 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16005 for ; Wed, 7 Apr 1999 17:22:36 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA02022 for ietf-open-pgp-bks; Wed, 7 Apr 1999 13:32:49 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA02018 for ; Wed, 7 Apr 1999 13:32:49 -0700 (PDT) Received: from jcallas ([38.232.7.55]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id NAA11447 for ; Wed, 7 Apr 1999 13:33:01 -0700 (PDT) Message-Id: <3.0.3.32.19990407132425.03c74010@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 07 Apr 1999 13:24:25 -0700 To: ietf-open-pgp@imc.org From: Jon Callas Subject: Re: Sample Twofish message In-Reply-To: <19990406194710.E16314@frodo.isil.d.shuttle.de> References: <199904052044.NAA25365@hal.sb.rain.org> <199904052044.NAA25365@hal.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: What about section 12.8 which says: Note that for an algorithm that has a larger block size than 64 bits, the equivalent function will be done with that entire block. For example, a 16-octet block algorithm would operate on 16 octets, and then produce two octets of check, and then work on 16-octet blocks. ----- Jon Callas jon@pgp.com CTO, Total Network Security 3965 Freedom Circle Network Associates, Inc. Santa Clara, CA 95054 (408) 346-5860 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) From owner-ietf-open-pgp@imc.org Thu Apr 8 02:13:41 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29376 for ; Thu, 8 Apr 1999 02:13:41 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA07433 for ietf-open-pgp-bks; Wed, 7 Apr 1999 22:39:15 -0700 (PDT) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA07429 for ; Wed, 7 Apr 1999 22:39:15 -0700 (PDT) Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.3/8.9.3) with ESMTP id WAA22907; Wed, 7 Apr 1999 22:39:53 -0700 (PDT) Received: (from hal@localhost) by hal.sb.rain.org (8.8.7/8.8.7) id WAA02648; Wed, 7 Apr 1999 22:39:55 -0700 Date: Wed, 7 Apr 1999 22:39:55 -0700 From: hal@rain.org Message-Id: <199904080539.WAA02648@hal.sb.rain.org> To: ietf-open-pgp@imc.org, jcallas@NAI.com Subject: Re: Sample Twofish message Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Jon Callas, , writes: > What about section 12.8 which says: > > Note that for an algorithm that has a larger block size than 64 bits, > the equivalent function will be done with that entire block. For > example, a 16-octet block algorithm would operate on 16 octets, and > then produce two octets of check, and then work on 16-octet blocks. Yes, you're right, that is inconsistent with section 5.7. I don't know how we should resolve it. Hal From owner-ietf-open-pgp@imc.org Thu Apr 8 03:01:42 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29741 for ; Thu, 8 Apr 1999 03:01:41 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA07783 for ietf-open-pgp-bks; Wed, 7 Apr 1999 23:20:13 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA07779 for ; Wed, 7 Apr 1999 23:20:11 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id IAA03634 for ietf-open-pgp@imc.org; Thu, 8 Apr 1999 08:20:51 +0200 (MET DST) Received: (qmail 17556 invoked from network); 8 Apr 1999 05:52:51 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 8 Apr 1999 05:52:51 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10V7hN-0001WD-00; Thu, 8 Apr 1999 07:49:57 +0200 Date: Thu, 8 Apr 1999 07:49:57 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Sample Twofish message Message-ID: <19990408074957.B5540@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904052044.NAA25365@hal.sb.rain.org> <199904052044.NAA25365@hal.sb.rain.org> <19990406194710.E16314@frodo.isil.d.shuttle.de> <3.0.3.32.19990407132425.03c74010@mail.pgp.com> <199904052044.NAA25365@hal.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <199904052044.NAA25365@hal.sb.rain.org>; from hal@rain.org on Mon, Apr 05, 1999 at 01:44:40PM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Okay, how can we resolve this conflict: From section 5.7: The data is encrypted in CFB mode, with a CFB shift size equal to the cipher's block size. The Initial Vector (IV) is specified as all zeros. Instead of using an IV, OpenPGP prefixes a 10-octet string to the data before it is encrypted. The first eight octets are random, and the 9th and 10th octets are copies of the 7th and 8th octets, respectively. After encrypting the first 10 octets, the CFB state is resynchronized if the cipher block size is 8 octets or less. The ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ last 8 octets of ciphertext are passed through the cipher and the block boundary is reset. From section 12.8: OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and prefixes the plaintext with ten octets of random data, such that octets 9 and 10 match octets 7 and 8. It does a CFB "resync" after ^^^^^^^^^^^^^^^^^^^^^ encrypting those ten octets. Note that for an algorithm that has a larger block size than 64 bits, the equivalent function will be done with that entire block. For example, a 16-octet block algorithm would operate on 16 octets, and then produce two octets of check, and then work on 16-octet blocks. 5.7 says that resync is only done for a blocksize <= 64 but 12.8 says that is done always (the following step by step list also says this). Please, can we agree on one version - I don't care which one, but it is a bad idea to change this after the first message/secret-key has been enciphered with a >64 bit blocksize cipher. We should agree on an interpretation of these questions: * Use resyncing at all for ciphers with a blocksize > 64 ? * Use it for encryption of secret key material in V3 packets ? * Use the blocksize or 64 bits for the CFB shift ? * Prepend 8+2 or blocksize+2 random bytes to the plaintext? * Keep the 8 byte salt for S2K modes? -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Thu Apr 8 05:48:45 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00476 for ; Thu, 8 Apr 1999 05:48:44 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA09939 for ietf-open-pgp-bks; Thu, 8 Apr 1999 01:53:42 -0700 (PDT) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA09935 for ; Thu, 8 Apr 1999 01:53:40 -0700 (PDT) Received: (from news@localhost) by grannus.iks-jena.de (8.9.3/8.9.2) id KAA10278 for ietf-open-pgp@imc.org; Thu, 8 Apr 1999 10:54:20 +0200 To: ietf-open-pgp@imc.org Path: lutz From: lutz@taranis.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Sample Twofish message Date: 8 Apr 1999 08:54:19 GMT Organization: IKS GmbH Jena Lines: 6 Message-ID: References: <199904052044.NAA25365@hal.sb.rain.org> <199904052044.NAA25365@hal.sb.rain.org> <19990406194710.E16314@frodo.isil.d.shuttle.de> <3.0.3.32.19990407132425.03c74010@mail.pgp.com> <199904052044.NAA25365@hal.sb.rain.org> <19990408074957.B5540@frodo.isil.d.shuttle.de> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: slrn/0.9.5.4 (UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Content-Transfer-Encoding: 8bit * Werner Koch wrote: >We should agree on an interpretation of these questions: > * Use resyncing at all for ciphers with a blocksize > 64 ? Use it if the processed cipher text is larger as the block size. Do not concat ciphers of different message parts. From owner-ietf-open-pgp@imc.org Thu Apr 8 16:21:52 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06263 for ; Thu, 8 Apr 1999 16:21:51 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA19501 for ietf-open-pgp-bks; Thu, 8 Apr 1999 12:52:08 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA19497 for ; Thu, 8 Apr 1999 12:52:07 -0700 (PDT) Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Thu Apr 8 15:51:45 EDT 1999 Received: from aura.research.bell-labs.com ([135.104.46.10]) by research; Thu Apr 8 15:51:43 EDT 1999 Received: (from bleichen@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id PAA11284 for ietf-open-pgp@imc.org; Thu, 8 Apr 1999 15:51:42 -0400 (EDT) Date: Thu, 8 Apr 1999 15:51:42 -0400 (EDT) From: Daniel Bleichenbacher Message-Id: <199904081951.PAA11284@aura.research.bell-labs.com> To: ietf-open-pgp@imc.org Subject: Decrypting ElGamal messages X-Sun-Charset: US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Can anyone tell me how an ElGamal encrypted message has to be decrypted? The open-pgp documentation doesn't give the answer. I'm specially interested in how padding and checksums are handled. I'm asking this question, because ElGamal encryption has the same multiplicative properties as RSA. In particular, given the encryption of a message M (including padding), it is easy to generate the encryption of M*S (mod p) for a given S, without knowing M. Hence the same attack that was possible against SSL potentially works against ElGamal, when used with PKCS #1 v1.5 padding. BTW, is there any reason why PKCS #1 v1.5 padding is used and not PKCS #1 v2? -- Daniel Bleichenbacher From owner-ietf-open-pgp@imc.org Thu Apr 8 18:22:41 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07241 for ; Thu, 8 Apr 1999 18:22:41 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA20590 for ietf-open-pgp-bks; Thu, 8 Apr 1999 14:46:30 -0700 (PDT) Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20585 for ; Thu, 8 Apr 1999 14:46:27 -0700 (PDT) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id JAA28258; Fri, 9 Apr 1999 09:46:08 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92360796703112>; Fri, 9 Apr 1999 09:46:07 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: bleichen@research.bell-labs.com, ietf-open-pgp@imc.org Subject: Re: Decrypting ElGamal messages Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Fri, 9 Apr 1999 09:46:07 (NZST) Message-ID: <92360796703112@cs26.cs.auckland.ac.nz> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Daniel Bleichenbacher writes: >I'm asking this question, because ElGamal encryption has the same >multiplicative properties as RSA. In particular, given the encryption of a >message M (including padding), it is easy to generate the encryption of M*S >(mod p) for a given S, without knowing M. Hence the same attack that was >possible against SSL potentially works against ElGamal, when used with PKCS >#1 v1.5 padding. > >BTW, is there any reason why PKCS #1 v1.5 padding is used and not PKCS #1 v2? This exact issue was debated on the ietf-smime list when I asked why X9.42 (which looks like the winning candidate from a 'Worst way to apply the DLP to solving a key transport problem' competition... [remainder bobbitted to avoid another flamewar over this :-]) was being used instead of the far more logical Elgamal, which would be a direct, patent-free drop-in replacement for the existing RSA key transport. The only reason anyone could put up against Elgamal was "You need to use OAEP because PKCS #1 padding is insecure". In response to this (at the end of a longish debate) I posted the following back-of-the-envelope analysis: -- Snip -- The second approach is to see just what it would take to implement this attack on CMS (not S/MIME, but anything involving CMS). For this analysis I'll make several assumptions: 1. The implementor has managed to design a protocol which will accept arbitrary numbers of chosen-ciphertext messages and reply to each one with an exact indication of how the decrypt failed, leaking information about the decrypted message to an attacker. This is a fairly remarkable feat, but let's say, just for arguments sake, that someone did do this. 2. The implementor and any third-party reviewers have somehow missed the CERT advisory, RSA labs bulletin, publicity about the attack, and whatever else is around there which tells people about the problem and (very simple) fix. 3. The PKCS #1 implementation being used is correct (that is, it doesn't have the implementation bug which was found and fixed in the SSL implementations). 4. A typical query+response takes half a second (this means opening a connecting, generating a chosen-ciphertext message, transmitting it, having the victim decode and try to decrypt it, generating a response, wrapping up an exact indication of the decryption error it encountered, and sending it back to the attacker). OK, so we have a server which does all of the above sitting there ready for attack. With a correct PKCS #1 implementation (that is, it checks the padding as per the PKCS #1 spec), the complexity is approximately 1 million attempts (for the 00 02 padding) x 20 (for the second 00 before the MEK) x 2 (for the minimum of 8 nonzero bytes), or 40 million attempts (the 1 million attempts requires the presence of the SSL implementation bug mentioned above). This requires just under 8 months of CPU time to perform, after which you've recovered a single MEK [S/MIME jargon for "message encryption key"]. I would suggest that anyone who doesn't notice that their server is under continuous attack for 8 solid months has more than simple crypto problems to worry about. -- Snip -- Peter. From owner-ietf-open-pgp@imc.org Thu Apr 8 18:22:42 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07249 for ; Thu, 8 Apr 1999 18:22:42 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA20510 for ietf-open-pgp-bks; Thu, 8 Apr 1999 14:39:53 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20506 for ; Thu, 8 Apr 1999 14:39:52 -0700 (PDT) Received: from jcallas (dhcp-47-64.dhcp.nai.com [161.69.47.64]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id OAA20279; Thu, 8 Apr 1999 14:38:43 -0700 (PDT) Message-Id: <3.0.3.32.19990408143618.03cb97f0@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 08 Apr 1999 14:36:18 -0700 To: hal@rain.org, ietf-open-pgp@imc.org, jcallas@NAI.com From: Jon Callas Subject: Re: Sample Twofish message In-Reply-To: <199904080539.WAA02648@hal.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 10:39 PM 4/7/99 -0700, hal@rain.org wrote: |Yes, you're right, that is inconsistent with section 5.7. I don't |know how we should resolve it. | When we were working on the RFC, the question of larger blocks came up, and there were some suggestions of changing all the 8s to Ns, and 10s to N+2s etc. There was the concern that we would make a mistake. We had the advantage the first time that people (like Tom) coded to the original description, and thus we had a check that it actually worked. So I put in the paragraph in 12.8, as a quick way to describe how to do the right thing. Do we agree now that the right thing to do is to start with a 16-byte IV, encrypt 16 bytes, sync with 2 and then continue? That's what I thought we all agreed on. If we agree that, then we don't have a problem, we have an elided description that needs to be expanded when we revise the RFC. I believe, though, that that's the right thing to do, work with full blocksizes. Jon ----- Jon Callas jon@pgp.com CTO, Total Network Security 3965 Freedom Circle Network Associates, Inc. Santa Clara, CA 95054 (408) 346-5860 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) From owner-ietf-open-pgp@imc.org Thu Apr 8 19:25:49 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07499 for ; Thu, 8 Apr 1999 19:25:48 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA20984 for ietf-open-pgp-bks; Thu, 8 Apr 1999 15:28:08 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA20979 for ; Thu, 8 Apr 1999 15:28:06 -0700 (PDT) Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Thu Apr 8 18:26:40 EDT 1999 Received: from aura.research.bell-labs.com ([135.104.46.10]) by research; Thu Apr 8 18:26:39 EDT 1999 Received: (from bleichen@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id SAA21909; Thu, 8 Apr 1999 18:26:39 -0400 (EDT) Date: Thu, 8 Apr 1999 18:26:39 -0400 (EDT) From: Daniel Bleichenbacher Message-Id: <199904082226.SAA21909@aura.research.bell-labs.com> To: bleichen@research.bell-labs.com, ietf-open-pgp@imc.org, pgut001@cs.auckland.ac.nz Subject: Re: Decrypting ElGamal messages X-Sun-Charset: US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > From: pgut001@cs.auckland.ac.nz (Peter Gutmann) > Date: Fri, 9 Apr 1999 09:46:07 (NZST) > > Daniel Bleichenbacher writes: > > >I'm asking this question, because ElGamal encryption has the same > >multiplicative properties as RSA. In particular, given the encryption of a > >message M (including padding), it is easy to generate the encryption of M*S > >(mod p) for a given S, without knowing M. Hence the same attack that was > >possible against SSL potentially works against ElGamal, when used with PKCS > >#1 v1.5 padding. > > > >BTW, is there any reason why PKCS #1 v1.5 padding is used and not PKCS #1 v2? > > This exact issue was debated on the ietf-smime list when I asked why X9.42 > (which looks like the winning candidate from a 'Worst way to apply the DLP to > solving a key transport problem' competition... [remainder bobbitted to avoid > another flamewar over this :-]) was being used instead of the far more logical > Elgamal, which would be a direct, patent-free drop-in replacement for the > existing RSA key transport. The only reason anyone could put up against > Elgamal was "You need to use OAEP because PKCS #1 padding is insecure". In > response to this (at the end of a longish debate) I posted the following > back-of-the-envelope analysis: > > -- Snip -- > > The second approach is to see just what it would take to implement this attack > on CMS (not S/MIME, but anything involving CMS). For this analysis I'll make > several assumptions: > > 1. The implementor has managed to design a protocol which will accept > arbitrary numbers of chosen-ciphertext messages and reply to each one with > an exact indication of how the decrypt failed, leaking information about > the decrypted message to an attacker. This is a fairly remarkable feat, > but let's say, just for arguments sake, that someone did do this. I'm not sure how remarkable this would be. Quite a large number of SSL servers actually returned the necessary error messages for an attack there. I think one shouldn't leave the chance here that the implementor makes mistakes and add some quidelines to the standard. > 2. The implementor and any third-party reviewers have somehow missed the CERT > advisory, RSA labs bulletin, publicity about the attack, and whatever else > is around there which tells people about the problem and (very simple) fix. They also have to know that ElGamal and RSA have similar mathematical properties. But, again wouldn't it be better if these people were informed via the standard? > 3. The PKCS #1 implementation being used is correct (that is, it doesn't have > the implementation bug which was found and fixed in the SSL implementations). Sure. You need to include a message digest. But if I'm correct then open-pgp uses a 2 byte modular checksum. > 4. A typical query+response takes half a second (this means opening a > connecting, generating a chosen-ciphertext message, transmitting it, having > the victim decode and try to decrypt it, generating a response, wrapping up > an exact indication of the decryption error it encountered, and sending it > back to the attacker). The latest that I heard of was a server presented at the RSA conference that can do 1500 SSL connections per second. > OK, so we have a server which does all of the above sitting there ready for > attack. With a correct PKCS #1 implementation (that is, it checks the padding > as per the PKCS #1 spec), the complexity is approximately 1 million attempts > (for the 00 02 padding) x 20 (for the second 00 before the MEK) x 2 (for the > minimum of 8 nonzero bytes), or 40 million attempts (the 1 million attempts > requires the presence of the SSL implementation bug mentioned above). > > This requires just under 8 months of CPU time to perform, after which you've > recovered a single MEK [S/MIME jargon for "message encryption key"]. The 1 million messages was an estimate for my algorithm for 1024 bit RSA moduli. This algorithm is not optimal. 100'000 is probably reachable with some work. Also for some strange moduli (e.g. 1025 bit) some experiments required less than 10'000 messages. It's not hard to imagine that someone configures a server that can be broken in much less than 1 hour. (Please note, this is an estimate for plain PKCS #1 v 1.5 formatting. I don't know anything about ElGamal padding yet.) > I would suggest that anyone who doesn't notice that their server is under > continuous attack for 8 solid months has more than simple crypto problems to > worry about. > > -- Snip -- > > Peter. Intrusion detection tricks like this are certainly worth considering. But I'd prefer a protocol that doesn't rely on this. Daniel From owner-ietf-open-pgp@imc.org Thu Apr 8 21:03:10 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08989 for ; Thu, 8 Apr 1999 21:03:08 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA22056 for ietf-open-pgp-bks; Thu, 8 Apr 1999 17:18:15 -0700 (PDT) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA22052 for ; Thu, 8 Apr 1999 17:18:14 -0700 (PDT) Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.3/8.9.3) with ESMTP id RAA27738; Thu, 8 Apr 1999 17:18:03 -0700 (PDT) Received: (from hal@localhost) by hal.sb.rain.org (8.8.7/8.8.7) id RAA01291; Thu, 8 Apr 1999 17:17:58 -0700 Date: Thu, 8 Apr 1999 17:17:58 -0700 From: hal@rain.org Message-Id: <199904090017.RAA01291@hal.sb.rain.org> To: bleichen@research.bell-labs.com, ietf-open-pgp@imc.org Subject: Re: Decrypting ElGamal messages Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Daniel Bleichenbacher, , writes: > Can anyone tell me how an ElGamal encrypted message has to be > decrypted? The open-pgp documentation doesn't give the answer. > I'm specially interested in how padding and checksums are handled. With both RSA and ElGamal messages, the session key is prepended with a byte identifying the symmetric algorithm used to encrypt the bulk message data (typically one of three or four supported symmetric algorithm values can go here). It is then appended with a two-byte checksum. The resulting string is PKCS-1 padded and encrypted. Upon decryption, the recipient needs to check the PKCS-1 formatting, the checksum, and that the symmetric algorithm byte is one of the supported algorithms. It then tries to decrypt the following message block using that algorithm and session key, which block also has in it a two-byte redundancy at the beginning to further detect bad keys. > I'm asking this question, because ElGamal encryption has the > same multiplicative properties as RSA. In particular, given > the encryption of a message M (including padding), it is easy > to generate the encryption of M*S (mod p) for a given S, without > knowing M. Hence the same attack that was possible against SSL > potentially works against ElGamal, when used with PKCS #1 v1.5 > padding. It would be good to mention this attack in a future version of the draft. It is important not to leak information about which step in the decryption process fails. Then, in order to fake a successful encrypted session key, it must not only be properly PKCS-1 padded, it must also have a correct two-byte checksum (adding 16 bits of difficulty), it must have a legal symmetric algorithm byte (adding about 6 bits of difficulty), and it must pass the checksum test when the payload data is decrypted (adding another 16 bits). This would make the attack in total about 2^38 times harder than against a bare PKCS-1 leaking decryptor, which should be a significant barrier in most practical situations. > BTW, is there any reason why PKCS #1 v1.5 padding is used and > not PKCS #1 v2? Although the RFC came out recently, it documents existing practice which was developed in 1996. At that time version 1.5 of PKCS 1 was extant. Hal Finney NAI, Inc. From owner-ietf-open-pgp@imc.org Thu Apr 8 21:39:52 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09425 for ; Thu, 8 Apr 1999 21:39:51 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA22682 for ietf-open-pgp-bks; Thu, 8 Apr 1999 18:11:29 -0700 (PDT) Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA22678 for ; Thu, 8 Apr 1999 18:11:25 -0700 (PDT) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id NAA06463; Fri, 9 Apr 1999 13:10:56 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92362025506148>; Fri, 9 Apr 1999 13:10:55 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: bleichen@research.bell-labs.com, ietf-open-pgp@imc.org Subject: Re: Decrypting ElGamal messages Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Fri, 9 Apr 1999 13:10:55 (NZST) Message-ID: <92362025506148@cs26.cs.auckland.ac.nz> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: >>1. The implementor has managed to design a protocol which will accept >> arbitrary numbers of chosen-ciphertext messages and reply to each one with >> an exact indication of how the decrypt failed, leaking information about >> the decrypted message to an attacker. This is a fairly remarkable feat, >> but let's say, just for arguments sake, that someone did do this. >I'm not sure how remarkable this would be. Quite a large number of SSL servers >actually returned the necessary error messages for an attack there. I think >one shouldn't leave the chance here that the implementor makes mistakes and >add some quidelines to the standard. That's what I'd proposed earlier on in the same thread. In addition you have to remember that S/MIME and PGP are very different beasties from SSL, unless you go out of your way to design a protocol which returns decryption results you'd never get this situation, the best you can hope for is an SMTP-level "Your mail probably got to some machine from which the recipient can collect it" which never gets near the security layer. Even though S/MIME has provisions for signed receipts, the most they can communicate is "I got your message", which is just a glorified form of the SMTP-level response and doesn't help with this particular attack. >>4. A typical query+response takes half a second (this means opening a >> connecting, generating a chosen-ciphertext message, transmitting it, having >> the victim decode and try to decrypt it, generating a response, wrapping up >> an exact indication of the decryption error it encountered, and sending it >> back to the attacker). >The latest that I heard of was a server presented at the RSA conference that >can do 1500 SSL connections per second. Again, it's a special case for SSL. For it to affect S/MIME or PGP you'd need to set up an autoresponder running a custom protocol designed to facilitate the attack (since it can't be done using any feature of standard S/MIME or PGP). Peter. From owner-ietf-open-pgp@imc.org Thu Apr 8 21:44:51 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09487 for ; Thu, 8 Apr 1999 21:44:51 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA22761 for ietf-open-pgp-bks; Thu, 8 Apr 1999 18:18:02 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA22757 for ; Thu, 8 Apr 1999 18:18:01 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id VAA06678; Thu, 8 Apr 1999 21:17:53 -0400 Received: from buoy.watson.ibm.com (buoy.watson.ibm.com [9.2.3.94]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id VAA07832; Thu, 8 Apr 1999 21:17:52 -0400 Received: by buoy.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA28494; Thu, 8 Apr 1999 21:17:46 -0400 From: Uri Blumenthal Message-Id: <9904090117.AA28494@buoy.watson.ibm.com> Subject: Re: Sample Twofish message To: wk@isil.d.shuttle.de (Werner Koch) Date: Thu, 8 Apr 1999 21:17:36 -0400 (EDT) Cc: ietf-open-pgp@imc.org In-Reply-To: <19990408074957.B5540@frodo.isil.d.shuttle.de> from "Werner Koch" at Apr 8, 99 07:49:57 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Werner Koch says: > Okay, how can we resolve this conflict: > >From section 5.7: > The data is encrypted in CFB mode, with a CFB shift size equal to the > cipher's block size. The Initial Vector (IV) is specified as all > zeros. Instead of using an IV, OpenPGP prefixes a 10-octet string to > the data before it is encrypted. The first eight octets are random, > and the 9th and 10th octets are copies of the 7th and 8th octets, > respectively. After encrypting the first 10 octets, the CFB state is > resynchronized if the cipher block size is 8 octets or less. The > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > last 8 octets of ciphertext are passed through the cipher and the > block boundary is reset. 1. For 128-bit block ciphers shouldn't the prefix be increased to, say, 18 bytes? 2. Shouldn't all procedures be adjusted to 16 octets for such ciphers? > >From section 12.8:......... > > 5.7 says that resync is only done for a blocksize <= 64 but 12.8 says > that is done always (the following step by step list also says this). I'd abandon (or fix :-) 12.8. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ietf-open-pgp@imc.org Fri Apr 9 07:28:25 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00815 for ; Fri, 9 Apr 1999 07:28:24 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA18958 for ietf-open-pgp-bks; Fri, 9 Apr 1999 02:51:03 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA18946 for ; Fri, 9 Apr 1999 02:50:58 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id LAA03703 for ietf-open-pgp@imc.org; Fri, 9 Apr 1999 11:50:54 +0200 (MET DST) Received: (qmail 20190 invoked from network); 9 Apr 1999 09:36:01 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 9 Apr 1999 09:36:01 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10VXf7-0003mw-00; Fri, 9 Apr 1999 11:33:21 +0200 Date: Fri, 9 Apr 1999 11:33:21 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Sample Twofish message Message-ID: <19990409113321.F14298@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904080539.WAA02648@hal.sb.rain.org> <3.0.3.32.19990408143618.03cb97f0@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <3.0.3.32.19990408143618.03cb97f0@mail.pgp.com>; from Jon Callas on Thu, Apr 08, 1999 at 02:36:18PM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Jon Callas writes: > Do we agree now that the right thing to do is to start with a 16-byte IV, > encrypt 16 bytes, sync with 2 and then continue? That's what I thought we ACK. > all agreed on. If we agree that, then we don't have a problem, we have an > elided description that needs to be expanded when we revise the RFC. I > believe, though, that that's the right thing to do, work with full blocksizes. We use a 8 byte IV for encrypting the secret key material; see section 5.5.3. Do we keep this 8 bytes or extend it to the blocksize? -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Fri Apr 9 08:03:26 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01706 for ; Fri, 9 Apr 1999 08:03:25 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA24400 for ietf-open-pgp-bks; Fri, 9 Apr 1999 04:28:54 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA24390 for ; Fri, 9 Apr 1999 04:28:46 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id NAA11740 for ietf-open-pgp@imc.org; Fri, 9 Apr 1999 13:28:42 +0200 (MET DST) Received: (qmail 20805 invoked from network); 9 Apr 1999 11:24:15 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 9 Apr 1999 11:24:15 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10VZLs-0004Rr-00; Fri, 9 Apr 1999 13:21:36 +0200 Date: Fri, 9 Apr 1999 13:21:35 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: New sample message Message-ID: <19990409132135.A17074@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904080539.WAA02648@hal.sb.rain.org> <3.0.3.32.19990408143618.03cb97f0@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <3.0.3.32.19990408143618.03cb97f0@mail.pgp.com>; from Jon Callas on Thu, Apr 08, 1999 at 02:36:18PM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi, Here is a new sample message for 256 bit block ciphers. Can anyone please check it? Note, that the message is preceded by 16 random bytes, then two more bytes which are copies of the last two of the random ones. A CFB sync is done after encrypting these 18 bytes. The message is encrypted using the one-letter passphrase "x". -----BEGIN PGP MESSAGE----- jA0ECgMCTwlMs52octhgyTEFgAUN6FWXpPHkYLqajQoEL0nK6G43N7aOKtfvAI7c faEmtImxBUrnq+P1a+PgWjiu =xKas -----END PGP MESSAGE----- The structure of this message is: :symkey enc packet: version 4, cipher 10, s2k 3, hash 2 salt 4f094cb39da872d8, count 96 :encrypted data packet: length: 49 :literal data packet: mode b, created 923655302, name="tf2", raw data: 20 bytes The 256 bit key is: D5 13 A1 FA 34 9C 99 71 55 EC 8A 48 76 F8 BD 2E A1 24 D8 78 75 0C 86 04 49 DF 3E 6F 85 56 25 D5 The begin of the plaintext messsage is: 81 3D D9 FE 58 35 62 7A 1E 0D 1C 6F 4D 10 04 4C 04 4C -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Fri Apr 9 12:19:49 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04206 for ; Fri, 9 Apr 1999 12:19:48 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA29017 for ietf-open-pgp-bks; Fri, 9 Apr 1999 08:44:55 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA29013 for ; Fri, 9 Apr 1999 08:44:54 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id LAA11148; Fri, 9 Apr 1999 11:44:14 -0400 Received: from buoy.watson.ibm.com (buoy.watson.ibm.com [9.2.3.94]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id LAA09668; Fri, 9 Apr 1999 11:44:14 -0400 Received: by buoy.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA16968; Fri, 9 Apr 1999 11:44:13 -0400 From: Uri Blumenthal Message-Id: <9904091544.AA16968@buoy.watson.ibm.com> Subject: Re: Sample Twofish message To: wk@isil.d.shuttle.de (Werner Koch) Date: Fri, 9 Apr 1999 11:44:12 -0400 (EDT) Cc: ietf-open-pgp@imc.org In-Reply-To: <19990409113321.F14298@frodo.isil.d.shuttle.de> from "Werner Koch" at Apr 9, 99 11:33:21 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Werner Koch says: > We use a 8 byte IV for encrypting the secret key material; see > section 5.5.3. Do we keep this 8 bytes or extend it to the blocksize? IV length normally is equal to the block size. I see no reason to divert from this. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ietf-open-pgp@imc.org Fri Apr 9 12:54:51 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04543 for ; Fri, 9 Apr 1999 12:54:50 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29370 for ietf-open-pgp-bks; Fri, 9 Apr 1999 09:20:58 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29366 for ; Fri, 9 Apr 1999 09:20:56 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id SAA04463 for ietf-open-pgp@imc.org; Fri, 9 Apr 1999 18:20:55 +0200 (MET DST) Received: (qmail 21240 invoked from network); 9 Apr 1999 16:13:57 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 9 Apr 1999 16:13:57 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10VdsH-0004XI-00; Fri, 9 Apr 1999 18:11:21 +0200 Date: Fri, 9 Apr 1999 18:11:21 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Sample Twofish message Message-ID: <19990409181120.A17264@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <19990409113321.F14298@frodo.isil.d.shuttle.de> <9904091544.AA16968@buoy.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <9904091544.AA16968@buoy.watson.ibm.com>; from Uri Blumenthal on Fri, Apr 09, 1999 at 11:44:12AM -0400 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Uri Blumenthal writes: > IV length normally is equal to the block size. I see no reason to > divert from this. Actually it is not the IV (which is always zero) but the random bytes prepended to the plaintext. However I think you are right and we should agree to use an IV of the blocksize instead of 8. The problem with this is that an application needs to know the blocksize of all possible algorithms to parse the packet - maybe it is better to change it only if we specify a new version number of the packet, Hmmm... -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Fri Apr 9 13:41:31 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04998 for ; Fri, 9 Apr 1999 13:41:30 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29706 for ietf-open-pgp-bks; Fri, 9 Apr 1999 09:58:04 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA29702 for ; Fri, 9 Apr 1999 09:58:02 -0700 (PDT) Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Fri Apr 9 12:56:45 EDT 1999 Received: from aura.research.bell-labs.com ([135.104.46.10]) by research; Fri Apr 9 12:56:44 EDT 1999 Received: (from bleichen@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id MAA27520; Fri, 9 Apr 1999 12:56:43 -0400 (EDT) Date: Fri, 9 Apr 1999 12:56:43 -0400 (EDT) From: Daniel Bleichenbacher Message-Id: <199904091656.MAA27520@aura.research.bell-labs.com> To: bleichen@research.bell-labs.com, ietf-open-pgp@imc.org, hal@rain.org Subject: Re: Decrypting ElGamal messages X-Sun-Charset: US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hal Finney , writes: > Daniel Bleichenbacher, , writes: > > Can anyone tell me how an ElGamal encrypted message has to be > > decrypted? The open-pgp documentation doesn't give the answer. > > I'm specially interested in how padding and checksums are handled. > > With both RSA and ElGamal messages, the session key is prepended with a > byte identifying the symmetric algorithm used to encrypt the bulk message > data (typically one of three or four supported symmetric algorithm > values can go here). It is then appended with a two-byte checksum. > The resulting string is PKCS-1 padded and encrypted. > > Upon decryption, the recipient needs to check the PKCS-1 formatting, > the checksum, and that the symmetric algorithm byte is one of the > supported algorithms. It then tries to decrypt the following message > block using that algorithm and session key, which block also has in > it a two-byte redundancy at the beginning to further detect bad keys. Thanks a lot for the information. Would have missed the checksum in the bulk data otherwise. > > I'm asking this question, because ElGamal encryption has the > > same multiplicative properties as RSA. In particular, given > > the encryption of a message M (including padding), it is easy > > to generate the encryption of M*S (mod p) for a given S, without > > knowing M. Hence the same attack that was possible against SSL > > potentially works against ElGamal, when used with PKCS #1 v1.5 > > padding. > > It would be good to mention this attack in a future version of the draft. > It is important not to leak information about which step in the decryption > process fails. > > Then, in order to fake a successful encrypted session key, it must not > only be properly PKCS-1 padded, it must also have a correct two-byte > checksum (adding 16 bits of difficulty), it must have a legal symmetric > algorithm byte (adding about 6 bits of difficulty), and it must pass the > checksum test when the payload data is decrypted (adding another 16 bits). > This would make the attack in total about 2^38 times harder than against > a bare PKCS-1 leaking decryptor, which should be a significant barrier > in most practical situations. I'm not sure about this "2^38 times harder...", but estimating this number is exactly the goal of the whole exercise. Are there any publications considering the security of the openpgp message format against chosen ciphertext attacks? As Peter Gutmann pointed out, a chosen ciphertext attacks would be almost impossible against plain PGP. The openpgp standard should however be useful for any application using the same message format, and client-server applications should not be prevented. > > BTW, is there any reason why PKCS #1 v1.5 padding is used and > > not PKCS #1 v2? > > Although the RFC came out recently, it documents existing practice which > was developed in 1996. At that time version 1.5 of PKCS 1 was extant. > > Hal Finney > NAI, Inc. Daniel Bleichenbacher From owner-ietf-open-pgp@imc.org Fri Apr 9 13:41:53 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05015 for ; Fri, 9 Apr 1999 13:41:53 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29695 for ietf-open-pgp-bks; Fri, 9 Apr 1999 09:56:21 -0700 (PDT) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29691 for ; Fri, 9 Apr 1999 09:56:20 -0700 (PDT) Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.3/8.9.3) with ESMTP id JAA11632; Fri, 9 Apr 1999 09:56:15 -0700 (PDT) Received: (from hal@localhost) by hal.sb.rain.org (8.8.7/8.8.7) id JAA02411; Fri, 9 Apr 1999 09:24:19 -0700 Date: Fri, 9 Apr 1999 09:24:19 -0700 From: hal@rain.org Message-Id: <199904091624.JAA02411@hal.sb.rain.org> To: uri@watson.ibm.com Subject: Re: Sample Twofish message Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Uri Blumenthal, , writes: > Werner Koch says: > > We use a 8 byte IV for encrypting the secret key material; see > > section 5.5.3. Do we keep this 8 bytes or extend it to the blocksize? > > IV length normally is equal to the block size. I see no reason to > divert from this. With regard to the secret key encryption: The only real requirement on an IV is that it is unique for that key, that it does not match any other IV's and it doesn't match any of the ciphertext blocks which are used with that key. For this purpose, 64 bits should be adequate unless we store more than 4 billion (2^32) private keys using the same passphrase (and even then the unique salt would save us). So a 64 bit IV is plenty big. However in the interests of convenience and consistency it would probably make more sense to use the block size. This avoids any ambiguities about whether a shorter IV should be left or right justified and how the remaining bits of the block should be filled in. With regard to message encryption, the symmetrically encrypted data packets: The 8+2 bytes which precede the message are not technically an IV; the IV is zero, and the 8+2 bytes are used in place of an IV to accomplish the same purpose. However this size does not work properly in the case of 128 bit blocks. If we had two messages encrypted with the same key, then for each of them we would encrypt a block of zeros and XOR that with the first 16 bytes of the message, to form the ciphertext. Only the first 10 bytes are random; the remaining 6 are plaintext. Therefore the last 6 bytes of this first block of data would be the first 6 bytes of plaintext, xored with a value which was the same for each encryption where that same key was used. This would allow an attacker to recover the XOR of the first 6 bytes of the plaintexts of multiple messages, and possibly therefore to find these 6 bytes of plaintext. This is a serious leak. We would possibly be saved by the fact that the spec says to use salt in hashing the passphrase, so it is unlikely that any two messages are encrypted with the same key even if the same passphrase is used. But still there is no reason to take this chance. Therefore we should increase the 8 bytes to be the size of the block cipher. Several people have commented that they don't like the extra CFB sync operation which is done after the first 8+2 (or now 16+2) bytes are read. It is a nonstandard operation and requires special code in the CFB module. I had suggested that we skip the CFB for larger blocks, on the theory that we would eventually migrate to larger block ciphers throughout, and then we could retire the CFB sync along with the support of 64 bit block ciphers. This would be perhaps four or five years from now. It is not difficult to code the CFB sync to be optional based on block size. Can we consider keeping the language to use the extra sync only for 64 bit block ciphers? Hal Finney NAI, Inc. From owner-ietf-open-pgp@imc.org Fri Apr 9 13:44:55 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05036 for ; Fri, 9 Apr 1999 13:44:54 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA29774 for ietf-open-pgp-bks; Fri, 9 Apr 1999 10:03:02 -0700 (PDT) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA29770 for ; Fri, 9 Apr 1999 10:03:02 -0700 (PDT) Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.3/8.9.3) with ESMTP id KAA12337; Fri, 9 Apr 1999 10:02:55 -0700 (PDT) Received: (from hal@localhost) by hal.sb.rain.org (8.8.7/8.8.7) id KAA02554; Fri, 9 Apr 1999 10:02:52 -0700 Date: Fri, 9 Apr 1999 10:02:52 -0700 From: hal@rain.org Message-Id: <199904091702.KAA02554@hal.sb.rain.org> To: ietf-open-pgp@imc.org, wk@isil.d.shuttle.de Subject: Re: Sample Twofish message Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Werner Koch, , writes: > Uri Blumenthal writes: > > IV length normally is equal to the block size. I see no reason to > > divert from this. > > Actually it is not the IV (which is always zero) but the random bytes > prepended to the plaintext. However I think you are right and we > should agree to use an IV of the blocksize instead of 8. The problem > with this is that an application needs to know the blocksize of all > possible algorithms to parse the packet - maybe it is better to change > it only if we specify a new version number of the packet, Hmmm... I believe Uri was referring to the passphrase-protected secret key data, which does use an IV in the conventional sense. As far as the need to know the block size, this would only be a problem if you faced an unknown cipher ID. But in that case you can't decrypt the rest of the packet anyway, so there is no need to parse it. You do have information about the overall packet size from the packet headers, so you can just skip past the encrypted data. I just spoke on the phone with Phil Zimmermann, who suggested a different approach for this problem. I will post a summary later this morning. Hal From owner-ietf-open-pgp@imc.org Fri Apr 9 15:14:23 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06327 for ; Fri, 9 Apr 1999 15:14:22 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA00805 for ietf-open-pgp-bks; Fri, 9 Apr 1999 11:40:17 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA00801 for ; Fri, 9 Apr 1999 11:40:16 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id UAA13426 for ietf-open-pgp@imc.org; Fri, 9 Apr 1999 20:40:14 +0200 (MET DST) Received: (qmail 21386 invoked from network); 9 Apr 1999 18:31:09 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 9 Apr 1999 18:31:09 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10Vg13-0004Z8-00; Fri, 9 Apr 1999 20:28:33 +0200 Date: Fri, 9 Apr 1999 20:28:33 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Sample Twofish message Message-ID: <19990409202833.A17482@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904091702.KAA02554@hal.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <199904091702.KAA02554@hal.sb.rain.org>; from hal@rain.org on Fri, Apr 09, 1999 at 10:02:52AM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: hal@rain.org writes: > I believe Uri was referring to the passphrase-protected secret key > data, which does use an IV in the conventional sense. Hmmm, from the pgp 2.6.3 documentation about secret key certificates: | and the checksum is used to tell if the password was good. The CFB | IV field is just encrypted random data, assuming the "true" IV was | zero. This is what is done in GnuPG too and I have checked interoperability against pgp 5.0beta. > the rest of the packet anyway, so there is no need to parse it. You do > have information about the overall packet size from the packet headers, > so you can just skip past the encrypted data. Sure, it adds extra complexity to the already complex issue with S2K and pgp2 mode - but no problem ;-) > approach for this problem. I will post a summary later this morning. This means late evening in Europe :-( -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Fri Apr 9 15:18:08 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06398 for ; Fri, 9 Apr 1999 15:18:07 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA00614 for ietf-open-pgp-bks; Fri, 9 Apr 1999 11:30:09 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA00610 for ; Fri, 9 Apr 1999 11:30:07 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id OAA09716; Fri, 9 Apr 1999 14:29:54 -0400 Received: from buoy.watson.ibm.com (buoy.watson.ibm.com [9.2.3.94]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id OAA18272; Fri, 9 Apr 1999 14:29:22 -0400 Received: by buoy.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA28528; Fri, 9 Apr 1999 14:29:12 -0400 From: Uri Blumenthal Message-Id: <9904091829.AA28528@buoy.watson.ibm.com> Subject: Re: Sample Twofish message To: hal@rain.org Date: Fri, 9 Apr 1999 14:29:12 -0400 (EDT) Cc: ietf-open-pgp@imc.org In-Reply-To: <199904091624.JAA02411@hal.sb.rain.org> from "hal@rain.org" at Apr 9, 99 09:24:19 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: hal@rain.org says: > > IV length normally is equal to the block size. I see no reason to > > divert from this. > > With regard to the secret key encryption: > The only real requirement on an IV is that it is unique for that key, > that it does not match any other IV's and it doesn't match any of the > ciphertext blocks which are used with that key. For this purpose, > 64 bits should be adequate unless we store more than 4 billion (2^32) > private keys using the same passphrase (and even then the unique salt > would save us). So a 64 bit IV is plenty big. True. But: > However in the interests of convenience and consistency it would probably > make more sense to use the block size. This avoids any ambiguities > about whether a shorter IV should be left or right justified and how > the remaining bits of the block should be filled in. Exactly! > With regard to message encryption, the symmetrically encrypted data > packets: > > The 8+2 bytes which precede the message are not technically an IV; the > IV is zero, and the 8+2 bytes are used in place of an IV to accomplish > the same purpose. However this size does not work properly in the case > of 128 bit blocks. In essence those 8+2 bytes *are* performing the function of IV. > [...description of a problem....] This is a serious leak. Probably. (:-) > .........But still there is no reason to take this chance. > Therefore we should increase the 8 bytes to be the size of the block > cipher. (:-) My wish precisely! > It is not difficult to code the CFB sync to be optional based on > block size. Can we consider keeping the language to use the extra > sync only for 64 bit block ciphers? Probably. No strong preference either way. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ietf-open-pgp@imc.org Fri Apr 9 16:20:43 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07041 for ; Fri, 9 Apr 1999 16:20:42 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA00811 for ietf-open-pgp-bks; Fri, 9 Apr 1999 11:40:21 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA00807 for ; Fri, 9 Apr 1999 11:40:19 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id UAA13433 for ietf-open-pgp@imc.org; Fri, 9 Apr 1999 20:40:17 +0200 (MET DST) Received: (qmail 21392 invoked from network); 9 Apr 1999 18:33:00 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 9 Apr 1999 18:33:00 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10Vg2q-0004ZE-00; Fri, 9 Apr 1999 20:30:24 +0200 Date: Fri, 9 Apr 1999 20:30:24 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Sample Twofish message Message-ID: <19990409203024.B17482@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904091624.JAA02411@hal.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <199904091624.JAA02411@hal.sb.rain.org>; from hal@rain.org on Fri, Apr 09, 1999 at 09:24:19AM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: hal@rain.org writes: > block size. Can we consider keeping the language to use the extra > sync only for 64 bit block ciphers? Yes. -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Fri Apr 9 17:19:30 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07587 for ; Fri, 9 Apr 1999 17:19:29 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA01878 for ietf-open-pgp-bks; Fri, 9 Apr 1999 13:31:18 -0700 (PDT) Received: from relay6.UU.NET (relay6.UU.NET [192.48.96.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA01874 for ; Fri, 9 Apr 1999 13:31:16 -0700 (PDT) Received: from xedia.com by relay6.UU.NET with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgkfy21116; Fri, 9 Apr 1999 16:30:19 -0400 (EDT) Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA22231; Fri, 9 Apr 99 16:30:08 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id QAA06095; Fri, 9 Apr 1999 16:30:12 -0400 Date: Fri, 9 Apr 1999 16:30:12 -0400 Message-Id: <199904092030.QAA06095@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: uri@watson.ibm.com Cc: hal@rain.org, ietf-open-pgp@imc.org Subject: Re: Sample Twofish message References: <199904091624.JAA02411@hal.sb.rain.org> <9904091829.AA28528@buoy.watson.ibm.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Content-Transfer-Encoding: 7bit >>>>> "Uri" == Uri Blumenthal writes: Uri> hal@rain.org says: >> > IV length normally is equal to the block size. I see no reason >> to > divert from this. >> >> With regard to the secret key encryption: The only real >> requirement on an IV is that it is unique for that key, that it >> does not match any other IV's and it doesn't match any of the >> ciphertext blocks which are used with that key. For this purpose, >> 64 bits should be adequate unless we store more than 4 billion >> (2^32) private keys using the same passphrase (and even then the >> unique salt would save us). So a 64 bit IV is plenty big. Uri> True. But: >> However in the interests of convenience and consistency it would >> probably make more sense to use the block size. This avoids any >> ambiguities about whether a shorter IV should be left or right >> justified and how the remaining bits of the block should be filled >> in. Uri> Exactly! I'm very hard pressed to see ANY valid argument for making an IV smaller than the blocksize. Even if it technically possible (which I guess it is with CFB mode) it should not be done. There is no benefit I can see, and a very clear issue: if you have a cypher with 128 bit blocks, 128 bit strength, etc., what conceivable cryptographic merit is there in introducing a 64 bit component into the puzzle? Why go through the process of analyzing the security implications and demonstrating that there aren't any when there is no benefit to be had? Or of there is one, certainly not one that justifies months of analysis? My impression from watching AES discussions is that weaknesses that open up O(2^64) attacks of any kind are considered things to be concerned about. Not being an academically trained cryptographer I may be reading too much into the discussion, but even so, that seems like a logical position to take. paul From owner-ietf-open-pgp@imc.org Fri Apr 9 19:15:29 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08321 for ; Fri, 9 Apr 1999 19:15:28 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA03401 for ietf-open-pgp-bks; Fri, 9 Apr 1999 15:46:00 -0700 (PDT) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA03397 for ; Fri, 9 Apr 1999 15:45:58 -0700 (PDT) Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.3/8.9.3) with ESMTP id PAA17943; Fri, 9 Apr 1999 15:45:55 -0700 (PDT) Received: (from hal@localhost) by hal.sb.rain.org (8.8.7/8.8.7) id PAA00841; Fri, 9 Apr 1999 15:45:02 -0700 Date: Fri, 9 Apr 1999 15:45:02 -0700 From: hal@rain.org Message-Id: <199904092245.PAA00841@hal.sb.rain.org> To: ietf-open-pgp@imc.org, wk@isil.d.shuttle.de Subject: Re: Sample Twofish message Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Werner Koch, , writes: > hal@rain.org writes: > > > I believe Uri was referring to the passphrase-protected secret key > > data, which does use an IV in the conventional sense. > > Hmmm, from the pgp 2.6.3 documentation about secret key certificates: > > | and the checksum is used to tell if the password was good. The CFB > | IV field is just encrypted random data, assuming the "true" IV was > | zero. > > This is what is done in GnuPG too and I have checked interoperability > against pgp 5.0beta. This is actually pretty funny. We're both interpreting it differently, but we interoperate. By my interpretation, the first 8 bytes are an IV. We encrypt those with the key, and XOR into the next 8 bytes to get the first 8 bytes of plaintext. With your interpretation, the IV is zero. You encrypt that with the key and XOR into the first 8 bytes to get 8 random bytes, which you discard. You then take the first block of ciphertext, whiich is the first 8 bytes of data, encrypt it with the key, and XOR into the next 8 bytes to get the first 8 bytes of plaintext. The result is exactly the same. That's why it interoperates. With CFB mode, each ciphertext block acts like an "IV" for the next block. The situation is different for encrypted data blocks, because there we have the extra two bytes of check data which must be compared against the decrypted form of the first 8 bytes. So we must use the convention of a zero IV to successfully decrypt that. But with the encrypted secret keys there are no check bytes and the two descriptions are equivalent (as long as the IV size == the block size). Sorry I have not yet sent out Phil's proposal, I've been having connectivity problems today. Hal Finney From owner-ietf-open-pgp@imc.org Mon Apr 12 16:08:25 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07881 for ; Mon, 12 Apr 1999 16:08:25 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA19859 for ietf-open-pgp-bks; Mon, 12 Apr 1999 12:04:11 -0700 (PDT) Received: from public.uni-hamburg.de (public.rrz.uni-hamburg.de [134.100.32.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA19854 for ; Mon, 12 Apr 1999 12:04:02 -0700 (PDT) Received: from paris.public.uni-hamburg.de (max2-021.public.uni-hamburg.de [134.100.45.21]) by public.uni-hamburg.de (8.8.8/8.8.8) with SMTP id VAA78996; Mon, 12 Apr 1999 21:03:59 +0200 Received: by ulf.mali.sub.org (Smail3.1.28.1 #1) id m10WlVG-0003bDC; Mon, 12 Apr 99 20:32 +0200 Message-Id: Date: Mon, 12 Apr 99 20:32 +0200 From: ulf@fitug.de (Ulf =?iso-8859-1?Q?M=F6ller?=) To: bleichen@research.bell-labs.com Subject: Re: Decrypting ElGamal messages Newsgroups: ulf.open-pgp In-Reply-To: <199904091656.MAA27520@aura.research.bell-labs.com> Organization: HR13 Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: >> Upon decryption, the recipient needs to check the PKCS-1 formatting, >> the checksum, and that the symmetric algorithm byte is one of the >> supported algorithms. It then tries to decrypt the following message >> block using that algorithm and session key, which block also has in >> it a two-byte redundancy at the beginning to further detect bad keys. > >Thanks a lot for the information. Would have missed the checksum >in the bulk data otherwise. I don't think you can count it in. While the semantics of a (Session Key Packet, Literal Packet) message is not defined in the RFC, a naïve implementor may very well try to be "generous in what they accept", as is suggested elsewhere in the document. PGP 5 does not accept such messages, but prints an "assertion failed" message only if the PKCS #1 padding and the Session Key Packet checksum are correct. From owner-ietf-open-pgp@imc.org Mon Apr 12 19:05:20 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09120 for ; Mon, 12 Apr 1999 19:05:20 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA21861 for ietf-open-pgp-bks; Mon, 12 Apr 1999 15:00:43 -0700 (PDT) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA21856 for ; Mon, 12 Apr 1999 15:00:42 -0700 (PDT) Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.3/8.9.3) with ESMTP id PAA22448 for ; Mon, 12 Apr 1999 15:00:55 -0700 (PDT) Received: (from hal@localhost) by hal.sb.rain.org (8.8.7/8.8.7) id OAA02053 for ietf-open-pgp@imc.org; Mon, 12 Apr 1999 14:59:59 -0700 Date: Mon, 12 Apr 1999 14:59:59 -0700 From: hal@rain.org Message-Id: <199904122159.OAA02053@hal.sb.rain.org> To: ietf-open-pgp@imc.org Subject: Phil Zimmermann's suggestion for large ciphers Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I spoke with Phil Zimmermann on the phone about the issues raised by moving to larger block ciphers, and he made the following proposal. Phil suggests that we take advantage of the fact that when we go to large block ciphers like Twofish, there are no backwards-compatibility issues. We know that we need to make some adjustments to the spec with regard to the large block size. Rather than trying to tweak the current symmetric encrypted data packet spec, let us define a new encrypted data packet which would be used for large ciphers and would solve some of the concerns people have had with our existing encrypted data packets. These concerns include - - The non-standard sync operation after the check bytes are handled - The non-standard treatment of IV - The lack of detection of message modification unless the message is signed (many people don't like to sign their messages for legal reasons, but they don't want them altered). We would define a new encrypted packet format which would be similar to the current one but which would resolve these problems. The first thing in the packet would be the IV, of a size equal to the block size of the cipher. It would be followed by the ciphertext, which would be handled in CFB-n mode, where n is the block size of the cipher. There would be no special shift or sync operations. The plaintext would be prepended with a header consisting of check bytes so that the proper key can be detected. The check bytes could be two random bytes, followed by the same two bytes, repeated. The plaintext would be followed by a SHA-1 hash of the plaintext data. This would be checked after decryption and detect message modification attacks. This gives us a standard CFB mode, with a standard IV; a simple form of redundancy at the beginning to verify the correct key; and a SHA-1 hash at the end to protect the integrity of the data. With this approach, rather than patching the spec to deal with large block ciphers in the existing packet format, we would say that the existing packets should only be used for ciphers with 64 bit blocks. Larger ciphers must use the new format. Again, this is a perfect opportunity to make this change because large ciphers won't be backwards compatible, anyway. We have talked about variants on this idea in the past. Let me briefly try to address some of the issues which have come up. One question is whether to use a keyed MAC, like an HMAC, for integrity protection. A MAC is a Message Authentication Code, and is useful when the two sides have authenticated themselves to each other. They have some shared secret and they use that to authenticate the data as having originated with the other. What we want is simple integrity protection. For this purpose there is no need for a shared secret and it is appropriate simply to use a hash to provide the protection. Another issue is whether to use a fixed hash like SHA-1 rather than allowing the specification of a hash algorithm in the header. There is no need for variable hash algorithms in this context. The attacker does not have access to the plaintext of the message. The SHA-1 hash is being used essentially as a complicated checksum. There are certain limited changes which an attacker can make to an encrypted message, and all we need is that the hash function has a complex enough structure that the attacker would not be able to alter the message and checksum to allow it to continue to verify. The threat model is very different from the case of cryptographic signatures, and a fixed hash like SHA-1 should be suitable. Allowing the specification of a hash algorithm would actually allow some new attacks, as an attacker could potentially modify the message to change the hash algorithm specification, at the cost of damaging some other parts of the message. The recipient would then find that the message had apparently been integrity-protected with an unknown hash algorithm, and the integrity protection would be lost. We have also discussed providing integrity protection via some modification to the signature packet format rather than by a new form of encrypted packet. There would be a special kind of "signature" which would just consist of a hash of the message to protect its integrity. However, Phil argues that this kind of integrity protection is inherently tied to the use of encryption. It has no functional effect if not used in conjunction with encryption. This is unlike our other signatures, which are cryptographically useful transformations even on their own. Because of this close tie to the encryption functionality it makes most sense to make it part of the encrypted packet. One objection to this linkage is that if the message is both signed and encrypted, there is redundancy, since we compute an integrity protection hash in the encryption layer, and also a signature verification hash in the signature layer. The signature provides integrity protection as well as authentication, and so it is wasteful to also provide integrity protection as part of the encryption. However, Phil points out that it is often the case that a signature cannot be verified because the signing key is not available. In that case there is no integrity protection at all. Putting integrity protection in the encryption layer ensures that all encrypted messages have integrity protection. Summing up, we have an opportunity now to move to a new encrypted packet format at the same time as we begin supporting new ciphers. We can fix some of the problems which people have been complaining about for years, without facing backwards compatibility issues. Hal Finney NAI, Inc. From owner-ietf-open-pgp@imc.org Mon Apr 12 19:48:41 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09362 for ; Mon, 12 Apr 1999 19:48:40 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA22504 for ietf-open-pgp-bks; Mon, 12 Apr 1999 16:09:00 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA22500 for ; Mon, 12 Apr 1999 16:08:59 -0700 (PDT) Received: from jcallas (dhcp-47-64.dhcp.nai.com [161.69.47.64]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id QAA19851; Mon, 12 Apr 1999 16:08:14 -0700 (PDT) Message-Id: <3.0.3.32.19990412160709.0336ed40@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 12 Apr 1999 16:07:09 -0700 To: hal@rain.org, ietf-open-pgp@imc.org From: Jon Callas Subject: Re: Phil Zimmermann's suggestion for large ciphers In-Reply-To: <199904122159.OAA02053@hal.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Is Phil suggesting that we *NOT* use Twofish with packet 9, that we hold off on large blocks until the new encrypted data packet gets defined? Jon ----- Jon Callas jon@pgp.com CTO, Total Network Security 3965 Freedom Circle Network Associates, Inc. Santa Clara, CA 95054 (408) 346-5860 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) From owner-ietf-open-pgp@imc.org Mon Apr 12 19:57:28 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09403 for ; Mon, 12 Apr 1999 19:57:28 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA22609 for ietf-open-pgp-bks; Mon, 12 Apr 1999 16:21:01 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA22605 for ; Mon, 12 Apr 1999 16:21:00 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id TAA08946; Mon, 12 Apr 1999 19:21:13 -0400 Received: from buoy.watson.ibm.com (buoy.watson.ibm.com [9.2.3.94]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id TAA22576; Mon, 12 Apr 1999 19:21:13 -0400 Received: by buoy.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA24998; Mon, 12 Apr 1999 19:21:13 -0400 From: uri Message-Id: <9904122321.AA24998@buoy.watson.ibm.com> Subject: Re: Phil Zimmermann's suggestion for large ciphers To: hal@rain.org Date: Mon, 12 Apr 1999 19:21:13 -0400 (EDT) Cc: ietf-open-pgp@imc.org In-Reply-To: <199904122159.OAA02053@hal.sb.rain.org> from "hal@rain.org" at Apr 12, 99 02:59:59 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: hal@rain.org says: > Phil suggests that we take advantage of the fact that when we go to large > block ciphers like Twofish, there are no backwards-compatibility issues. > ...................... Rather than trying to tweak the current symmetric > encrypted data packet spec, let us define a new encrypted data packet > which would be used for large ciphers and would solve some of the concerns > people have had with our existing encrypted data packets. Good. About time. > These concerns include - > > - The non-standard sync operation after the check bytes are handled Kill it. > - The non-standard treatment of IV Later. > - The lack of detection of message modification unless the message is > signed (many people don't like to sign their messages for legal reasons, > but they don't want them altered). Fix it. > The first thing in the packet would be the IV, of a size equal to the > block size of the cipher. It would be followed by the ciphertext, which > would be handled in CFB-n mode, where n is the block size of the cipher. > There would be no special shift or sync operations. I kinda like the idea of constant zero IV and plaintext prefixed with 128 random bits... Looks better than the "traditional" IV to me... > The plaintext would be prepended with a header consisting of check bytes > so that the proper key can be detected. The check bytes could be two > random bytes, followed by the same two bytes, repeated. Make the "pseudo-IV" prefix partially non-random - i.e. the last two bytes being checksum for the other 14. No big deal security-wise and noticeable help in detecting the right key. > The plaintext would be followed by a SHA-1 hash of the plaintext data. > This would be checked after decryption and detect message modification > attacks. Good enough. > This gives us a standard CFB mode, with a standard IV; a simple form of > redundancy at the beginning to verify the correct key; and a SHA-1 hash > at the end to protect the integrity of the data. Sure - but I still prefer "hidden" IV in the shape of plaintext prefix, and "visible" IV all zeroized... > One question is whether to use a keyed MAC, like an HMAC, for integrity > protection. A MAC is a Message Authentication Code, and is useful when > the two sides have authenticated themselves to each other. Exactly. And this is not a MAC - it's an MDC at best (Modification Detection Code). I do not think MAC is warranted here. In short - IMnotsoHM no need for keyed MAC or MDC. Plain SHA-1. > Another issue is whether to use a fixed hash like SHA-1 rather than > allowing the specification of a hash algorithm in the header. Shooting from the hip - no need for plenty of hashes. SHA-1 is good enough for this purpose. > The threat model is very different from the > case of cryptographic signatures, and a fixed hash like SHA-1 should > be suitable. It is. > We have also discussed providing integrity protection via some > modification to the signature packet format rather than by a new form > of encrypted packet. There would be a special kind of "signature" which > would just consist of a hash of the message to protect its integrity. Nah, IMNSHO isn't worth it. > One objection to this linkage is that if the message is both signed and > encrypted, there is redundancy, since we compute an integrity protection > hash in the encryption layer, and also a signature verification hash > in the signature layer. So? Compared to cost of one RSA or DSA operation, one SHA-1 is negligible. Who cares? > The signature provides integrity protection as > well as authentication, and so it is wasteful to also provide integrity > protection as part of the encryption. "Penny-wise, pound-foolish". I'd rather not do things in dozens of different ways. Phil is correct here - it is better to have that extra "wasteful" protection. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ietf-open-pgp@imc.org Mon Apr 12 20:18:40 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09544 for ; Mon, 12 Apr 1999 20:18:39 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA22774 for ietf-open-pgp-bks; Mon, 12 Apr 1999 16:45:32 -0700 (PDT) Received: from mail9.svr.pol.co.uk (mail9.svr.pol.co.uk [195.92.193.22]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA22770 for ; Mon, 12 Apr 1999 16:45:31 -0700 (PDT) Received: from modem-38.barium.dialup.pol.co.uk ([62.136.27.166] helo=server.eternity.org) by mail9.svr.pol.co.uk with esmtp (Exim 2.12 #1) id 10WqOX-0007ri-00; Tue, 13 Apr 1999 00:45:38 +0100 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id AAA10973; Tue, 13 Apr 1999 00:41:53 +0100 Date: Tue, 13 Apr 1999 00:41:53 +0100 Message-Id: <199904122341.AAA10973@server.eternity.org> From: Adam Back To: hal@rain.org Cc: ietf-open-pgp@imc.org Cc: prz@pgp.com In-reply-to: <199904122159.OAA02053@hal.sb.rain.org> Subject: Re: Phil Zimmermann's suggestion for large ciphers Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I just spent a bit of time reviewing the previous discussions on fixes for Gary Howland's message modification attack. In general I like PRZs proposal, and it seems well thought out. Starting from PRZs functionality list, I agree with the design. However i think the functionality list has a gap: it doesn't cover that many people will want to continue using IDEA, 3DES, blowfish. There will remain no way to prevent message modification for unsigned messages for these. The point that PRZ made: > However, Phil points out that it is often the case that a signature > cannot be verified because the signing key is not available. In > that case there is no integrity protection at all. is important too, and I therefore think it would be quite useful to have a MDC in signed and encrypted messages (as well as just encrypted messages) for the non-large ciphers too. Now if one adds to PRZs functionality list that we want this to be backwards compatible so that non-large ciphers can use it, you need a way to send a MDC inside an encryption envelope such that it won't cause current implementations to barf. For this the appended hash method doesn't work (or at least I can see no elegant way to make it work). For this reason I would argue for a new signature type `symmetric MDC', where you put a hash (or a MAC) in a signature packet. in previous discussions Tom Zerucha made this point: : a signature algorithm : of 0 means the message digest is stored in the clear (maybe as a : MPI), and leave the rest of the format alone. Old implmentations : should fail gracefully with "unknown signature algorithm". The : onepass signature header lets the "MAC" be at the end yet insures : that someone can't just delete the "MAC". Some additional benefits of a symmetric signature are that: - the attacker is left guessing whether or not the recipient will check the MDC, even for all existing pgp2.x, pgp5.x and pgp6.x implementations - if the recipient later upgrades he can at that later time check the MDCs and detect the modification after the fact I argue that these benefits make it worth favoring the new signature type over appended hash approach. I agree that the addition of large ciphers would be a good time to phase in the other proposed changes. Perhaps even, we could clean up the length business at the same time, which would allow eventual deprecation of sections 4.2.1, 4.2.2 and 4.2.3 The new-format packet lengths (4.2.2, 4.2.3) are even more complicated than the old ones (4.2.1). Adam From owner-ietf-open-pgp@imc.org Mon Apr 12 20:42:43 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09685 for ; Mon, 12 Apr 1999 20:42:43 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA23033 for ietf-open-pgp-bks; Mon, 12 Apr 1999 17:06:00 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA23029 for ; Mon, 12 Apr 1999 17:05:59 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id UAA06244; Mon, 12 Apr 1999 20:06:10 -0400 Received: from buoy.watson.ibm.com (buoy.watson.ibm.com [9.2.3.94]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id UAA22562; Mon, 12 Apr 1999 20:06:10 -0400 Received: by buoy.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA24736; Mon, 12 Apr 1999 20:06:09 -0400 From: uri Message-Id: <9904130006.AA24736@buoy.watson.ibm.com> Subject: Re: Phil Zimmermann's suggestion for large ciphers To: aba@dcs.ex.ac.uk (Adam Back) Date: Mon, 12 Apr 1999 20:06:09 -0400 (EDT) Cc: hal@rain.org, ietf-open-pgp@imc.org, prz@pgp.com In-Reply-To: <199904122341.AAA10973@server.eternity.org> from "Adam Back" at Apr 13, 99 00:41:53 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Adam Back says: > Starting from PRZs functionality list, I agree with the design. (:-) > However i think the functionality list has a gap: it doesn't cover > that many people will want to continue using IDEA, 3DES, blowfish. > There will remain no way to prevent message modification for unsigned > messages for these. And there's absolutely no protection for those who continue using unencrypted unsigned e-mail. I say - the world is moving forward. It is bad enough to have to be compatible with the existing "old" methods - it will be far worse to have to in addition be compatible with "new old" methods. Enough is enough. > is important too, and I therefore think it would be quite useful to > have a MDC in signed and encrypted messages (as well as just encrypted > messages) for the non-large ciphers too. We agree here. > Now if one adds to PRZs functionality list that we want this to be > backwards compatible so that non-large ciphers can use it, you need a > way to send a MDC inside an encryption envelope such that it won't > cause current implementations to barf. For this the appended hash > method doesn't work (or at least I can see no elegant way to make it > work). A good enough reason for me to vote down the support for MDC in "old" ciphers. > For this reason I would argue for a new signature type `symmetric > MDC', where you put a hash (or a MAC) in a signature packet. No MAC - as MAC will require yet another key. > I argue that these benefits make it worth favoring the new signature > type over appended hash approach. Let's say that we disagree here. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ietf-open-pgp@imc.org Mon Apr 12 23:11:13 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12088 for ; Mon, 12 Apr 1999 23:11:12 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA01275 for ietf-open-pgp-bks; Mon, 12 Apr 1999 19:37:47 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.8/8.8.5) with SMTP id TAA01265 for ; Mon, 12 Apr 1999 19:37:45 -0700 (PDT) Received: (qmail 4407 invoked by uid 666); 13 Apr 1999 02:38:13 -0000 Date: 13 Apr 1999 02:38:13 -0000 Message-ID: <19990413023813.4405.qmail@cr.yp.to> From: "D. J. Bernstein" To: ietf-open-pgp@imc.org Subject: Re: Phil Zimmermann's suggestion for large ciphers Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hal Finney writes: > The plaintext would be followed by a SHA-1 hash of the plaintext data. I have an unconditionally secure MAC that's much faster than SHA-1---in fact, even faster than MD5. The alpha implementation is available from http://pobox.com/~djb/hash127.html Please send any comments or questions to the hash127 mailing list. To subscribe, send an empty message to hash127-subscribe@list.cr.yp.to. > many people don't like to sign their messages for legal reasons, Why? Because signatures can't be repudiated? One easy solution, under the original Diffie-Hellman system, is to use a MAC as above, where the MAC key is generated from the Diffie-Hellman shared secret. The receiver can generate new MACs under the same key, so he can't prove to a judge that a message came from you. (There are similar solutions using RSA, but Diffie-Hellman is faster.) ---Dan From owner-ietf-open-pgp@imc.org Tue Apr 13 04:25:59 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20598 for ; Tue, 13 Apr 1999 04:25:58 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA25365 for ietf-open-pgp-bks; Tue, 13 Apr 1999 00:51:00 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA25361 for ; Tue, 13 Apr 1999 00:50:58 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id JAA09773 for ietf-open-pgp@imc.org; Tue, 13 Apr 1999 09:51:13 +0200 (MET DST) Received: (qmail 26894 invoked from network); 13 Apr 1999 07:50:09 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 13 Apr 1999 07:50:09 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10Wxva-00004N-00; Tue, 13 Apr 1999 09:48:14 +0200 Date: Tue, 13 Apr 1999 09:48:14 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Phil Zimmermann's suggestion for large ciphers Message-ID: <19990413094814.B221@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904122159.OAA02053@hal.sb.rain.org> <9904122321.AA24998@buoy.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <9904122321.AA24998@buoy.watson.ibm.com>; from uri on Mon, Apr 12, 1999 at 07:21:13PM -0400 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: uri writes: > Make the "pseudo-IV" prefix partially non-random - i.e. the last two > bytes being checksum for the other 14. No big deal security-wise and > noticeable help in detecting the right key. I aggree as this will help detecting bad keys for conventional-only encrypted data. > So? Compared to cost of one RSA or DSA operation, one SHA-1 is negligible. > Who cares? Hashing 700 Mges takes a while and sometimes conventional only encryption is used. But IMHO it is worth this time. If someone does not like it, he can still use packet type 9 and the specs shoudl say that an implemention SHOULD display a notice if a cipher >= 7 is used without a MDC. -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Tue Apr 13 04:33:24 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20679 for ; Tue, 13 Apr 1999 04:33:23 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA25371 for ietf-open-pgp-bks; Tue, 13 Apr 1999 00:51:02 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA25366 for ; Tue, 13 Apr 1999 00:51:00 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id JAA09766 for ietf-open-pgp@imc.org; Tue, 13 Apr 1999 09:51:10 +0200 (MET DST) Received: (qmail 26878 invoked from network); 13 Apr 1999 07:43:46 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 13 Apr 1999 07:43:46 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10WxpP-00004I-00; Tue, 13 Apr 1999 09:41:51 +0200 Date: Tue, 13 Apr 1999 09:41:51 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Phil Zimmermann's suggestion for large ciphers Message-ID: <19990413094151.A221@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904122159.OAA02053@hal.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <199904122159.OAA02053@hal.sb.rain.org>; from hal@rain.org on Mon, Apr 12, 1999 at 02:59:59PM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: hal@rain.org writes: > Phil suggests that we take advantage of the fact that when we go to large > block ciphers like Twofish, there are no backwards-compatibility issues. Please note that the RFC already handles ciphers with different blocksizes; the only problem ist that there are some glitches in the specification. > The plaintext would be followed by a SHA-1 hash of the plaintext data. To avoid the need to create new packet types in the future (maybe there will be a demand for a larger sized digest algorithm or someone likes to replace SHA-1 by RIPE-MD160) we should at least encode a version number in the encrypted data packet. > This gives us a standard CFB mode, with a standard IV; a simple form of > redundancy at the beginning to verify the correct key; and a SHA-1 hash Keep the Zero-IV and extend the current scheme. Implementions must already cope with this to be compatible with rfc2440 and there is no security risk with this. > Larger ciphers must use the new format. Again, this is a perfect If a cipher with id >= 7 is listed in the preferences an implementations SHOULD use the new format. I think there are no implementations which are yet using those ciphers, so we can easily fix it without breaking rfc2440 too much. > opportunity to make this change because large ciphers won't be backwards > compatible, anyway. But they are compatible with rfc2440 - despite the fact that we don't have a cipher id for those official assigned (except the reserved ones for AES). > originated with the other. What we want is simple integrity protection. > For this purpose there is no need for a shared secret and it is Right. > Another issue is whether to use a fixed hash like SHA-1 rather than > allowing the specification of a hash algorithm in the header. There is > no need for variable hash algorithms in this context. The attacker does "There will never be the need for more than 640k of RAM" ;-) We have already specified hash preferences which may be utilized to use a different hash algorithm. So it would be wise to encrypt a version number, the type of MDC used and the hash algorithm with the encrypted text. We are already prefixing the message with some random bytes and a kind of checksum; we can simple add those additional information and don't increase the risk of a known plaintext attack as the structure of the data which follows is anyway known (literal data packet or compressed data packet). -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Tue Apr 13 05:09:46 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20850 for ; Tue, 13 Apr 1999 05:09:46 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA26729 for ietf-open-pgp-bks; Tue, 13 Apr 1999 01:20:59 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA26724 for ; Tue, 13 Apr 1999 01:20:56 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id KAA13923 for ietf-open-pgp@imc.org; Tue, 13 Apr 1999 10:21:11 +0200 (MET DST) Received: (qmail 26980 invoked from network); 13 Apr 1999 07:56:47 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 13 Apr 1999 07:56:47 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10Wy21-00004V-00; Tue, 13 Apr 1999 09:54:53 +0200 Date: Tue, 13 Apr 1999 09:54:52 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Packet 5,7 and blocksizes Message-ID: <19990413095452.C221@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Just a reminder that we have to change the specs to increase the size of the IV in the secrek key material encryption from 8 bytes to the blocksize. And I still like to have a length of the IV in the packet (okay, for the next version of the packet) becuase it makes parsing more easier. Now I have to use a table of blocksizes for each cipher to do correct parsing of the data; adding one byte for this should not be a problem. -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Tue Apr 13 12:11:49 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23897 for ; Tue, 13 Apr 1999 12:11:48 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA13610 for ietf-open-pgp-bks; Tue, 13 Apr 1999 08:22:12 -0700 (PDT) Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA13605 for ; Tue, 13 Apr 1999 08:22:11 -0700 (PDT) Received: from xedia.com by relay5.UU.NET with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgktx21231; Tue, 13 Apr 1999 11:21:12 -0400 (EDT) Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA04789; Tue, 13 Apr 99 11:20:59 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA11395; Tue, 13 Apr 1999 11:21:07 -0400 Date: Tue, 13 Apr 1999 11:21:07 -0400 Message-Id: <199904131521.LAA11395@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: wk@isil.d.shuttle.de Cc: ietf-open-pgp@imc.org Subject: Re: Phil Zimmermann's suggestion for large ciphers References: <199904122159.OAA02053@hal.sb.rain.org> <9904122321.AA24998@buoy.watson.ibm.com> <19990413094814.B221@frodo.isil.d.shuttle.de> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Content-Transfer-Encoding: 7bit >>>>> "Werner" == Werner Koch writes: Werner> uri writes: >> So? Compared to cost of one RSA or DSA operation, one SHA-1 is >> negligible. Who cares? Werner> Hashing 700 Mges takes a while and sometimes conventional Werner> only encryption is used. True, but compared to conventional crypto SHA-1 is still a small component. I've measured it at 4-5 times the speed of single DES. paul From owner-ietf-open-pgp@imc.org Tue Apr 13 14:06:35 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25616 for ; Tue, 13 Apr 1999 14:06:34 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA17387 for ietf-open-pgp-bks; Tue, 13 Apr 1999 10:13:20 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA17383 for ; Tue, 13 Apr 1999 10:13:19 -0700 (PDT) Received: by brickwall.ceddec.com id <42115>; Tue, 13 Apr 1999 13:11:45 -0400 Date: Tue, 13 Apr 1999 13:13:31 -0400 From: Tom Zerucha X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: Re: Phil Zimmermann's suggestion - Implementation? In-Reply-To: <199904122159.OAA02053@hal.sb.rain.org> Message-Id: <99Apr13.131145edt.42115@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Mon, 12 Apr 1999 hal@rain.org wrote: > I spoke with Phil Zimmermann on the phone about the issues raised by > moving to larger block ciphers, and he made the following proposal. > These concerns include - > > - The non-standard sync operation after the check bytes are handled > > - The non-standard treatment of IV > > - The lack of detection of message modification unless the message is > signed (many people don't like to sign their messages for legal reasons, > but they don't want them altered). > > We would define a new encrypted packet format which would be similar to > the current one but which would resolve these problems. Note that what you are defining is a different "method" or processing layer. This is NOT best implemented using different cipher numbers, but with a range of cipher numbers or some other key indicating the new usage. The current structure could be described as follows: Plaintext -> IV/CFB xor -> Ciphertext ^ | Secret -> Cipher (By secret I mean all material, both key and initial IV if nonzero, etc.). The IV/CFB xor box resets at 10. The new model becomes (please correct ommissions) Plaintext -> MAC append -> IV/CFB xor -> Ciphertext ^ | Secret -> Cipher The IV/CFB box is different. So why not just define a new IV/CFB mode or method instead of jamming this definition into the cipher? For now, I would prefer looking at a way of specifying the new IV/CFB or whatever *method* as different from specifying the underlying cipher. Also the MAC gives me some indigestion. There are uses of this for stream processing, and the MAC in this format needs an OOB EOF and processing. And to ask a question, how do I know where the MAC is? I have to decrypt and hold back 20 bytes just in case I see the EOF? The new stream format might have EOF detect problems there, i.e. I don't know where the MAC is until I am past it. (This is easily addressed, so should be before proceeding). (See my comments following) > With this approach, rather than patching the spec to deal with large > block ciphers in the existing packet format, we would say that the > existing packets should only be used for ciphers with 64 bit blocks. > Larger ciphers must use the new format. Again, this is a perfect > opportunity to make this change because large ciphers won't be backwards > compatible, anyway. Is there a particular reason not to use the old ciphers with the new format (if it is available)? Other than backwards compatibility - which you won't have anyway? > We have also discussed providing integrity protection via some > modification to the signature packet format rather than by a new form > of encrypted packet. There would be a special kind of "signature" which > would just consist of a hash of the message to protect its integrity. Such as a signature with a "zero" encryption algorithm that would just store the 20 bytes of the SHA-1 hash? This could be easily added to the existing code (with provisos that it doesn't display as a signature). > However, Phil argues that this kind of integrity protection is inherently > tied to the use of encryption. It has no functional effect if not used > in conjunction with encryption. This is unlike our other signatures, > which are cryptographically useful transformations even on their own. > Because of this close tie to the encryption functionality it makes most > sense to make it part of the encrypted packet. Or simply encrypt the signature with the symmetric algorithm the message was encrypted with (instead of the PK signature algorithms). This leaves all the existing hashing code where it is and only requires a mod to the final stage (and perhaps preservation of the cipher state on EOF). Doing a MAC within the encryption packet now adds a layer on the inside, which will be there even for signed messages. I really don't like extra layers if an existing layer can provide the functionality. > However, Phil points out that it is often the case that a signature > cannot be verified because the signing key is not available. In that case > there is no integrity protection at all. Putting integrity protection in > the encryption layer ensures that all encrypted messages have integrity > protection. Since you can have multiple signature packets, adding the symmetric MAC "non-signature" adds this function without the layer. > Summing up, we have an opportunity now to move to a new encrypted packet > format at the same time as we begin supporting new ciphers. We can > fix some of the problems which people have been complaining about for > years, without facing backwards compatibility issues. Please fix the symmetrical encryption packet lack-of-checksum while you are at it. (This is when you have a pass phrase protecting more key material - the second has no checksum so you can't tell if the key is good without decrypting some of the ciphertext). From owner-ietf-open-pgp@imc.org Tue Apr 13 14:42:05 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26482 for ; Tue, 13 Apr 1999 14:42:05 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA18987 for ietf-open-pgp-bks; Tue, 13 Apr 1999 11:05:22 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA18983 for ; Tue, 13 Apr 1999 11:05:21 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id OAA09638; Tue, 13 Apr 1999 14:05:39 -0400 Received: from buoy.watson.ibm.com (buoy.watson.ibm.com [9.2.3.94]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id OAA08946; Tue, 13 Apr 1999 14:05:39 -0400 Received: by buoy.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA26446; Tue, 13 Apr 1999 14:05:39 -0400 From: uri Message-Id: <9904131805.AA26446@buoy.watson.ibm.com> Subject: Re: Phil Zimmermann's suggestion - Implementation? To: tzeruch@ceddec.com (Tom Zerucha) Date: Tue, 13 Apr 1999 14:05:38 -0400 (EDT) Cc: ietf-open-pgp@imc.org In-Reply-To: <99Apr13.131145edt.42115@brickwall.ceddec.com> from "Tom Zerucha" at Apr 13, 99 01:13:31 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Tom Zerucha says: > The new model becomes (please correct ommissions) > > Plaintext -> MAC append -> IV/CFB xor -> Ciphertext > ^ > | > Secret -> Cipher It's not MAc - it's MDC. Otherwise your diagram looks correct to me. > The IV/CFB box is different. So why not just define a new IV/CFB mode or > method instead of jamming this definition into the cipher? I don't know - does it really matter how to define "this" new way of processing? > Also the MAC gives me some indigestion. There are uses of this for stream > processing, and the MAC in this format needs an OOB EOF and processing. What is "OOB EOF"? What's the big deal anyway? You're firing up encryptor and at the same time block-by-block computing MDC (SHA-1 hash). When you reach the last block, you have your MDC complete and can encrypt it as block-after-last... When decrypting you always take the last 20 bytes as MDC... What problem am I missing? > And to ask a question, how do I know where the MAC is? In the last 20 bytes of the plaintext, where else... > I have to decrypt and hold back 20 bytes just in case I see the EOF? You have to decrypt - then you have to "clip" the last 20 bytes of the resulting plaintext and give them to MDC verifier. Of course you can be computing the MDC block-by-block as you're decrypting the message... > Is there a particular reason not to use the old ciphers with the new > format (if it is available)? Other than backwards compatibility - which > you won't have anyway? Yes. It is preferable not to introduce the whole zoo of algorithms. So with the move to 128-bit block ciphers I'd expect AND PREFER the old 64-bit block ciphers to quietly go away, the sooner the better. > > We have also discussed providing integrity protection via some > > modification to the signature packet format rather than by a new form > > of encrypted packet. There would be a special kind of "signature" which > > would just consist of a hash of the message to protect its integrity. > > Such as a signature with a "zero" encryption algorithm that would just > store the 20 bytes of the SHA-1 hash? This could be easily added to the > existing code (with provisos that it doesn't display as a signature). I'm strongly against it. Such a signature does not make sense [to me]. > Doing a MAC within the encryption packet now adds a layer on the inside, > which will be there even for signed messages. It is NOT a MAC - it's MDC (Modification Detection Code). Different type, different application, different security considerations. > I really don't like extra layers if an existing layer can provide the > functionality. (:-) > Since you can have multiple signature packets, adding the symmetric MAC > "non-signature" adds this function without the layer. In short, I'm against it. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ietf-open-pgp@imc.org Tue Apr 13 16:17:03 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28197 for ; Tue, 13 Apr 1999 16:17:02 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA21750 for ietf-open-pgp-bks; Tue, 13 Apr 1999 12:30:57 -0700 (PDT) Received: from jhcloos.com (cloos@austin.jhcloos.com [206.224.83.202]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA21744 for ; Tue, 13 Apr 1999 12:30:55 -0700 (PDT) Received: (from cloos@localhost) by jhcloos.com (8.8.7/8.8.7) id OAA06395; Tue, 13 Apr 1999 14:31:12 -0500 To: ietf-open-pgp@imc.org Subject: Mixing rsa and dh/dsa From: "James H. Cloos Jr." MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: 13 Apr 1999 14:31:12 -0500 Message-ID: Lines: 21 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Given a recipient with only an RSA keypair (algo 1), and a sender with only a DSA/Elgamal pair (algos 17 and 16), should the sender encrypt+sign, will any extant software be able to decrypt and verify? - -JimC - -- James H. Cloos, Jr. 1024D/ED7DAEA6 E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 -----BEGIN PGP SIGNATURE----- Version: GnuPG v0.9.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE3E5t/mXqfF+19rqYRAhDGAJ0WlNorTuD1CV7CfvXMt3LwfdKGCgCgpVWs 9cAHPeSAjZn6NiJn3KXRjHM= =2o8F -----END PGP SIGNATURE----- From owner-ietf-open-pgp@imc.org Tue Apr 13 16:28:02 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28379 for ; Tue, 13 Apr 1999 16:28:02 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA22624 for ietf-open-pgp-bks; Tue, 13 Apr 1999 12:47:24 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA22619 for ; Tue, 13 Apr 1999 12:47:23 -0700 (PDT) Received: by brickwall.ceddec.com id <42115>; Tue, 13 Apr 1999 15:45:52 -0400 Date: Tue, 13 Apr 1999 15:47:38 -0400 From: Tom Zerucha X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: Re: Phil Zimmermann's suggestion - Implementation? In-Reply-To: <9904131805.AA26446@buoy.watson.ibm.com> Message-Id: <99Apr13.154552edt.42115@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Tue, 13 Apr 1999, uri wrote: > > The IV/CFB box is different. So why not just define a new IV/CFB mode or > > method instead of jamming this definition into the cipher? > > I don't know - does it really matter how to define "this" new way > of processing? It depends a lot if new ciphers are all going to use the new method, or if it will be defined with existing ciphers. If the method is going to be specific to the ciphers, then it makes sense to incorporate it into the ciphers. If there are going to be multiple methods applied to ciphers, it is best to define the methods. The spec has ciphers and the PGPCFB method defined in different areas. If we add a method, it would be applicable to ciphers. Otherwise the method becomes part of the cipher and we should restructure the document (and derivative code) that way. > > Also the MAC gives me some indigestion. There are uses of this for stream > > processing, and the MAC in this format needs an OOB EOF and processing. > > What is "OOB EOF"? Out Of Band End of File, e.g. getting 0xffff instead of 0-0xff in getchar. > What's the big deal anyway? You're firing up encryptor > and at the same time block-by-block computing MDC (SHA-1 hash). When you > reach the last block, you have your MDC complete and can encrypt it as > block-after-last... When decrypting you always take the last 20 bytes > as MDC... What problem am I missing? So we are going to require multithreading? If I don't have that capability, "firing up" multiple filters isn't as simple as you make it out to be. Can I pass the data through two layers instead of one? Yes, but I don't want to if I don't have to. Especially since it would be encrypt(mdc(hash-for-signature(plaintext))) now. PGP is already bloating as it is. > > And to ask a question, how do I know where the MAC is? > > In the last 20 bytes of the plaintext, where else... If you don't know the length of the input, this means it is at which byte? Saying something is 5 miles east of Kunkle doesn't help if you don't know where Kunkle is. So I keep feeding bytes to the hasher, and then oops, I only have 10 bytes left. I have to rewind now that I know the length of the file. Or I have to hold back 20 bytes until I know where the real EOF is. > > I have to decrypt and hold back 20 bytes just in case I see the EOF? > > You have to decrypt - then you have to "clip" the last 20 bytes of > the resulting plaintext and give them to MDC verifier. Of course > you can be computing the MDC block-by-block as you're > decrypting the message... So if the data is coming through a pipe, how do I know there are going to be exactly 20 bytes and no more coming through? If I want to run through the file once to count, fine, but assume that I don't. Either that or require the old style CTB prefixes - the ones that give the length instead of the new ones designed to do streaming. Streaming does have disadvantages. Or put the MDC at the beginning. This should be just as easy, and you can just save those 20 bytes, decrypt/hash and then memcmp(,,20). This is only slightly less difficult, but it would be on the encryption side, and encryption is done fewer times than decryption. > > Is there a particular reason not to use the old ciphers with the new > > format (if it is available)? Other than backwards compatibility - which > > you won't have anyway? > > Yes. It is preferable not to introduce the whole zoo of algorithms. > So with the move to 128-bit block ciphers I'd expect AND PREFER > the old 64-bit block ciphers to quietly go away, the sooner > the better. Then why not drop PGP entirely? I doubt there is going to be a move to the new ciphers until everyone has the newer versions, and there are still people using 2.6.x. In short, they won't go away. > > Such as a signature with a "zero" encryption algorithm that would just > > store the 20 bytes of the SHA-1 hash? This could be easily added to the > > existing code (with provisos that it doesn't display as a signature). > > I'm strongly against it. Such a signature does not make sense [to me]. It isn't a signature. It is the same 20 bytes encrypted, except within the existing packet structure. No new layers, processing, or code ripups. If you want to put 20 bytes of MDC somewhere, these packets have a place for it, and it is easier to add one more new signature (non-signature) subtype than an entire new layer of processing. If you want an MDC, and there is already a place for MDCs, then it should go there if the format can be adapted. > > Since you can have multiple signature packets, adding the symmetric MAC > > "non-signature" adds this function without the layer. > > In short, I'm against it. And I am against adding an MDC to the "inside" of the symmetric encryption packet. There is already a defined place for one outside, although only in the context of either null or PK encryption. In short, if you really want to do this, then add an MDC-only signature type or subtype. The (non)signature packets will be encrypted with the rest of the stream. In fact, the null cipher type might work as is. Does anyone have a reason that (plaintext+20) is going to be worse than (1passhdr)(plaintext)(sig-MDC)? The code for the latter already exists - simply bypass the PK encryption. This also adds the MDC capability to the old ciphers. The spec already warned about PK alg ID 0, or we can add a new one, but I don't know what the various implementations do. If MDC is that useful, it will be useful with the old ciphers. Or just define a completely new packet ID for the MDC. It will be basically a signature packet minus a lot of header and other bytes, but you would have (plaintext)(MDC) with known boundaries. From owner-ietf-open-pgp@imc.org Tue Apr 13 16:59:06 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28896 for ; Tue, 13 Apr 1999 16:59:06 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA24192 for ietf-open-pgp-bks; Tue, 13 Apr 1999 13:23:27 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA24186 for ; Tue, 13 Apr 1999 13:23:26 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id QAA10192; Tue, 13 Apr 1999 16:23:45 -0400 Received: from buoy.watson.ibm.com (buoy.watson.ibm.com [9.2.3.94]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id QAA19332; Tue, 13 Apr 1999 16:23:45 -0400 Received: by buoy.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA25802; Tue, 13 Apr 1999 16:23:44 -0400 From: uri Message-Id: <9904132023.AA25802@buoy.watson.ibm.com> Subject: Re: Phil Zimmermann's suggestion - Implementation? To: tzeruch@ceddec.com (Tom Zerucha) Date: Tue, 13 Apr 1999 16:23:44 -0400 (EDT) Cc: ietf-open-pgp@imc.org In-Reply-To: <99Apr13.154552edt.42115@brickwall.ceddec.com> from "Tom Zerucha" at Apr 13, 99 03:47:38 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Tom Zerucha says: > > What's the big deal anyway? You're firing up encryptor > > and at the same time block-by-block computing MDC (SHA-1 hash). When you > > reach the last block, you have your MDC complete and can encrypt it as > > block-after-last... When decrypting you always take the last 20 bytes > > as MDC... What problem am I missing? > > So we are going to require multithreading? No, I'm merely saying that the logical processing would be do get new plaintext block update the hash encrypt plaintext block and spit it out until last block is done spit out the MDC encrypt MDC > If I don't have that > capability, "firing up" multiple filters isn't as simple as you make it > out to be. Can I pass the data through two layers instead of one? Yes, > but I don't want to if I don't have to. Especially since it would be > encrypt(mdc(hash-for-signature(plaintext))) now. PGP is already bloating > as it is. No. It's encrypt(plaintext||hash(plaintext)) where mdc(A) = hash(A) > > > And to ask a question, how do I know where the MAC is? > > > > In the last 20 bytes of the plaintext, where else... > > If you don't know the length of the input, this means it is at which byte? Since you can't avoid getting to the last byte when decrypting, and since you have no business monkeying with MDC until you finished decrypted, telling you that MDC is in the last 20 bytes is both necessary and sufficient... > Saying something is 5 miles east of Kunkle doesn't help if you don't know > where Kunkle is. Since you *are* going to Kunkle, and if you don't get there nothing else matters - the "5 miles east" is as precise as you have to know. > So I keep feeding bytes to the hasher, and then oops, I > only have 10 bytes left. I have to rewind now that I know the length of > the file. Or I have to hold back 20 bytes until I know where the real EOF > is. A very good point, thank you! Yes, it is more complicated on decrypting side, as you spotted (and I confess - I didn't). However, as you yourself point out, the solution is simple, if less than beautiful. > > > I have to decrypt and hold back 20 bytes just in case I see the EOF? > > > > You have to decrypt - then you have to "clip" the last 20 bytes of > > the resulting plaintext and give them to MDC verifier. Of course > > you can be computing the MDC block-by-block as you're > > decrypting the message... > > So if the data is coming through a pipe, how do I know there are going to > be exactly 20 bytes and no more coming through? If I want to run through > the file once to count, fine, but assume that I don't. Oh, I do assume you don't want to run through the file counting! (:-) The practical solution I see is delaying the hash update when decrypting by one block. I.e. you decrypt block K+1 and hash block K... Yes, it's not going to win a beauty contest. But it will work. > Or put the MDC at the beginning. This should be just as easy, and you can > just save those 20 bytes, decrypt/hash and then memcmp(,,20). This is > only slightly less difficult, but it would be on the encryption side, and > encryption is done fewer times than decryption. Nope! The problem with this is - you'll *have* to run through the file on extra time. Undesirable for pipes! > > Yes. It is preferable not to introduce the whole zoo of algorithms. > > So with the move to 128-bit block ciphers I'd expect AND PREFER > > the old 64-bit block ciphers to quietly go away, the sooner > > the better. > > Then why not drop PGP entirely? This you can figure out yourself (:-) > I doubt there is going to be a move to > the new ciphers until everyone has the newer versions, and there are still > people using 2.6.x. In short, they won't go away. Which is why people preserve ugly backwards compatibility, but aren't bending over their backs to modify/improve the old modes. > > I'm strongly against it. Such a signature does not make sense [to me]. > > It isn't a signature. It is the same 20 bytes encrypted, except within > the existing packet structure. No new layers, processing, or code ripups. > If you want to put 20 bytes of MDC somewhere, these packets have a place > for it, and it is easier to add one more new signature (non-signature) > subtype than an entire new layer of processing. > > If you want an MDC, and there is already a place for MDCs, then it should > go there if the format can be adapted. OK, I don't object as strongly any more. I'm neutral now. > In short, if you really want to do this, then add an MDC-only signature > type or subtype. The (non)signature packets will be encrypted with the > rest of the stream. In fact, the null cipher type might work as is. But it's NOT a signature! > Or just define a completely new packet ID for the MDC. It will be > basically a signature packet minus a lot of header and other bytes, but > you would have (plaintext)(MDC) with known boundaries. Hmm... Not qualified to judge this. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ietf-open-pgp@imc.org Tue Apr 13 16:59:29 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28910 for ; Tue, 13 Apr 1999 16:59:29 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA24100 for ietf-open-pgp-bks; Tue, 13 Apr 1999 13:20:52 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA24094 for ; Tue, 13 Apr 1999 13:20:47 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id WAA26404 for ietf-open-pgp@imc.org; Tue, 13 Apr 1999 22:21:06 +0200 (MET DST) Received: (qmail 28678 invoked from network); 13 Apr 1999 20:04:07 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 13 Apr 1999 20:04:07 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10X9Ny-0000D7-00; Tue, 13 Apr 1999 22:02:18 +0200 Date: Tue, 13 Apr 1999 22:02:18 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Phil Zimmermann's suggestion - Implementation? Message-ID: <19990413220218.C765@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <99Apr13.131145edt.42115@brickwall.ceddec.com> <9904131805.AA26446@buoy.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <9904131805.AA26446@buoy.watson.ibm.com>; from uri on Tue, Apr 13, 1999 at 02:05:38PM -0400 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: uri writes: > What is "OOB EOF"? What's the big deal anyway? You're firing up encryptor > and at the same time block-by-block computing MDC (SHA-1 hash). When you > reach the last block, you have your MDC complete and can encrypt it as > block-after-last... When decrypting you always take the last 20 bytes > as MDC... What problem am I missing? Tom already described it. You have always to store the last 20 bytes of what you are decrypting instead of writing it simply to the output. We introduce the onepass signature packets to implementing a stream mode of operation so why add the extra burden for deferring the last bytes? But I think this is still the most simple solution and we should do it. A more sophisticated solution could be to put MDCs every n byte into the data to help early detection of modification. However this has not much to do with offline encryption but with online protocols like SSH. So I suggest we keep the simple solution but use use a new packet type for it. > Yes. It is preferable not to introduce the whole zoo of algorithms. > So with the move to 128-bit block ciphers I'd expect AND PREFER > the old 64-bit block ciphers to quietly go away, the sooner I think it is bad style to change a standard which already defines how to handle different blocksizes (albeit with some conflicts). > > Such as a signature with a "zero" encryption algorithm that would just > > store the 20 bytes of the SHA-1 hash? This could be easily added to the > > existing code (with provisos that it doesn't display as a signature). > > I'm strongly against it. Such a signature does not make sense [to me]. It really does not make sense without a MAC (message authentication code). -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Tue Apr 13 18:14:22 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00264 for ; Tue, 13 Apr 1999 18:14:21 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26264 for ietf-open-pgp-bks; Tue, 13 Apr 1999 14:36:18 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26259 for ; Tue, 13 Apr 1999 14:36:17 -0700 (PDT) Received: by brickwall.ceddec.com id <42114>; Tue, 13 Apr 1999 17:34:45 -0400 Date: Tue, 13 Apr 1999 17:36:25 -0400 From: Tom Zerucha X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: Re: Phil Zimmermann's suggestion - Implementation? In-Reply-To: <9904132023.AA25802@buoy.watson.ibm.com> Message-Id: <99Apr13.173445edt.42114@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Tue, 13 Apr 1999, uri wrote: > Oh, I do assume you don't want to run through the file counting! (:-) No, I want to both count and hash at the same time, but I can't because... > The practical solution I see is delaying the hash update when decrypting > by one block. I.e. you decrypt block K+1 and hash block K... Yes, it's > not going to win a beauty contest. But it will work. With the stream format the last block might be less than 20 bytes. A 520 byte file will be 512+...8 (or for larger values, 5000 would be 4096+...4). And you can't hold back one "block", at least it would be difficult if the block is the maximum legal size (2^31 bytes?). You have to hold back at least 20 bytes at the end of any nonterminal packet. > > Or put the MDC at the beginning. This should be just as easy, and you can > > just save those 20 bytes, decrypt/hash and then memcmp(,,20). This is > > only slightly less difficult, but it would be on the encryption side, and > > encryption is done fewer times than decryption. > > Nope! The problem with this is - you'll *have* to run through the file > on extra time. Undesirable for pipes! Only on encryption! I would rather run through one more time there, than once per decryption. Decryption is really messy but only requires a 20 byte delay, so it is not quite the same thing. > > It isn't a signature. It is the same 20 bytes encrypted, except within > > the existing packet structure. No new layers, processing, or code ripups. > > If you want to put 20 bytes of MDC somewhere, these packets have a place > > for it, and it is easier to add one more new signature (non-signature) > > subtype than an entire new layer of processing. > > > > If you want an MDC, and there is already a place for MDCs, then it should > > go there if the format can be adapted. > > OK, I don't object as strongly any more. I'm neutral now. Lets see what the other implementors have to say. If expanding the definition of an existing packet to "verification (signature or MDC)" packet is easy to do in the existing code base (incl NAI PGP 6.0!), we can start implementing this now as a test. Then we would have MDCs and be able to merge them into the spec, and both spec and code would update in synchronization. > > In short, if you really want to do this, then add an MDC-only signature > > type or subtype. The (non)signature packets will be encrypted with the > > rest of the stream. In fact, the null cipher type might work as is. > > But it's NOT a signature! I don't know what else to call it because it is identified as the "signature packet" in the Spec. Maybe we can start calling it the "frooble" packet if that would be less confusing. I prefer simply renaming "signature packet" to "verification packet" or whatever it would be - and this nomenclature change should be done. But I can't use different words right now with out it being even more confusing. From owner-ietf-open-pgp@imc.org Tue Apr 13 18:14:42 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00279 for ; Tue, 13 Apr 1999 18:14:42 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26398 for ietf-open-pgp-bks; Tue, 13 Apr 1999 14:40:49 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26394 for ; Tue, 13 Apr 1999 14:40:48 -0700 (PDT) Received: by brickwall.ceddec.com id <42114>; Tue, 13 Apr 1999 17:39:19 -0400 Date: Tue, 13 Apr 1999 17:41:03 -0400 From: Tom Zerucha X-Sender: nobody@mars To: "James H. Cloos Jr." cc: ietf-open-pgp@imc.org Subject: Re: Mixing rsa and dh/dsa In-Reply-To: Message-Id: <99Apr13.173919edt.42114@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Tue, 13 Apr 1999, James H. Cloos Jr. wrote: > Given a recipient with only an RSA keypair (algo 1), and a sender with > only a DSA/Elgamal pair (algos 17 and 16), should the sender > encrypt+sign, will any extant software be able to decrypt and verify? Yes. The encryption is done using the RSA algorithm, but the signing is done using DSA. The recipient can decrypt using his RSA key and verify from the DSA from a keyserver or keyring. The encryption algorithm is separate and thus can be different from any signature algorithm. My test suite generates every possible combination, so I know it is possible for this to work. Whether any particular implementation handles this depends on that implmementaiton, but there should not be any problems if they simply did things in an obvious manner. From owner-ietf-open-pgp@imc.org Tue Apr 13 18:21:05 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00371 for ; Tue, 13 Apr 1999 18:21:04 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26754 for ietf-open-pgp-bks; Tue, 13 Apr 1999 14:48:52 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26749 for ; Tue, 13 Apr 1999 14:48:51 -0700 (PDT) Received: by brickwall.ceddec.com id <42114>; Tue, 13 Apr 1999 17:47:19 -0400 Date: Tue, 13 Apr 1999 17:49:01 -0400 From: Tom Zerucha X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: Re: Phil Zimmermann's suggestion - Implementation? In-Reply-To: <19990413220218.C765@frodo.isil.d.shuttle.de> Message-Id: <99Apr13.174719edt.42114@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Tue, 13 Apr 1999, Werner Koch wrote: > But I think this is still the most simple solution and we should do > it. A more sophisticated solution could be to put MDCs every n byte > into the data to help early detection of modification. However this > has not much to do with offline encryption but with online protocols > like SSH. So I suggest we keep the simple solution but use use a new > packet type for it. This could be implemented with a new packet-stream type, so that the partial packets could append X bytes. Putting an MDC at the packetization level is better than at the crypto level. I.e (1:4096)(4096:data)(MDC:20)...(1:17)(17:data)(MDC:20) > I think it is bad style to change a standard which already defines how > to handle different blocksizes (albeit with some conflicts). Which is why I call it a different "method". The spec already has something for the existing method (PGP/CFB) with larger block sizes, and my implementation is set up to handle these correctly, at least as far as I have been able to verify. From owner-ietf-open-pgp@imc.org Tue Apr 13 19:20:50 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01340 for ; Tue, 13 Apr 1999 19:20:50 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA29734 for ietf-open-pgp-bks; Tue, 13 Apr 1999 15:54:42 -0700 (PDT) Received: from mail1.svr.pol.co.uk (mail1.svr.pol.co.uk [195.92.193.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA29730 for ; Tue, 13 Apr 1999 15:54:41 -0700 (PDT) Received: from modem-15.gadolinium.dialup.pol.co.uk ([62.136.31.143] helo=server.eternity.org) by mail1.svr.pol.co.uk with esmtp (Exim 2.12 #1) id 10XC57-0006tv-00; Tue, 13 Apr 1999 23:55:01 +0100 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id XAA15191; Tue, 13 Apr 1999 23:51:26 +0100 Date: Tue, 13 Apr 1999 23:51:26 +0100 Message-Id: <199904132251.XAA15191@server.eternity.org> From: Adam Back To: tzeruch@ceddec.com CC: ietf-open-pgp@imc.org In-reply-to: <99Apr13.173445edt.42114@brickwall.ceddec.com> (message from Tom Zerucha on Tue, 13 Apr 1999 17:36:25 -0400) Subject: Re: Phil Zimmermann's suggestion - Implementation? Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Tom Zerucha writes: > Uri writes: > > > > OK, I don't object as strongly any more. I'm neutral now. > > Lets see what the other implementors have to say. If expanding the > definition of an existing packet to "verification (signature or MDC)" > packet is easy to do in the existing code base (incl NAI PGP 6.0!), we can > start implementing this now as a test. Then we would have MDCs and be > able to merge them into the spec, and both spec and code would update in > synchronization. I think Ian Brown is away from email at present travelling, but perhaps systemics/Ian Grigg would have comments; the cryptix java PGP implementation is heavily object oriented -- I would expect that modifying for MDC sigs would be easy -- just adding a new specialisation signature, with a new reserved number. The append hash method however is all new, and has the buffering problems Tom was identifying, and whilst it is easy to conceptualise and say "oh that's easy just do blah" actually _doing it_ to some code brings out the complexity of it fast. PGP's 5.x and 6.x code is object oriented too. > > > In short, if you really want to do this, then add an MDC-only signature > > > type or subtype. The (non)signature packets will be encrypted with the > > > rest of the stream. In fact, the null cipher type might work as is. > > > > But it's NOT a signature! > > I don't know what else to call it because it is identified as the > "signature packet" in the Spec. Maybe we can start calling it the > "frooble" packet if that would be less confusing. > > I prefer simply renaming "signature packet" to "verification packet" or > whatever it would be - and this nomenclature change should be done. But I > can't use different words right now with out it being even more confusing. The name of the packet in RFC2440 doesn't sound like a big stumbling block here either. Adam From owner-ietf-open-pgp@imc.org Tue Apr 13 19:21:23 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01356 for ; Tue, 13 Apr 1999 19:21:22 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA29745 for ietf-open-pgp-bks; Tue, 13 Apr 1999 15:54:48 -0700 (PDT) Received: from mail1.svr.pol.co.uk (mail1.svr.pol.co.uk [195.92.193.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA29740 for ; Tue, 13 Apr 1999 15:54:47 -0700 (PDT) Received: from modem-15.gadolinium.dialup.pol.co.uk ([62.136.31.143] helo=server.eternity.org) by mail1.svr.pol.co.uk with esmtp (Exim 2.12 #1) id 10XC5A-0006tv-00; Tue, 13 Apr 1999 23:55:04 +0100 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id XAA15183; Tue, 13 Apr 1999 23:43:39 +0100 Date: Tue, 13 Apr 1999 23:43:39 +0100 Message-Id: <199904132243.XAA15183@server.eternity.org> From: Adam Back To: uri@watson.ibm.com CC: hal@rain.org, ietf-open-pgp@imc.org, prz@pgp.com In-reply-to: <9904130006.AA24736@buoy.watson.ibm.com> (message from uri on Mon, 12 Apr 1999 20:06:09 -0400 (EDT)) Subject: MDC symmetric sig type vs new bundled encrypt+MDC (Re: Phil Zimmermann's suggestion for large ciphers) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Uri writes: > > However i think the functionality list has a gap: it doesn't cover > > that many people will want to continue using IDEA, 3DES, blowfish. > > There will remain no way to prevent message modification for unsigned > > messages for these. > > It is bad enough to have to be compatible with the existing > "old" methods - it will be far worse to have to in addition > be compatible with "new old" methods. Enough is enough. We had plenty of warning about the MDC issue. The issue was discussed on this list over a year ago (Jan 98). Even before that Gary Howland presented the problem at Hip in Aug 97. If I recall at the time ita was reported that PGP made a press release or some kind of public statement saying they had a fix for the problem. We have a recently released rfc2440 and people are now finally talking about fixing the MDC problem, yet they want to do it in ways which rfc2440 implementations can't benefit from. > > Now if one adds to PRZs functionality list that we want this to be > > backwards compatible so that non-large ciphers can use it, you need a > > way to send a MDC inside an encryption envelope such that it won't > > cause current implementations to barf. For this the appended hash > > method doesn't work (or at least I can see no elegant way to make it > > work). > > A good enough reason for me to vote down the support for MDC in > "old" ciphers. Not really, the symmetric MDC packet is more elgant, as well as providing the possibility of working with the existing RFC, and so provides more overall security. We only just finished writing 2440, and you want to start obsoleting it. There are I think more pgp2.x implementations than 5.x, 6.x and GPG together. I think your comments about ease of implementation are off-base -- Tom Zerucha, who wrote an OpenPGP implementation votes that symmetric MDCs are easier. I haven't implemented OP, but I have implemented parts of pgp2.x, and I think this change would be easier also. It fits right into the existing framework, and doesn't require buffering tricks. > > I argue that these benefits make it worth favoring the new signature > > type over appended hash approach. > > Let's say that we disagree here. Perhaps if we could list the pros and cons: - ease of implementation (MDC sig wins) - adds security for more implementations (MDC sig wins) What are your arguments against MDC sigs? Note I am not against the "big clean up" phase planned for openPGP 2.0. I am all for it. I think PRZs suggestion that we add a new encryption method (standard CFB etc) is a _good thing_. However I would sooner see MDCs implemented in a way which fits into the existing framework, and thus is backwards compatible! That's what the framework is for -- so that there are defined means for algorithms to get added. Therefore I argue you should do what you can, especially when it is more elegant anyway, within the existing framework. Adam -- print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Tue, 13 Apr 1999 19:28:35 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA29613 for ietf-open-pgp-bks; Tue, 13 Apr 1999 15:51:26 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA29608 for ; Tue, 13 Apr 1999 15:51:25 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id SAA06544; Tue, 13 Apr 1999 18:51:44 -0400 Received: from buoy.watson.ibm.com (buoy.watson.ibm.com [9.2.3.94]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id SAA20876; Tue, 13 Apr 1999 18:51:44 -0400 Received: by buoy.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA26366; Tue, 13 Apr 1999 18:51:44 -0400 From: uri Message-Id: <9904132251.AA26366@buoy.watson.ibm.com> Subject: Re: Phil Zimmermann's suggestion - Implementation? To: tzeruch@ceddec.com (Tom Zerucha) Date: Tue, 13 Apr 1999 18:51:44 -0400 (EDT) Cc: ietf-open-pgp@imc.org In-Reply-To: <99Apr13.173445edt.42114@brickwall.ceddec.com> from "Tom Zerucha" at Apr 13, 99 05:36:25 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Tom Zerucha says: > > Oh, I do assume you don't want to run through the file counting! (:-) > > No, I want to both count and hash at the same time, but I can't because... Yes you can - but you th hash may be one block behind. Still, you run through the file only once, and do a bit of special things at the *end*. > > The practical solution I see is delaying the hash update when decrypting > > by one block. I.e. you decrypt block K+1 and hash block K... Yes, it's > > not going to win a beauty contest. But it will work. > > With the stream format the last block might be less than 20 bytes. A 520 > byte file will be 512+...8 (or for larger values, 5000 would be > 4096+...4). And you can't hold back one "block", at least it would be > difficult if the block is the maximum legal size (2^31 bytes?). You have > to hold back at least 20 bytes at the end of any nonterminal packet. I meant - one cipher or hash block, i.e. 160 bits. So if you got the last *file* block 4 bytes, you figure that these 4 bytes together with the last 16 bytes from the "saved" last cipher-block constitute the MDC. > > Nope! The problem with this is - you'll *have* to run through the file > > on extra time. Undesirable for pipes! > > Only on encryption! I would rather run through one more time there, than > once per decryption. Decryption is really messy but only requires a 20 > byte delay, so it is not quite the same thing. But it seems unnecessary to introduce such "second run". > > > If you want an MDC, and there is already a place for MDCs, then it should > > > go there if the format can be adapted. > > OK, I don't object as strongly any more. I'm neutral now. > Lets see what the other implementors have to say. Sure. > > > In short, if you really want to do this, then add an MDC-only signature > > > type or subtype. The (non)signature packets will be encrypted with the > > > rest of the stream. In fact, the null cipher type might work as is. > > > > But it's NOT a signature! > > I don't know what else to call it because it is identified as the > "signature packet" in the Spec. Maybe we can start calling it the > "frooble" packet if that would be less confusing. A "signature" vouches for the authenticity of the data. MDC vouches only for its integrity... -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ietf-open-pgp@imc.org Wed Apr 14 15:07:09 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00116 for ; Wed, 14 Apr 1999 15:07:08 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA07348 for ietf-open-pgp-bks; Wed, 14 Apr 1999 11:03:36 -0700 (PDT) Received: from 226-132.adsl2.avtel.net (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA07344 for ; Wed, 14 Apr 1999 11:03:35 -0700 (PDT) Received: (from hal@localhost) by 226-132.adsl2.avtel.net (8.8.7/8.8.7) id LAA03168 for ietf-open-pgp@imc.org; Wed, 14 Apr 1999 11:03:30 -0700 Date: Wed, 14 Apr 1999 11:03:30 -0700 From: hal@rain.org Message-Id: <199904141803.LAA03168@226-132.adsl2.avtel.net> To: ietf-open-pgp@imc.org Subject: Restricting key sizes to mult of 64 bits Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: The DSS spec requires that DSS keys be a multiple of 64 bits in size. PGP has not enforced this limitation in the past, but we are adding that now. At the same time, we are considering requiring that newly generated keys of the other types, ElGamal and RSA, also be multiple of 64 bits (note that this is only enforced on keygen). The rationale is that keys of "oddball" sizes may not be properly supported by all implementations. We want users' keys to be able to be used in a wide range of present and future implementations, possibly including non-PGP environments like smartcard systems and X.509 or SPKI. By making the key sizes a nice, round number, we improve the chances of them functioning properly in these other environments. Some users have already encountered a problem with oddly sized keys. We shipped software which used Microsoft's built-in Crypto API (CAPI) to do the RSA calculations. As it turned out, CAPI had a bug which prevented it from working properly with unusual key sizes. Those users weren't able to use their keys with the CAPI version. We would like to reduce the chance of running into similar problems in the future, and keeping keys to round sizes should help. The choice of 64 bits as the multiple is based on trading off the desire for plenty of key sizes versus minimizing the chance of an unsupported key size. The fact that DSS uses 64 bit multiples suggests that this is a reasonable value. However, there is some concern that the user and developer community may be opposed to losing this flexibility in their key size choices. I was hoping to get some feedback here about whether this change seems reasonable. OpenPGP participants have provided valuable feedback in the past regarding design decisions made by NAI, often after the fact. This time it would be helpful to find out beforehand if there will be opposition to restricting newly generated keys in this way. Thanks for your comments, Hal Finney NAI, Inc. From owner-ietf-open-pgp@imc.org Wed Apr 14 15:19:12 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00749 for ; Wed, 14 Apr 1999 15:19:12 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA07502 for ietf-open-pgp-bks; Wed, 14 Apr 1999 11:19:13 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA07498 for ; Wed, 14 Apr 1999 11:19:12 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id UAA09720 for ietf-open-pgp@imc.org; Wed, 14 Apr 1999 20:19:26 +0200 (MET DST) Received: (qmail 29983 invoked from network); 14 Apr 1999 17:45:22 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 14 Apr 1999 17:45:22 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10XThO-0000Tg-00; Wed, 14 Apr 1999 19:43:42 +0200 Date: Wed, 14 Apr 1999 19:43:42 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: MDC packet (was: Phil Zimmermann's suggestion - Implementation?) Message-ID: <19990414194342.A1826@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <9904132023.AA25802@buoy.watson.ibm.com> <99Apr13.173445edt.42114@brickwall.ceddec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <99Apr13.173445edt.42114@brickwall.ceddec.com>; from Tom Zerucha on Tue, Apr 13, 1999 at 05:36:25PM -0400 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Tom Zerucha writes: > Lets see what the other implementors have to say. If expanding the > definition of an existing packet to "verification (signature or MDC)" > packet is easy to do in the existing code base (incl NAI PGP 6.0!), we can > start implementing this now as a test. Then we would have MDCs and be > able to merge them into the spec, and both spec and code would update in I like Tom's proposal. If someone can define the extension to the signature packet (or a new one) I'll add it to GnuPG ASAP. -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Wed Apr 14 17:04:25 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05549 for ; Wed, 14 Apr 1999 17:04:22 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA08965 for ietf-open-pgp-bks; Wed, 14 Apr 1999 13:14:56 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA08961 for ; Wed, 14 Apr 1999 13:14:54 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id WAA19227 for ietf-open-pgp@imc.org; Wed, 14 Apr 1999 22:15:18 +0200 (MET DST) Received: (qmail 30609 invoked from network); 14 Apr 1999 20:13:32 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 14 Apr 1999 20:13:31 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10XVyl-00054C-00; Wed, 14 Apr 1999 22:09:47 +0200 Date: Wed, 14 Apr 1999 22:09:47 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Restricting key sizes to mult of 64 bits Message-ID: <19990414220947.B19463@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904141803.LAA03168@226-132.adsl2.avtel.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <199904141803.LAA03168@226-132.adsl2.avtel.net>; from hal@rain.org on Wed, Apr 14, 1999 at 11:03:30AM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: hal@rain.org writes: > At the same time, we are considering requiring that newly generated keys > of the other types, ElGamal and RSA, also be multiple of 64 bits (note I can agree on a multiple of 8 bits but I don't the an advantage to use any other value. > to do the RSA calculations. As it turned out, CAPI had a bug which > prevented it from working properly with unusual key sizes. Those users > weren't able to use their keys with the CAPI version. Working around bugs in one companies new product is a Bad Thing to do. There are many other issues we could fix for them by changing the standards ;-). Adding workarounds for some products which are around for a long time is a different thing. Just my 0.02 Euros -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Fri Apr 16 11:17:20 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04866 for ; Fri, 16 Apr 1999 11:17:19 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA04032 for ietf-open-pgp-bks; Fri, 16 Apr 1999 07:17:44 -0700 (PDT) Received: from dfw-ix3.ix.netcom.com (dfw-ix3.ix.netcom.com [206.214.98.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA04028 for ; Fri, 16 Apr 1999 07:17:43 -0700 (PDT) Received: (from smap@localhost) by dfw-ix3.ix.netcom.com (8.8.4/8.8.4) id JAA10863; Fri, 16 Apr 1999 09:16:37 -0500 (CDT) Received: from ren-nv4-50.ix.netcom.com(207.94.110.50) by dfw-ix3.ix.netcom.com via smap (V1.3) id rma010726; Fri Apr 16 09:15:48 1999 Message-Id: <3.0.5.32.19990416071030.0098f100> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 16 Apr 1999 07:10:30 -0700 To: Werner Koch From: Michael Marking Subject: Re: Restricting key sizes to mult of 64 bits Cc: ietf-open-pgp@imc.org In-Reply-To: <19990414220947.B19463@frodo.isil.d.shuttle.de> References: <199904141803.LAA03168@226-132.adsl2.avtel.net> <199904141803.LAA03168@226-132.adsl2.avtel.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 10:09 PM 99/04/14 +0200, you wrote: >hal@rain.org writes: > >> At the same time, we are considering requiring that >> newly generated keys of the other types, ElGamal >> and RSA, also be multiple of 64 bits (note > >I can agree on a multiple of 8 bits but I don't the >an advantage to use any other value. Why? For a given maximum key size, this restriction cuts the available key space in half, approximately. What effect does it have on the difficulty of an attack? >> to do the RSA calculations. As it turned out, CAPI >> had a bug which prevented it from working properly >> with unusual key sizes. Those users weren't able >> to use their keys with the CAPI version. > >Working around bugs in one companies new product is a >Bad Thing to do. Discovered errors are an indicator that additional, latent errors are likely to exist. The fringe cases are often the ones which encounter the errors. If we do not permit "odd" key sizes, or other inconvenient usage, then we may allow sloppy practices which ultimately might jeopardize the security of the user. >There are many other issues we could fix for them by >changing the standards ;-). >Adding workarounds for some products which are around >for a long time is a different thing. Yes. A warning to the user, or a documented configuration option, is a much better solution. -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.5.3 iQA/AwUBNxdE1d3xSrdLzmIWEQIC/QCglPlmDWGK1lFvKHgv9I+0e8TvXkwAniSS zfdv4rzgNA1/tourvMQ5l0BO =g6pw -----END PGP SIGNATURE----- From owner-ietf-open-pgp@imc.org Fri Apr 16 13:46:29 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09278 for ; Fri, 16 Apr 1999 13:46:28 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA17421 for ietf-open-pgp-bks; Fri, 16 Apr 1999 09:50:46 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA17406 for ; Fri, 16 Apr 1999 09:50:41 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id SAA26520 for ietf-open-pgp@imc.org; Fri, 16 Apr 1999 18:51:11 +0200 (MET DST) Received: (qmail 657 invoked from network); 16 Apr 1999 16:27:53 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 16 Apr 1999 16:27:53 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10YBPq-0005bc-00; Fri, 16 Apr 1999 18:24:30 +0200 Date: Fri, 16 Apr 1999 18:24:29 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Restricting key sizes to mult of 64 bits Message-ID: <19990416182429.B21536@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904141803.LAA03168@226-132.adsl2.avtel.net> <199904141803.LAA03168@226-132.adsl2.avtel.net> <19990414220947.B19463@frodo.isil.d.shuttle.de> <3.0.5.32.19990416071030.0098f100> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <3.0.5.32.19990416071030.0098f100>; from Michael Marking on Fri, Apr 16, 1999 at 07:10:30AM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Michael Marking writes: > >I can agree on a multiple of 8 bits but I don't the > >an advantage to use any other value. > > Why? Because it is the natural unit of measure on most computers. > For a given maximum key size, this restriction cuts > the available key space in half, approximately. What > effect does it have on the difficulty of an attack? I didn't mean that we need a restriction at all. -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Tue Apr 20 13:35:45 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13857 for ; Tue, 20 Apr 1999 13:35:44 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA00507 for ietf-open-pgp-bks; Tue, 20 Apr 1999 09:29:47 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA00502 for ; Tue, 20 Apr 1999 09:29:38 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id SAA06715 for ietf-open-pgp@imc.org; Tue, 20 Apr 1999 18:30:04 +0200 (MET DST) Received: (qmail 7983 invoked from network); 20 Apr 1999 16:20:42 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 20 Apr 1999 16:20:42 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10ZdDs-0001xn-00; Tue, 20 Apr 1999 18:18:08 +0200 Date: Tue, 20 Apr 1999 18:18:08 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: MDC packet Message-ID: <19990420181806.D7486@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <9904132023.AA25802@buoy.watson.ibm.com> <99Apr13.173445edt.42114@brickwall.ceddec.com> <19990414194342.A1826@frodo.isil.d.shuttle.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i In-Reply-To: <19990414194342.A1826@frodo.isil.d.shuttle.de>; from Werner Koch on Wed, Apr 14, 1999 at 07:43:42PM +0200 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Werner Koch writes: > I like Tom's proposal. If someone can define the extension to the > signature packet (or a new one) I'll add it to GnuPG ASAP. Hmmm, no comments on this for a week. Does this mean I should design a new packet or extend the signature packet specs? -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Wed Apr 21 02:18:07 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01929 for ; Wed, 21 Apr 1999 02:18:07 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA15162 for ietf-open-pgp-bks; Tue, 20 Apr 1999 22:48:09 -0700 (PDT) Received: from 226-132.adsl2.avtel.net (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA15154 for ; Tue, 20 Apr 1999 22:48:07 -0700 (PDT) Received: (from hal@localhost) by 226-132.adsl2.avtel.net (8.8.7/8.8.7) id WAA00726; Tue, 20 Apr 1999 22:48:34 -0700 Date: Tue, 20 Apr 1999 22:48:34 -0700 From: hal@rain.org Message-Id: <199904210548.WAA00726@226-132.adsl2.avtel.net> To: ietf-open-pgp@imc.org, prz@pgp.com, tzeruch@ceddec.com Subject: Re: Phil Zimmermann's suggestion - Implementation? Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I have experimentally implemented the integrated message integrity check within the encryption/decryption layer. It is not difficult to handle the 20-byte trailing hash during decryption. I use a circular buffer in which I put the trailing part of each chunk of decrypted data. It always has the last 20 decrypted bytes in it. The data is passed through the hash as we output it from this decryption layer; once we hit EOF we take the 20 bytes in the buffer and we know those should be matched against the calculated hash. I can't speak for other implementations, but I found doing it this way to be fairly straightforward. I don't see implementation difficulty as being a barrier to this approach, or a reason to put the integrity checking in a pseudo-signature packet. The problem with doing it in a signature packet is that it is a fundamentally different function than signatures. The hash only provides integrity in the context of an encryption envelope. Logically the integrity protection is a property of the encryption layer. Doing the hash without encryption provides no integrity protection. The signature packet is functionally the wrong place to put it. Hal Finney NAI, Inc. From owner-ietf-open-pgp@imc.org Wed Apr 21 09:56:23 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06491 for ; Wed, 21 Apr 1999 09:56:22 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA06999 for ietf-open-pgp-bks; Wed, 21 Apr 1999 06:14:59 -0700 (PDT) Received: from mail15.svr.pol.co.uk (mail15.svr.pol.co.uk [195.92.193.25]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA06994 for ; Wed, 21 Apr 1999 06:14:56 -0700 (PDT) Received: from modem-102.promethium.dialup.pol.co.uk ([62.136.30.102] helo=server.eternity.org) by mail15.svr.pol.co.uk with esmtp (Exim 2.12 #1) id 10Zwr0-0006Hy-00; Wed, 21 Apr 1999 14:15:50 +0100 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id OAA04701; Wed, 21 Apr 1999 14:07:54 +0100 Date: Wed, 21 Apr 1999 14:07:54 +0100 Message-Id: <199904211307.OAA04701@server.eternity.org> From: Adam Back To: ietf-open-pgp@imc.org Cc: prz@pgp.com Cc: hal@rain.org Subject: new approach to MDCs: single shared private key Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Whilst looking at RFC2440 with a view to defining suitable algorithm ids and minimal backwards compatible changes to try out the verification packet approach, in response to Werner Koch's posts, an insight struck me: all we have to do is publish and agree upon a minimal sized RSA public and private key and publish it. This allows us to provide: - the best backwards compatibility of all (allows even pgp23a to *check* MDCs, which is even better than just "not choking" on them). - the lowest implementation overhead of all (ie none!) This approach: - prevents Gary Howland's encrypted message modification attack because the signature with known public and private key performs the same function as a hash inside the encryption envelope. - it doesn't provide non-repudiation because the private key is shared (which is the whole point, we don't want non-repudiation in this scenario, and some people have good reasons for not wanting it). - any pgp2.3a and forward implementation can "implement" these MDCs merely by adding this public and private key pair to their key ring. - PRZ identified the problem that even with signed messages often the public key is not present to verify them, so integrity is not assured. With openPGP and pgp(5|6).x where multiple signatures can be applied, the document could be signed by both the fixed published RSA key, and the user's private RSA key. - The same approach of a published public and private DSA key can be used to do the same thing with DSA for implementations temporarily avoiding RSA until the patent expires. - The only extra overhead is the signature creation and verification. The key size does not affect security, so using a small a key as possible does not adversely affect security. A 384 bit key, or perhaps even 256 bit key would be perfectly adequate. (The limit will be imposed by the size of RSA block required to hold the minimum sized padded document hash.) The minimum key size that the already deployed DSA and RSA signature verification code would consider a valid signature - The keyid on the keys can be set to the string "Integrity Verification Key" to help ensure that implementations present representative messages. - These public and private keys can be distributed with new implementations, and distrubted widely on the internet. Comments? I think it is a neat, and exciting trick which allows even pgp2.3a to overcome the message modification problem with no implementation work. The only advantages of defining a different MDC packet (which is what I was in the process of doing when this occured to me) is to avoid this small computational and space overhead. Defining an elegant, space and computationally efficiient implementation at our leisure can be done once the standard RSA and DSA private and public keys are agreed upon, as an optimally backwards compatible approach can be used for old implementations. Adam From owner-ietf-open-pgp@imc.org Wed Apr 21 11:51:55 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09644 for ; Wed, 21 Apr 1999 11:51:55 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA08571 for ietf-open-pgp-bks; Wed, 21 Apr 1999 08:00:42 -0700 (PDT) Received: from mail1.svr.pol.co.uk (mail1.svr.pol.co.uk [195.92.193.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA08566 for ; Wed, 21 Apr 1999 08:00:40 -0700 (PDT) Received: from modem-32.neodymium.dialup.pol.co.uk ([62.136.29.160] helo=server.eternity.org) by mail1.svr.pol.co.uk with esmtp (Exim 2.12 #1) id 10ZyVM-0003Y3-00; Wed, 21 Apr 1999 16:01:36 +0100 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id PAA05398; Wed, 21 Apr 1999 15:44:29 +0100 Date: Wed, 21 Apr 1999 15:44:29 +0100 Message-Id: <199904211444.PAA05398@server.eternity.org> From: Adam Back To: ietf-open-pgp@imc.org Cc: cypherpunks@cyberpass.net Subject: shared private key for MDCs Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I thought I'd have a go at testing out the shared private key approach to implementing an interity check/MDC (MDC=Modification Detection Code). pgp263i won't generate keys below 384 bits. So I compiled one without that restriction, and it seems that the the smallest key that (normal) pgp263i will create signatures for and verify signatures for, empirically is 289 bits. (This is due to the padding that must fit inside the signature: > PGP versions 2.3 and later encode the MD into the MPI as follows: > > MSB . . . LSB > > 0 1 FF(n bytes) 0 ASN(18 bytes) MD(16 bytes) > > See RFC1423 for an explanation of the meaning of the ASN string. > It is the following 18 byte long hex value: > > 3020300c06082a864886f70d020505000410 which it would seem from the above is 2+0+1+18+16=37 bytes, which is 296. It seems that the implementation lets you get away with 289, perhaps because the leading 0 is presumed on odd sized integers.) So here is a 289 bit private and public key: Type Bits/KeyID Date User ID sec 289/AADC77C5 1999/04/21 Integrity Verification Key -----BEGIN PGP SECRET KEY BLOCK----- Version: 2.6.3i lQCYAzcd278AAAEBIQGJDbfjBrve0Ips+daIHWQjgKyn5AUR8fxH6ODUATO0f6rc d8UABREAAR9Q7DxygWLqG+BDnNlYQklSmn1cSDIiDELfP2k2A/ftZzMnITsAkOK8 EHA9EkYOnR//AD2uMfL2vwCRAbvJSkV5XA6mRK2lyGNugHSWewCPRIcJHBV0F/vY OdbY0L5AgJ3RKqO0GkludGVncml0eSBWZXJpZmljYXRpb24gS2V5 =ZDof -----END PGP SECRET KEY BLOCK----- Type Bits/KeyID Date User ID pub 289/AADC77C5 1999/04/21 Integrity Verification Key Type Bits/KeyID Date User ID pub 289/AADC77C5 1999/04/21 Integrity Verification Key -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQAyAzcd278AAAEBIQGJDbfjBrve0Ips+daIHWQjgKyn5AUR8fxH6ODUATO0f6rc d8UABRG0GkludGVncml0eSBWZXJpZmljYXRpb24gS2V5 =52/E -----END PGP PUBLIC KEY BLOCK----- And here is a conventionally encrypted, uncompressed message which has been signed with the above key. the conventional encrypt password is "fred" (no quotes). % echo hello world > test % pgp -csa -zfred test -u 0xAADC77C5 % cat test.asc -----BEGIN PGP MESSAGE----- Version: 2.6.3i pgAAAGNphXbrTqYwlo9KM6gIo4182vQxkm8+cNoFVcLCxgA0x9Ibj+sbims/nFKJ VuXUQGn/MeBwvjULg4OROnz0si5jkCv8/GMOzeoeonOFi9t1twH4en/+lbe9ddV2 vxiVyGJ+Jwc= =hOMd -----END PGP MESSAGE----- and here is what is displayed by pgp263i when you decrypt that: % pgp -zfred test.asc File is conventionally encrypted. Just a moment....Pass phrase appears good. . File has signature. Public key is required to check signature. . Good signature from user "Integrity Verification Key". Signature made 1999/04/21 14:35 GMT using 289-bit key, key ID AADC77C5 % and by pgp50i when you decrypt it: % pgpv -zfred test.asc Message is encrypted. Opening file "test" type binary. Good signature made 1999-04-21 14:34 GMT by key: 289 bits, Key ID AADC77C5, Created 1999-04-21 "Integrity Verification Key" WARNING: The signing key is not trusted to belong to: Integrity Verification Key % I removed the self signature from the key because it seems pointless to self sign a key which has a published private key. Interestingly pgp263i seems to consider this key trusted due to the presence of the private key on the private key ring, whereas pgp50i considers it to have "undefined trust". Adam -- print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Wed, 21 Apr 1999 16:33:25 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA12162 for ietf-open-pgp-bks; Wed, 21 Apr 1999 12:50:13 -0700 (PDT) Received: from atanda.com ([204.162.11.9]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA12158 for ; Wed, 21 Apr 1999 12:50:12 -0700 (PDT) From: Dave@DelTor.to Received: from [192.168.248.7] (216.100.248.78) by atanda.com with ESMTP (Eudora Internet Mail Server 1.2.1); Wed, 21 Apr 1999 12:52:01 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Message-Id: In-Reply-To: <199904211307.OAA04701@server.eternity.org> References: <199904211307.OAA04701@server.eternity.org> X-PGPkeyID-Fprnt: 4AAF00E5 - 30d81f34 84e6a83f 6ec8d7f0 cab3d265 Date: Wed, 21 Apr 1999 12:46:01 -0700 To: Adam Back Subject: Re: new approach to MDCs: single shared private key Cc: ietf-open-pgp@imc.org, prz@pgp.com Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 2:07 PM +0100 1999-04-21, Adam Back wrote: >[elided] >- PRZ identified the problem that even with signed messages often the >public key is not present to verify them, so integrity is not assured. >With openPGP and pgp(5|6).x where multiple signatures can be applied, >the document could be signed by both the fixed published RSA key, and >the user's private RSA key. [...] Adam, The parallel signature extension I've added to the forthcoming OpenPGP/MIME draft will make this very easy for MIME-compliant mailers. Thomas Roessler and I are hoping to have the draft ready for the Oslo IETF in July, and we'll have it up on the list for dsicussion fairly soon. dave An excerpt: ................................. cut here ................................. 8. Parallel (Multiple) Signatures Digitally signed messages conforming to this document are denoted by the "multipart/signed" content type, defined in RFC 1847, with a "protocol" parameter which MUST have a value of "multipart/mixed". (MUST be quoted). The "micalg" parameter MUST contain a comma-separated list of hash- symbols. These hash-symbols identify the message integrity check (MIC) algorithm(s) used to generate the subsequent signature(s). Hash-symbols MUST NOT occur more than once in this list. The multipart/signed body MUST consist of exactly two parts. The first part contains the signed data in MIME canonical format, including a set of appropriate content headers describing the data. The second part MUST be of type "multipart/mixed". Each sub-part represents an individual digital signature which has been formed according to RFC 1847 and the specification of the signature protocol used. Example message: From: Dave Del Torto To: Raph Levien Mime-Version: 1.0 Content-Type: multipart/signed; protocol="multipart/mixed"; boundary=0000_031; micalg="pgp-md5,pgp-sha1,rsa-md5" --0000_031 Content-Type: text/plain Hi Raph, Here's some text with parallel (multiple) digital signatures in various formats. dave ______________________________________________________________________ "All email luxuriantly hand-crafted using only the finest ASCII text." --0000_031 Content-Type: multipart/mixed; boundary=0000_032 --0000_032 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 2.6.2 Comment: Hash computed using MD5 micalg. iQCVAwUBM0Iu16HBOF9KrwDlAQGaiQP9EU1YXgMSoNxDAqSmo7UoCE52DuYCfxm7 x8RfRr9+Xz3nPFytSYM2TIWGMeKi1fVr5PhfjdrKvOh9sCq97h6zndZVpGA9x62k mPVn/QY3fz1eOdyJbYvW4ba7WQll5OoA6cqmEb9tWwh4ra4yE8hZMnLS9a0uPpuB 5dpiTTAE/gY= =hD3D -----END PGP SIGNATURE----- --0000_032 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Comment: Hash computed using SHA-1 micalg (FIPS 180-1). iQCVAwUBM0It9qHBOF9KrwDlAQFBaQQAisIzQUgyknT2v729b7MImcUc3ROdRBh6 nwMyAfdewQYCDxqdDWvnD1UWoUjwjA1JNA6qhTXBxs8yPtZdDZaguOG2zWawyat9 Jib556AuSx10psREDC3vNsaJ99MV8SKFF92H53l9w/YhVOA0aMZeNfLE0jJVypkY /so4/7DHhqQ= =/wlj -----END PGP SIGNATURE----- --0000_032 Content-Type: application/x-pkcs7-signature Content-Transfer-Encoding: base64 Comment: Hash computed using S/MIME MD5 micalg. MIAGCSqGSIb3DQEHAqCAMIACAQExDjAMBggqhkiG9w0CBQUAMIAGCSqGSIb3DQEH [ciphertext elided] +kNIWIbxNiNje1wlzIhaGjrGrOnvYc8+tFn2LgAAAAAAAAAA --0000_032-- --0000_031-- From owner-ietf-open-pgp@imc.org Wed Apr 21 18:23:36 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26950 for ; Wed, 21 Apr 1999 18:23:35 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA13016 for ietf-open-pgp-bks; Wed, 21 Apr 1999 14:34:14 -0700 (PDT) Received: from exeter.ac.uk (hermes.ex.ac.uk [144.173.6.14]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA13011 for ; Wed, 21 Apr 1999 14:34:13 -0700 (PDT) Received: from cronus [144.173.6.20] by hermes via SMTP (WAA02473); Wed, 21 Apr 1999 22:35:10 +0100 (BST) Date: Wed, 21 Apr 1999 22:35:10 +0100 Message-Id: <8509.199904212135@cronus> From: Adam Back To: ietf-open-pgp@imc.org Cc: cypherpunks@cyberpass.net In-reply-to: <199904211444.PAA05398@server.eternity.org> (message from Adam Back on Wed, 21 Apr 1999 15:44:29 +0100) Subject: DSS shared private key for MDCs (Re: shared private key for MDCs) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: And here is a shared private key for DSS MDCs. I had to modify pgp50i to allow it to generate smaller keys, normally it won't create DSS keys below 768 bits. It doesn't appear to be able to create DSS keys below 512 bits, and I doubt it would verify them or make sigs with them either as DSS is defined to have key sizes from 512 to 1024 bits. So the key is a 512 bit key, being the smallest (for efficiency) valid key. (I had to resort to emacs for removing the Elgamal encryption subkeys, there appears no way to remove them separately, nor create DSS keys without encryption subkeys with unix pgp 50i normally). Type Bits KeyID Created Expires Algorithm Use pub 512 0x0EE50720 1999-04-21 ---------- DSS Sign only -----BEGIN PGP PUBLIC KEY BLOCK----- Armor: arm.pl mQDiBDceN7sRAgDhsbpuoOOFhXYe8WimMwrgH6+V2IecY6mrp8RgfE/grDI3yFc4 Y6TUJirYbsTA/l7vhRBO7yMkg76op/2mF+HDAKD/n1iSgq6e8M0g2++WPUR2UVsl VwH/QRxvbzpoW4247IL8O4eqtgaDnekJg6G6hmZtcdWVX2NAfMdh3iqIK/AXdNkK Yq/P3a47Zu99GGQwZ9Fc227NvgH/bxCPd6AIUFk7orBKwYbYNljjQ1ClVEalQVLv LJTjGwIqSpwqzpvyiz1vFPpQXuhJ6iTX4FvbVqw+JeAbeBXMSbQaSW50ZWdyaXR5 IFZlcmlmaWNhdGlvbiBLZXk= -----END PGP PUBLIC KEY BLOCK----- Type Bits KeyID Created Expires Algorithm Use sec 512 0x0EE50720 1999-04-21 ---------- DSS Sign only -----BEGIN PGP SECRET KEY BLOCK----- Armor: arm.pl lQD7BDceN7sRAgDhsbpuoOOFhXYe8WimMwrgH6+V2IecY6mrp8RgfE/grDI3yFc4 Y6TUJirYbsTA/l7vhRBO7yMkg76op/2mF+HDAKD/n1iSgq6e8M0g2++WPUR2UVsl VwH/QRxvbzpoW4247IL8O4eqtgaDnekJg6G6hmZtcdWVX2NAfMdh3iqIK/AXdNkK Yq/P3a47Zu99GGQwZ9Fc227NvgH/bxCPd6AIUFk7orBKwYbYNljjQ1ClVEalQVLv LJTjGwIqSpwqzpvyiz1vFPpQXuhJ6iTX4FvbVqw+JeAbeBXMSQAAn0+t0HGYxE9p GYtIONiEqv3oJFp+Cvu0GkludGVncml0eSBWZXJpZmljYXRpb24gS2V5 -----END PGP SECRET KEY BLOCK----- And here is a conventionally encrypted message which has been signed with the above key. the conventional encrypt password is "fred" (no quotes). % echo hello world > test % pgpe -csa -zfred test -u 0x0EE50720 % cat test.asc -----BEGIN PGP MESSAGE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: /QiKruEMWv11r/vKHdrywdyCsSnuba7A pGvRemGaX2Mvw1tf2bq7hv9DoBHwPM6nt3Btd93qGJlSR1mK9y3SGBbMuZJJYCCX MxE69+VaDTMJ0+bLWVJRPTIT3J+aoKOS32XoejK5pMTx2BlvW5pWohMcQ2hL9AxA +iPKXlakHKMCT3F7Og== =PZOZ -----END PGP MESSAGE----- % and here is what is displayed by unix pgp50i when you decrypt that: % pgpv -zfred test.asc Message is encrypted. Opening file "test" type binary. Good signature made 1999-04-21 21:24 GMT by key: 512 bits, Key ID 0EE50720, Created 1999-04-21 "Integrity Verification Key" WARNING: The signing key is not trusted to belong to: Integrity Verification Key % Adam From owner-ietf-open-pgp@imc.org Wed Apr 21 18:44:48 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27436 for ; Wed, 21 Apr 1999 18:44:47 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA13724 for ietf-open-pgp-bks; Wed, 21 Apr 1999 15:10:59 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA13720 for ; Wed, 21 Apr 1999 15:10:58 -0700 (PDT) Received: from jcallas (dhcp-47-64.dhcp.nai.com [161.69.47.64]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id PAA11428; Wed, 21 Apr 1999 15:11:07 -0700 (PDT) Message-Id: <3.0.3.32.19990421150531.030b0a00@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 21 Apr 1999 15:05:31 -0700 To: "James H. Cloos Jr." , ietf-open-pgp@imc.org From: Jon Callas Subject: Re: Mixing rsa and dh/dsa In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 02:31 PM 4/13/99 -0500, James H. Cloos Jr. wrote: |Given a recipient with only an RSA keypair (algo 1), and a sender with |only a DSA/Elgamal pair (algos 17 and 16), should the sender |encrypt+sign, will any extant software be able to decrypt and verify? | If the sender has software that can do RSA, yes. If their software can't do RSA (for example, suppose they had an NAI/PGP freeware version), then the sender cannot encrypt to the recipient. Any OpenPGP-compliant version, though will be able to verify DSA sigs and encrypt to Elgamal keys. Does that answer your question? Really your question is an implementation question, not a standards question. Jon ----- Jon Callas jon@pgp.com CTO, Total Network Security 3965 Freedom Circle Network Associates, Inc. Santa Clara, CA 95054 (408) 346-5860 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) From owner-ietf-open-pgp@imc.org Wed Apr 21 19:06:07 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27873 for ; Wed, 21 Apr 1999 19:06:07 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA13936 for ietf-open-pgp-bks; Wed, 21 Apr 1999 15:32:10 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA13931 for ; Wed, 21 Apr 1999 15:32:08 -0700 (PDT) Received: from [38.232.7.6] (161.69.48.157) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Wed, 21 Apr 1999 14:33:06 -0800 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <19990416182429.B21536@frodo.isil.d.shuttle.de> References: <3.0.5.32.19990416071030.0098f100>; from Michael Marking on Fri, Apr 16, 1999 at 07:10:30AM -0700 <199904141803.LAA03168@226-132.adsl2.avtel.net> <199904141803.LAA03168@226-132.adsl2.avtel.net> <19990414220947.B19463@frodo.isil.d.shuttle.de> <3.0.5.32.19990416071030.0098f100> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Apr 1999 15:21:58 -0700 To: ietf-open-pgp@imc.org From: Jon Callas Subject: Re: Restricting key sizes to mult of 64 bits Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: As has been noted, DSS requires that the keys be a multiple of 64. According to M,Vo,&V (section 11.58, p453), DSA requires this too. It says, "...the size of p can be any multiple of 64 bits between 512 and 1024 bits inclusive." They are apparently quoting FIPS 186 on this. I know that Schneier also says something similar. I think it's tacit that DSA keys need to be multiples of 64 bits. I'm willing to explicitly say this in the next revision. It is, of course, polite for an implementation to permit odd-size keys, but an implementation is permitted to reject this. I don't see any reason to restrict the key sizes on Elgamal or RSA keys. And as the owner of a 1723 bit RSA key, I'm against it. Jon From owner-ietf-open-pgp@imc.org Wed Apr 21 19:55:04 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28376 for ; Wed, 21 Apr 1999 19:55:03 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA14847 for ietf-open-pgp-bks; Wed, 21 Apr 1999 16:24:00 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA14843 for ; Wed, 21 Apr 1999 16:23:58 -0700 (PDT) Received: from [38.232.7.6] (161.69.48.157) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Wed, 21 Apr 1999 15:24:56 -0800 X-Sender: jon@merrymeet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Apr 1999 16:24:46 -0700 To: ietf-open-pgp@imc.org From: Jon Callas Subject: Message Integrity Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: My apologies for not jumping in here sooner. The consensus that I've seen is against overloading message integrity on signature packets. We also discussed it in Orlando, and there was great consensus against it there. I confess that personally, I also question the wisdom of separating them. Especially if it requires a shared key. In Orlando, there was consensus that we wanted to add several things to OpenPGP for our next RFC. They were: (1) Message Integrity Codes (a.k.a. MDCs or whatever. I've been using the term Message Integrity Code or MIC -- if people prefer the other terminology, I can write it up that way.) (2) Normalization of encryption modes. Among the solutions to this are (a) using normal CFB mode or (b) using CBC mode. I've heard from people who prefer each, and don't know if there's a consensus on which is better. I don't care. (3) Rich user IDs. (4) A V5 signature packet that allows 4-byte lengths. There's a tangential discussion to this that is to start deprecating some of the more bizarre length types, but that's a can of worms I don't want to open today. Next week. (5) A signature sub-packet that allows a certificate to declare which of the above advanced features it speaks. I've been calling this the "features" subpacket. Only (1) and (2) are germane to this present discussion. A scheme that has been discussed, and I thought we had a lot of agreement on even back in Orlando was to solve (1) and (2) with a new encrypted data packet that used a standard encryption mode and appended a hash at the end. I've been in discussion with several people who've offered several opinions on what that hash can or should be, and I believe that the best thing to do is just make it a SHA-1 hash, as a minimal OpenPGP implementation must already have SHA-1 in it. No one who's done any work on it has come up with a different solution that is better. I really don't like overloading MICs on signature packets. That's a kluge, and it offends my sensitive architect's aesthetics. OpenPGP already has quite enough kluges in it. I'd prefer to stomp on a few rather than add another. Adding in shared keys makes it a worse kluge. I can't see what goodness comes from a null-signature packet. I've been waiting for someone else to create this packet, and I'm tired of waiting, so here's *my* definition of it. This new packet is like Packet 9 in semantics but consists of: - Encrypted data, the output of the selected symmetric-key cipher operating in (XXX) mode. - A 20-octet SHA-1 of the plaintext contents of the packet. Note that if the contents of the encrypted packet is another packet (or packets), the hash runs over the whole of them. I confess that I am concerned about the possible implementation difficulties here, but I'm also confused, because I don't see the problem. Unless the packet is encoded with indefinite length, you know how long the thing is. So you just subtract 20 from the length, and you know how much to hash. I am willing to write in there that if the packet is coded with indefinite length, the last chunk MUST include at least one byte of data and the 20-byte hash. Does this help any implementation problems? Tom? Hal? Werner? Jon From owner-ietf-open-pgp@imc.org Wed Apr 21 20:11:53 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28516 for ; Wed, 21 Apr 1999 20:11:53 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA15073 for ietf-open-pgp-bks; Wed, 21 Apr 1999 16:37:29 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA15068 for ; Wed, 21 Apr 1999 16:37:28 -0700 (PDT) Received: by brickwall.ceddec.com id <42113>; Wed, 21 Apr 1999 19:36:56 -0400 Date: Wed, 21 Apr 1999 19:38:20 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars To: hal@rain.org cc: ietf-open-pgp@imc.org, prz@pgp.com Subject: Re: Phil Zimmermann's suggestion - Implementation? In-Reply-To: <199904210548.WAA00726@226-132.adsl2.avtel.net> Message-Id: <99Apr21.193656edt.42113@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Wed, 21 Apr 1999 hal@rain.org wrote: > I have experimentally implemented the integrated message integrity > check within the encryption/decryption layer. It is not difficult to > handle the 20-byte trailing hash during decryption. I use a circular > buffer in which I put the trailing part of each chunk of decrypted data. > It always has the last 20 decrypted bytes in it. The data is passed > through the hash as we output it from this decryption layer; once we > hit EOF we take the 20 bytes in the buffer and we know those should be > matched against the calculated hash. > > I can't speak for other implementations, but I found doing it this way to > be fairly straightforward. I don't see implementation difficulty as being > a barrier to this approach, or a reason to put the integrity checking > in a pseudo-signature packet. Implementation difficulty of one thing is not a reason, but I could probably come up with hundreds of tiny little things to make it better which would add some value but bloat the code greatly after all were implemented. And we should also fix existing implementation/functional problems such as the lack of a checksum on the new sym-encrypted-sym-key packets so you have to try each key on the ciphertext. You could also create a new packet type, so the EOF would simply signal that you should look for a(n encrypted) new packet type X with 20 bytes of contents which is the hash result. Otherwise, why bother with all this packet nonsense and the CTBs and whatever in the first place? You could theoretically not have any of this and simply search backwards (or include a 2 byte tag) to the beginning of the first signature packet. There is a packet infrastructure. This should be used in one capacity or another. I make an exception for header bytes because these are either of fixed or well defined short lengths. Tacking things on the end can be made to work, but it is not a clean way to do things. We have packets with undefined types which we can add one for this function. We also have a predefined packet which is (symmetrically) encrypted as part of the existing infrastructure which in normal usage contains the same data, except in signed form so we call it a signature packet, but only because it has to this point only contained signatures. To repeat: The reason to put integrity checking in a pseudo-signature packet is because all the necessary code is ALREADY THERE, so instead of adding a 20 byte delay line you only need a new algorithm ID to identify this and an IF() test to bypass the signature validation routine. If something is already there and easily adapted it is silly to create a new layer. Sort of like an old comedy sketch when satellites were first being used to transmit TV where Mr. Smith was in the kitchen, but they flew him across the country so he could appear in Mrs. Smith's living room "live via satellite. You want to duplicate 70% of the existing signature packet infrastructure and add a delay line layer because the MDC function is not a "signature"? I want to make a 2% change to the existing signature routines that would accomplish the same function. How many lines of code did it take for your change? How much slower? Remember to add in the hash computation. And the second hash computation if there is one if the same packet is going to be signed anyway. Care to take a stab at adding that function to my opgp and count the lines as a percentage? And try my technique and count the impact on the code. Or find some reason the function fails to be accomplished by my method. If you could argue that it wouldn't work (or work well, or have security problems) I would say do it your way (except in a unique packet). > The problem with doing it in a signature packet is that it is a > fundamentally different function than signatures. The hash only provides > integrity in the context of an encryption envelope. Logically the > integrity protection is a property of the encryption layer. Doing the > hash without encryption provides no integrity protection. The signature > packet is functionally the wrong place to put it. As I pointed out, the "signature packet" can be called something different, e.g. "verification packet" or "validation packet". Had I known that a MDC feature might be added I would have raised a big stink about using the word "validation" or "verification" instead of "signature" for the packet type in the RFC "just in case we want to do something other than full signatures with it". What is being asked for is merely a proper subset of what happens to create the existing packets. It may be a fundamentally different function, but it happens at exactly the same point in the implmementation and merely omits one step - the actual crypto function to validate the signature. And if you are encrypting, these packets are encrypted along with the message. Normal messages are just the encrypted literal packet. Or encryption applied to a 1-pass validation (was signature) header, the literal packet, and the validation packet. You just have your hash over the V4 hashed material value in addition to the literal packet. Your point about requiring encryption is correct, but you can more easily have implementations reject unencrypted non-signature validation packets as providing no information, i.e. only worry about the validation if the whole came from the encryption. And are you sure that no one is going to want to add the validation or other information provided by the subpackets? (e.g. Date info - you could also add file permissions, length, etc. to the validation packet infrastructure, but not to a fixed 20 byte MAC). From owner-ietf-open-pgp@imc.org Wed Apr 21 20:52:19 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28839 for ; Wed, 21 Apr 1999 20:52:19 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA16276 for ietf-open-pgp-bks; Wed, 21 Apr 1999 17:11:52 -0700 (PDT) Received: from 226-132.adsl2.avtel.net (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA16272 for ; Wed, 21 Apr 1999 17:11:50 -0700 (PDT) Received: (from hal@localhost) by 226-132.adsl2.avtel.net (8.8.7/8.8.7) id RAA02112; Wed, 21 Apr 1999 17:12:21 -0700 Date: Wed, 21 Apr 1999 17:12:21 -0700 From: hal@rain.org Message-Id: <199904220012.RAA02112@226-132.adsl2.avtel.net> To: ietf-open-pgp@imc.org, jon@callas.org Subject: Re: Message Integrity Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Jon Callas, , writes: > I've been waiting for someone else to create this packet, and I'm tired of > waiting, so here's *my* definition of it. This new packet is like Packet 9 > in semantics but consists of: > > - Encrypted data, the output of the selected symmetric-key cipher > operating in (XXX) mode. > > - A 20-octet SHA-1 of the plaintext contents of the packet. Note that if > the contents of the encrypted packet is another packet (or packets), the > hash runs over the whole of them. I did make a proposal for a format, to wit: : The first thing in the packet would be the IV, of a size equal to the : block size of the cipher. It would be followed by the ciphertext, which : would be handled in CFB-n mode, where n is the block size of the cipher. : There would be no special shift or sync operations. : : The plaintext would be prepended with a header consisting of check bytes : so that the proper key can be detected. The check bytes could be two : random bytes, followed by the same two bytes, repeated. : : The plaintext would be followed by a SHA-1 hash of the plaintext data. : This would be checked after decryption and detect message modification : attacks. I proposed to put check bytes before the plaintext so that we can tell when we have the right decryption key. This is important in some cases, notably following symmetric ESK packets which don't have any internal check bytes in them. It is important to make it clear that the SHA-1 hash gets encrypted along with the plaintext data. Otherwise it could leak info about the plaintext. > I confess that I am concerned about the possible implementation > difficulties here, but I'm also confused, because I don't see the problem. > Unless the packet is encoded with indefinite length, you know how long the > thing is. So you just subtract 20 from the length, and you know how much to > hash. I am willing to write in there that if the packet is coded with > indefinite length, the last chunk MUST include at least one byte of data > and the 20-byte hash. Does this help any implementation problems? Tom? Hal? > Werner? As I said, I didn't particularly have difficulties even in the general case, by using an extra buffer. I don't really like putting restrictions on the indefinite length encoding for this case, when we don't have them anywhere else. But if it would really make a difference for other implementations, we could consider it. If we do it, it should be sufficient to require that the whole hash be in one chunk (which will automatically be the last one), not to also require an extra byte of data. This is enough that the decryptor will always know when he is looking at data which is part of the hash. That data is never broken up, and it is always in the final subpacket, which is recognizable in our encoding. Furthermore, this should not be a significant constraint on the encryption end. I wouldn't expect anyone to need to output the hash in more than one packet. You get the hash in one step, and you have all the info you need to put it into a packet. Hal Finney Network Associates, Inc. From owner-ietf-open-pgp@imc.org Wed Apr 21 21:01:38 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28964 for ; Wed, 21 Apr 1999 21:01:38 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA16454 for ietf-open-pgp-bks; Wed, 21 Apr 1999 17:27:12 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA16449 for ; Wed, 21 Apr 1999 17:27:10 -0700 (PDT) Received: from [38.232.7.6] (161.69.48.157) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Wed, 21 Apr 1999 16:28:09 -0800 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <199904220012.RAA02112@226-132.adsl2.avtel.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Apr 1999 17:27:58 -0700 To: hal@rain.org, ietf-open-pgp@imc.org From: Jon Callas Subject: Re: Message Integrity Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 5:12 PM -0700 4/21/1999, hal@rain.org said: I did make a proposal for a format, to wit: : The first thing in the packet would be the IV, of a size equal to the : block size of the cipher. It would be followed by the ciphertext, which : would be handled in CFB-n mode, where n is the block size of the cipher. : There would be no special shift or sync operations. : : The plaintext would be prepended with a header consisting of check bytes : so that the proper key can be detected. The check bytes could be two : random bytes, followed by the same two bytes, repeated. : : The plaintext would be followed by a SHA-1 hash of the plaintext data. : This would be checked after decryption and detect message modification : attacks. I proposed to put check bytes before the plaintext so that we can tell when we have the right decryption key. This is important in some cases, notably following symmetric ESK packets which don't have any internal check bytes in them. It is important to make it clear that the SHA-1 hash gets encrypted along with the plaintext data. Otherwise it could leak info about the plaintext. Mea culpa. Please forgive me. I obviously was on a mental lunch break. Okay -- I thought the hash would be at the end, rather than the front, just for one-passedness. OpenPGP tends to do that, to make it easy to pipeline, and I would have thought that would mean hash at the end. Either way is fine with me. Does anyone else have a preference? As I said, I didn't particularly have difficulties even in the general case, by using an extra buffer. I don't really like putting restrictions on the indefinite length encoding for this case, when we don't have them anywhere else. But if it would really make a difference for other implementations, we could consider it. If we do it, it should be sufficient to require that the whole hash be in one chunk (which will automatically be the last one), not to also require an extra byte of data. This is enough that the decryptor will always know when he is looking at data which is part of the hash. That data is never broken up, and it is always in the final subpacket, which is recognizable in our encoding. Furthermore, this should not be a significant constraint on the encryption end. I wouldn't expect anyone to need to output the hash in more than one packet. You get the hash in one step, and you have all the info you need to put it into a packet. We do have one, that the first indefinite packet must be at least 512 bytes. But nonetheless, no restrictions are better than some, and if the hash is at the front, then there's no problem. My suggestion was just to make it easier for implementors, and if it doesn't, we don't need it. Merely keeping the hash whole is also just fine with me. Jon From owner-ietf-open-pgp@imc.org Wed Apr 21 21:06:39 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29013 for ; Wed, 21 Apr 1999 21:06:39 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA16529 for ietf-open-pgp-bks; Wed, 21 Apr 1999 17:34:09 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA16525 for ; Wed, 21 Apr 1999 17:34:07 -0700 (PDT) Received: from [38.232.7.6] (161.69.48.157) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Wed, 21 Apr 1999 16:35:07 -0800 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <99Apr21.193656edt.42113@brickwall.ceddec.com> References: <199904210548.WAA00726@226-132.adsl2.avtel.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Apr 1999 17:34:58 -0700 To: tzeruch@ceddec.com, hal@rain.org From: Jon Callas Subject: Re: Phil Zimmermann's suggestion - Implementation? Cc: ietf-open-pgp@imc.org, prz@pgp.com Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Tom, again -- unless the data is of indefinite-length, you *know* how long the thing is, and you just subtract 20 from the length you hash. Won't that work? And if indefinite length is a problem, we can always say you can't use indefinite length with a MICed packet. I have no especial love for indefinite length, and to my mind, it's there to provide TLS-like function, which is probably better done with TLS. :-) Jon From owner-ietf-open-pgp@imc.org Wed Apr 21 21:12:19 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29047 for ; Wed, 21 Apr 1999 21:12:18 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA16613 for ietf-open-pgp-bks; Wed, 21 Apr 1999 17:41:06 -0700 (PDT) Received: from 226-132.adsl2.avtel.net (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA16609 for ; Wed, 21 Apr 1999 17:41:05 -0700 (PDT) Received: (from hal@localhost) by 226-132.adsl2.avtel.net (8.8.7/8.8.7) id RAA02217; Wed, 21 Apr 1999 17:41:34 -0700 Date: Wed, 21 Apr 1999 17:41:34 -0700 From: hal@rain.org Message-Id: <199904220041.RAA02217@226-132.adsl2.avtel.net> To: hal@rain.org, ietf-open-pgp@imc.org, jon@callas.org Subject: Re: Message Integrity Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Just to clarify, I did not mean to suggest that the hash would be at the beginning. I agree that it is better to put it at the end, to facilitate one pass operation. What I meant to emphasize was that the hash would be encrypted, along with the plaintext. The input to the encryption would look like: checkbytes plaintext hash This would all be encrypted to form the ciphertext. The packet would then look like: IV ciphertext Sorry if I was unclear. Hal From owner-ietf-open-pgp@imc.org Wed Apr 21 21:17:46 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29090 for ; Wed, 21 Apr 1999 21:17:45 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA16594 for ietf-open-pgp-bks; Wed, 21 Apr 1999 17:40:20 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA16590 for ; Wed, 21 Apr 1999 17:40:18 -0700 (PDT) Received: by brickwall.ceddec.com id <42113>; Wed, 21 Apr 1999 20:39:48 -0400 Date: Wed, 21 Apr 1999 20:41:07 -0400 From: Tom Zerucha X-Sender: nobody@mars To: Jon Callas cc: ietf-open-pgp@imc.org Subject: Re: Message Integrity In-Reply-To: Message-Id: <99Apr21.203948edt.42113@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Wed, 21 Apr 1999, Jon Callas wrote: > My apologies for not jumping in here sooner. > > The consensus that I've seen is against overloading message integrity on > signature packets. We also discussed it in Orlando, and there was great > consensus against it there. I confess that personally, I also question the > wisdom of separating them. Especially if it requires a shared key. Or a well defined "anonymous" sign-only key, which is what I think Adam Back was proposing. > A scheme that has been discussed, and I thought we had a lot of agreement > on even back in Orlando was to solve (1) and (2) with a new encrypted data > packet that used a standard encryption mode and appended a hash at the end. > I've been in discussion with several people who've offered several opinions > on what that hash can or should be, and I believe that the best thing to do > is just make it a SHA-1 hash, as a minimal OpenPGP implementation must > already have SHA-1 in it. No one who's done any work on it has come up with > a different solution that is better. When was the Orlando meeting and who attended? New packet types should be avoided if only because you cannot tell what old implmentations will do with them. They would know that they cannot handle a new algorithm in an existing packet type because they would know it was an encryption packet. I don't think anyone objects to using SHA-1 for the purpose of a MIC. > I really don't like overloading MICs on signature packets. That's a kluge, > and it offends my sensitive architect's aesthetics. OpenPGP already has > quite enough kluges in it. I'd prefer to stomp on a few rather than add > another. Adding in shared keys makes it a worse kluge. I can't see what > goodness comes from a null-signature packet. Throwing 20 bytes at the end of a stream instead of making it a packet is a worse kluge (imho). A standard anonymous key assigned to "MIC validation only" wouldn't make it worse and would allow this functionality in a method that is actually compatable with existing implementations. The goodness is that the code is there (and hopefully tested), so that the information - the hash result (which is already computed for signatures when they are present) is simply inserted without the signature computation step. This takes only a few lines of code in most implementations - the addition of a non-signature algorithm ID. (I would suggest ID 0 since it implied a null algorithm at one point). We could be doing interoperability tests on MICs using existing algorithms next week. > I've been waiting for someone else to create this packet, and I'm tired of > waiting, so here's *my* definition of it. This new packet is like Packet 9 > in semantics but consists of: > > - Encrypted data, the output of the selected symmetric-key cipher > operating in (XXX) mode. Use the existing packet. Specify a new algorithm number. Or will no one ever want to do 3DES, CAST, or IDEA encryption with MIC? Will the REQUIRED algorithms include this new algorithm? Unless you do, this is the only way you are going to get a MIC. If you don't, but want the MIC to be SHOULD, the new packet ID is an old packet (maybe with other fixes) but with appended MIC. And I don't see the new algorithm(s) being adopted that quickly. When is SSL going to have Twofish? > - A 20-octet SHA-1 of the plaintext contents of the packet. Note that if > the contents of the encrypted packet is another packet (or packets), the > hash runs over the whole of them. If you must do this outside of the existing signature packet, then make just this the new packet, potentially with a corresponding 1-pass header packet. > I confess that I am concerned about the possible implementation > difficulties here, but I'm also confused, because I don't see the problem. > Unless the packet is encoded with indefinite length, you know how long the > thing is. So you just subtract 20 from the length, and you know how much to > hash. I am willing to write in there that if the packet is coded with > indefinite length, the last chunk MUST include at least one byte of data > and the 20-byte hash. Does this help any implementation problems? Tom? Hal? > Werner? Every encryption packet since 5.0 in many implementations uses the indefinite length format. So start by assuming every packet in this new format is going to be (for the same reason Encrypters don't want to put the 20 bytes up front - it requries a rewind operation so it won't work on a stream - the old CTB/length had to be rewound to). Your proposal adds a problem to the encryptor since the minimum indefinite length byte is 512, so what if there are 500 bytes left? You could simply make the buffer 512+20 bytes and emit a end packet with the final length, so it isn't that bad, but must be watched for. Further, there is no "validation" routine at the end of the existing decryptors. The good/bad message handler will have to be added and identify the encryption layer as detecting the fault. If you complain that signatures are a different class of validation, I would counter that encryption is a different phylum. But no one has said why the MIC can't simply be in its own packet, so I get the virtual EOF for the encryption stream, then see the MIC packet (i.e. a current signature packet with lots of stuff removed and a different number) and pull 20 bytes from it. So you have a separate packet and packet handler. It would be a MIC layer between the signature and encryption layers. Doing exactly one less step than the signature layer. Let me throw in one more complication. The above formats generally have fixed length, so you know where all the bytes are. Extending to validation packets would make the boundary where the end of message is hard to find. I don't understand how adding a new packet type with a new method (encryption-cum-MIC) with new algorithm IDs and formats which are all still undefined is less a kludge than simply using a new algorithm ID for the new encryption algorithm, and specifying Algorithm 0 and storing the SHA1 result as a plain MPI in the existing structure. Everyone really wants new code, new layers, new specifiers? I don't like writing code that much, and I prefer simplicity. And having existing working, tested code as a base is better than ex-nihilo code. Does anyone have any functional problems (e.g. security holes) with modifying the existing signature packet into a validation packet? From owner-ietf-open-pgp@imc.org Thu Apr 22 04:25:56 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10372 for ; Thu, 22 Apr 1999 04:25:56 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA12073 for ietf-open-pgp-bks; Thu, 22 Apr 1999 00:50:29 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA12068 for ; Thu, 22 Apr 1999 00:50:21 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id JAA26587 for ietf-open-pgp@imc.org; Thu, 22 Apr 1999 09:51:17 +0200 (MET DST) Received: (qmail 10477 invoked from network); 22 Apr 1999 07:49:45 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 22 Apr 1999 07:49:45 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10aECr-0002Tm-00; Thu, 22 Apr 1999 09:47:33 +0200 Date: Thu, 22 Apr 1999 09:47:33 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: new approach to MDCs: single shared private key Message-ID: <19990422094732.D9510@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904211307.OAA04701@server.eternity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i In-Reply-To: <199904211307.OAA04701@server.eternity.org>; from Adam Back on Wed, Apr 21, 1999 at 02:07:54PM +0100 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Adam Back writes: > all we have to do is publish and agree upon a minimal sized > RSA public and private key and publish it. But not before Sep 20th, 2000. Or we would have to make it optional. -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Thu Apr 22 04:50:26 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10496 for ; Thu, 22 Apr 1999 04:50:25 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA12513 for ietf-open-pgp-bks; Thu, 22 Apr 1999 01:20:20 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA12509 for ; Thu, 22 Apr 1999 01:20:09 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id KAA29853 for ietf-open-pgp@imc.org; Thu, 22 Apr 1999 10:21:01 +0200 (MET DST) Received: (qmail 10579 invoked from network); 22 Apr 1999 08:16:08 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 22 Apr 1999 08:16:08 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10aEcO-0002Tx-00; Thu, 22 Apr 1999 10:13:56 +0200 Date: Thu, 22 Apr 1999 10:13:56 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Message Integrity Message-ID: <19990422101355.E9510@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i In-Reply-To: ; from Jon Callas on Wed, Apr 21, 1999 at 04:24:46PM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Jon Callas writes: > hash. I am willing to write in there that if the packet is coded with > indefinite length, the last chunk MUST include at least one byte of data > and the 20-byte hash. Does this help any implementation problems? Tom? Hal? No, it would make thinks even more worse. In my implementation the encryption layer does not know about things like packet length or wehter a packet uses partial length headers. Requiring that the last chunk must be at least 20 bytes would need some special hacks to allow it. There is an explicit statement, that the last chunk may even have a length of zero. I'd prefer an extra MIC packet which can be handled nearly the same as a signature packet and has the advantage of easier implementation (no delay line), usable with 64 bit blocksizes too, extendable to be used for file attributes (although I think, this has to go to the literal data packet). However, to come to a solution we should use the IV|checkbytes|plaintext|SHA1 proposal and assign a new packet type to it (and add a version number just in case we want to change it again). How do we handle secret key material encryption with 128 bit blocksizes? Increase the IV in the packet to the blocksize or keep it at 8 bytes? -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Thu Apr 22 04:55:52 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10512 for ; Thu, 22 Apr 1999 04:55:51 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA12590 for ietf-open-pgp-bks; Thu, 22 Apr 1999 01:26:33 -0700 (PDT) Received: from mail9.svr.pol.co.uk (mail9.svr.pol.co.uk [195.92.193.22]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA12586 for ; Thu, 22 Apr 1999 01:26:32 -0700 (PDT) Received: from modem-88.cesium.dialup.pol.co.uk ([62.136.27.88] helo=server.eternity.org) by mail9.svr.pol.co.uk with esmtp (Exim 2.12 #1) id 10aEpV-0003yl-00; Thu, 22 Apr 1999 09:27:30 +0100 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id JAA08070; Thu, 22 Apr 1999 09:25:18 +0100 Date: Thu, 22 Apr 1999 09:25:18 +0100 Message-Id: <199904220825.JAA08070@server.eternity.org> From: Adam Back To: tzeruch@ceddec.com CC: jon@callas.org, ietf-open-pgp@imc.org In-reply-to: <99Apr21.203948edt.42113@brickwall.ceddec.com> (message from Tom Zerucha on Wed, 21 Apr 1999 20:41:07 -0400) Subject: Re: Message Integrity Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Tom Zerucha writes: > On Wed, 21 Apr 1999, Jon Callas wrote: > > > My apologies for not jumping in here sooner. > > > > The consensus that I've seen is against overloading message integrity on > > signature packets. We also discussed it in Orlando, and there was great > > consensus against it there. I confess that personally, I also question the > > wisdom of separating them. Especially if it requires a shared key. > > Or a well defined "anonymous" sign-only key, which is what I think Adam > Back was proposing. Yes that was a third proposal, which has the advantage over the other two that it works with out changing old software, and new software could be setup to regonize the defined keys, and display different messages on that basis. I also like Tom's suggestion of using algorithm ID 0 for signature. Adds conotations of "no signature algorithm". Nice. Why don't you try implementing that in your PGP implementation Tom? It should come out as fewer lines, and simpler code than the other method. You should be able to post the patch (export control wise) because it is authentication only. There is a potential problem with shared key, we would need to be absolutely sure that people did not erroneously include certificates made by it in the WoT calculation. Distributing it with trust parameter of 0 might work. It would need to be looked at further wrt the major implementations behaviour. Adam From owner-ietf-open-pgp@imc.org Thu Apr 22 04:59:54 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10523 for ; Thu, 22 Apr 1999 04:59:53 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA12581 for ietf-open-pgp-bks; Thu, 22 Apr 1999 01:26:28 -0700 (PDT) Received: from mail9.svr.pol.co.uk (mail9.svr.pol.co.uk [195.92.193.22]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA12577 for ; Thu, 22 Apr 1999 01:26:26 -0700 (PDT) Received: from modem-88.cesium.dialup.pol.co.uk ([62.136.27.88] helo=server.eternity.org) by mail9.svr.pol.co.uk with esmtp (Exim 2.12 #1) id 10aEpT-0003yl-00; Thu, 22 Apr 1999 09:27:28 +0100 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id JAA08077; Thu, 22 Apr 1999 09:25:51 +0100 Date: Thu, 22 Apr 1999 09:25:51 +0100 Message-Id: <199904220825.JAA08077@server.eternity.org> From: Adam Back To: jon@callas.org CC: ietf-open-pgp@imc.org In-reply-to: (message from Jon Callas on Wed, 21 Apr 1999 16:24:46 -0700) Subject: consensus was not against verification packets (Re: Message Integrity) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Jon Callas writes: > The consensus that I've seen is against overloading message integrity on > signature packets. I disagree. Perhaps you weren't reading. Tom Zerucha and Werner Koch sounded like they were going to try out verification packets. I argued for the approach also. Hal Finney presented the bundled MDC+encrypt approach, and did a trial implementation. Uri Watson at first argued against verification packets based on ease of implementing bundled MDC+enc, but revised that to neutral, viz: Tom wrote: > Uri wrote: > > If you want an MDC, and there is already a place for MDCs, then it should > > go there if the format can be adapted. > > OK, I don't object as strongly any more. I'm neutral now. So I tally that as 3 verify packet, one bundled MDC+encrypt, and one neutral. You breeze in late and call that a concensus for MDC+encrypt? > We also discussed it in Orlando, and there was great consensus > against it there. I wasn't at Orlando. No minutes were ever posted that I discovered. Decisions are supposed to be made on list. > I confess that personally, I also question the wisdom of separating > them. Especially if it requires a shared key. What shared key? PRZ proposed SHA1 not a keyed MAC. Adam -- print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Thu, 22 Apr 1999 13:00:54 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA27562 for ietf-open-pgp-bks; Thu, 22 Apr 1999 09:12:27 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA27558 for ; Thu, 22 Apr 1999 09:12:26 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id MAA06252; Thu, 22 Apr 1999 12:13:16 -0400 Received: from buoy.watson.ibm.com (buoy.watson.ibm.com [9.2.3.94]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id MAA08338; Thu, 22 Apr 1999 12:13:16 -0400 Received: by buoy.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA27242; Thu, 22 Apr 1999 12:13:15 -0400 From: uri Message-Id: <9904221613.AA27242@buoy.watson.ibm.com> Subject: Re: consensus was not against verification packets (Re: Message Integrity) To: aba@dcs.ex.ac.uk (Adam Back) Date: Thu, 22 Apr 1999 12:13:15 -0400 (EDT) Cc: jon@callas.org, ietf-open-pgp@imc.org In-Reply-To: <199904220825.JAA08077@server.eternity.org> from "Adam Back" at Apr 22, 99 09:25:51 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Adam Back says: > Hal Finney presented the bundled MDC+encrypt approach, and did a > trial implementation. > > Uri Watson at first argued against verification packets based on ease > of implementing bundled MDC+enc, but revised that to neutral, viz:... Hmmm, It's Uri BLUMENTHAL (who happens to work at Watson Research Center :-). [Though I'm sure old Thomas Watson would be proud if I were to adopt his family name :-] -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ietf-open-pgp@imc.org Thu Apr 22 13:09:05 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22951 for ; Thu, 22 Apr 1999 13:09:04 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA27518 for ietf-open-pgp-bks; Thu, 22 Apr 1999 09:09:12 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA27514 for ; Thu, 22 Apr 1999 09:09:10 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id MAA08796; Thu, 22 Apr 1999 12:09:52 -0400 Received: from buoy.watson.ibm.com (buoy.watson.ibm.com [9.2.3.94]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id MAA12552; Thu, 22 Apr 1999 12:09:52 -0400 Received: by buoy.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA27212; Thu, 22 Apr 1999 12:09:51 -0400 From: uri Message-Id: <9904221609.AA27212@buoy.watson.ibm.com> Subject: Re: Message Integrity To: wk@isil.d.shuttle.de (Werner Koch) Date: Thu, 22 Apr 1999 12:09:50 -0400 (EDT) Cc: ietf-open-pgp@imc.org In-Reply-To: <19990422101355.E9510@frodo.isil.d.shuttle.de> from "Werner Koch" at Apr 22, 99 10:13:56 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Werner Koch says: > However, to come to a solution we should use the > IV|checkbytes|plaintext|SHA1 > proposal and assign a new packet type to it (and add a version number > just in case we want to change it again). If the above is the *plaintext* - I agree. I personally like implicit IV=0x00...0 and the plaintext prepended with random 128 bits. > How do we handle secret key material encryption with 128 bit > blocksizes? Increase the IV in the packet to the blocksize or keep > it at 8 bytes? NO! With 128-bit cipher you MUST use 128-bit IV. [I understand it's coming across rather strong - but then, how much is your security worth to you?] -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ietf-open-pgp@imc.org Thu Apr 22 13:11:30 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23061 for ; Thu, 22 Apr 1999 13:11:28 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA27840 for ietf-open-pgp-bks; Thu, 22 Apr 1999 09:30:58 -0700 (PDT) Received: from 226-132.adsl2.avtel.net (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA27836 for ; Thu, 22 Apr 1999 09:30:56 -0700 (PDT) Received: (from hal@localhost) by 226-132.adsl2.avtel.net (8.8.7/8.8.7) id JAA03006; Thu, 22 Apr 1999 09:31:33 -0700 Date: Thu, 22 Apr 1999 09:31:33 -0700 From: hal@rain.org Message-Id: <199904221631.JAA03006@226-132.adsl2.avtel.net> To: ietf-open-pgp@imc.org, wk@isil.d.shuttle.de Subject: Re: Message Integrity Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Werner Koch, , writes: > However, to come to a solution we should use the > IV|checkbytes|plaintext|SHA1 > proposal and assign a new packet type to it (and add a version number > just in case we want to change it again). > > How do we handle secret key material encryption with 128 bit > blocksizes? Increase the IV in the packet to the blocksize or keep > it at 8 bytes? I think for consistency and simplicity we should have all IVs be the cipher's blocksize. In the old-style encryption packets this is a necessity, as I pointed out earlier. It also simplifies implementation in that you can just point at the IV in the packet and load it into the cipher. With 8 byte IVs I had to move the 8 bytes into a buffer and zero the other 8 bytes to have a nice 16-byte block of data that I could pass to the encryption algorithm. Hal From owner-ietf-open-pgp@imc.org Thu Apr 22 13:33:34 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23965 for ; Thu, 22 Apr 1999 13:33:33 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA28129 for ietf-open-pgp-bks; Thu, 22 Apr 1999 09:49:56 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA28125 for ; Thu, 22 Apr 1999 09:49:54 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id SAA26573 for ietf-open-pgp@imc.org; Thu, 22 Apr 1999 18:50:56 +0200 (MET DST) Received: (qmail 12262 invoked from network); 22 Apr 1999 16:40:32 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 22 Apr 1999 16:40:32 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10aMUb-00047k-00; Thu, 22 Apr 1999 18:38:25 +0200 Date: Thu, 22 Apr 1999 18:38:25 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Message Integrity Message-ID: <19990422183824.B15537@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <19990422101355.E9510@frodo.isil.d.shuttle.de> <9904221609.AA27212@buoy.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i In-Reply-To: <9904221609.AA27212@buoy.watson.ibm.com>; from uri on Thu, Apr 22, 1999 at 12:09:50PM -0400 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: uri writes: > Werner Koch says: > > However, to come to a solution we should use the > > IV|checkbytes|plaintext|SHA1 > > proposal and assign a new packet type to it (and add a version number > > just in case we want to change it again). > > If the above is the *plaintext* - I agree. I personally like Sure. > implicit IV=0x00...0 and the plaintext prepended with random > 128 bits. So do I, s/IV/random_bytes/ > NO! With 128-bit cipher you MUST use 128-bit IV. [I understand it's So we have to fix it in the RFC (I already implemented it this way). -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Thu Apr 22 13:40:39 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24184 for ; Thu, 22 Apr 1999 13:40:38 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA28261 for ietf-open-pgp-bks; Thu, 22 Apr 1999 09:58:49 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA28257 for ; Thu, 22 Apr 1999 09:58:48 -0700 (PDT) Received: by brickwall.ceddec.com id <42113>; Thu, 22 Apr 1999 12:58:22 -0400 Date: Thu, 22 Apr 1999 12:59:45 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars To: Jon Callas cc: hal@rain.org, ietf-open-pgp@imc.org, prz@pgp.com Subject: Re: Phil Zimmermann's suggestion - Implementation? In-Reply-To: Message-Id: <99Apr22.125822edt.42113@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Wed, 21 Apr 1999, Jon Callas wrote: > Tom, again -- unless the data is of indefinite-length, you *know* how long > the thing is, and you just subtract 20 from the length you hash. Won't that > work? Yes, but the specification says that either packet format is valid and most current implementations use the indefinite length format for any potentially unknown length stream (e.g. encrypt stdin). Ask Hal or someone else how easy it would be to make PGP 6.x do definite length formats by default. I simply asked if the 20 bytes of hash could be put at the front instead of the end (a similar problem since if you have to rewind to put the length in the fields, you could just move a few bytes forward and put the hash data at the beginning). In short, if you have definite length packets, there is probably no penalty for putting the hash at the beginning. > And if indefinite length is a problem, we can always say you can't use > indefinite length with a MICed packet. I have no especial love for > indefinite length, and to my mind, it's there to provide TLS-like function, > which is probably better done with TLS. :-) I don't like them either, but they are there, and are perfectly valid to use for any packet and add this given functionality. If we start to get rid of these, we may as well depricate their use in future releases. And why wouldn't a MIC packet work, i.e. why do the 20 bytes have to be tacked onto the end of the encryption stream without the virtual EOF and one more packet? From owner-ietf-open-pgp@imc.org Thu Apr 22 14:05:56 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25017 for ; Thu, 22 Apr 1999 14:05:55 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA28652 for ietf-open-pgp-bks; Thu, 22 Apr 1999 10:26:12 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA28648 for ; Thu, 22 Apr 1999 10:26:11 -0700 (PDT) Received: by brickwall.ceddec.com id <42113>; Thu, 22 Apr 1999 13:25:47 -0400 Date: Thu, 22 Apr 1999 13:27:10 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars To: Adam Back cc: jon@callas.org, ietf-open-pgp@imc.org Subject: Re: Message Integrity In-Reply-To: <199904220825.JAA08070@server.eternity.org> Message-Id: <99Apr22.132547edt.42113@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Thu, 22 Apr 1999, Adam Back wrote: > I also like Tom's suggestion of using algorithm ID 0 for signature. > Adds conotations of "no signature algorithm". Nice. Why don't you > try implementing that in your PGP implementation Tom? It should come > out as fewer lines, and simpler code than the other method. You > should be able to post the patch (export control wise) because it is > authentication only. There is only one detail. Do we use the DER prefix with the 0 and 1 so it looks like a standard bignum signature, or do we just use the 20 bytes? From owner-ietf-open-pgp@imc.org Thu Apr 22 14:37:08 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26048 for ; Thu, 22 Apr 1999 14:37:05 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA28974 for ietf-open-pgp-bks; Thu, 22 Apr 1999 10:46:55 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA28970 for ; Thu, 22 Apr 1999 10:46:54 -0700 (PDT) Received: by brickwall.ceddec.com id <42113>; Thu, 22 Apr 1999 13:46:31 -0400 Date: Thu, 22 Apr 1999 13:47:47 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars To: Adam Back cc: jon@callas.org, ietf-open-pgp@imc.org Subject: Re: Message Integrity In-Reply-To: <199904220825.JAA08070@server.eternity.org> Message-Id: <99Apr22.134631edt.42113@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Thu, 22 Apr 1999, Adam Back wrote: > I also like Tom's suggestion of using algorithm ID 0 for signature. > Adds conotations of "no signature algorithm". Nice. Why don't you > try implementing that in your PGP implementation Tom? It should come > out as fewer lines, and simpler code than the other method. The patch is now 83 lines affecting 3 files (sigchk sigmak elitmk). I think the DER version would be a few more, and it took less than 30 minutes. I am using a keyid of zero to trigger the MIC mode (internally I derive the algorithm from the keyid, but I could a flag or something else). (Though I need to add a test to switch from "signature" to "MIC"). From owner-ietf-open-pgp@imc.org Thu Apr 22 16:50:09 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28824 for ; Thu, 22 Apr 1999 16:50:09 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA01012 for ietf-open-pgp-bks; Thu, 22 Apr 1999 12:49:59 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01006 for ; Thu, 22 Apr 1999 12:49:58 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id VAA11145 for ietf-open-pgp@imc.org; Thu, 22 Apr 1999 21:51:00 +0200 (MET DST) Received: (qmail 12610 invoked from network); 22 Apr 1999 19:40:46 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 22 Apr 1999 19:40:46 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10aPJ3-0004CE-00; Thu, 22 Apr 1999 21:38:41 +0200 Date: Thu, 22 Apr 1999 21:38:40 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Phil Zimmermann's suggestion - Implementation? Message-ID: <19990422213839.C16112@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <99Apr22.125822edt.42113@brickwall.ceddec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i In-Reply-To: <99Apr22.125822edt.42113@brickwall.ceddec.com>; from tzeruch@ceddec.com on Thu, Apr 22, 1999 at 12:59:45PM -0400 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: tzeruch@ceddec.com writes: > > indefinite length, and to my mind, it's there to provide TLS-like function, > > which is probably better done with TLS. :-) > > I don't like them either, but they are there, and are perfectly valid to And there are really applications for it: What about creating a tar from a large filesystem , encrypt it, put it on tape or CD - Do you really want to use a temporary file of such a size - only to put the hash on the front? I started with GnuPG before I actually knew about OpenPGP and invented an extension to the v3 format to allow encrypting and signing of streams. There are indeed folks who encrypt large amounts of data and they don't want to waste space for temporary files. Conclusion: Partial length headers are absolutely needed. > And why wouldn't a MIC packet work, i.e. why do the 20 bytes have to be > tacked onto the end of the encryption stream without the virtual EOF and > one more packet? And why not define that we put n bytes on the end of the encryption stream and by some lucky coincident these bytes actually look like a signature/MDC packet ;-) -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Thu Apr 22 16:53:51 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28868 for ; Thu, 22 Apr 1999 16:53:50 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA01007 for ietf-open-pgp-bks; Thu, 22 Apr 1999 12:49:58 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01001 for ; Thu, 22 Apr 1999 12:49:54 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id VAA11138 for ietf-open-pgp@imc.org; Thu, 22 Apr 1999 21:50:58 +0200 (MET DST) Received: (qmail 12604 invoked from network); 22 Apr 1999 19:29:02 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 22 Apr 1999 19:29:02 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10aP7g-0004C5-00; Thu, 22 Apr 1999 21:26:56 +0200 Date: Thu, 22 Apr 1999 21:26:56 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Message Integrity Message-ID: <19990422212653.B16112@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904220825.JAA08070@server.eternity.org> <99Apr22.134631edt.42113@brickwall.ceddec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i In-Reply-To: <99Apr22.134631edt.42113@brickwall.ceddec.com>; from tzeruch@ceddec.com on Thu, Apr 22, 1999 at 01:47:47PM -0400 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: tzeruch@ceddec.com writes: > think the DER version would be a few more, and it took less than 30 > minutes. I am using a keyid of zero to trigger the MIC mode (internally I > derive the algorithm from the keyid, but I could a flag or something I'll be ready by tomorrow. For now I also just append the 20 bytes but I think it would make more sense to use a bignum. -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Thu Apr 22 16:54:52 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28945 for ; Thu, 22 Apr 1999 16:54:51 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA01214 for ietf-open-pgp-bks; Thu, 22 Apr 1999 13:02:46 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA01210 for ; Thu, 22 Apr 1999 13:02:44 -0700 (PDT) Received: from [161.69.48.157] (161.69.48.157) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Thu, 22 Apr 1999 12:03:45 -0800 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <19990422183824.B15537@frodo.isil.d.shuttle.de> References: <9904221609.AA27212@buoy.watson.ibm.com>; from uri on Thu, Apr 22, 1999 at 12:09:50PM -0400 <19990422101355.E9510@frodo.isil.d.shuttle.de> <9904221609.AA27212@buoy.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 Apr 1999 12:58:56 -0700 To: Werner Koch , ietf-open-pgp@imc.org From: Jon Callas Subject: Re: Message Integrity Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 9:38 AM -0700 4/22/1999, Werner Koch said: So we have to fix it in the RFC (I already implemented it this way). The RFC needs to be clarified, but the section I quoted before was put there to do it the way you said, with block-length IVs etc. Jon From owner-ietf-open-pgp@imc.org Thu Apr 22 18:43:07 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00098 for ; Thu, 22 Apr 1999 18:43:07 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA02714 for ietf-open-pgp-bks; Thu, 22 Apr 1999 15:10:10 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA02710 for ; Thu, 22 Apr 1999 15:10:08 -0700 (PDT) Received: from [161.69.48.157] (161.69.48.157) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Thu, 22 Apr 1999 14:11:12 -0800 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <19990422212653.B16112@frodo.isil.d.shuttle.de> References: <99Apr22.134631edt.42113@brickwall.ceddec.com>; from tzeruch@ceddec.com on Thu, Apr 22, 1999 at 01:47:47PM -0400 <199904220825.JAA08070@server.eternity.org> <99Apr22.134631edt.42113@brickwall.ceddec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 Apr 1999 15:10:44 -0700 To: Werner Koch , ietf-open-pgp@imc.org From: Jon Callas Subject: Re: Message Integrity Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 12:26 PM -0700 4/22/1999, Werner Koch said: I'll be ready by tomorrow. For now I also just append the 20 bytes but I think it would make more sense to use a bignum. I agree. It makes sense to make it be a bignum. To be clear on this, what are you doing? I presume that this is a V4 signature, with signature type of 0 (binary document), PKALG of 0 (no public-key algorithm), hash algorithm type of the appropriate hash, no subpackets, two hash bytes that duplicate the high-order octets of the hash, and then a single MPI containing the hash. Is this correct? Jon From owner-ietf-open-pgp@imc.org Thu Apr 22 18:44:14 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00109 for ; Thu, 22 Apr 1999 18:44:13 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA02643 for ietf-open-pgp-bks; Thu, 22 Apr 1999 15:01:37 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA02639 for ; Thu, 22 Apr 1999 15:01:34 -0700 (PDT) Received: from [161.69.48.157] (161.69.48.157) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Thu, 22 Apr 1999 14:02:37 -0800 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <199904220825.JAA08077@server.eternity.org> References: (message from Jon Callas on Wed, 21 Apr 1999 16:24:46 -0700) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 Apr 1999 15:00:17 -0700 To: Adam Back From: Jon Callas Subject: Re: consensus was not against verification packets (Re: Message Integrity) Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 1:25 AM -0700 4/22/1999, Adam Back said: Jon Callas writes: > The consensus that I've seen is against overloading message integrity on > signature packets. I disagree. Perhaps you weren't reading. Nope. The consensus that I've seen since late last year is for a new data packet that has a standard encryption mode, be it CFB or CBC, and a hash in it. What I see *now* is that you want to revise that consensus. I've seen arguments as follows: (1) The MIC-signature can ride on existing signature processing. However, it raises the question of how to handle it and public-key signatures too. The issue of wanting both MIC-sigs and PK-sigs and how they interact in a single message needs to be looked at, especially if we care about backwards compatibility. It's also allegedly easier to implement this way. I find Tom's report of how easy it is significant. It would be nice if we had someone implement both methods so they can be compared. (By the bye, it is not a goal of this working group to make it easier to tack features on to 2.X, especially now that there are two other implementations out there that can be relatively freely modified -- Tom's and Werner's. One of the OpenPGP principles is to encourage but not require compatibility with 2.X.) (2) There's a desire to deprecate PGP-CFB mode over time, and use either standard CFB or CBC mode. This requires a new data packet anyway, so why not kill two birds with one stone? (3) A MIC-signature computes a hash over the plaintext. The integrated packet computes it over the actual encrypted content, which is likely to be compressed data, and may also include a real signature. This has the advantage of providing an integrity check on the signature and compression when they're available, as well as the meta-data (mode, filename, etc.) of the literal packet. This is important in the case where a message has been damaged, and you'd like to know it is damaged before you go to the trouble of calculating the signature. It also lets you detect attacks where someone damages a signature packet, or changes unhashed data in it. These are all reasons for MICing data, do we want to lose this property? There's a compromise solution here, which is to make a separate packet type for MICing -- I forget who suggested this -- but if you're going to hash the whole packet, not just its contents, then you lose the ease-of-implementation benefit. > I confess that personally, I also question the wisdom of separating > them. Especially if it requires a shared key. What shared key? PRZ proposed SHA1 not a keyed MAC. You suggested a shared public key. Sorry, I find that a kluge. If we're willing to live with a MIC-signature that has only a hash in it, that's fine. But using a universal public key makes me wince. I'd like to see discussion of the points I laid out above. When I look at them, it seems to me that the integrated packet is the best solution. Feel free to change my mind on it. Jon From owner-ietf-open-pgp@imc.org Thu Apr 22 18:56:09 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00209 for ; Thu, 22 Apr 1999 18:56:08 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA02916 for ietf-open-pgp-bks; Thu, 22 Apr 1999 15:23:55 -0700 (PDT) Received: from 226-132.adsl2.avtel.net (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA02912 for ; Thu, 22 Apr 1999 15:23:54 -0700 (PDT) Received: (from hal@localhost) by 226-132.adsl2.avtel.net (8.8.7/8.8.7) id PAA03806; Thu, 22 Apr 1999 15:24:29 -0700 Date: Thu, 22 Apr 1999 15:24:29 -0700 From: hal@rain.org Message-Id: <199904222224.PAA03806@226-132.adsl2.avtel.net> To: aba@dcs.ex.ac.uk, tzeruch@ceddec.com Subject: Re: Message Integrity Cc: ietf-open-pgp@imc.org, jon@callas.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: tzeruch@ceddec.com writes: > The patch is now 83 lines affecting 3 files (sigchk sigmak elitmk). I > think the DER version would be a few more, and it took less than 30 > minutes. I am using a keyid of zero to trigger the MIC mode (internally I > derive the algorithm from the keyid, but I could a flag or something > else). Do you have a sense of how big the code would be to implement the MDC in the encryption layer as originally proposed? Possibly if the MDC were in a separate packet so you could identify it easily? Hal From owner-ietf-open-pgp@imc.org Thu Apr 22 18:56:14 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00222 for ; Thu, 22 Apr 1999 18:56:13 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA02908 for ietf-open-pgp-bks; Thu, 22 Apr 1999 15:23:11 -0700 (PDT) Received: from 226-132.adsl2.avtel.net (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA02904 for ; Thu, 22 Apr 1999 15:23:09 -0700 (PDT) Received: (from hal@localhost) by 226-132.adsl2.avtel.net (8.8.7/8.8.7) id PAA03802; Thu, 22 Apr 1999 15:23:42 -0700 Date: Thu, 22 Apr 1999 15:23:42 -0700 From: hal@rain.org Message-Id: <199904222223.PAA03802@226-132.adsl2.avtel.net> To: aba@dcs.ex.ac.uk, tzeruch@ceddec.com Subject: Re: Message Integrity Cc: ietf-open-pgp@imc.org, jon@callas.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I still don't see that the signature packets are a very natural or comfortable place to put this data. We would probably use one-pass signature packets for this so that the MDC (MIC) can go at the end and the encryptor doesn't need to buffer up all the data. The format of a one-pass signature is: - version number - signature type - hash algorithm - public key algorithm - signing keyid (8 bytes) - nesting flag Most of these fields are not relevant for the MDC. We need to put a magic value into one of them (Tom is looking for all-zero keyid, others had suggested using a zero public key algorithm). The others are really not meaningful. The signature type with all its variations is not relevant; hash algorithm is unnecessary, a fixed hash algorithm is fine; public key algorithm and signing keyid aren't meaningful; nesting flag is not relevant either. Likewise, the signature packet fields are equally meaningless: - version number - length of hashed portion (must be 5) - signature type - signature creation time - key id of signer - public key algorithm - hash algorithm - left 16 bits of hash - Multi Precision Integer holding the signature Again, we have signature type, key id, public key and hash algorithms, all unnecessary or irrelevant. We have a timestamp, also inappropriate for an MDC (which is inherently a transient concept). We have the left 16 bits of the hash! Will we keep that, when we're going to be storing the hash itself in the MPI signature field? It's just going to be a copy of two bytes of the hash. Utterly pointless. And last we have the signature itself, which is the only meaningful piece of data in this entire packet, since that is where we will put the hash. We have to agree on how to encode the hash, presumably as an MPI, which implies special treatment of leading zeros. Or maybe we'll just shove the 20 bytes in there and have done with it since we're misusing the rest of the packet so badly anyway. Looking over these comments, it's clear that these packets are completely inappropriate for the use to which we are proposing to put them. This solution is a real kludge. If we absolutely, positively had to put this data into signature packets, maybe we should create a new version of the packets and use that. Or better still, use new packet types. Make the prefix packet be just a flag that the following data will be checked with a MIC. Then make the trailer packet just have the MIC in it. Simple and clean, unlike the above. Or even better, use a special encryption packet to indicate that there is a MIC (MDC) following, and a special MIC packet to hold it following the encryption packet, as Werner proposed. It is not too different from the original idea and if it would help with the implementation it seems like a reasonable method. Hal From owner-ietf-open-pgp@imc.org Thu Apr 22 19:52:08 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00586 for ; Thu, 22 Apr 1999 19:52:04 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA03724 for ietf-open-pgp-bks; Thu, 22 Apr 1999 16:19:28 -0700 (PDT) Received: from na-ex-bridge2.nai.com (na-ex-bridge2.nai.com [208.228.228.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA03720 for ; Thu, 22 Apr 1999 16:19:28 -0700 (PDT) Received: by na-ex-bridge2.nai.com with Internet Mail Service (5.5.2448.0) id <2TXAZQ44>; Thu, 22 Apr 1999 16:25:10 -0700 Message-ID: <6BC5E520D4A4D11184A200A0C99D8FBE02EF2EB9@ca-exchange1.nai.com> From: "Salzman, Noah" To: ietf-open-pgp@imc.org Subject: typo? Date: Thu, 22 Apr 1999 16:22:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Sorry to interrupt the new invigorated discussion, but is this a typo? ------------ The CRC is computed by using the generator 0x864CFB and an initialization of 0xB704CE. 6.1. An Implementation of the CRC-24 in "C" #define CRC24_INIT 0xb704ceL #define CRC24_POLY 0x1864cfbL ------------ The generator constant in the code sample has a "1" that is not in the preceding text. --Noah-- From owner-ietf-open-pgp@imc.org Thu Apr 22 20:02:01 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00699 for ; Thu, 22 Apr 1999 20:01:59 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA03844 for ietf-open-pgp-bks; Thu, 22 Apr 1999 16:28:01 -0700 (PDT) Received: from praseodumium (praseodumium.btinternet.com [194.73.73.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA03840 for ; Thu, 22 Apr 1999 16:28:00 -0700 (PDT) Received: from [195.99.63.78] (helo=server.eternity.org) by praseodumium with esmtp (Exim 2.05 #1) id 10aSqS-00024S-00; Fri, 23 Apr 1999 00:25:24 +0100 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id AAA13142; Fri, 23 Apr 1999 00:06:07 +0100 Date: Fri, 23 Apr 1999 00:06:07 +0100 Message-Id: <199904222306.AAA13142@server.eternity.org> From: Adam Back To: tzeruch@ceddec.com CC: jon@callas.org, ietf-open-pgp@imc.org In-reply-to: <99Apr22.134631edt.42113@brickwall.ceddec.com> (tzeruch@ceddec.com) Subject: Re: Message Integrity Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Tom writes: > On Thu, 22 Apr 1999, Adam Back wrote: > > > I also like Tom's suggestion of using algorithm ID 0 for signature. > > Adds conotations of "no signature algorithm". Nice. Why don't you > > try implementing that in your PGP implementation Tom? It should come > > out as fewer lines, and simpler code than the other method. > > The patch is now 83 lines affecting 3 files (sigchk sigmak elitmk). I > think the DER version would be a few more, and it took less than 30 > minutes. Cool. > I am using a keyid of zero to trigger the MIC mode (internally I > derive the algorithm from the keyid, but I could a flag or something > else). Wasn't keyid of all 0s already reserved for another purpose. I seem to recall a discussion by Hal and others some time back about reducing the number of keyid bits to reduce identity leakage. Ultimately this came down to having an empty keyid, where the recipient would have to check on private keys on their key ring sequentialy to discover which one to use. I don't know the outcome of this old discussion. Did the variable length keyid go beyond discussions? Don't you use the algorithm ID (1 = RSA, 2 etc) as the item in the switch statement in your existing code? Couldn't you then use alg ID = 0 for no sig? Adam From owner-ietf-open-pgp@imc.org Thu Apr 22 20:19:20 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00804 for ; Thu, 22 Apr 1999 20:19:19 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA04051 for ietf-open-pgp-bks; Thu, 22 Apr 1999 16:44:48 -0700 (PDT) Received: from 226-132.adsl2.avtel.net (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA04047 for ; Thu, 22 Apr 1999 16:44:47 -0700 (PDT) Received: (from hal@localhost) by 226-132.adsl2.avtel.net (8.8.7/8.8.7) id QAA04511; Thu, 22 Apr 1999 16:45:25 -0700 Date: Thu, 22 Apr 1999 16:45:25 -0700 From: hal@rain.org Message-Id: <199904222345.QAA04511@226-132.adsl2.avtel.net> To: ietf-open-pgp@imc.org, Noah_Salzman@NAI.com Subject: Re: typo? Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Noah - I think that is OK. CRC24_POLY is used in the sample code as: if (crc & 0x1000000) crc ^= CRC24_POLY; So the extra "1" in CRC24_POLY is actually there to clear the "1" in the crc variable. It might have been clearer to define CRC24_POLY without the "1" and then to do if (crc & 0x1000000) crc ^= CRC24_POLY | 0x1000000; or even if (crc & 0x1000000) { crc &= 0xffffff; crc ^= CRC24_POLY; } but it works out the same. Hal From owner-ietf-open-pgp@imc.org Thu Apr 22 20:50:19 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00945 for ; Thu, 22 Apr 1999 20:50:17 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA04458 for ietf-open-pgp-bks; Thu, 22 Apr 1999 17:18:13 -0700 (PDT) Received: from ignem.omnigroup.com (root@omnigroup.com [198.151.161.40]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04454 for ; Thu, 22 Apr 1999 17:18:12 -0700 (PDT) Received: from reason.omnigroup.com (reason [198.151.161.25]) by ignem.omnigroup.com (8.8.5/8.8.5) with SMTP id RAA07312; Thu, 22 Apr 1999 17:19:22 -0700 (PDT) Message-Id: <199904230019.RAA07312@ignem.omnigroup.com> Received: by reason.omnigroup.com (NX5.67g/NX3.0X) id AA16307; Thu, 22 Apr 99 17:19:29 -0700 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.2mach v148) In-Reply-To: <6BC5E520D4A4D11184A200A0C99D8FBE02EF2EB9@ca-exchange1.nai.com> X-Nextstep-Mailer: Mail 4.2mach (Enhance 2.1) Received: by NeXT.Mailer (1.148) From: William Lewis Date: Thu, 22 Apr 99 17:19:28 -0700 To: "Salzman, Noah" Subject: Re: typo? Cc: ietf-open-pgp@imc.org References: <6BC5E520D4A4D11184A200A0C99D8FBE02EF2EB9@ca-exchange1.nai.com> X-Pgp-Id: 0x27F772C1 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: You wrote: > The generator constant in the code sample has a "1" that is not in the > preceding text. CRC polynomials are usually written without the leading term. Whether the constant in the code has the term is an implementation detail --- for example, if the CRC width is the same as the word width (e.g. a CRC-32), it's easier and faster not to write it that way. I'd recommend ftp://ftp.rocksoft.com/clients/rocksoft/papers/crc_v3.txt as an introduction to theoretical and practical aspects of CRCs. From owner-ietf-open-pgp@imc.org Thu Apr 22 21:01:31 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01043 for ; Thu, 22 Apr 1999 21:01:30 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA04623 for ietf-open-pgp-bks; Thu, 22 Apr 1999 17:27:21 -0700 (PDT) Received: from tungsten (tungsten.btinternet.com [194.73.73.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04619 for ; Thu, 22 Apr 1999 17:27:20 -0700 (PDT) Received: from [195.99.63.79] (helo=server.eternity.org) by tungsten with esmtp (Exim 2.05 #1) id 10aTov-0002qq-00; Fri, 23 Apr 1999 01:27:53 +0100 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id BAA13503; Fri, 23 Apr 1999 01:26:34 +0100 Date: Fri, 23 Apr 1999 01:26:34 +0100 Message-Id: <199904230026.BAA13503@server.eternity.org> From: Adam Back To: jon@callas.org CC: ietf-open-pgp@imc.org In-reply-to: (message from Jon Callas on Thu, 22 Apr 1999 15:00:17 -0700) Subject: Re: consensus was not against verification packets (Re: Message Integrity) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Jon writes: > The consensus that I've seen since late last year is for a new data > packet that has a standard encryption mode, be it CFB or CBC, and a > hash in it. I did a little grepping of last years open-pgp traffic. The posts discussing MDCs are below. None of them mentions this idea. I asked at the time if anyone at PGP planned to fix MDCs and Hal responded: Hal wrote in Jul 98: > There is no plan to add MAC or other lightweight signatures to PGP 6.0. > That may go into a future version. As far as I recall Hal's recent posting of PRZs "hash inside enc envelope" was the first time I have seen that proposal. As none of the posts to the list mention the proposal in question I can't see how you can claim there was a concensus for it on list "last year". I have no idea what was discussed at the Orlando meeting, because as I said, no minutes were ever published that I found. These were all made around July 1998: Tom: > Unless they do something nonsensical, it would be easy to extend 1.0 - for > example, a signature algorithm of 0 means the message digest is stored in > the clear (maybe as a MPI), and leave the rest of the format alone. Old > implmentations should fail gracefully with "unknown signature algorithm". > The onepass signature header lets the "MAC" be at the end yet insures that > someone can't just delete the "MAC". Adam in response to Toms above proposal: > The most important aspect of this, as Tom suggested, is that > openPGP-1.0 should gracefully cope with this (and other similar) > unknown signature packets, by still emitting plaintext. > > I suggest that we consider reserving a packet number for MDC/Integrity > check purposes. Jon in response to Adam: > If you can design something that is wholly backwards-compatible, it'll be > trivial to put it in 1.1 or simple document it as an extension. Not being > in 1.0 won't be an issue > > If you can't design something backward compatible, then it's too late to go > in 1.0. Either way, it doesn't make it. So after arguing against the idea of reserving an MDC packet in Jul 98, and saying it'll be trivial to make something backwards compatible with 1.0 without doing so, you then argue the reverse now, when Tom, Werner and I bring up Tom's earlier proposal for this which would have benefited from reserving a verification packet ID. Adam -- print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Thu, 22 Apr 1999 21:09:53 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA04685 for ietf-open-pgp-bks; Thu, 22 Apr 1999 17:31:18 -0700 (PDT) Received: from na-ex-bridge2.nai.com (na-ex-bridge2.nai.com [208.228.228.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04680 for ; Thu, 22 Apr 1999 17:31:15 -0700 (PDT) Received: by na-ex-bridge2.nai.com with Internet Mail Service (5.5.2448.0) id <2TXAZSXS>; Thu, 22 Apr 1999 17:37:00 -0700 Message-ID: <6BC5E520D4A4D11184A200A0C99D8FBE02EF2ED9@ca-exchange1.nai.com> From: "Salzman, Noah" To: William Lewis , "Salzman, Noah" Cc: ietf-open-pgp@imc.org Subject: RE: typo? Date: Thu, 22 Apr 1999 17:34:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Thank very much, I understand now. --Noah-- > -----Original Message----- > From: William Lewis [mailto:wiml@omnigroup.com] > Sent: Thursday, April 22, 1999 5:19 PM > To: Salzman, Noah > Cc: ietf-open-pgp@imc.org > Subject: Re: typo? > > > You wrote: > > The generator constant in the code sample has a "1" that is > not in the > > preceding text. > > CRC polynomials are usually written without the leading term. > Whether the > constant in the code has the term is an implementation detail > --- for > example, if the CRC width is the same as the word width (e.g. > a CRC-32), it's > easier and faster not to write it that way. > > I'd recommend > ftp://ftp.rocksoft.com/clients/rocksoft/papers/> crc_v3.txt as > > an introduction to theoretical and practical > aspects of CRCs. > From owner-ietf-open-pgp@imc.org Thu Apr 22 21:22:11 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01144 for ; Thu, 22 Apr 1999 21:22:09 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA04924 for ietf-open-pgp-bks; Thu, 22 Apr 1999 17:49:10 -0700 (PDT) Received: from neodymium (neodymium.btinternet.com [194.73.73.83]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04920 for ; Thu, 22 Apr 1999 17:49:08 -0700 (PDT) Received: from [195.99.63.79] (helo=server.eternity.org) by neodymium with esmtp (Exim 2.05 #1) id 10aU8D-0005NP-00 for ietf-open-pgp@imc.org; Fri, 23 Apr 1999 01:47:50 +0100 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id BAA13738; Fri, 23 Apr 1999 01:49:10 +0100 Date: Fri, 23 Apr 1999 01:49:10 +0100 Message-Id: <199904230049.BAA13738@server.eternity.org> From: Adam Back To: ietf-open-pgp@imc.org Subject: old MDC discussions Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: The old discussions, should anyone wish to review them, can be found by starting at the following links in sequence: http://www.imc.org/ietf-open-pgp/mail-archive/msg01746.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01748.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01754.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01756.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01757.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01758.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01763.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01770.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01771.html From msg01771.html particularly, we have a description of the same proposal that was made recently, and Jon proposing _not_ reserving explicit packet IDs for it as requested in a message a few previous. Jon: > Adam Back: > > I didn't suggest that MDCs go into 1.0 in the last round. What I > suggested was that the following be verified: > > that when processing a message containing signatures a 1.0 > implementation MUST continue to emit plaintext (ie fail > gracefully) in the presence of signature algorithms it does > not recognise. > > this readily allows adding MDCs or other signature algorithms in > version 1.1, and ensures backwards compatibility is possible. > > Sure, but I don't think we need to add anything. If someone writes an > implementation that (for instance) bus errors when it receives an algorithm > encrypted with AES (which I pick because we all know it's going to go in, > but it isn't there now), then the implementation is clearly broken. > > Signatures are different because there's a meaningful thing to do -- emit > plaintext, and shrug over the sig -- which is a little different than the > crypto, or compression, or whatever. But nonetheless, there are many > failure and partial failure conditions, and an implementation that doesn't > fail gracefully is broken. > > This spec isn't a how-to-program manual, it's a format specification. By > necessity it tells you a lot of what to do with the format, but there's a > lot that this document can't tell an implementor. > > Jon and some even older discussions: http://www.imc.org/ietf-open-pgp/mail-archive/msg01112.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01113.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01115.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01117.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01114.html Adam -- print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Thu, 22 Apr 1999 21:46:57 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA05125 for ietf-open-pgp-bks; Thu, 22 Apr 1999 18:14:34 -0700 (PDT) Received: from 226-132.adsl2.avtel.net (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA05121 for ; Thu, 22 Apr 1999 18:14:33 -0700 (PDT) Received: (from hal@localhost) by 226-132.adsl2.avtel.net (8.8.7/8.8.7) id SAA05936; Thu, 22 Apr 1999 18:15:08 -0700 Date: Thu, 22 Apr 1999 18:15:08 -0700 From: hal@rain.org Message-Id: <199904230115.SAA05936@226-132.adsl2.avtel.net> To: aba@dcs.ex.ac.uk, jon@callas.org Subject: Re: consensus was not against verification packets (Re: Message Integrity) Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Adam Back, , writes: > Jon writes: > > The consensus that I've seen since late last year is for a new data > > packet that has a standard encryption mode, be it CFB or CBC, and a > > hash in it. > > I did a little grepping of last years open-pgp traffic. The posts > discussing MDCs are below. None of them mentions this idea. Actually, there was some mention of it, but it did not use the term MDC so your grep did not find it. Take a look at http://www.imc.org/ietf-open-pgp/mail-archive/msg01670.html where you are responding to an earlier comment by Jon: : > I thought the consensus was that with 1.X we would look at adding : > some form of integrity check, perhaps with a new type of encrypted : > data packet. : : The reason I am keen on adding a MAC is a) it is broken (badly in my : view) and needs fixing; b) it is easy to fix; c) it does not affect : backwards compatibility. : : I prefer a digest packet inside the encrypted envelope (at the end of : the plaintext to aid one-pass processing), rather than a MAC for : reasons of simplicity (people already have code to compute and emit : digest packets for the available hashes). It is probably easiest to : define the digest packet as a signature packet. (This can then borrow : the one pass packets etc from existing signature parts). Not so different from the present discussion... Hal From owner-ietf-open-pgp@imc.org Thu Apr 22 22:57:54 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03368 for ; Thu, 22 Apr 1999 22:57:52 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA10373 for ietf-open-pgp-bks; Thu, 22 Apr 1999 19:25:25 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA10366 for ; Thu, 22 Apr 1999 19:25:24 -0700 (PDT) Received: by brickwall.ceddec.com id <42113>; Thu, 22 Apr 1999 22:25:03 -0400 Date: Thu, 22 Apr 1999 22:26:17 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars To: hal@rain.org cc: aba@dcs.ex.ac.uk, ietf-open-pgp@imc.org, jon@callas.org Subject: Re: Message Integrity In-Reply-To: <199904222224.PAA03806@226-132.adsl2.avtel.net> Message-Id: <99Apr22.222503edt.42113@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Thu, 22 Apr 1999 hal@rain.org wrote: > tzeruch@ceddec.com writes: > > The patch is now 83 lines affecting 3 files (sigchk sigmak elitmk). I > > think the DER version would be a few more, and it took less than 30 > > minutes. I am using a keyid of zero to trigger the MIC mode (internally I > > derive the algorithm from the keyid, but I could a flag or something > > else). > > Do you have a sense of how big the code would be to implement the MDC in > the encryption layer as originally proposed? Possibly if the MDC were > in a separate packet so you could identify it easily? My estimate would be over 300 lines (which for me is about 6%). If the MDC were in a separate packet (with an indicator at front similar to the 1 pass signature packet, or the MDC has to go up front), it would not be too much worse than my current changes. Although it would be a new packet type, it would be fall into the structure in parallel with the signatures, i.e. where I have signatures started, I could add an else if (MDC_PRESENT) and fire up the same hashing routines. Basically instead of adding algorithm 0 to the signature generator/checks, I add a new MDC packet type where the signature packets are processed. Let me give it a try (probably this weekend), and see. I will use my own packet format and IDs. So I would need either the MDC itself or an indicator packet *before* the MDC-ed stream for this to be easy. Functionally this is the elstrippo signature packet for MDC/MICs with a different ID. But it should be easier to parse. From owner-ietf-open-pgp@imc.org Thu Apr 22 23:00:57 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03387 for ; Thu, 22 Apr 1999 23:00:56 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA11303 for ietf-open-pgp-bks; Thu, 22 Apr 1999 19:31:01 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA11296 for ; Thu, 22 Apr 1999 19:31:00 -0700 (PDT) Received: by brickwall.ceddec.com id <42113>; Thu, 22 Apr 1999 22:30:39 -0400 Date: Thu, 22 Apr 1999 22:31:53 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars To: Adam Back cc: jon@callas.org, ietf-open-pgp@imc.org Subject: Re: Message Integrity In-Reply-To: <199904222306.AAA13142@server.eternity.org> Message-Id: <99Apr22.223039edt.42113@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Thu, 22 Apr 1999, Adam Back wrote: > > I am using a keyid of zero to trigger the MIC mode (internally I > > derive the algorithm from the keyid, but I could a flag or something > > else). > > Wasn't keyid of all 0s already reserved for another purpose. I seem > to recall a discussion by Hal and others some time back about reducing > the number of keyid bits to reduce identity leakage. Ultimately this > came down to having an empty keyid, where the recipient would have to > check on private keys on their key ring sequentialy to discover which > one to use. This was for encryption, so you could place the message in a public forum without identifying the recipient. For signing it would be less practical, and I don't know if anyone really implements it. (i.e. you would have to keep the public keys private so only the group could verify the signature and know who signed it). The algorithm ID would be zero too. My implementation selects the signature algorithm based on key id, but that could be fixed too, though I would need to alter the command line and maybe some API parameters. > Don't you use the algorithm ID (1 = RSA, 2 etc) as the item in the > switch statement in your existing code? Couldn't you then use alg ID > = 0 for no sig? Basically this is what I do, but I have it in the form of if-elseif-else type things instead of case statements. From owner-ietf-open-pgp@imc.org Fri Apr 23 01:55:55 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04756 for ; Fri, 23 Apr 1999 01:55:54 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA26263 for ietf-open-pgp-bks; Thu, 22 Apr 1999 22:19:54 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA26259 for ; Thu, 22 Apr 1999 22:19:52 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id HAA11766 for ietf-open-pgp@imc.org; Fri, 23 Apr 1999 07:20:59 +0200 (MET DST) Received: (qmail 13049 invoked from network); 23 Apr 1999 04:33:34 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 23 Apr 1999 04:33:34 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10aXcj-0004F6-00; Fri, 23 Apr 1999 06:31:33 +0200 Date: Fri, 23 Apr 1999 06:31:33 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Message Integrity Message-ID: <19990423063132.A16309@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <99Apr22.134631edt.42113@brickwall.ceddec.com>; <199904220825.JAA08070@server.eternity.org> <99Apr22.134631edt.42113@brickwall.ceddec.com> <19990422212653.B16112@frodo.isil.d.shuttle.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i In-Reply-To: ; from Jon Callas on Thu, Apr 22, 1999 at 03:10:44PM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Jon Callas writes: > I presume that this is a V4 signature, with signature type of 0 (binary > document), PKALG of 0 (no public-key algorithm), hash algorithm type of the > appropriate hash, no subpackets, two hash bytes that duplicate the Hmmm, I think I have subpackets but I can drop them. > high-order octets of the hash, and then a single MPI containing the hash. > Is this correct? Yes. And I put a onepass signature packet in front with a keyid of all 0 and a pubkey algo of 0; it is not required for decryption. -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Fri Apr 23 10:38:12 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18948 for ; Fri, 23 Apr 1999 10:38:11 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA11150 for ietf-open-pgp-bks; Fri, 23 Apr 1999 06:47:10 -0700 (PDT) Received: from stax05.cubis.de (proxy.cubis.de [194.112.101.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA11118; Fri, 23 Apr 1999 06:45:37 -0700 (PDT) Received: from secunet.de (huehnlein.cubis.de [10.0.129.33]) by stax05.cubis.de (8.7.5/8.7.3) with ESMTP id PAA02374; Fri, 23 Apr 1999 15:04:16 +0200 (MET DST) Message-ID: <37207D2C.B78F8881@secunet.de> Date: Fri, 23 Apr 1999 15:01:16 +0100 From: "Detlef =?iso-8859-1?Q?H=FChnlein?=" Organization: Secunet GmbH - The Trust Company X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: "cqre@secunet.de" Subject: Final Call for Papers - CQRE [Secure] networking Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id GAA11119 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hallo! Please accept my sincere appologies, if you receive this Final Call for Papers multiple times. The mail is just to remind you that there are only !!! THREE !!! more weeks until the deadline for submission of extended abstracts on May 14th, 1999. Recent news: * best paper award at CQRE * publication of proceedings in Springer's LNCS * first invited speakers: - Stephen Kent (GTE) - Bruce Schneier (Counterpane) - Helena Handschuh (Gemplus/ENST) Best regards Detlef Huehnlein *************************************************************** Final Call for Papers CQRE [Secure] Congress & Exhibition Duesseldorf, Germany, Nov. 30 - Dec. 2 1999 --------------------------------------------------------------- provides a new international forum covering most aspects of information security with a special focus to the role of information security in the context of rapidly evolving economic processes. --------------------------------------------------------------- Deadline for submission of extended abstracts: May 14, 1999 CQRE - website: http://www.cqre.net (under construction) CfP - at: http://www.secunet.de/forum/cqre.html mailing-list: send mailto:cqre@secunet.de (where the subject is "subscribe" without paranthesis) *************************************************************** The "CQRE [Secure] networking" provides a new international forum giving a close-up view on information security in the context of rapidly evolving economic processes. The unprecedented reliance on computer technology transformed the previous technical side-issue "information security" to a management problem requiring decisions of strategic importance. Hence, the targeted audience represents decision makers from government, industry, commercial, and academic communities. If you are developing solutions to problems relating to the protection of your country´s information infrastructure or a commercial enterprise, consider submitting a paper to the "CQRE [Secure] networking" conference. We are looking for papers and panel discussions covering: * electronic commerce - new business processes - secure business transactions - online merchandising - electronic payment / banking - innovative applications * network security - virtual private networks - security aspects in internet utilization - security aspects in multimedia applications - intrusion detection systems * legal aspects - digital signatures acts - privacy and anonymity - crypto regulation - liability * corporate security - access control - secure teleworking - enterprise key management - IT-audit - risk / disaster management - security awareness and training - implementation, accreditation, and operation of secure systems in a government, business, or industry environment * security technology - cryptography - public key infrastructures - chip card technology - biometrics * trust management - evaluation of products and systems - international harmonization of security evaluation criterias * standardization * future perspectives Any other contribution addressing the involvement of IT security in economic processes will be welcome. Authors are invited to submit an extended abstract of their contribution to the program chair. The submissions should be original research results, survey articles or "high quality" case studies and position papers. Product advertisements are welcome for presentation, but will not be considered for the proceedings. Manuscripts must be in English, and should not be more than 2.000 words. The extended abstracts should be in a form suitable for anonymous review, with no author names, affiliations, acknowledgements or obvious references. Contributions must not be submitted in parallel to any conference or workshop that has proceedings. Separately, an abstract of the paper with no more than 200 words and with title, name and addresses (incl. an E-mail address) of the authors shall be submitted. In the case of multiple authors the contacting author must be clearly identified. We strongly encourage electronic submission in Postscript format. The submissions must be in 11 pt format, use standard fonts or include the necessary fonts. Proposals for panel discussions should also be sent to the program chair. Panels of interest include those that present alternative/controversial viewpoints or those that encourage lively discussions of relevant issues. Panels that are collections of unrefereed papers will not be considered. Panel proposals should be a minimum of one page describing the subject matter, the appropriateness of the panel for this conference and should identify participants and their respective viewpoints. best paper award: This award will be presented at CQRE to the authors of the best paper to be selected by the program committee. mailing list/ web-site: If you want to receive emails with up to date information, please send a brief mail to cqre@secunet.de. You will find this call for papers and further information at http://www.secunet.de/forum/cqre.html. publication: The proceedings will be published by Springer-Verlag in the Lecture Notes of Computer Science (LNCS) Series. The final papers must be prepared as described in http://www.springer.de/comp/lncs/authors.html. important dates: deadline for submission of extended abstracts May 14, 1999 deadline for submission of panel proposals June 1, 1999 notification of acceptance June 25, 1999 deadline for submission of complete papers July 30, 1999 program committee: Johannes Buchmann (TU Darmstadt) Dirk Fox (Secorvo) Walter Fumy (Siemens) Ruediger Grimm (GMD) Helena Handschuh (ENST/Gemplus) Thomas Hoeren (Uni Muenster) Pil Joong Lee (POSTECH) Alfred Menezes (U.o.Waterloo/Certicom) David Naccache (Gemplus) Clifford Neumann (USC) Joachim Posegga (German Telekom) Mike Reiter (Bell Labs) Matt Robshaw (RSA) Richard Schlechter (EU-comm.) Bruce Schneier (Counterpane) Tsuyoshi Takagi (NTT) Yiannis Tsiounis (GTE Labs) Michael Waidner (IBM) Moti Yung (CERTCO) Robert Zuccherato (Entrust) program chair: Rainer Baumgart secunet - Security Networks GmbH Weidenauer Str. 223 - 225 57076 Siegen Germany Tel.: +49-271-48950-15 Fax: +49-271-48950-50 R.Baumgart@secunet.de From owner-ietf-open-pgp@imc.org Fri Apr 23 15:26:54 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25429 for ; Fri, 23 Apr 1999 15:26:53 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA13762 for ietf-open-pgp-bks; Fri, 23 Apr 1999 11:18:36 -0700 (PDT) Received: from mail.replay.com (basement.replay.com [194.109.9.44]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA13758 for ; Fri, 23 Apr 1999 11:18:34 -0700 (PDT) Received: (from remailer@localhost) by mail.replay.com (8.9.2/8.9.2/Replay Associates LLP) id UAA05631; Fri, 23 Apr 1999 20:19:13 +0200 (CEST) Date: Fri, 23 Apr 1999 20:19:13 +0200 (CEST) Message-Id: <199904231819.UAA05631@mail.replay.com> From: Anonymous Comments: This message did not originate from the Sender address above. It was remailed automatically by anonymizing remailer software. Please report problems or inappropriate use to the remailer administrator at . Subject: Re: Message Integrity In-Reply-To: To: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > (4) A V5 signature packet that allows 4-byte lengths. Yet another signature packet version! Is this a scheme to increase S/MIME support? From owner-ietf-open-pgp@imc.org Fri Apr 23 16:22:23 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26249 for ; Fri, 23 Apr 1999 16:22:21 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA14512 for ietf-open-pgp-bks; Fri, 23 Apr 1999 12:19:53 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA14508 for ; Fri, 23 Apr 1999 12:19:51 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id VAA23245 for ietf-open-pgp@imc.org; Fri, 23 Apr 1999 21:20:58 +0200 (MET DST) Received: (qmail 14112 invoked from network); 23 Apr 1999 19:04:49 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 23 Apr 1999 19:04:49 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10alE1-0004fR-00; Fri, 23 Apr 1999 21:02:57 +0200 Date: Fri, 23 Apr 1999 21:02:57 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: MDC testdata Message-ID: <19990423210255.A17940@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi, I did some test encryptions with GnuPG and MDCs ala Tom. MDCs are stored as bignums. I hope not to annoy you with this large stuff of material. File x1: ******** :pubkey enc packet: version 3, algo 16, keyid 6AE6D7EE46A871F8 data: [1023 bits] data: [1023 bits] :encrypted data packet: length: 96 :compressed packet: algo=2 :onepass_sig packet: keyid 0000000000000000 version 3, sigclass 00, digest 2, pubkey 0, last=1 :literal data packet: mode b, created 924893198, name="hallo", raw data: 25 bytes :signature packet: algo 0, keyid 0000000000000000 version 4, created 0, md5len 0, sigclass 00 digest algo 2, begin of digest 9b c8 MDC data: [160 bits] -----BEGIN PGP MESSAGE----- hQEOA2rm1+5GqHH4EAP/bqTfjMullxhBTGcvGcXWMJXcxW0jX0lrWb33UxdXEgYQ QI062S6n1yjYMrnaNWFUiobCCrHVn8Mi4omiIPVXsfYOflO/9YaB45Ma8RvOERG1 Ej00Kc+BnuGV94/6jQtA+ujYcul8KPL+hNm8cwrRKZjZWLPEOwVBIwL2jM9wWawD /2ieNNRQOeiXMXmei81Fa3TIyiCyDIEEYe3ZBxM1mwqiZXk7peZsSTmso+QKkbuZ ySMZ9H4i4xjLaKvbFNNYs0dS+2G5ImZGLQu7dTXHXubKlX8Sf92ECkQQ/GAQvQ2L M06q91HVy8S0uBWGawRWL8VL48JzMLJYvzpg+pWPXaVGyWCZiETC6PyZwO6i1Eff F7XYCBrjEVBe+C8f71b6GCMtPOVKEdb8AmNRtS2IVkTyNRGEkbu5UdBxIRAUkpCv SmwUG0kF6iqL8CeBkLQkYj08IPWqbUvAk8Oe827X9qqHYTM= =9X0x -----END PGP MESSAGE----- File x2: (without compression) ******** :pubkey enc packet: version 3, algo 16, keyid 6AE6D7EE46A871F8 data: [1019 bits] data: [1023 bits] :encrypted data packet: length: 97 :onepass_sig packet: keyid 0000000000000000 version 3, sigclass 00, digest 2, pubkey 0, last=1 :literal data packet: mode b, created 924893233, name="hallo", raw data: 25 bytes :signature packet: algo 0, keyid 0000000000000000 version 4, created 0, md5len 0, sigclass 00 digest algo 2, begin of digest 9b c8 MDC data: [160 bits] -----BEGIN PGP MESSAGE----- hQEOA2rm1+5GqHH4EAP7B2siRT/m4hU//n+JY4E2jRjK3q0BgQneBi29jsX/1Z4P YQeRfGPV0LOKw0j6yGpoDKUdptgflNk4glN1R3VAwVVpv3BFqvy6ucKpdHDDCQdo czduLzmp4XuWxHeQHh8Q2+orkbOJiJkkHBCbRz3gwkktPxaq7GGSmlp0Nr+E1bwD /2Ct0zA1TksUKr3PCvo9Zdi2ycjeNf6dfMRvWIYa8xBE7j6EF8MoIKBA8RRCGCDt 5xxA9ZRqGLLKHUBGh/astMxnj9QImFgVXObUaqiGYiljqmil1g2dYUJr0NkODaaT Hj9KfNKiHfCqztSyU/EFku4RpDZXTEqC0E168Ls50qyQyWEsVW1oV15ocHpwrjFw aR/C659kHb5tI/JB39K+hon+3An6NQaTbckuzWG73wuLArkohEpXzHK/ICz1jpzC 6LSN7lOCnWObGDw+hnZq8tJYWUJvtf15VdjRUYrxQ/wrBUuv =3bWf -----END PGP MESSAGE----- File x3: (Twofish) ******** :pubkey enc packet: version 3, algo 16, keyid 6AE6D7EE46A871F8 data: [1020 bits] data: [1024 bits] :encrypted data packet: length: 105 :onepass_sig packet: keyid 0000000000000000 version 3, sigclass 00, digest 2, pubkey 0, last=1 :literal data packet: mode b, created 924893255, name="hallo", raw data: 25 bytes :signature packet: algo 0, keyid 0000000000000000 version 4, created 0, md5len 0, sigclass 00 digest algo 2, begin of digest 9b c8 MDC data: [160 bits] -----BEGIN PGP MESSAGE----- hQEOA2rm1+5GqHH4EAP8CK3z4zNkxKYR6FFSXEAr4xu7FX8AwU1OnQbG/4Uodyct qUSs2FWMjnQX3z97Re7rQw4cdIZN48MYJvpNcqRNbEDAfiCRF/1uNzAFlrQ3H/jc TMdsUN4ZYUo8yY9NPOiTAoAtiQRW/gGc5XHrTdNUeJmYhh+c3mNtXlpnB/ZW/aoE AJdAh9K8AbMjwmSHIR+9lamAyudJISgG70LsGIHF/RlxXmblYZpSO5+dAfxuqJdW yIcxAhaxSI7gd8rCnqEt8YADVPRtMC9j6EU7Ev+PPwCkfN3GSVdcPiyukWHiRi1+ P4wujQVIN/3TvZU04TNIkhQz1knQ6GFtUzwMz0sJcQ5dyWk3MuKZF1u/uMy/EnMu 09HDSGE/6rJckjc9Qlk7dLbxUjRvJd4M2Nvor8uSZvclmWa9zehTlyzsLrQB9+s2 qeMVMCg/O5IZR+aqUOR0Hn4XUmcIRNqAhv/qjLleHd5YzroX3xJIpX3n5Hw= =yhGH -----END PGP MESSAGE----- And here are the keys (passphrase is "abc"): pub 1024D/68697734 1999-03-08 Alpha Test (demo key) uid Alice (demo key) uid Alfa Test (demo key) sub 1024g/46A871F8 1999-03-08 -----BEGIN PGP PUBLIC KEY BLOCK----- mQGiBDbjjp4RBAC2ZbFDX0wmJI8yLDYQdIiZeAuHLmfyHsqXaLGUMZtWiAvn/hNp ctwahmzKm5oXinHUvUkLOQ0s8rOlu15nhw4azc30rTP1LsIkn5zORNnFdgYC6RKy hOeim/63+/yGtdnTm49lVfaCqwsEmBCEkXaeWDGq+ie1b89J89T6n/JquwCgoQkj VeVGG+B/SzJ6+yifdHWQVkcD/RXDyLXX4+WHGP2aet51XlKojWGwsZmc9LPPYhwU /RcUO7ce1QQb0XFlUVFBhY0JQpM/ty/kNi+aGWFzigbQ+HAWZkUvA8+VIAVneN+p +SHhGIyLTXKpAYTq46AwvllZ5Cpvf02Cp/+W1aVyA0qnBWMyeIxXmR9HOi6lxxn5 cjajA/9VZufOXWqCXkBvz4Oy3Q5FbjQQ0/+ty8rDn8OTaiPi41FyUnEi6LO+qyBS 09FjnZj++PkcRcXW99SNxmEJRY7MuNHt5wIvEH2jNEOJ9lszzZFBDbuwsjXHK35+ lPbGEy69xCP26iEafysKKbRXJhE1C+tk8SnK+Gm62sivmK/5arQpQWxwaGEgVGVz dCAoZGVtbyBrZXkpIDxhbHBoYUBleGFtcGxlLm5ldD6IVQQTEQIAFQUCNuOOngML CgMDFQMCAxYCAQIXgAAKCRAtcnzHaGl3NDl4AKCBLmRplv/8ZfSqep5IjqEAuaXv WwCgl6NEzT+/WewPTGcwZY+pLkycLv20EEFsaWNlIChkZW1vIGtleSmIVQQTEQIA FQUCNuO2qwMLCgMDFQMCAxYCAQIXgAAKCRAtcnzHaGl3NCeMAJ9MeUVrago5Jc6P dwdeN5OMwby37QCghW65cZTQlD1bBlIq/QM8bz9AN4G0J0FsZmEgVGVzdCAoZGVt byBrZXkpIDxhbGZhQGV4YW1wbGUubmV0PohVBBMRAgAVBQI247hYAwsKAwMVAwID FgIBAheAAAoJEC1yfMdoaXc0t8IAoJPwa6j+Vm5Vi3Nvuo8JZri4PJ/DAJ9dqbma JdB8FdJnHfGh1rXK3y/JcrkBDQQ2448PEAQAnI3XH1f0uyN9fZnw72zsHMw706g7 EW29nD4UDQG4OzRZViSrUa5n39eI7QrfTO+1meVvs0y8F/PvFst5jH68rPLnGSrX z4sTl1T4cop1FBkquvCAKwPLy0lE7jjtCyItOSwIOo8xoTfY4JEEXmcqsbm+KHv9 yYSF/YK4Cf7bIzcAAwcD/Rnl5jKxoucDA96pD2829TKsLFQSau+Xiy8bvOSSDdly ABsOkNBSaeKO3eAQEKgDM7dzjVNTnAlpQ0EQ8Y9Z8pxOWYEQYlaMrnRBC4DZ2Iad zEhLlIOz5BVp/jfhrr8oVVBwKZXsrz9PZLz+e4Yn+siUUvlei9boD9L2ZgSOHakP iEYEGBECAAYFAjbjjw8ACgkQLXJ8x2hpdzQgqQCfcDXmD8uNVdKg/C9vqI3JSndq knsAnRxzVeHi/iJ73OCKtvFrHbV9Gogq =sBZo -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP PRIVATE KEY BLOCK----- lQHOBDbjjp4RBAC2ZbFDX0wmJI8yLDYQdIiZeAuHLmfyHsqXaLGUMZtWiAvn/hNp ctwahmzKm5oXinHUvUkLOQ0s8rOlu15nhw4azc30rTP1LsIkn5zORNnFdgYC6RKy hOeim/63+/yGtdnTm49lVfaCqwsEmBCEkXaeWDGq+ie1b89J89T6n/JquwCgoQkj VeVGG+B/SzJ6+yifdHWQVkcD/RXDyLXX4+WHGP2aet51XlKojWGwsZmc9LPPYhwU /RcUO7ce1QQb0XFlUVFBhY0JQpM/ty/kNi+aGWFzigbQ+HAWZkUvA8+VIAVneN+p +SHhGIyLTXKpAYTq46AwvllZ5Cpvf02Cp/+W1aVyA0qnBWMyeIxXmR9HOi6lxxn5 cjajA/9VZufOXWqCXkBvz4Oy3Q5FbjQQ0/+ty8rDn8OTaiPi41FyUnEi6LO+qyBS 09FjnZj++PkcRcXW99SNxmEJRY7MuNHt5wIvEH2jNEOJ9lszzZFBDbuwsjXHK35+ lPbGEy69xCP26iEafysKKbRXJhE1C+tk8SnK+Gm62sivmK/5av8EAQNuYiCeVh4Q pF3i4v6LDa82cNBI92zOHLJAu1nbeJ6bl86f/lrm6DuHtClBbHBoYSBUZXN0IChk ZW1vIGtleSkgPGFscGhhQGV4YW1wbGUubmV0PohVBBMRAgAVBQI2446eAwsKAwMV AwIDFgIBAheAAAoJEC1yfMdoaXc0OXgAniui4cH4ukKQ2LkLn2McRrWRsA3MAKCZ 122s1KPXI/JMLBTBGCE9SiYQJLQQQWxpY2UgKGRlbW8ga2V5KYhVBBMRAgAVBQI2 47arAwsKAwMVAwIDFgIBAheAAAoJEC1yfMdoaXc0J4wAn0x5RWtqCjklzo93B143 k4zBvLftAKCFbrlxlNCUPVsGUir9AzxvP0A3gbQnQWxmYSBUZXN0IChkZW1vIGtl eSkgPGFsZmFAZXhhbXBsZS5uZXQ+iFUEExECABUFAjbjuFgDCwoDAxUDAgMWAgEC F4AACgkQLXJ8x2hpdzS3wgCgk/BrqP5WblWLc2+6jwlmuLg8n8MAn12puZol0HwV 0mcd8aHWtcrfL8lynQGlBDbjjw8QBACcjdcfV/S7I319mfDvbOwczDvTqDsRbb2c PhQNAbg7NFlWJKtRrmff14jtCt9M77WZ5W+zTLwX8+8Wy3mMfrys8ucZKtfPixOX VPhyinUUGSq68IArA8vLSUTuOO0LIi05LAg6jzGhN9jgkQReZyqxub4oe/3JhIX9 grgJ/tsjNwADBwP9GeXmMrGi5wMD3qkPbzb1MqwsVBJq75eLLxu85JIN2XIAGw6Q 0FJp4o7d4BAQqAMzt3ONU1OcCWlDQRDxj1nynE5ZgRBiVoyudEELgNnYhp3MSEuU g7PkFWn+N+GuvyhVUHApleyvP09kvP57hif6yJRS+V6L1ugP0vZmBI4dqQ//BAED bmIgnlYeEKRd4uL+iw2vNnOO9Y3cRSExyy8unuzNvx5GFG6KNtxoFCDzMMzUa0ED H1x/QJA3CgqMpS282nLdk/5O+AphiEVeGv8+c6pL/t7falIfSgKZ0j2nvCKH12So bwiNflTGJB+jLnnesjqYJD7h0SVLjToP/vtKPYlXOU1ZpKzDwP5YcQQuRhF9Tj8S UxScIIhGBBgRAgAGBQI2448PAAoJEC1yfMdoaXc0IKkAoJ/NQGlvFv5clcDIf1AX jLlTFG9uAJ9rs8IOzHfNWuUSNxdhRvO+O7fYFw== =7Y3J -----END PGP PRIVATE KEY BLOCK----- -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Fri Apr 23 16:30:11 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26329 for ; Fri, 23 Apr 1999 16:30:10 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA14968 for ietf-open-pgp-bks; Fri, 23 Apr 1999 12:43:07 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA14964 for ; Fri, 23 Apr 1999 12:43:05 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id VAA24707 for ietf-open-pgp@imc.org; Fri, 23 Apr 1999 21:44:12 +0200 (MET DST) Received: (qmail 14188 invoked from network); 23 Apr 1999 19:32:35 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 23 Apr 1999 19:32:35 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10alet-0004fc-00; Fri, 23 Apr 1999 21:30:43 +0200 Date: Fri, 23 Apr 1999 21:30:43 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Message Integrity Message-ID: <19990423213040.B17940@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904222223.PAA03802@226-132.adsl2.avtel.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i In-Reply-To: <199904222223.PAA03802@226-132.adsl2.avtel.net>; from hal@rain.org on Thu, Apr 22, 1999 at 03:23:42PM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: hal@rain.org writes: > Or even better, use a special encryption packet to indicate that there > is a MIC (MDC) following, and a special MIC packet to hold it following I think this will be the cleanest solution. * Create a new encrypted data packet: - 1 byte version number (please, we have this on most others too) - 1 byte mdc-algorithm (hash algorithm used or 0 for no MDC) - n byte encrypted-data (in standard CFB mode with prepended random and check bytes) * Create a MDC packet: - 1 byte version number - 1 byte mdc-algorithm (should be > 0 ) - n bytes hash I don't know whether it is better to use 1 or 3 for the version numbers. I think PGP 6 has some new packet types, so someone else should suggest the numbers. Implementation of this seems to be more easier than the hacked signature packets. Maybe a little bit more code but much easier to understand. And we don't need to redefine the specs (I still remember the trouble I had when using the old rfc1991 comment packet and then the one from the draft). We can state that the new ciphers (which are not yet defined in the specs) SHOULD use the new encryption packet. Werner -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 From owner-ietf-open-pgp@imc.org Mon Apr 26 10:19:18 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17726 for ; Mon, 26 Apr 1999 10:19:18 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA28368 for ietf-open-pgp-bks; Mon, 26 Apr 1999 06:29:00 -0700 (PDT) Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA28364 for ; Mon, 26 Apr 1999 06:28:57 -0700 (PDT) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id BAA05139; Tue, 27 Apr 1999 01:29:48 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92513338818607>; Tue, 27 Apr 1999 01:29:48 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: hal@rain.org, ietf-open-pgp@imc.org Subject: Re: Restricting key sizes to mult of 64 bits Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Tue, 27 Apr 1999 01:29:48 (NZST) Message-ID: <92513338818607@cs26.cs.auckland.ac.nz> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: >Some users have already encountered a problem with oddly sized keys. We >shipped software which used Microsoft's built-in Crypto API (CAPI) to do the >RSA calculations. As it turned out, CAPI had a bug which prevented it from >working properly with unusual key sizes. Those users weren't able to use >their keys with the CAPI version. This has been a known problem (well, known to everyone but Microsoft) since the very first CryptoAPI shipped about three years ago. For people who haven't seen this, MS assume that an RSA key has certain fixed properties (eg that p, q = n/2 bits exactly, that e < 32 bits, and various other bletcherousness - noone will ever need more than 640K, and noone will ever type a URL larger than 1024 characters). I don't think PGP should have to include workarounds for bugs in their code. >We would like to reduce the chance of running into similar problems in the >future, and keeping keys to round sizes should help. The choice of 64 bits as >the multiple is based on trading off the desire for plenty of key sizes versus >minimizing the chance of an unsupported key size. The fact that DSS uses 64 >bit multiples suggests that this is a reasonable value. I'm not sure of the rationale for this in DSS (possibly some hardware limitation, perhaps in the Capstone chips?) but requiring it isn't a good idea. DSS assumes that you'll be using Kravitz' kosherizer to generate keys, however there are other, better (in some circumstances) algorithms which can't easily generate keys of a certain size. For example the Lim-Lee algorithm, which generates keys with certain very nice properties for DLP-based PKC's, doesn't easily generate keys of a certain size (this is a problem with the X9.42 standard for DH, which mandates the use of the kosherizer for generating DH keys (!!!) and then has to add all sorts of horrible kludges to get around things like small subgroup attacks. If they used Lim-Lee this wouldn't be a problem, and generation would be much more efficient than with the kosherizer). The point of this ramble is that requiring certain more or less arbitrary properties (eg X9.42's requirement to use the kosherizer) greatly limits the flexibility available during key generation while providing no clear advantage. Peter. From owner-ietf-open-pgp@imc.org Tue Apr 27 20:49:50 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03056 for ; Tue, 27 Apr 1999 20:49:50 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA13010 for ietf-open-pgp-bks; Tue, 27 Apr 1999 16:57:44 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA13006 for ; Tue, 27 Apr 1999 16:57:43 -0700 (PDT) Received: by brickwall.ceddec.com id <42113>; Tue, 27 Apr 1999 19:57:54 -0400 Date: Tue, 27 Apr 1999 19:59:01 -0400 From: Tom Zerucha X-Sender: nobody@mars To: Werner Koch cc: ietf-open-pgp@imc.org Subject: Re: Message Integrity In-Reply-To: <19990423063132.A16309@frodo.isil.d.shuttle.de> Message-Id: <99Apr27.195754edt.42113@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Fri, 23 Apr 1999, Werner Koch wrote: > Jon Callas writes: > > > I presume that this is a V4 signature, with signature type of 0 (binary > > document), PKALG of 0 (no public-key algorithm), hash algorithm type of the > > appropriate hash, no subpackets, two hash bytes that duplicate the > > Hmmm, I think I have subpackets but I can drop them. Same here - I include the time and keyid, but they were required for signatures. > > high-order octets of the hash, and then a single MPI containing the hash. > > Is this correct? > > Yes. And I put a onepass signature packet in front with a keyid of > all 0 and a pubkey algo of 0; it is not required for decryption. My 1pass is optional, but the same thing happens. It does start the proper hash algorithm. (I haven't done anything with the other method - a new MDC packet; too many other projects at the moment). From owner-ietf-open-pgp@imc.org Tue Apr 27 21:14:19 1999 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03258 for ; Tue, 27 Apr 1999 21:14:18 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA14102 for ietf-open-pgp-bks; Tue, 27 Apr 1999 17:22:56 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA14097 for ; Tue, 27 Apr 1999 17:22:54 -0700 (PDT) Received: by brickwall.ceddec.com id <42113>; Tue, 27 Apr 1999 20:23:10 -0400 Date: Tue, 27 Apr 1999 20:24:14 -0400 From: Tom Zerucha X-Sender: nobody@mars To: Werner Koch cc: ietf-open-pgp@imc.org Subject: Re: Message Integrity In-Reply-To: <19990423063132.A16309@frodo.isil.d.shuttle.de> Message-Id: <99Apr27.202310edt.42113@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Fri, 23 Apr 1999, Werner Koch wrote: > Jon Callas writes: > > > I presume that this is a V4 signature, with signature type of 0 (binary > > document), PKALG of 0 (no public-key algorithm), hash algorithm type of the > > appropriate hash, no subpackets, two hash bytes that duplicate the > > Hmmm, I think I have subpackets but I can drop them. In the message you posted, the length of both types of subpackets were zero. My program recognized everything fine, but didn't get the right hash value. I cannot get the hash to match - are you also hashing the 6 byte length plus like a signature? Are you also hashing the literal header? Or maybe I should just ask which portion is being hashed. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA14102 for ietf-open-pgp-bks; Tue, 27 Apr 1999 17:22:56 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA14097 for ; Tue, 27 Apr 1999 17:22:54 -0700 (PDT) Received: by brickwall.ceddec.com id <42113>; Tue, 27 Apr 1999 20:23:10 -0400 Date: Tue, 27 Apr 1999 20:24:14 -0400 From: Tom Zerucha X-Sender: nobody@mars To: Werner Koch cc: ietf-open-pgp@imc.org Subject: Re: Message Integrity In-Reply-To: <19990423063132.A16309@frodo.isil.d.shuttle.de> Message-Id: <99Apr27.202310edt.42113@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Fri, 23 Apr 1999, Werner Koch wrote: > Jon Callas writes: > > > I presume that this is a V4 signature, with signature type of 0 (binary > > document), PKALG of 0 (no public-key algorithm), hash algorithm type of the > > appropriate hash, no subpackets, two hash bytes that duplicate the > > Hmmm, I think I have subpackets but I can drop them. In the message you posted, the length of both types of subpackets were zero. My program recognized everything fine, but didn't get the right hash value. I cannot get the hash to match - are you also hashing the 6 byte length plus like a signature? Are you also hashing the literal header? Or maybe I should just ask which portion is being hashed. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA13010 for ietf-open-pgp-bks; Tue, 27 Apr 1999 16:57:44 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA13006 for ; Tue, 27 Apr 1999 16:57:43 -0700 (PDT) Received: by brickwall.ceddec.com id <42113>; Tue, 27 Apr 1999 19:57:54 -0400 Date: Tue, 27 Apr 1999 19:59:01 -0400 From: Tom Zerucha X-Sender: nobody@mars To: Werner Koch cc: ietf-open-pgp@imc.org Subject: Re: Message Integrity In-Reply-To: <19990423063132.A16309@frodo.isil.d.shuttle.de> Message-Id: <99Apr27.195754edt.42113@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Fri, 23 Apr 1999, Werner Koch wrote: > Jon Callas writes: > > > I presume that this is a V4 signature, with signature type of 0 (binary > > document), PKALG of 0 (no public-key algorithm), hash algorithm type of the > > appropriate hash, no subpackets, two hash bytes that duplicate the > > Hmmm, I think I have subpackets but I can drop them. Same here - I include the time and keyid, but they were required for signatures. > > high-order octets of the hash, and then a single MPI containing the hash. > > Is this correct? > > Yes. And I put a onepass signature packet in front with a keyid of > all 0 and a pubkey algo of 0; it is not required for decryption. My 1pass is optional, but the same thing happens. It does start the proper hash algorithm. (I haven't done anything with the other method - a new MDC packet; too many other projects at the moment). Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA28368 for ietf-open-pgp-bks; Mon, 26 Apr 1999 06:29:00 -0700 (PDT) Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA28364 for ; Mon, 26 Apr 1999 06:28:57 -0700 (PDT) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id BAA05139; Tue, 27 Apr 1999 01:29:48 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92513338818607>; Tue, 27 Apr 1999 01:29:48 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: hal@rain.org, ietf-open-pgp@imc.org Subject: Re: Restricting key sizes to mult of 64 bits Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Tue, 27 Apr 1999 01:29:48 (NZST) Message-ID: <92513338818607@cs26.cs.auckland.ac.nz> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: >Some users have already encountered a problem with oddly sized keys. We >shipped software which used Microsoft's built-in Crypto API (CAPI) to do the >RSA calculations. As it turned out, CAPI had a bug which prevented it from >working properly with unusual key sizes. Those users weren't able to use >their keys with the CAPI version. This has been a known problem (well, known to everyone but Microsoft) since the very first CryptoAPI shipped about three years ago. For people who haven't seen this, MS assume that an RSA key has certain fixed properties (eg that p, q = n/2 bits exactly, that e < 32 bits, and various other bletcherousness - noone will ever need more than 640K, and noone will ever type a URL larger than 1024 characters). I don't think PGP should have to include workarounds for bugs in their code. >We would like to reduce the chance of running into similar problems in the >future, and keeping keys to round sizes should help. The choice of 64 bits as >the multiple is based on trading off the desire for plenty of key sizes versus >minimizing the chance of an unsupported key size. The fact that DSS uses 64 >bit multiples suggests that this is a reasonable value. I'm not sure of the rationale for this in DSS (possibly some hardware limitation, perhaps in the Capstone chips?) but requiring it isn't a good idea. DSS assumes that you'll be using Kravitz' kosherizer to generate keys, however there are other, better (in some circumstances) algorithms which can't easily generate keys of a certain size. For example the Lim-Lee algorithm, which generates keys with certain very nice properties for DLP-based PKC's, doesn't easily generate keys of a certain size (this is a problem with the X9.42 standard for DH, which mandates the use of the kosherizer for generating DH keys (!!!) and then has to add all sorts of horrible kludges to get around things like small subgroup attacks. If they used Lim-Lee this wouldn't be a problem, and generation would be much more efficient than with the kosherizer). The point of this ramble is that requiring certain more or less arbitrary properties (eg X9.42's requirement to use the kosherizer) greatly limits the flexibility available during key generation while providing no clear advantage. Peter. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA14968 for ietf-open-pgp-bks; Fri, 23 Apr 1999 12:43:07 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA14964 for ; Fri, 23 Apr 1999 12:43:05 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id VAA24707 for ietf-open-pgp@imc.org; Fri, 23 Apr 1999 21:44:12 +0200 (MET DST) Received: (qmail 14188 invoked from network); 23 Apr 1999 19:32:35 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 23 Apr 1999 19:32:35 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10alet-0004fc-00; Fri, 23 Apr 1999 21:30:43 +0200 Date: Fri, 23 Apr 1999 21:30:43 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Message Integrity Message-ID: <19990423213040.B17940@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904222223.PAA03802@226-132.adsl2.avtel.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i In-Reply-To: <199904222223.PAA03802@226-132.adsl2.avtel.net>; from hal@rain.org on Thu, Apr 22, 1999 at 03:23:42PM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: hal@rain.org writes: > Or even better, use a special encryption packet to indicate that there > is a MIC (MDC) following, and a special MIC packet to hold it following I think this will be the cleanest solution. * Create a new encrypted data packet: - 1 byte version number (please, we have this on most others too) - 1 byte mdc-algorithm (hash algorithm used or 0 for no MDC) - n byte encrypted-data (in standard CFB mode with prepended random and check bytes) * Create a MDC packet: - 1 byte version number - 1 byte mdc-algorithm (should be > 0 ) - n bytes hash I don't know whether it is better to use 1 or 3 for the version numbers. I think PGP 6 has some new packet types, so someone else should suggest the numbers. Implementation of this seems to be more easier than the hacked signature packets. Maybe a little bit more code but much easier to understand. And we don't need to redefine the specs (I still remember the trouble I had when using the old rfc1991 comment packet and then the one from the draft). We can state that the new ciphers (which are not yet defined in the specs) SHOULD use the new encryption packet. Werner -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA14512 for ietf-open-pgp-bks; Fri, 23 Apr 1999 12:19:53 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA14508 for ; Fri, 23 Apr 1999 12:19:51 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id VAA23245 for ietf-open-pgp@imc.org; Fri, 23 Apr 1999 21:20:58 +0200 (MET DST) Received: (qmail 14112 invoked from network); 23 Apr 1999 19:04:49 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 23 Apr 1999 19:04:49 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10alE1-0004fR-00; Fri, 23 Apr 1999 21:02:57 +0200 Date: Fri, 23 Apr 1999 21:02:57 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: MDC testdata Message-ID: <19990423210255.A17940@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi, I did some test encryptions with GnuPG and MDCs ala Tom. MDCs are stored as bignums. I hope not to annoy you with this large stuff of material. File x1: ******** :pubkey enc packet: version 3, algo 16, keyid 6AE6D7EE46A871F8 data: [1023 bits] data: [1023 bits] :encrypted data packet: length: 96 :compressed packet: algo=2 :onepass_sig packet: keyid 0000000000000000 version 3, sigclass 00, digest 2, pubkey 0, last=1 :literal data packet: mode b, created 924893198, name="hallo", raw data: 25 bytes :signature packet: algo 0, keyid 0000000000000000 version 4, created 0, md5len 0, sigclass 00 digest algo 2, begin of digest 9b c8 MDC data: [160 bits] -----BEGIN PGP MESSAGE----- hQEOA2rm1+5GqHH4EAP/bqTfjMullxhBTGcvGcXWMJXcxW0jX0lrWb33UxdXEgYQ QI062S6n1yjYMrnaNWFUiobCCrHVn8Mi4omiIPVXsfYOflO/9YaB45Ma8RvOERG1 Ej00Kc+BnuGV94/6jQtA+ujYcul8KPL+hNm8cwrRKZjZWLPEOwVBIwL2jM9wWawD /2ieNNRQOeiXMXmei81Fa3TIyiCyDIEEYe3ZBxM1mwqiZXk7peZsSTmso+QKkbuZ ySMZ9H4i4xjLaKvbFNNYs0dS+2G5ImZGLQu7dTXHXubKlX8Sf92ECkQQ/GAQvQ2L M06q91HVy8S0uBWGawRWL8VL48JzMLJYvzpg+pWPXaVGyWCZiETC6PyZwO6i1Eff F7XYCBrjEVBe+C8f71b6GCMtPOVKEdb8AmNRtS2IVkTyNRGEkbu5UdBxIRAUkpCv SmwUG0kF6iqL8CeBkLQkYj08IPWqbUvAk8Oe827X9qqHYTM= =9X0x -----END PGP MESSAGE----- File x2: (without compression) ******** :pubkey enc packet: version 3, algo 16, keyid 6AE6D7EE46A871F8 data: [1019 bits] data: [1023 bits] :encrypted data packet: length: 97 :onepass_sig packet: keyid 0000000000000000 version 3, sigclass 00, digest 2, pubkey 0, last=1 :literal data packet: mode b, created 924893233, name="hallo", raw data: 25 bytes :signature packet: algo 0, keyid 0000000000000000 version 4, created 0, md5len 0, sigclass 00 digest algo 2, begin of digest 9b c8 MDC data: [160 bits] -----BEGIN PGP MESSAGE----- hQEOA2rm1+5GqHH4EAP7B2siRT/m4hU//n+JY4E2jRjK3q0BgQneBi29jsX/1Z4P YQeRfGPV0LOKw0j6yGpoDKUdptgflNk4glN1R3VAwVVpv3BFqvy6ucKpdHDDCQdo czduLzmp4XuWxHeQHh8Q2+orkbOJiJkkHBCbRz3gwkktPxaq7GGSmlp0Nr+E1bwD /2Ct0zA1TksUKr3PCvo9Zdi2ycjeNf6dfMRvWIYa8xBE7j6EF8MoIKBA8RRCGCDt 5xxA9ZRqGLLKHUBGh/astMxnj9QImFgVXObUaqiGYiljqmil1g2dYUJr0NkODaaT Hj9KfNKiHfCqztSyU/EFku4RpDZXTEqC0E168Ls50qyQyWEsVW1oV15ocHpwrjFw aR/C659kHb5tI/JB39K+hon+3An6NQaTbckuzWG73wuLArkohEpXzHK/ICz1jpzC 6LSN7lOCnWObGDw+hnZq8tJYWUJvtf15VdjRUYrxQ/wrBUuv =3bWf -----END PGP MESSAGE----- File x3: (Twofish) ******** :pubkey enc packet: version 3, algo 16, keyid 6AE6D7EE46A871F8 data: [1020 bits] data: [1024 bits] :encrypted data packet: length: 105 :onepass_sig packet: keyid 0000000000000000 version 3, sigclass 00, digest 2, pubkey 0, last=1 :literal data packet: mode b, created 924893255, name="hallo", raw data: 25 bytes :signature packet: algo 0, keyid 0000000000000000 version 4, created 0, md5len 0, sigclass 00 digest algo 2, begin of digest 9b c8 MDC data: [160 bits] -----BEGIN PGP MESSAGE----- hQEOA2rm1+5GqHH4EAP8CK3z4zNkxKYR6FFSXEAr4xu7FX8AwU1OnQbG/4Uodyct qUSs2FWMjnQX3z97Re7rQw4cdIZN48MYJvpNcqRNbEDAfiCRF/1uNzAFlrQ3H/jc TMdsUN4ZYUo8yY9NPOiTAoAtiQRW/gGc5XHrTdNUeJmYhh+c3mNtXlpnB/ZW/aoE AJdAh9K8AbMjwmSHIR+9lamAyudJISgG70LsGIHF/RlxXmblYZpSO5+dAfxuqJdW yIcxAhaxSI7gd8rCnqEt8YADVPRtMC9j6EU7Ev+PPwCkfN3GSVdcPiyukWHiRi1+ P4wujQVIN/3TvZU04TNIkhQz1knQ6GFtUzwMz0sJcQ5dyWk3MuKZF1u/uMy/EnMu 09HDSGE/6rJckjc9Qlk7dLbxUjRvJd4M2Nvor8uSZvclmWa9zehTlyzsLrQB9+s2 qeMVMCg/O5IZR+aqUOR0Hn4XUmcIRNqAhv/qjLleHd5YzroX3xJIpX3n5Hw= =yhGH -----END PGP MESSAGE----- And here are the keys (passphrase is "abc"): pub 1024D/68697734 1999-03-08 Alpha Test (demo key) uid Alice (demo key) uid Alfa Test (demo key) sub 1024g/46A871F8 1999-03-08 -----BEGIN PGP PUBLIC KEY BLOCK----- mQGiBDbjjp4RBAC2ZbFDX0wmJI8yLDYQdIiZeAuHLmfyHsqXaLGUMZtWiAvn/hNp ctwahmzKm5oXinHUvUkLOQ0s8rOlu15nhw4azc30rTP1LsIkn5zORNnFdgYC6RKy hOeim/63+/yGtdnTm49lVfaCqwsEmBCEkXaeWDGq+ie1b89J89T6n/JquwCgoQkj VeVGG+B/SzJ6+yifdHWQVkcD/RXDyLXX4+WHGP2aet51XlKojWGwsZmc9LPPYhwU /RcUO7ce1QQb0XFlUVFBhY0JQpM/ty/kNi+aGWFzigbQ+HAWZkUvA8+VIAVneN+p +SHhGIyLTXKpAYTq46AwvllZ5Cpvf02Cp/+W1aVyA0qnBWMyeIxXmR9HOi6lxxn5 cjajA/9VZufOXWqCXkBvz4Oy3Q5FbjQQ0/+ty8rDn8OTaiPi41FyUnEi6LO+qyBS 09FjnZj++PkcRcXW99SNxmEJRY7MuNHt5wIvEH2jNEOJ9lszzZFBDbuwsjXHK35+ lPbGEy69xCP26iEafysKKbRXJhE1C+tk8SnK+Gm62sivmK/5arQpQWxwaGEgVGVz dCAoZGVtbyBrZXkpIDxhbHBoYUBleGFtcGxlLm5ldD6IVQQTEQIAFQUCNuOOngML CgMDFQMCAxYCAQIXgAAKCRAtcnzHaGl3NDl4AKCBLmRplv/8ZfSqep5IjqEAuaXv WwCgl6NEzT+/WewPTGcwZY+pLkycLv20EEFsaWNlIChkZW1vIGtleSmIVQQTEQIA FQUCNuO2qwMLCgMDFQMCAxYCAQIXgAAKCRAtcnzHaGl3NCeMAJ9MeUVrago5Jc6P dwdeN5OMwby37QCghW65cZTQlD1bBlIq/QM8bz9AN4G0J0FsZmEgVGVzdCAoZGVt byBrZXkpIDxhbGZhQGV4YW1wbGUubmV0PohVBBMRAgAVBQI247hYAwsKAwMVAwID FgIBAheAAAoJEC1yfMdoaXc0t8IAoJPwa6j+Vm5Vi3Nvuo8JZri4PJ/DAJ9dqbma JdB8FdJnHfGh1rXK3y/JcrkBDQQ2448PEAQAnI3XH1f0uyN9fZnw72zsHMw706g7 EW29nD4UDQG4OzRZViSrUa5n39eI7QrfTO+1meVvs0y8F/PvFst5jH68rPLnGSrX z4sTl1T4cop1FBkquvCAKwPLy0lE7jjtCyItOSwIOo8xoTfY4JEEXmcqsbm+KHv9 yYSF/YK4Cf7bIzcAAwcD/Rnl5jKxoucDA96pD2829TKsLFQSau+Xiy8bvOSSDdly ABsOkNBSaeKO3eAQEKgDM7dzjVNTnAlpQ0EQ8Y9Z8pxOWYEQYlaMrnRBC4DZ2Iad zEhLlIOz5BVp/jfhrr8oVVBwKZXsrz9PZLz+e4Yn+siUUvlei9boD9L2ZgSOHakP iEYEGBECAAYFAjbjjw8ACgkQLXJ8x2hpdzQgqQCfcDXmD8uNVdKg/C9vqI3JSndq knsAnRxzVeHi/iJ73OCKtvFrHbV9Gogq =sBZo -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP PRIVATE KEY BLOCK----- lQHOBDbjjp4RBAC2ZbFDX0wmJI8yLDYQdIiZeAuHLmfyHsqXaLGUMZtWiAvn/hNp ctwahmzKm5oXinHUvUkLOQ0s8rOlu15nhw4azc30rTP1LsIkn5zORNnFdgYC6RKy hOeim/63+/yGtdnTm49lVfaCqwsEmBCEkXaeWDGq+ie1b89J89T6n/JquwCgoQkj VeVGG+B/SzJ6+yifdHWQVkcD/RXDyLXX4+WHGP2aet51XlKojWGwsZmc9LPPYhwU /RcUO7ce1QQb0XFlUVFBhY0JQpM/ty/kNi+aGWFzigbQ+HAWZkUvA8+VIAVneN+p +SHhGIyLTXKpAYTq46AwvllZ5Cpvf02Cp/+W1aVyA0qnBWMyeIxXmR9HOi6lxxn5 cjajA/9VZufOXWqCXkBvz4Oy3Q5FbjQQ0/+ty8rDn8OTaiPi41FyUnEi6LO+qyBS 09FjnZj++PkcRcXW99SNxmEJRY7MuNHt5wIvEH2jNEOJ9lszzZFBDbuwsjXHK35+ lPbGEy69xCP26iEafysKKbRXJhE1C+tk8SnK+Gm62sivmK/5av8EAQNuYiCeVh4Q pF3i4v6LDa82cNBI92zOHLJAu1nbeJ6bl86f/lrm6DuHtClBbHBoYSBUZXN0IChk ZW1vIGtleSkgPGFscGhhQGV4YW1wbGUubmV0PohVBBMRAgAVBQI2446eAwsKAwMV AwIDFgIBAheAAAoJEC1yfMdoaXc0OXgAniui4cH4ukKQ2LkLn2McRrWRsA3MAKCZ 122s1KPXI/JMLBTBGCE9SiYQJLQQQWxpY2UgKGRlbW8ga2V5KYhVBBMRAgAVBQI2 47arAwsKAwMVAwIDFgIBAheAAAoJEC1yfMdoaXc0J4wAn0x5RWtqCjklzo93B143 k4zBvLftAKCFbrlxlNCUPVsGUir9AzxvP0A3gbQnQWxmYSBUZXN0IChkZW1vIGtl eSkgPGFsZmFAZXhhbXBsZS5uZXQ+iFUEExECABUFAjbjuFgDCwoDAxUDAgMWAgEC F4AACgkQLXJ8x2hpdzS3wgCgk/BrqP5WblWLc2+6jwlmuLg8n8MAn12puZol0HwV 0mcd8aHWtcrfL8lynQGlBDbjjw8QBACcjdcfV/S7I319mfDvbOwczDvTqDsRbb2c PhQNAbg7NFlWJKtRrmff14jtCt9M77WZ5W+zTLwX8+8Wy3mMfrys8ucZKtfPixOX VPhyinUUGSq68IArA8vLSUTuOO0LIi05LAg6jzGhN9jgkQReZyqxub4oe/3JhIX9 grgJ/tsjNwADBwP9GeXmMrGi5wMD3qkPbzb1MqwsVBJq75eLLxu85JIN2XIAGw6Q 0FJp4o7d4BAQqAMzt3ONU1OcCWlDQRDxj1nynE5ZgRBiVoyudEELgNnYhp3MSEuU g7PkFWn+N+GuvyhVUHApleyvP09kvP57hif6yJRS+V6L1ugP0vZmBI4dqQ//BAED bmIgnlYeEKRd4uL+iw2vNnOO9Y3cRSExyy8unuzNvx5GFG6KNtxoFCDzMMzUa0ED H1x/QJA3CgqMpS282nLdk/5O+AphiEVeGv8+c6pL/t7falIfSgKZ0j2nvCKH12So bwiNflTGJB+jLnnesjqYJD7h0SVLjToP/vtKPYlXOU1ZpKzDwP5YcQQuRhF9Tj8S UxScIIhGBBgRAgAGBQI2448PAAoJEC1yfMdoaXc0IKkAoJ/NQGlvFv5clcDIf1AX jLlTFG9uAJ9rs8IOzHfNWuUSNxdhRvO+O7fYFw== =7Y3J -----END PGP PRIVATE KEY BLOCK----- -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA13762 for ietf-open-pgp-bks; Fri, 23 Apr 1999 11:18:36 -0700 (PDT) Received: from mail.replay.com (basement.replay.com [194.109.9.44]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA13758 for ; Fri, 23 Apr 1999 11:18:34 -0700 (PDT) Received: (from remailer@localhost) by mail.replay.com (8.9.2/8.9.2/Replay Associates LLP) id UAA05631; Fri, 23 Apr 1999 20:19:13 +0200 (CEST) Date: Fri, 23 Apr 1999 20:19:13 +0200 (CEST) Message-Id: <199904231819.UAA05631@mail.replay.com> From: Anonymous Comments: This message did not originate from the Sender address above. It was remailed automatically by anonymizing remailer software. Please report problems or inappropriate use to the remailer administrator at . Subject: Re: Message Integrity In-Reply-To: To: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > (4) A V5 signature packet that allows 4-byte lengths. Yet another signature packet version! Is this a scheme to increase S/MIME support? Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA11150 for ietf-open-pgp-bks; Fri, 23 Apr 1999 06:47:10 -0700 (PDT) Received: from stax05.cubis.de (proxy.cubis.de [194.112.101.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA11118; Fri, 23 Apr 1999 06:45:37 -0700 (PDT) Received: from secunet.de (huehnlein.cubis.de [10.0.129.33]) by stax05.cubis.de (8.7.5/8.7.3) with ESMTP id PAA02374; Fri, 23 Apr 1999 15:04:16 +0200 (MET DST) Message-ID: <37207D2C.B78F8881@secunet.de> Date: Fri, 23 Apr 1999 15:01:16 +0100 From: "Detlef =?iso-8859-1?Q?H=FChnlein?=" Organization: Secunet GmbH - The Trust Company X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: "cqre@secunet.de" Subject: Final Call for Papers - CQRE [Secure] networking Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id GAA11119 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hallo! Please accept my sincere appologies, if you receive this Final Call for Papers multiple times. The mail is just to remind you that there are only !!! THREE !!! more weeks until the deadline for submission of extended abstracts on May 14th, 1999. Recent news: * best paper award at CQRE * publication of proceedings in Springer's LNCS * first invited speakers: - Stephen Kent (GTE) - Bruce Schneier (Counterpane) - Helena Handschuh (Gemplus/ENST) Best regards Detlef Huehnlein *************************************************************** Final Call for Papers CQRE [Secure] Congress & Exhibition Duesseldorf, Germany, Nov. 30 - Dec. 2 1999 --------------------------------------------------------------- provides a new international forum covering most aspects of information security with a special focus to the role of information security in the context of rapidly evolving economic processes. --------------------------------------------------------------- Deadline for submission of extended abstracts: May 14, 1999 CQRE - website: http://www.cqre.net (under construction) CfP - at: http://www.secunet.de/forum/cqre.html mailing-list: send mailto:cqre@secunet.de (where the subject is "subscribe" without paranthesis) *************************************************************** The "CQRE [Secure] networking" provides a new international forum giving a close-up view on information security in the context of rapidly evolving economic processes. The unprecedented reliance on computer technology transformed the previous technical side-issue "information security" to a management problem requiring decisions of strategic importance. Hence, the targeted audience represents decision makers from government, industry, commercial, and academic communities. If you are developing solutions to problems relating to the protection of your country´s information infrastructure or a commercial enterprise, consider submitting a paper to the "CQRE [Secure] networking" conference. We are looking for papers and panel discussions covering: * electronic commerce - new business processes - secure business transactions - online merchandising - electronic payment / banking - innovative applications * network security - virtual private networks - security aspects in internet utilization - security aspects in multimedia applications - intrusion detection systems * legal aspects - digital signatures acts - privacy and anonymity - crypto regulation - liability * corporate security - access control - secure teleworking - enterprise key management - IT-audit - risk / disaster management - security awareness and training - implementation, accreditation, and operation of secure systems in a government, business, or industry environment * security technology - cryptography - public key infrastructures - chip card technology - biometrics * trust management - evaluation of products and systems - international harmonization of security evaluation criterias * standardization * future perspectives Any other contribution addressing the involvement of IT security in economic processes will be welcome. Authors are invited to submit an extended abstract of their contribution to the program chair. The submissions should be original research results, survey articles or "high quality" case studies and position papers. Product advertisements are welcome for presentation, but will not be considered for the proceedings. Manuscripts must be in English, and should not be more than 2.000 words. The extended abstracts should be in a form suitable for anonymous review, with no author names, affiliations, acknowledgements or obvious references. Contributions must not be submitted in parallel to any conference or workshop that has proceedings. Separately, an abstract of the paper with no more than 200 words and with title, name and addresses (incl. an E-mail address) of the authors shall be submitted. In the case of multiple authors the contacting author must be clearly identified. We strongly encourage electronic submission in Postscript format. The submissions must be in 11 pt format, use standard fonts or include the necessary fonts. Proposals for panel discussions should also be sent to the program chair. Panels of interest include those that present alternative/controversial viewpoints or those that encourage lively discussions of relevant issues. Panels that are collections of unrefereed papers will not be considered. Panel proposals should be a minimum of one page describing the subject matter, the appropriateness of the panel for this conference and should identify participants and their respective viewpoints. best paper award: This award will be presented at CQRE to the authors of the best paper to be selected by the program committee. mailing list/ web-site: If you want to receive emails with up to date information, please send a brief mail to cqre@secunet.de. You will find this call for papers and further information at http://www.secunet.de/forum/cqre.html. publication: The proceedings will be published by Springer-Verlag in the Lecture Notes of Computer Science (LNCS) Series. The final papers must be prepared as described in http://www.springer.de/comp/lncs/authors.html. important dates: deadline for submission of extended abstracts May 14, 1999 deadline for submission of panel proposals June 1, 1999 notification of acceptance June 25, 1999 deadline for submission of complete papers July 30, 1999 program committee: Johannes Buchmann (TU Darmstadt) Dirk Fox (Secorvo) Walter Fumy (Siemens) Ruediger Grimm (GMD) Helena Handschuh (ENST/Gemplus) Thomas Hoeren (Uni Muenster) Pil Joong Lee (POSTECH) Alfred Menezes (U.o.Waterloo/Certicom) David Naccache (Gemplus) Clifford Neumann (USC) Joachim Posegga (German Telekom) Mike Reiter (Bell Labs) Matt Robshaw (RSA) Richard Schlechter (EU-comm.) Bruce Schneier (Counterpane) Tsuyoshi Takagi (NTT) Yiannis Tsiounis (GTE Labs) Michael Waidner (IBM) Moti Yung (CERTCO) Robert Zuccherato (Entrust) program chair: Rainer Baumgart secunet - Security Networks GmbH Weidenauer Str. 223 - 225 57076 Siegen Germany Tel.: +49-271-48950-15 Fax: +49-271-48950-50 R.Baumgart@secunet.de Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA26263 for ietf-open-pgp-bks; Thu, 22 Apr 1999 22:19:54 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA26259 for ; Thu, 22 Apr 1999 22:19:52 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id HAA11766 for ietf-open-pgp@imc.org; Fri, 23 Apr 1999 07:20:59 +0200 (MET DST) Received: (qmail 13049 invoked from network); 23 Apr 1999 04:33:34 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 23 Apr 1999 04:33:34 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10aXcj-0004F6-00; Fri, 23 Apr 1999 06:31:33 +0200 Date: Fri, 23 Apr 1999 06:31:33 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Message Integrity Message-ID: <19990423063132.A16309@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <99Apr22.134631edt.42113@brickwall.ceddec.com>; <199904220825.JAA08070@server.eternity.org> <99Apr22.134631edt.42113@brickwall.ceddec.com> <19990422212653.B16112@frodo.isil.d.shuttle.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i In-Reply-To: ; from Jon Callas on Thu, Apr 22, 1999 at 03:10:44PM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Jon Callas writes: > I presume that this is a V4 signature, with signature type of 0 (binary > document), PKALG of 0 (no public-key algorithm), hash algorithm type of the > appropriate hash, no subpackets, two hash bytes that duplicate the Hmmm, I think I have subpackets but I can drop them. > high-order octets of the hash, and then a single MPI containing the hash. > Is this correct? Yes. And I put a onepass signature packet in front with a keyid of all 0 and a pubkey algo of 0; it is not required for decryption. -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA11303 for ietf-open-pgp-bks; Thu, 22 Apr 1999 19:31:01 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA11296 for ; Thu, 22 Apr 1999 19:31:00 -0700 (PDT) Received: by brickwall.ceddec.com id <42113>; Thu, 22 Apr 1999 22:30:39 -0400 Date: Thu, 22 Apr 1999 22:31:53 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars To: Adam Back cc: jon@callas.org, ietf-open-pgp@imc.org Subject: Re: Message Integrity In-Reply-To: <199904222306.AAA13142@server.eternity.org> Message-Id: <99Apr22.223039edt.42113@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Thu, 22 Apr 1999, Adam Back wrote: > > I am using a keyid of zero to trigger the MIC mode (internally I > > derive the algorithm from the keyid, but I could a flag or something > > else). > > Wasn't keyid of all 0s already reserved for another purpose. I seem > to recall a discussion by Hal and others some time back about reducing > the number of keyid bits to reduce identity leakage. Ultimately this > came down to having an empty keyid, where the recipient would have to > check on private keys on their key ring sequentialy to discover which > one to use. This was for encryption, so you could place the message in a public forum without identifying the recipient. For signing it would be less practical, and I don't know if anyone really implements it. (i.e. you would have to keep the public keys private so only the group could verify the signature and know who signed it). The algorithm ID would be zero too. My implementation selects the signature algorithm based on key id, but that could be fixed too, though I would need to alter the command line and maybe some API parameters. > Don't you use the algorithm ID (1 = RSA, 2 etc) as the item in the > switch statement in your existing code? Couldn't you then use alg ID > = 0 for no sig? Basically this is what I do, but I have it in the form of if-elseif-else type things instead of case statements. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA10373 for ietf-open-pgp-bks; Thu, 22 Apr 1999 19:25:25 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA10366 for ; Thu, 22 Apr 1999 19:25:24 -0700 (PDT) Received: by brickwall.ceddec.com id <42113>; Thu, 22 Apr 1999 22:25:03 -0400 Date: Thu, 22 Apr 1999 22:26:17 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars To: hal@rain.org cc: aba@dcs.ex.ac.uk, ietf-open-pgp@imc.org, jon@callas.org Subject: Re: Message Integrity In-Reply-To: <199904222224.PAA03806@226-132.adsl2.avtel.net> Message-Id: <99Apr22.222503edt.42113@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Thu, 22 Apr 1999 hal@rain.org wrote: > tzeruch@ceddec.com writes: > > The patch is now 83 lines affecting 3 files (sigchk sigmak elitmk). I > > think the DER version would be a few more, and it took less than 30 > > minutes. I am using a keyid of zero to trigger the MIC mode (internally I > > derive the algorithm from the keyid, but I could a flag or something > > else). > > Do you have a sense of how big the code would be to implement the MDC in > the encryption layer as originally proposed? Possibly if the MDC were > in a separate packet so you could identify it easily? My estimate would be over 300 lines (which for me is about 6%). If the MDC were in a separate packet (with an indicator at front similar to the 1 pass signature packet, or the MDC has to go up front), it would not be too much worse than my current changes. Although it would be a new packet type, it would be fall into the structure in parallel with the signatures, i.e. where I have signatures started, I could add an else if (MDC_PRESENT) and fire up the same hashing routines. Basically instead of adding algorithm 0 to the signature generator/checks, I add a new MDC packet type where the signature packets are processed. Let me give it a try (probably this weekend), and see. I will use my own packet format and IDs. So I would need either the MDC itself or an indicator packet *before* the MDC-ed stream for this to be easy. Functionally this is the elstrippo signature packet for MDC/MICs with a different ID. But it should be easier to parse. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA05125 for ietf-open-pgp-bks; Thu, 22 Apr 1999 18:14:34 -0700 (PDT) Received: from 226-132.adsl2.avtel.net (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA05121 for ; Thu, 22 Apr 1999 18:14:33 -0700 (PDT) Received: (from hal@localhost) by 226-132.adsl2.avtel.net (8.8.7/8.8.7) id SAA05936; Thu, 22 Apr 1999 18:15:08 -0700 Date: Thu, 22 Apr 1999 18:15:08 -0700 From: hal@rain.org Message-Id: <199904230115.SAA05936@226-132.adsl2.avtel.net> To: aba@dcs.ex.ac.uk, jon@callas.org Subject: Re: consensus was not against verification packets (Re: Message Integrity) Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Adam Back, , writes: > Jon writes: > > The consensus that I've seen since late last year is for a new data > > packet that has a standard encryption mode, be it CFB or CBC, and a > > hash in it. > > I did a little grepping of last years open-pgp traffic. The posts > discussing MDCs are below. None of them mentions this idea. Actually, there was some mention of it, but it did not use the term MDC so your grep did not find it. Take a look at http://www.imc.org/ietf-open-pgp/mail-archive/msg01670.html where you are responding to an earlier comment by Jon: : > I thought the consensus was that with 1.X we would look at adding : > some form of integrity check, perhaps with a new type of encrypted : > data packet. : : The reason I am keen on adding a MAC is a) it is broken (badly in my : view) and needs fixing; b) it is easy to fix; c) it does not affect : backwards compatibility. : : I prefer a digest packet inside the encrypted envelope (at the end of : the plaintext to aid one-pass processing), rather than a MAC for : reasons of simplicity (people already have code to compute and emit : digest packets for the available hashes). It is probably easiest to : define the digest packet as a signature packet. (This can then borrow : the one pass packets etc from existing signature parts). Not so different from the present discussion... Hal Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA04924 for ietf-open-pgp-bks; Thu, 22 Apr 1999 17:49:10 -0700 (PDT) Received: from neodymium (neodymium.btinternet.com [194.73.73.83]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04920 for ; Thu, 22 Apr 1999 17:49:08 -0700 (PDT) Received: from [195.99.63.79] (helo=server.eternity.org) by neodymium with esmtp (Exim 2.05 #1) id 10aU8D-0005NP-00 for ietf-open-pgp@imc.org; Fri, 23 Apr 1999 01:47:50 +0100 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id BAA13738; Fri, 23 Apr 1999 01:49:10 +0100 Date: Fri, 23 Apr 1999 01:49:10 +0100 Message-Id: <199904230049.BAA13738@server.eternity.org> From: Adam Back To: ietf-open-pgp@imc.org Subject: old MDC discussions Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: The old discussions, should anyone wish to review them, can be found by starting at the following links in sequence: http://www.imc.org/ietf-open-pgp/mail-archive/msg01746.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01748.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01754.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01756.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01757.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01758.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01763.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01770.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01771.html >From msg01771.html particularly, we have a description of the same proposal that was made recently, and Jon proposing _not_ reserving explicit packet IDs for it as requested in a message a few previous. Jon: > Adam Back: > > I didn't suggest that MDCs go into 1.0 in the last round. What I > suggested was that the following be verified: > > that when processing a message containing signatures a 1.0 > implementation MUST continue to emit plaintext (ie fail > gracefully) in the presence of signature algorithms it does > not recognise. > > this readily allows adding MDCs or other signature algorithms in > version 1.1, and ensures backwards compatibility is possible. > > Sure, but I don't think we need to add anything. If someone writes an > implementation that (for instance) bus errors when it receives an algorithm > encrypted with AES (which I pick because we all know it's going to go in, > but it isn't there now), then the implementation is clearly broken. > > Signatures are different because there's a meaningful thing to do -- emit > plaintext, and shrug over the sig -- which is a little different than the > crypto, or compression, or whatever. But nonetheless, there are many > failure and partial failure conditions, and an implementation that doesn't > fail gracefully is broken. > > This spec isn't a how-to-program manual, it's a format specification. By > necessity it tells you a lot of what to do with the format, but there's a > lot that this document can't tell an implementor. > > Jon and some even older discussions: http://www.imc.org/ietf-open-pgp/mail-archive/msg01112.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01113.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01115.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01117.html http://www.imc.org/ietf-open-pgp/mail-archive/msg01114.html Adam -- print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Thu, 22 Apr 1999 17:31:15 -0700 (PDT) Received: by na-ex-bridge2.nai.com with Internet Mail Service (5.5.2448.0) id <2TXAZSXS>; Thu, 22 Apr 1999 17:37:00 -0700 Message-ID: <6BC5E520D4A4D11184A200A0C99D8FBE02EF2ED9@ca-exchange1.nai.com> From: "Salzman, Noah" To: William Lewis , "Salzman, Noah" Cc: ietf-open-pgp@imc.org Subject: RE: typo? Date: Thu, 22 Apr 1999 17:34:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Thank very much, I understand now. --Noah-- > -----Original Message----- > From: William Lewis [mailto:wiml@omnigroup.com] > Sent: Thursday, April 22, 1999 5:19 PM > To: Salzman, Noah > Cc: ietf-open-pgp@imc.org > Subject: Re: typo? > > > You wrote: > > The generator constant in the code sample has a "1" that is > not in the > > preceding text. > > CRC polynomials are usually written without the leading term. > Whether the > constant in the code has the term is an implementation detail > --- for > example, if the CRC width is the same as the word width (e.g. > a CRC-32), it's > easier and faster not to write it that way. > > I'd recommend > ftp://ftp.rocksoft.com/clients/rocksoft/papers/> crc_v3.txt as > > an introduction to theoretical and practical > aspects of CRCs. > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA04623 for ietf-open-pgp-bks; Thu, 22 Apr 1999 17:27:21 -0700 (PDT) Received: from tungsten (tungsten.btinternet.com [194.73.73.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04619 for ; Thu, 22 Apr 1999 17:27:20 -0700 (PDT) Received: from [195.99.63.79] (helo=server.eternity.org) by tungsten with esmtp (Exim 2.05 #1) id 10aTov-0002qq-00; Fri, 23 Apr 1999 01:27:53 +0100 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id BAA13503; Fri, 23 Apr 1999 01:26:34 +0100 Date: Fri, 23 Apr 1999 01:26:34 +0100 Message-Id: <199904230026.BAA13503@server.eternity.org> From: Adam Back To: jon@callas.org CC: ietf-open-pgp@imc.org In-reply-to: (message from Jon Callas on Thu, 22 Apr 1999 15:00:17 -0700) Subject: Re: consensus was not against verification packets (Re: Message Integrity) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Jon writes: > The consensus that I've seen since late last year is for a new data > packet that has a standard encryption mode, be it CFB or CBC, and a > hash in it. I did a little grepping of last years open-pgp traffic. The posts discussing MDCs are below. None of them mentions this idea. I asked at the time if anyone at PGP planned to fix MDCs and Hal responded: Hal wrote in Jul 98: > There is no plan to add MAC or other lightweight signatures to PGP 6.0. > That may go into a future version. As far as I recall Hal's recent posting of PRZs "hash inside enc envelope" was the first time I have seen that proposal. As none of the posts to the list mention the proposal in question I can't see how you can claim there was a concensus for it on list "last year". I have no idea what was discussed at the Orlando meeting, because as I said, no minutes were ever published that I found. These were all made around July 1998: Tom: > Unless they do something nonsensical, it would be easy to extend 1.0 - for > example, a signature algorithm of 0 means the message digest is stored in > the clear (maybe as a MPI), and leave the rest of the format alone. Old > implmentations should fail gracefully with "unknown signature algorithm". > The onepass signature header lets the "MAC" be at the end yet insures that > someone can't just delete the "MAC". Adam in response to Toms above proposal: > The most important aspect of this, as Tom suggested, is that > openPGP-1.0 should gracefully cope with this (and other similar) > unknown signature packets, by still emitting plaintext. > > I suggest that we consider reserving a packet number for MDC/Integrity > check purposes. Jon in response to Adam: > If you can design something that is wholly backwards-compatible, it'll be > trivial to put it in 1.1 or simple document it as an extension. Not being > in 1.0 won't be an issue > > If you can't design something backward compatible, then it's too late to go > in 1.0. Either way, it doesn't make it. So after arguing against the idea of reserving an MDC packet in Jul 98, and saying it'll be trivial to make something backwards compatible with 1.0 without doing so, you then argue the reverse now, when Tom, Werner and I bring up Tom's earlier proposal for this which would have benefited from reserving a verification packet ID. Adam -- print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Thu, 22 Apr 1999 17:18:12 -0700 (PDT) Received: from reason.omnigroup.com (reason [198.151.161.25]) by ignem.omnigroup.com (8.8.5/8.8.5) with SMTP id RAA07312; Thu, 22 Apr 1999 17:19:22 -0700 (PDT) Message-Id: <199904230019.RAA07312@ignem.omnigroup.com> Received: by reason.omnigroup.com (NX5.67g/NX3.0X) id AA16307; Thu, 22 Apr 99 17:19:29 -0700 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.2mach v148) In-Reply-To: <6BC5E520D4A4D11184A200A0C99D8FBE02EF2EB9@ca-exchange1.nai.com> X-Nextstep-Mailer: Mail 4.2mach (Enhance 2.1) Received: by NeXT.Mailer (1.148) From: William Lewis Date: Thu, 22 Apr 99 17:19:28 -0700 To: "Salzman, Noah" Subject: Re: typo? Cc: ietf-open-pgp@imc.org References: <6BC5E520D4A4D11184A200A0C99D8FBE02EF2EB9@ca-exchange1.nai.com> X-Pgp-Id: 0x27F772C1 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: You wrote: > The generator constant in the code sample has a "1" that is not in the > preceding text. CRC polynomials are usually written without the leading term. Whether the constant in the code has the term is an implementation detail --- for example, if the CRC width is the same as the word width (e.g. a CRC-32), it's easier and faster not to write it that way. I'd recommend ftp://ftp.rocksoft.com/clients/rocksoft/papers/crc_v3.txt as an introduction to theoretical and practical aspects of CRCs. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA04051 for ietf-open-pgp-bks; Thu, 22 Apr 1999 16:44:48 -0700 (PDT) Received: from 226-132.adsl2.avtel.net (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA04047 for ; Thu, 22 Apr 1999 16:44:47 -0700 (PDT) Received: (from hal@localhost) by 226-132.adsl2.avtel.net (8.8.7/8.8.7) id QAA04511; Thu, 22 Apr 1999 16:45:25 -0700 Date: Thu, 22 Apr 1999 16:45:25 -0700 From: hal@rain.org Message-Id: <199904222345.QAA04511@226-132.adsl2.avtel.net> To: ietf-open-pgp@imc.org, Noah_Salzman@NAI.com Subject: Re: typo? Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Noah - I think that is OK. CRC24_POLY is used in the sample code as: if (crc & 0x1000000) crc ^= CRC24_POLY; So the extra "1" in CRC24_POLY is actually there to clear the "1" in the crc variable. It might have been clearer to define CRC24_POLY without the "1" and then to do if (crc & 0x1000000) crc ^= CRC24_POLY | 0x1000000; or even if (crc & 0x1000000) { crc &= 0xffffff; crc ^= CRC24_POLY; } but it works out the same. Hal Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA03844 for ietf-open-pgp-bks; Thu, 22 Apr 1999 16:28:01 -0700 (PDT) Received: from praseodumium (praseodumium.btinternet.com [194.73.73.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA03840 for ; Thu, 22 Apr 1999 16:28:00 -0700 (PDT) Received: from [195.99.63.78] (helo=server.eternity.org) by praseodumium with esmtp (Exim 2.05 #1) id 10aSqS-00024S-00; Fri, 23 Apr 1999 00:25:24 +0100 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id AAA13142; Fri, 23 Apr 1999 00:06:07 +0100 Date: Fri, 23 Apr 1999 00:06:07 +0100 Message-Id: <199904222306.AAA13142@server.eternity.org> From: Adam Back To: tzeruch@ceddec.com CC: jon@callas.org, ietf-open-pgp@imc.org In-reply-to: <99Apr22.134631edt.42113@brickwall.ceddec.com> (tzeruch@ceddec.com) Subject: Re: Message Integrity Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Tom writes: > On Thu, 22 Apr 1999, Adam Back wrote: > > > I also like Tom's suggestion of using algorithm ID 0 for signature. > > Adds conotations of "no signature algorithm". Nice. Why don't you > > try implementing that in your PGP implementation Tom? It should come > > out as fewer lines, and simpler code than the other method. > > The patch is now 83 lines affecting 3 files (sigchk sigmak elitmk). I > think the DER version would be a few more, and it took less than 30 > minutes. Cool. > I am using a keyid of zero to trigger the MIC mode (internally I > derive the algorithm from the keyid, but I could a flag or something > else). Wasn't keyid of all 0s already reserved for another purpose. I seem to recall a discussion by Hal and others some time back about reducing the number of keyid bits to reduce identity leakage. Ultimately this came down to having an empty keyid, where the recipient would have to check on private keys on their key ring sequentialy to discover which one to use. I don't know the outcome of this old discussion. Did the variable length keyid go beyond discussions? Don't you use the algorithm ID (1 = RSA, 2 etc) as the item in the switch statement in your existing code? Couldn't you then use alg ID = 0 for no sig? Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA03724 for ietf-open-pgp-bks; Thu, 22 Apr 1999 16:19:28 -0700 (PDT) Received: from na-ex-bridge2.nai.com (na-ex-bridge2.nai.com [208.228.228.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA03720 for ; Thu, 22 Apr 1999 16:19:28 -0700 (PDT) Received: by na-ex-bridge2.nai.com with Internet Mail Service (5.5.2448.0) id <2TXAZQ44>; Thu, 22 Apr 1999 16:25:10 -0700 Message-ID: <6BC5E520D4A4D11184A200A0C99D8FBE02EF2EB9@ca-exchange1.nai.com> From: "Salzman, Noah" To: ietf-open-pgp@imc.org Subject: typo? Date: Thu, 22 Apr 1999 16:22:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Sorry to interrupt the new invigorated discussion, but is this a typo? ------------ The CRC is computed by using the generator 0x864CFB and an initialization of 0xB704CE. 6.1. An Implementation of the CRC-24 in "C" #define CRC24_INIT 0xb704ceL #define CRC24_POLY 0x1864cfbL ------------ The generator constant in the code sample has a "1" that is not in the preceding text. --Noah-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA02916 for ietf-open-pgp-bks; Thu, 22 Apr 1999 15:23:55 -0700 (PDT) Received: from 226-132.adsl2.avtel.net (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA02912 for ; Thu, 22 Apr 1999 15:23:54 -0700 (PDT) Received: (from hal@localhost) by 226-132.adsl2.avtel.net (8.8.7/8.8.7) id PAA03806; Thu, 22 Apr 1999 15:24:29 -0700 Date: Thu, 22 Apr 1999 15:24:29 -0700 From: hal@rain.org Message-Id: <199904222224.PAA03806@226-132.adsl2.avtel.net> To: aba@dcs.ex.ac.uk, tzeruch@ceddec.com Subject: Re: Message Integrity Cc: ietf-open-pgp@imc.org, jon@callas.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: tzeruch@ceddec.com writes: > The patch is now 83 lines affecting 3 files (sigchk sigmak elitmk). I > think the DER version would be a few more, and it took less than 30 > minutes. I am using a keyid of zero to trigger the MIC mode (internally I > derive the algorithm from the keyid, but I could a flag or something > else). Do you have a sense of how big the code would be to implement the MDC in the encryption layer as originally proposed? Possibly if the MDC were in a separate packet so you could identify it easily? Hal Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA02908 for ietf-open-pgp-bks; Thu, 22 Apr 1999 15:23:11 -0700 (PDT) Received: from 226-132.adsl2.avtel.net (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA02904 for ; Thu, 22 Apr 1999 15:23:09 -0700 (PDT) Received: (from hal@localhost) by 226-132.adsl2.avtel.net (8.8.7/8.8.7) id PAA03802; Thu, 22 Apr 1999 15:23:42 -0700 Date: Thu, 22 Apr 1999 15:23:42 -0700 From: hal@rain.org Message-Id: <199904222223.PAA03802@226-132.adsl2.avtel.net> To: aba@dcs.ex.ac.uk, tzeruch@ceddec.com Subject: Re: Message Integrity Cc: ietf-open-pgp@imc.org, jon@callas.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I still don't see that the signature packets are a very natural or comfortable place to put this data. We would probably use one-pass signature packets for this so that the MDC (MIC) can go at the end and the encryptor doesn't need to buffer up all the data. The format of a one-pass signature is: - version number - signature type - hash algorithm - public key algorithm - signing keyid (8 bytes) - nesting flag Most of these fields are not relevant for the MDC. We need to put a magic value into one of them (Tom is looking for all-zero keyid, others had suggested using a zero public key algorithm). The others are really not meaningful. The signature type with all its variations is not relevant; hash algorithm is unnecessary, a fixed hash algorithm is fine; public key algorithm and signing keyid aren't meaningful; nesting flag is not relevant either. Likewise, the signature packet fields are equally meaningless: - version number - length of hashed portion (must be 5) - signature type - signature creation time - key id of signer - public key algorithm - hash algorithm - left 16 bits of hash - Multi Precision Integer holding the signature Again, we have signature type, key id, public key and hash algorithms, all unnecessary or irrelevant. We have a timestamp, also inappropriate for an MDC (which is inherently a transient concept). We have the left 16 bits of the hash! Will we keep that, when we're going to be storing the hash itself in the MPI signature field? It's just going to be a copy of two bytes of the hash. Utterly pointless. And last we have the signature itself, which is the only meaningful piece of data in this entire packet, since that is where we will put the hash. We have to agree on how to encode the hash, presumably as an MPI, which implies special treatment of leading zeros. Or maybe we'll just shove the 20 bytes in there and have done with it since we're misusing the rest of the packet so badly anyway. Looking over these comments, it's clear that these packets are completely inappropriate for the use to which we are proposing to put them. This solution is a real kludge. If we absolutely, positively had to put this data into signature packets, maybe we should create a new version of the packets and use that. Or better still, use new packet types. Make the prefix packet be just a flag that the following data will be checked with a MIC. Then make the trailer packet just have the MIC in it. Simple and clean, unlike the above. Or even better, use a special encryption packet to indicate that there is a MIC (MDC) following, and a special MIC packet to hold it following the encryption packet, as Werner proposed. It is not too different from the original idea and if it would help with the implementation it seems like a reasonable method. Hal Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA02714 for ietf-open-pgp-bks; Thu, 22 Apr 1999 15:10:10 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA02710 for ; Thu, 22 Apr 1999 15:10:08 -0700 (PDT) Received: from [161.69.48.157] (161.69.48.157) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Thu, 22 Apr 1999 14:11:12 -0800 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <19990422212653.B16112@frodo.isil.d.shuttle.de> References: <99Apr22.134631edt.42113@brickwall.ceddec.com>; from tzeruch@ceddec.com on Thu, Apr 22, 1999 at 01:47:47PM -0400 <199904220825.JAA08070@server.eternity.org> <99Apr22.134631edt.42113@brickwall.ceddec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 Apr 1999 15:10:44 -0700 To: Werner Koch , ietf-open-pgp@imc.org From: Jon Callas Subject: Re: Message Integrity Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 12:26 PM -0700 4/22/1999, Werner Koch said: I'll be ready by tomorrow. For now I also just append the 20 bytes but I think it would make more sense to use a bignum. I agree. It makes sense to make it be a bignum. To be clear on this, what are you doing? I presume that this is a V4 signature, with signature type of 0 (binary document), PKALG of 0 (no public-key algorithm), hash algorithm type of the appropriate hash, no subpackets, two hash bytes that duplicate the high-order octets of the hash, and then a single MPI containing the hash. Is this correct? Jon Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA02643 for ietf-open-pgp-bks; Thu, 22 Apr 1999 15:01:37 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA02639 for ; Thu, 22 Apr 1999 15:01:34 -0700 (PDT) Received: from [161.69.48.157] (161.69.48.157) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Thu, 22 Apr 1999 14:02:37 -0800 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <199904220825.JAA08077@server.eternity.org> References: (message from Jon Callas on Wed, 21 Apr 1999 16:24:46 -0700) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 Apr 1999 15:00:17 -0700 To: Adam Back From: Jon Callas Subject: Re: consensus was not against verification packets (Re: Message Integrity) Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 1:25 AM -0700 4/22/1999, Adam Back said: Jon Callas writes: > The consensus that I've seen is against overloading message integrity on > signature packets. I disagree. Perhaps you weren't reading. Nope. The consensus that I've seen since late last year is for a new data packet that has a standard encryption mode, be it CFB or CBC, and a hash in it. What I see *now* is that you want to revise that consensus. I've seen arguments as follows: (1) The MIC-signature can ride on existing signature processing. However, it raises the question of how to handle it and public-key signatures too. The issue of wanting both MIC-sigs and PK-sigs and how they interact in a single message needs to be looked at, especially if we care about backwards compatibility. It's also allegedly easier to implement this way. I find Tom's report of how easy it is significant. It would be nice if we had someone implement both methods so they can be compared. (By the bye, it is not a goal of this working group to make it easier to tack features on to 2.X, especially now that there are two other implementations out there that can be relatively freely modified -- Tom's and Werner's. One of the OpenPGP principles is to encourage but not require compatibility with 2.X.) (2) There's a desire to deprecate PGP-CFB mode over time, and use either standard CFB or CBC mode. This requires a new data packet anyway, so why not kill two birds with one stone? (3) A MIC-signature computes a hash over the plaintext. The integrated packet computes it over the actual encrypted content, which is likely to be compressed data, and may also include a real signature. This has the advantage of providing an integrity check on the signature and compression when they're available, as well as the meta-data (mode, filename, etc.) of the literal packet. This is important in the case where a message has been damaged, and you'd like to know it is damaged before you go to the trouble of calculating the signature. It also lets you detect attacks where someone damages a signature packet, or changes unhashed data in it. These are all reasons for MICing data, do we want to lose this property? There's a compromise solution here, which is to make a separate packet type for MICing -- I forget who suggested this -- but if you're going to hash the whole packet, not just its contents, then you lose the ease-of-implementation benefit. > I confess that personally, I also question the wisdom of separating > them. Especially if it requires a shared key. What shared key? PRZ proposed SHA1 not a keyed MAC. You suggested a shared public key. Sorry, I find that a kluge. If we're willing to live with a MIC-signature that has only a hash in it, that's fine. But using a universal public key makes me wince. I'd like to see discussion of the points I laid out above. When I look at them, it seems to me that the integrated packet is the best solution. Feel free to change my mind on it. Jon Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA01214 for ietf-open-pgp-bks; Thu, 22 Apr 1999 13:02:46 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA01210 for ; Thu, 22 Apr 1999 13:02:44 -0700 (PDT) Received: from [161.69.48.157] (161.69.48.157) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Thu, 22 Apr 1999 12:03:45 -0800 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <19990422183824.B15537@frodo.isil.d.shuttle.de> References: <9904221609.AA27212@buoy.watson.ibm.com>; from uri on Thu, Apr 22, 1999 at 12:09:50PM -0400 <19990422101355.E9510@frodo.isil.d.shuttle.de> <9904221609.AA27212@buoy.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 Apr 1999 12:58:56 -0700 To: Werner Koch , ietf-open-pgp@imc.org From: Jon Callas Subject: Re: Message Integrity Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 9:38 AM -0700 4/22/1999, Werner Koch said: So we have to fix it in the RFC (I already implemented it this way). The RFC needs to be clarified, but the section I quoted before was put there to do it the way you said, with block-length IVs etc. Jon Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA01012 for ietf-open-pgp-bks; Thu, 22 Apr 1999 12:49:59 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01006 for ; Thu, 22 Apr 1999 12:49:58 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id VAA11145 for ietf-open-pgp@imc.org; Thu, 22 Apr 1999 21:51:00 +0200 (MET DST) Received: (qmail 12610 invoked from network); 22 Apr 1999 19:40:46 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 22 Apr 1999 19:40:46 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10aPJ3-0004CE-00; Thu, 22 Apr 1999 21:38:41 +0200 Date: Thu, 22 Apr 1999 21:38:40 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Phil Zimmermann's suggestion - Implementation? Message-ID: <19990422213839.C16112@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <99Apr22.125822edt.42113@brickwall.ceddec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i In-Reply-To: <99Apr22.125822edt.42113@brickwall.ceddec.com>; from tzeruch@ceddec.com on Thu, Apr 22, 1999 at 12:59:45PM -0400 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: tzeruch@ceddec.com writes: > > indefinite length, and to my mind, it's there to provide TLS-like function, > > which is probably better done with TLS. :-) > > I don't like them either, but they are there, and are perfectly valid to And there are really applications for it: What about creating a tar from a large filesystem , encrypt it, put it on tape or CD - Do you really want to use a temporary file of such a size - only to put the hash on the front? I started with GnuPG before I actually knew about OpenPGP and invented an extension to the v3 format to allow encrypting and signing of streams. There are indeed folks who encrypt large amounts of data and they don't want to waste space for temporary files. Conclusion: Partial length headers are absolutely needed. > And why wouldn't a MIC packet work, i.e. why do the 20 bytes have to be > tacked onto the end of the encryption stream without the virtual EOF and > one more packet? And why not define that we put n bytes on the end of the encryption stream and by some lucky coincident these bytes actually look like a signature/MDC packet ;-) -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA01007 for ietf-open-pgp-bks; Thu, 22 Apr 1999 12:49:58 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01001 for ; Thu, 22 Apr 1999 12:49:54 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id VAA11138 for ietf-open-pgp@imc.org; Thu, 22 Apr 1999 21:50:58 +0200 (MET DST) Received: (qmail 12604 invoked from network); 22 Apr 1999 19:29:02 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 22 Apr 1999 19:29:02 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10aP7g-0004C5-00; Thu, 22 Apr 1999 21:26:56 +0200 Date: Thu, 22 Apr 1999 21:26:56 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Message Integrity Message-ID: <19990422212653.B16112@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904220825.JAA08070@server.eternity.org> <99Apr22.134631edt.42113@brickwall.ceddec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i In-Reply-To: <99Apr22.134631edt.42113@brickwall.ceddec.com>; from tzeruch@ceddec.com on Thu, Apr 22, 1999 at 01:47:47PM -0400 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: tzeruch@ceddec.com writes: > think the DER version would be a few more, and it took less than 30 > minutes. I am using a keyid of zero to trigger the MIC mode (internally I > derive the algorithm from the keyid, but I could a flag or something I'll be ready by tomorrow. For now I also just append the 20 bytes but I think it would make more sense to use a bignum. -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA28974 for ietf-open-pgp-bks; Thu, 22 Apr 1999 10:46:55 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA28970 for ; Thu, 22 Apr 1999 10:46:54 -0700 (PDT) Received: by brickwall.ceddec.com id <42113>; Thu, 22 Apr 1999 13:46:31 -0400 Date: Thu, 22 Apr 1999 13:47:47 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars To: Adam Back cc: jon@callas.org, ietf-open-pgp@imc.org Subject: Re: Message Integrity In-Reply-To: <199904220825.JAA08070@server.eternity.org> Message-Id: <99Apr22.134631edt.42113@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Thu, 22 Apr 1999, Adam Back wrote: > I also like Tom's suggestion of using algorithm ID 0 for signature. > Adds conotations of "no signature algorithm". Nice. Why don't you > try implementing that in your PGP implementation Tom? It should come > out as fewer lines, and simpler code than the other method. The patch is now 83 lines affecting 3 files (sigchk sigmak elitmk). I think the DER version would be a few more, and it took less than 30 minutes. I am using a keyid of zero to trigger the MIC mode (internally I derive the algorithm from the keyid, but I could a flag or something else). (Though I need to add a test to switch from "signature" to "MIC"). Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA28652 for ietf-open-pgp-bks; Thu, 22 Apr 1999 10:26:12 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA28648 for ; Thu, 22 Apr 1999 10:26:11 -0700 (PDT) Received: by brickwall.ceddec.com id <42113>; Thu, 22 Apr 1999 13:25:47 -0400 Date: Thu, 22 Apr 1999 13:27:10 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars To: Adam Back cc: jon@callas.org, ietf-open-pgp@imc.org Subject: Re: Message Integrity In-Reply-To: <199904220825.JAA08070@server.eternity.org> Message-Id: <99Apr22.132547edt.42113@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Thu, 22 Apr 1999, Adam Back wrote: > I also like Tom's suggestion of using algorithm ID 0 for signature. > Adds conotations of "no signature algorithm". Nice. Why don't you > try implementing that in your PGP implementation Tom? It should come > out as fewer lines, and simpler code than the other method. You > should be able to post the patch (export control wise) because it is > authentication only. There is only one detail. Do we use the DER prefix with the 0 and 1 so it looks like a standard bignum signature, or do we just use the 20 bytes? Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA28261 for ietf-open-pgp-bks; Thu, 22 Apr 1999 09:58:49 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA28257 for ; Thu, 22 Apr 1999 09:58:48 -0700 (PDT) Received: by brickwall.ceddec.com id <42113>; Thu, 22 Apr 1999 12:58:22 -0400 Date: Thu, 22 Apr 1999 12:59:45 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars To: Jon Callas cc: hal@rain.org, ietf-open-pgp@imc.org, prz@pgp.com Subject: Re: Phil Zimmermann's suggestion - Implementation? In-Reply-To: Message-Id: <99Apr22.125822edt.42113@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Wed, 21 Apr 1999, Jon Callas wrote: > Tom, again -- unless the data is of indefinite-length, you *know* how long > the thing is, and you just subtract 20 from the length you hash. Won't that > work? Yes, but the specification says that either packet format is valid and most current implementations use the indefinite length format for any potentially unknown length stream (e.g. encrypt stdin). Ask Hal or someone else how easy it would be to make PGP 6.x do definite length formats by default. I simply asked if the 20 bytes of hash could be put at the front instead of the end (a similar problem since if you have to rewind to put the length in the fields, you could just move a few bytes forward and put the hash data at the beginning). In short, if you have definite length packets, there is probably no penalty for putting the hash at the beginning. > And if indefinite length is a problem, we can always say you can't use > indefinite length with a MICed packet. I have no especial love for > indefinite length, and to my mind, it's there to provide TLS-like function, > which is probably better done with TLS. :-) I don't like them either, but they are there, and are perfectly valid to use for any packet and add this given functionality. If we start to get rid of these, we may as well depricate their use in future releases. And why wouldn't a MIC packet work, i.e. why do the 20 bytes have to be tacked onto the end of the encryption stream without the virtual EOF and one more packet? Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA28129 for ietf-open-pgp-bks; Thu, 22 Apr 1999 09:49:56 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA28125 for ; Thu, 22 Apr 1999 09:49:54 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id SAA26573 for ietf-open-pgp@imc.org; Thu, 22 Apr 1999 18:50:56 +0200 (MET DST) Received: (qmail 12262 invoked from network); 22 Apr 1999 16:40:32 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 22 Apr 1999 16:40:32 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10aMUb-00047k-00; Thu, 22 Apr 1999 18:38:25 +0200 Date: Thu, 22 Apr 1999 18:38:25 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Message Integrity Message-ID: <19990422183824.B15537@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <19990422101355.E9510@frodo.isil.d.shuttle.de> <9904221609.AA27212@buoy.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i In-Reply-To: <9904221609.AA27212@buoy.watson.ibm.com>; from uri on Thu, Apr 22, 1999 at 12:09:50PM -0400 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: uri writes: > Werner Koch says: > > However, to come to a solution we should use the > > IV|checkbytes|plaintext|SHA1 > > proposal and assign a new packet type to it (and add a version number > > just in case we want to change it again). > > If the above is the *plaintext* - I agree. I personally like Sure. > implicit IV=0x00...0 and the plaintext prepended with random > 128 bits. So do I, s/IV/random_bytes/ > NO! With 128-bit cipher you MUST use 128-bit IV. [I understand it's So we have to fix it in the RFC (I already implemented it this way). -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA27840 for ietf-open-pgp-bks; Thu, 22 Apr 1999 09:30:58 -0700 (PDT) Received: from 226-132.adsl2.avtel.net (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA27836 for ; Thu, 22 Apr 1999 09:30:56 -0700 (PDT) Received: (from hal@localhost) by 226-132.adsl2.avtel.net (8.8.7/8.8.7) id JAA03006; Thu, 22 Apr 1999 09:31:33 -0700 Date: Thu, 22 Apr 1999 09:31:33 -0700 From: hal@rain.org Message-Id: <199904221631.JAA03006@226-132.adsl2.avtel.net> To: ietf-open-pgp@imc.org, wk@isil.d.shuttle.de Subject: Re: Message Integrity Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Werner Koch, , writes: > However, to come to a solution we should use the > IV|checkbytes|plaintext|SHA1 > proposal and assign a new packet type to it (and add a version number > just in case we want to change it again). > > How do we handle secret key material encryption with 128 bit > blocksizes? Increase the IV in the packet to the blocksize or keep > it at 8 bytes? I think for consistency and simplicity we should have all IVs be the cipher's blocksize. In the old-style encryption packets this is a necessity, as I pointed out earlier. It also simplifies implementation in that you can just point at the IV in the packet and load it into the cipher. With 8 byte IVs I had to move the 8 bytes into a buffer and zero the other 8 bytes to have a nice 16-byte block of data that I could pass to the encryption algorithm. Hal Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA27562 for ietf-open-pgp-bks; Thu, 22 Apr 1999 09:12:27 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA27558 for ; Thu, 22 Apr 1999 09:12:26 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id MAA06252; Thu, 22 Apr 1999 12:13:16 -0400 Received: from buoy.watson.ibm.com (buoy.watson.ibm.com [9.2.3.94]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id MAA08338; Thu, 22 Apr 1999 12:13:16 -0400 Received: by buoy.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA27242; Thu, 22 Apr 1999 12:13:15 -0400 From: uri Message-Id: <9904221613.AA27242@buoy.watson.ibm.com> Subject: Re: consensus was not against verification packets (Re: Message Integrity) To: aba@dcs.ex.ac.uk (Adam Back) Date: Thu, 22 Apr 1999 12:13:15 -0400 (EDT) Cc: jon@callas.org, ietf-open-pgp@imc.org In-Reply-To: <199904220825.JAA08077@server.eternity.org> from "Adam Back" at Apr 22, 99 09:25:51 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Adam Back says: > Hal Finney presented the bundled MDC+encrypt approach, and did a > trial implementation. > > Uri Watson at first argued against verification packets based on ease > of implementing bundled MDC+enc, but revised that to neutral, viz:... Hmmm, It's Uri BLUMENTHAL (who happens to work at Watson Research Center :-). [Though I'm sure old Thomas Watson would be proud if I were to adopt his family name :-] -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA27518 for ietf-open-pgp-bks; Thu, 22 Apr 1999 09:09:12 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA27514 for ; Thu, 22 Apr 1999 09:09:10 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id MAA08796; Thu, 22 Apr 1999 12:09:52 -0400 Received: from buoy.watson.ibm.com (buoy.watson.ibm.com [9.2.3.94]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id MAA12552; Thu, 22 Apr 1999 12:09:52 -0400 Received: by buoy.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA27212; Thu, 22 Apr 1999 12:09:51 -0400 From: uri Message-Id: <9904221609.AA27212@buoy.watson.ibm.com> Subject: Re: Message Integrity To: wk@isil.d.shuttle.de (Werner Koch) Date: Thu, 22 Apr 1999 12:09:50 -0400 (EDT) Cc: ietf-open-pgp@imc.org In-Reply-To: <19990422101355.E9510@frodo.isil.d.shuttle.de> from "Werner Koch" at Apr 22, 99 10:13:56 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Werner Koch says: > However, to come to a solution we should use the > IV|checkbytes|plaintext|SHA1 > proposal and assign a new packet type to it (and add a version number > just in case we want to change it again). If the above is the *plaintext* - I agree. I personally like implicit IV=0x00...0 and the plaintext prepended with random 128 bits. > How do we handle secret key material encryption with 128 bit > blocksizes? Increase the IV in the packet to the blocksize or keep > it at 8 bytes? NO! With 128-bit cipher you MUST use 128-bit IV. [I understand it's coming across rather strong - but then, how much is your security worth to you?] -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA12590 for ietf-open-pgp-bks; Thu, 22 Apr 1999 01:26:33 -0700 (PDT) Received: from mail9.svr.pol.co.uk (mail9.svr.pol.co.uk [195.92.193.22]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA12586 for ; Thu, 22 Apr 1999 01:26:32 -0700 (PDT) Received: from modem-88.cesium.dialup.pol.co.uk ([62.136.27.88] helo=server.eternity.org) by mail9.svr.pol.co.uk with esmtp (Exim 2.12 #1) id 10aEpV-0003yl-00; Thu, 22 Apr 1999 09:27:30 +0100 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id JAA08070; Thu, 22 Apr 1999 09:25:18 +0100 Date: Thu, 22 Apr 1999 09:25:18 +0100 Message-Id: <199904220825.JAA08070@server.eternity.org> From: Adam Back To: tzeruch@ceddec.com CC: jon@callas.org, ietf-open-pgp@imc.org In-reply-to: <99Apr21.203948edt.42113@brickwall.ceddec.com> (message from Tom Zerucha on Wed, 21 Apr 1999 20:41:07 -0400) Subject: Re: Message Integrity Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Tom Zerucha writes: > On Wed, 21 Apr 1999, Jon Callas wrote: > > > My apologies for not jumping in here sooner. > > > > The consensus that I've seen is against overloading message integrity on > > signature packets. We also discussed it in Orlando, and there was great > > consensus against it there. I confess that personally, I also question the > > wisdom of separating them. Especially if it requires a shared key. > > Or a well defined "anonymous" sign-only key, which is what I think Adam > Back was proposing. Yes that was a third proposal, which has the advantage over the other two that it works with out changing old software, and new software could be setup to regonize the defined keys, and display different messages on that basis. I also like Tom's suggestion of using algorithm ID 0 for signature. Adds conotations of "no signature algorithm". Nice. Why don't you try implementing that in your PGP implementation Tom? It should come out as fewer lines, and simpler code than the other method. You should be able to post the patch (export control wise) because it is authentication only. There is a potential problem with shared key, we would need to be absolutely sure that people did not erroneously include certificates made by it in the WoT calculation. Distributing it with trust parameter of 0 might work. It would need to be looked at further wrt the major implementations behaviour. Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA12581 for ietf-open-pgp-bks; Thu, 22 Apr 1999 01:26:28 -0700 (PDT) Received: from mail9.svr.pol.co.uk (mail9.svr.pol.co.uk [195.92.193.22]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA12577 for ; Thu, 22 Apr 1999 01:26:26 -0700 (PDT) Received: from modem-88.cesium.dialup.pol.co.uk ([62.136.27.88] helo=server.eternity.org) by mail9.svr.pol.co.uk with esmtp (Exim 2.12 #1) id 10aEpT-0003yl-00; Thu, 22 Apr 1999 09:27:28 +0100 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id JAA08077; Thu, 22 Apr 1999 09:25:51 +0100 Date: Thu, 22 Apr 1999 09:25:51 +0100 Message-Id: <199904220825.JAA08077@server.eternity.org> From: Adam Back To: jon@callas.org CC: ietf-open-pgp@imc.org In-reply-to: (message from Jon Callas on Wed, 21 Apr 1999 16:24:46 -0700) Subject: consensus was not against verification packets (Re: Message Integrity) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Jon Callas writes: > The consensus that I've seen is against overloading message integrity on > signature packets. I disagree. Perhaps you weren't reading. Tom Zerucha and Werner Koch sounded like they were going to try out verification packets. I argued for the approach also. Hal Finney presented the bundled MDC+encrypt approach, and did a trial implementation. Uri Watson at first argued against verification packets based on ease of implementing bundled MDC+enc, but revised that to neutral, viz: Tom wrote: > Uri wrote: > > If you want an MDC, and there is already a place for MDCs, then it should > > go there if the format can be adapted. > > OK, I don't object as strongly any more. I'm neutral now. So I tally that as 3 verify packet, one bundled MDC+encrypt, and one neutral. You breeze in late and call that a concensus for MDC+encrypt? > We also discussed it in Orlando, and there was great consensus > against it there. I wasn't at Orlando. No minutes were ever posted that I discovered. Decisions are supposed to be made on list. > I confess that personally, I also question the wisdom of separating > them. Especially if it requires a shared key. What shared key? PRZ proposed SHA1 not a keyed MAC. Adam -- print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Thu, 22 Apr 1999 01:20:09 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id KAA29853 for ietf-open-pgp@imc.org; Thu, 22 Apr 1999 10:21:01 +0200 (MET DST) Received: (qmail 10579 invoked from network); 22 Apr 1999 08:16:08 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 22 Apr 1999 08:16:08 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10aEcO-0002Tx-00; Thu, 22 Apr 1999 10:13:56 +0200 Date: Thu, 22 Apr 1999 10:13:56 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Message Integrity Message-ID: <19990422101355.E9510@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i In-Reply-To: ; from Jon Callas on Wed, Apr 21, 1999 at 04:24:46PM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Jon Callas writes: > hash. I am willing to write in there that if the packet is coded with > indefinite length, the last chunk MUST include at least one byte of data > and the 20-byte hash. Does this help any implementation problems? Tom? Hal? No, it would make thinks even more worse. In my implementation the encryption layer does not know about things like packet length or wehter a packet uses partial length headers. Requiring that the last chunk must be at least 20 bytes would need some special hacks to allow it. There is an explicit statement, that the last chunk may even have a length of zero. I'd prefer an extra MIC packet which can be handled nearly the same as a signature packet and has the advantage of easier implementation (no delay line), usable with 64 bit blocksizes too, extendable to be used for file attributes (although I think, this has to go to the literal data packet). However, to come to a solution we should use the IV|checkbytes|plaintext|SHA1 proposal and assign a new packet type to it (and add a version number just in case we want to change it again). How do we handle secret key material encryption with 128 bit blocksizes? Increase the IV in the packet to the blocksize or keep it at 8 bytes? -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA12073 for ietf-open-pgp-bks; Thu, 22 Apr 1999 00:50:29 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA12068 for ; Thu, 22 Apr 1999 00:50:21 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id JAA26587 for ietf-open-pgp@imc.org; Thu, 22 Apr 1999 09:51:17 +0200 (MET DST) Received: (qmail 10477 invoked from network); 22 Apr 1999 07:49:45 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 22 Apr 1999 07:49:45 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10aECr-0002Tm-00; Thu, 22 Apr 1999 09:47:33 +0200 Date: Thu, 22 Apr 1999 09:47:33 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: new approach to MDCs: single shared private key Message-ID: <19990422094732.D9510@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904211307.OAA04701@server.eternity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i In-Reply-To: <199904211307.OAA04701@server.eternity.org>; from Adam Back on Wed, Apr 21, 1999 at 02:07:54PM +0100 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Adam Back writes: > all we have to do is publish and agree upon a minimal sized > RSA public and private key and publish it. But not before Sep 20th, 2000. Or we would have to make it optional. -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA16613 for ietf-open-pgp-bks; Wed, 21 Apr 1999 17:41:06 -0700 (PDT) Received: from 226-132.adsl2.avtel.net (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA16609 for ; Wed, 21 Apr 1999 17:41:05 -0700 (PDT) Received: (from hal@localhost) by 226-132.adsl2.avtel.net (8.8.7/8.8.7) id RAA02217; Wed, 21 Apr 1999 17:41:34 -0700 Date: Wed, 21 Apr 1999 17:41:34 -0700 From: hal@rain.org Message-Id: <199904220041.RAA02217@226-132.adsl2.avtel.net> To: hal@rain.org, ietf-open-pgp@imc.org, jon@callas.org Subject: Re: Message Integrity Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Just to clarify, I did not mean to suggest that the hash would be at the beginning. I agree that it is better to put it at the end, to facilitate one pass operation. What I meant to emphasize was that the hash would be encrypted, along with the plaintext. The input to the encryption would look like: checkbytes plaintext hash This would all be encrypted to form the ciphertext. The packet would then look like: IV ciphertext Sorry if I was unclear. Hal Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA16594 for ietf-open-pgp-bks; Wed, 21 Apr 1999 17:40:20 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA16590 for ; Wed, 21 Apr 1999 17:40:18 -0700 (PDT) Received: by brickwall.ceddec.com id <42113>; Wed, 21 Apr 1999 20:39:48 -0400 Date: Wed, 21 Apr 1999 20:41:07 -0400 From: Tom Zerucha X-Sender: nobody@mars To: Jon Callas cc: ietf-open-pgp@imc.org Subject: Re: Message Integrity In-Reply-To: Message-Id: <99Apr21.203948edt.42113@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Wed, 21 Apr 1999, Jon Callas wrote: > My apologies for not jumping in here sooner. > > The consensus that I've seen is against overloading message integrity on > signature packets. We also discussed it in Orlando, and there was great > consensus against it there. I confess that personally, I also question the > wisdom of separating them. Especially if it requires a shared key. Or a well defined "anonymous" sign-only key, which is what I think Adam Back was proposing. > A scheme that has been discussed, and I thought we had a lot of agreement > on even back in Orlando was to solve (1) and (2) with a new encrypted data > packet that used a standard encryption mode and appended a hash at the end. > I've been in discussion with several people who've offered several opinions > on what that hash can or should be, and I believe that the best thing to do > is just make it a SHA-1 hash, as a minimal OpenPGP implementation must > already have SHA-1 in it. No one who's done any work on it has come up with > a different solution that is better. When was the Orlando meeting and who attended? New packet types should be avoided if only because you cannot tell what old implmentations will do with them. They would know that they cannot handle a new algorithm in an existing packet type because they would know it was an encryption packet. I don't think anyone objects to using SHA-1 for the purpose of a MIC. > I really don't like overloading MICs on signature packets. That's a kluge, > and it offends my sensitive architect's aesthetics. OpenPGP already has > quite enough kluges in it. I'd prefer to stomp on a few rather than add > another. Adding in shared keys makes it a worse kluge. I can't see what > goodness comes from a null-signature packet. Throwing 20 bytes at the end of a stream instead of making it a packet is a worse kluge (imho). A standard anonymous key assigned to "MIC validation only" wouldn't make it worse and would allow this functionality in a method that is actually compatable with existing implementations. The goodness is that the code is there (and hopefully tested), so that the information - the hash result (which is already computed for signatures when they are present) is simply inserted without the signature computation step. This takes only a few lines of code in most implementations - the addition of a non-signature algorithm ID. (I would suggest ID 0 since it implied a null algorithm at one point). We could be doing interoperability tests on MICs using existing algorithms next week. > I've been waiting for someone else to create this packet, and I'm tired of > waiting, so here's *my* definition of it. This new packet is like Packet 9 > in semantics but consists of: > > - Encrypted data, the output of the selected symmetric-key cipher > operating in (XXX) mode. Use the existing packet. Specify a new algorithm number. Or will no one ever want to do 3DES, CAST, or IDEA encryption with MIC? Will the REQUIRED algorithms include this new algorithm? Unless you do, this is the only way you are going to get a MIC. If you don't, but want the MIC to be SHOULD, the new packet ID is an old packet (maybe with other fixes) but with appended MIC. And I don't see the new algorithm(s) being adopted that quickly. When is SSL going to have Twofish? > - A 20-octet SHA-1 of the plaintext contents of the packet. Note that if > the contents of the encrypted packet is another packet (or packets), the > hash runs over the whole of them. If you must do this outside of the existing signature packet, then make just this the new packet, potentially with a corresponding 1-pass header packet. > I confess that I am concerned about the possible implementation > difficulties here, but I'm also confused, because I don't see the problem. > Unless the packet is encoded with indefinite length, you know how long the > thing is. So you just subtract 20 from the length, and you know how much to > hash. I am willing to write in there that if the packet is coded with > indefinite length, the last chunk MUST include at least one byte of data > and the 20-byte hash. Does this help any implementation problems? Tom? Hal? > Werner? Every encryption packet since 5.0 in many implementations uses the indefinite length format. So start by assuming every packet in this new format is going to be (for the same reason Encrypters don't want to put the 20 bytes up front - it requries a rewind operation so it won't work on a stream - the old CTB/length had to be rewound to). Your proposal adds a problem to the encryptor since the minimum indefinite length byte is 512, so what if there are 500 bytes left? You could simply make the buffer 512+20 bytes and emit a end packet with the final length, so it isn't that bad, but must be watched for. Further, there is no "validation" routine at the end of the existing decryptors. The good/bad message handler will have to be added and identify the encryption layer as detecting the fault. If you complain that signatures are a different class of validation, I would counter that encryption is a different phylum. But no one has said why the MIC can't simply be in its own packet, so I get the virtual EOF for the encryption stream, then see the MIC packet (i.e. a current signature packet with lots of stuff removed and a different number) and pull 20 bytes from it. So you have a separate packet and packet handler. It would be a MIC layer between the signature and encryption layers. Doing exactly one less step than the signature layer. Let me throw in one more complication. The above formats generally have fixed length, so you know where all the bytes are. Extending to validation packets would make the boundary where the end of message is hard to find. I don't understand how adding a new packet type with a new method (encryption-cum-MIC) with new algorithm IDs and formats which are all still undefined is less a kludge than simply using a new algorithm ID for the new encryption algorithm, and specifying Algorithm 0 and storing the SHA1 result as a plain MPI in the existing structure. Everyone really wants new code, new layers, new specifiers? I don't like writing code that much, and I prefer simplicity. And having existing working, tested code as a base is better than ex-nihilo code. Does anyone have any functional problems (e.g. security holes) with modifying the existing signature packet into a validation packet? Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA16529 for ietf-open-pgp-bks; Wed, 21 Apr 1999 17:34:09 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA16525 for ; Wed, 21 Apr 1999 17:34:07 -0700 (PDT) Received: from [38.232.7.6] (161.69.48.157) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Wed, 21 Apr 1999 16:35:07 -0800 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <99Apr21.193656edt.42113@brickwall.ceddec.com> References: <199904210548.WAA00726@226-132.adsl2.avtel.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Apr 1999 17:34:58 -0700 To: tzeruch@ceddec.com, hal@rain.org From: Jon Callas Subject: Re: Phil Zimmermann's suggestion - Implementation? Cc: ietf-open-pgp@imc.org, prz@pgp.com Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Tom, again -- unless the data is of indefinite-length, you *know* how long the thing is, and you just subtract 20 from the length you hash. Won't that work? And if indefinite length is a problem, we can always say you can't use indefinite length with a MICed packet. I have no especial love for indefinite length, and to my mind, it's there to provide TLS-like function, which is probably better done with TLS. :-) Jon Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA16454 for ietf-open-pgp-bks; Wed, 21 Apr 1999 17:27:12 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA16449 for ; Wed, 21 Apr 1999 17:27:10 -0700 (PDT) Received: from [38.232.7.6] (161.69.48.157) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Wed, 21 Apr 1999 16:28:09 -0800 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <199904220012.RAA02112@226-132.adsl2.avtel.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Apr 1999 17:27:58 -0700 To: hal@rain.org, ietf-open-pgp@imc.org From: Jon Callas Subject: Re: Message Integrity Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 5:12 PM -0700 4/21/1999, hal@rain.org said: I did make a proposal for a format, to wit: : The first thing in the packet would be the IV, of a size equal to the : block size of the cipher. It would be followed by the ciphertext, which : would be handled in CFB-n mode, where n is the block size of the cipher. : There would be no special shift or sync operations. : : The plaintext would be prepended with a header consisting of check bytes : so that the proper key can be detected. The check bytes could be two : random bytes, followed by the same two bytes, repeated. : : The plaintext would be followed by a SHA-1 hash of the plaintext data. : This would be checked after decryption and detect message modification : attacks. I proposed to put check bytes before the plaintext so that we can tell when we have the right decryption key. This is important in some cases, notably following symmetric ESK packets which don't have any internal check bytes in them. It is important to make it clear that the SHA-1 hash gets encrypted along with the plaintext data. Otherwise it could leak info about the plaintext. Mea culpa. Please forgive me. I obviously was on a mental lunch break. Okay -- I thought the hash would be at the end, rather than the front, just for one-passedness. OpenPGP tends to do that, to make it easy to pipeline, and I would have thought that would mean hash at the end. Either way is fine with me. Does anyone else have a preference? As I said, I didn't particularly have difficulties even in the general case, by using an extra buffer. I don't really like putting restrictions on the indefinite length encoding for this case, when we don't have them anywhere else. But if it would really make a difference for other implementations, we could consider it. If we do it, it should be sufficient to require that the whole hash be in one chunk (which will automatically be the last one), not to also require an extra byte of data. This is enough that the decryptor will always know when he is looking at data which is part of the hash. That data is never broken up, and it is always in the final subpacket, which is recognizable in our encoding. Furthermore, this should not be a significant constraint on the encryption end. I wouldn't expect anyone to need to output the hash in more than one packet. You get the hash in one step, and you have all the info you need to put it into a packet. We do have one, that the first indefinite packet must be at least 512 bytes. But nonetheless, no restrictions are better than some, and if the hash is at the front, then there's no problem. My suggestion was just to make it easier for implementors, and if it doesn't, we don't need it. Merely keeping the hash whole is also just fine with me. Jon Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA16276 for ietf-open-pgp-bks; Wed, 21 Apr 1999 17:11:52 -0700 (PDT) Received: from 226-132.adsl2.avtel.net (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA16272 for ; Wed, 21 Apr 1999 17:11:50 -0700 (PDT) Received: (from hal@localhost) by 226-132.adsl2.avtel.net (8.8.7/8.8.7) id RAA02112; Wed, 21 Apr 1999 17:12:21 -0700 Date: Wed, 21 Apr 1999 17:12:21 -0700 From: hal@rain.org Message-Id: <199904220012.RAA02112@226-132.adsl2.avtel.net> To: ietf-open-pgp@imc.org, jon@callas.org Subject: Re: Message Integrity Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Jon Callas, , writes: > I've been waiting for someone else to create this packet, and I'm tired of > waiting, so here's *my* definition of it. This new packet is like Packet 9 > in semantics but consists of: > > - Encrypted data, the output of the selected symmetric-key cipher > operating in (XXX) mode. > > - A 20-octet SHA-1 of the plaintext contents of the packet. Note that if > the contents of the encrypted packet is another packet (or packets), the > hash runs over the whole of them. I did make a proposal for a format, to wit: : The first thing in the packet would be the IV, of a size equal to the : block size of the cipher. It would be followed by the ciphertext, which : would be handled in CFB-n mode, where n is the block size of the cipher. : There would be no special shift or sync operations. : : The plaintext would be prepended with a header consisting of check bytes : so that the proper key can be detected. The check bytes could be two : random bytes, followed by the same two bytes, repeated. : : The plaintext would be followed by a SHA-1 hash of the plaintext data. : This would be checked after decryption and detect message modification : attacks. I proposed to put check bytes before the plaintext so that we can tell when we have the right decryption key. This is important in some cases, notably following symmetric ESK packets which don't have any internal check bytes in them. It is important to make it clear that the SHA-1 hash gets encrypted along with the plaintext data. Otherwise it could leak info about the plaintext. > I confess that I am concerned about the possible implementation > difficulties here, but I'm also confused, because I don't see the problem. > Unless the packet is encoded with indefinite length, you know how long the > thing is. So you just subtract 20 from the length, and you know how much to > hash. I am willing to write in there that if the packet is coded with > indefinite length, the last chunk MUST include at least one byte of data > and the 20-byte hash. Does this help any implementation problems? Tom? Hal? > Werner? As I said, I didn't particularly have difficulties even in the general case, by using an extra buffer. I don't really like putting restrictions on the indefinite length encoding for this case, when we don't have them anywhere else. But if it would really make a difference for other implementations, we could consider it. If we do it, it should be sufficient to require that the whole hash be in one chunk (which will automatically be the last one), not to also require an extra byte of data. This is enough that the decryptor will always know when he is looking at data which is part of the hash. That data is never broken up, and it is always in the final subpacket, which is recognizable in our encoding. Furthermore, this should not be a significant constraint on the encryption end. I wouldn't expect anyone to need to output the hash in more than one packet. You get the hash in one step, and you have all the info you need to put it into a packet. Hal Finney Network Associates, Inc. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA15073 for ietf-open-pgp-bks; Wed, 21 Apr 1999 16:37:29 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA15068 for ; Wed, 21 Apr 1999 16:37:28 -0700 (PDT) Received: by brickwall.ceddec.com id <42113>; Wed, 21 Apr 1999 19:36:56 -0400 Date: Wed, 21 Apr 1999 19:38:20 -0400 From: tzeruch@ceddec.com X-Sender: nobody@mars To: hal@rain.org cc: ietf-open-pgp@imc.org, prz@pgp.com Subject: Re: Phil Zimmermann's suggestion - Implementation? In-Reply-To: <199904210548.WAA00726@226-132.adsl2.avtel.net> Message-Id: <99Apr21.193656edt.42113@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Wed, 21 Apr 1999 hal@rain.org wrote: > I have experimentally implemented the integrated message integrity > check within the encryption/decryption layer. It is not difficult to > handle the 20-byte trailing hash during decryption. I use a circular > buffer in which I put the trailing part of each chunk of decrypted data. > It always has the last 20 decrypted bytes in it. The data is passed > through the hash as we output it from this decryption layer; once we > hit EOF we take the 20 bytes in the buffer and we know those should be > matched against the calculated hash. > > I can't speak for other implementations, but I found doing it this way to > be fairly straightforward. I don't see implementation difficulty as being > a barrier to this approach, or a reason to put the integrity checking > in a pseudo-signature packet. Implementation difficulty of one thing is not a reason, but I could probably come up with hundreds of tiny little things to make it better which would add some value but bloat the code greatly after all were implemented. And we should also fix existing implementation/functional problems such as the lack of a checksum on the new sym-encrypted-sym-key packets so you have to try each key on the ciphertext. You could also create a new packet type, so the EOF would simply signal that you should look for a(n encrypted) new packet type X with 20 bytes of contents which is the hash result. Otherwise, why bother with all this packet nonsense and the CTBs and whatever in the first place? You could theoretically not have any of this and simply search backwards (or include a 2 byte tag) to the beginning of the first signature packet. There is a packet infrastructure. This should be used in one capacity or another. I make an exception for header bytes because these are either of fixed or well defined short lengths. Tacking things on the end can be made to work, but it is not a clean way to do things. We have packets with undefined types which we can add one for this function. We also have a predefined packet which is (symmetrically) encrypted as part of the existing infrastructure which in normal usage contains the same data, except in signed form so we call it a signature packet, but only because it has to this point only contained signatures. To repeat: The reason to put integrity checking in a pseudo-signature packet is because all the necessary code is ALREADY THERE, so instead of adding a 20 byte delay line you only need a new algorithm ID to identify this and an IF() test to bypass the signature validation routine. If something is already there and easily adapted it is silly to create a new layer. Sort of like an old comedy sketch when satellites were first being used to transmit TV where Mr. Smith was in the kitchen, but they flew him across the country so he could appear in Mrs. Smith's living room "live via satellite. You want to duplicate 70% of the existing signature packet infrastructure and add a delay line layer because the MDC function is not a "signature"? I want to make a 2% change to the existing signature routines that would accomplish the same function. How many lines of code did it take for your change? How much slower? Remember to add in the hash computation. And the second hash computation if there is one if the same packet is going to be signed anyway. Care to take a stab at adding that function to my opgp and count the lines as a percentage? And try my technique and count the impact on the code. Or find some reason the function fails to be accomplished by my method. If you could argue that it wouldn't work (or work well, or have security problems) I would say do it your way (except in a unique packet). > The problem with doing it in a signature packet is that it is a > fundamentally different function than signatures. The hash only provides > integrity in the context of an encryption envelope. Logically the > integrity protection is a property of the encryption layer. Doing the > hash without encryption provides no integrity protection. The signature > packet is functionally the wrong place to put it. As I pointed out, the "signature packet" can be called something different, e.g. "verification packet" or "validation packet". Had I known that a MDC feature might be added I would have raised a big stink about using the word "validation" or "verification" instead of "signature" for the packet type in the RFC "just in case we want to do something other than full signatures with it". What is being asked for is merely a proper subset of what happens to create the existing packets. It may be a fundamentally different function, but it happens at exactly the same point in the implmementation and merely omits one step - the actual crypto function to validate the signature. And if you are encrypting, these packets are encrypted along with the message. Normal messages are just the encrypted literal packet. Or encryption applied to a 1-pass validation (was signature) header, the literal packet, and the validation packet. You just have your hash over the V4 hashed material value in addition to the literal packet. Your point about requiring encryption is correct, but you can more easily have implementations reject unencrypted non-signature validation packets as providing no information, i.e. only worry about the validation if the whole came from the encryption. And are you sure that no one is going to want to add the validation or other information provided by the subpackets? (e.g. Date info - you could also add file permissions, length, etc. to the validation packet infrastructure, but not to a fixed 20 byte MAC). Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA14847 for ietf-open-pgp-bks; Wed, 21 Apr 1999 16:24:00 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA14843 for ; Wed, 21 Apr 1999 16:23:58 -0700 (PDT) Received: from [38.232.7.6] (161.69.48.157) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Wed, 21 Apr 1999 15:24:56 -0800 X-Sender: jon@merrymeet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Apr 1999 16:24:46 -0700 To: ietf-open-pgp@imc.org From: Jon Callas Subject: Message Integrity Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: My apologies for not jumping in here sooner. The consensus that I've seen is against overloading message integrity on signature packets. We also discussed it in Orlando, and there was great consensus against it there. I confess that personally, I also question the wisdom of separating them. Especially if it requires a shared key. In Orlando, there was consensus that we wanted to add several things to OpenPGP for our next RFC. They were: (1) Message Integrity Codes (a.k.a. MDCs or whatever. I've been using the term Message Integrity Code or MIC -- if people prefer the other terminology, I can write it up that way.) (2) Normalization of encryption modes. Among the solutions to this are (a) using normal CFB mode or (b) using CBC mode. I've heard from people who prefer each, and don't know if there's a consensus on which is better. I don't care. (3) Rich user IDs. (4) A V5 signature packet that allows 4-byte lengths. There's a tangential discussion to this that is to start deprecating some of the more bizarre length types, but that's a can of worms I don't want to open today. Next week. (5) A signature sub-packet that allows a certificate to declare which of the above advanced features it speaks. I've been calling this the "features" subpacket. Only (1) and (2) are germane to this present discussion. A scheme that has been discussed, and I thought we had a lot of agreement on even back in Orlando was to solve (1) and (2) with a new encrypted data packet that used a standard encryption mode and appended a hash at the end. I've been in discussion with several people who've offered several opinions on what that hash can or should be, and I believe that the best thing to do is just make it a SHA-1 hash, as a minimal OpenPGP implementation must already have SHA-1 in it. No one who's done any work on it has come up with a different solution that is better. I really don't like overloading MICs on signature packets. That's a kluge, and it offends my sensitive architect's aesthetics. OpenPGP already has quite enough kluges in it. I'd prefer to stomp on a few rather than add another. Adding in shared keys makes it a worse kluge. I can't see what goodness comes from a null-signature packet. I've been waiting for someone else to create this packet, and I'm tired of waiting, so here's *my* definition of it. This new packet is like Packet 9 in semantics but consists of: - Encrypted data, the output of the selected symmetric-key cipher operating in (XXX) mode. - A 20-octet SHA-1 of the plaintext contents of the packet. Note that if the contents of the encrypted packet is another packet (or packets), the hash runs over the whole of them. I confess that I am concerned about the possible implementation difficulties here, but I'm also confused, because I don't see the problem. Unless the packet is encoded with indefinite length, you know how long the thing is. So you just subtract 20 from the length, and you know how much to hash. I am willing to write in there that if the packet is coded with indefinite length, the last chunk MUST include at least one byte of data and the 20-byte hash. Does this help any implementation problems? Tom? Hal? Werner? Jon Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA13936 for ietf-open-pgp-bks; Wed, 21 Apr 1999 15:32:10 -0700 (PDT) Received: from merrymeet.com (Discordia@merrymeet.com [38.232.7.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA13931 for ; Wed, 21 Apr 1999 15:32:08 -0700 (PDT) Received: from [38.232.7.6] (161.69.48.157) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Wed, 21 Apr 1999 14:33:06 -0800 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <19990416182429.B21536@frodo.isil.d.shuttle.de> References: <3.0.5.32.19990416071030.0098f100>; from Michael Marking on Fri, Apr 16, 1999 at 07:10:30AM -0700 <199904141803.LAA03168@226-132.adsl2.avtel.net> <199904141803.LAA03168@226-132.adsl2.avtel.net> <19990414220947.B19463@frodo.isil.d.shuttle.de> <3.0.5.32.19990416071030.0098f100> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Apr 1999 15:21:58 -0700 To: ietf-open-pgp@imc.org From: Jon Callas Subject: Re: Restricting key sizes to mult of 64 bits Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: As has been noted, DSS requires that the keys be a multiple of 64. According to M,Vo,&V (section 11.58, p453), DSA requires this too. It says, "...the size of p can be any multiple of 64 bits between 512 and 1024 bits inclusive." They are apparently quoting FIPS 186 on this. I know that Schneier also says something similar. I think it's tacit that DSA keys need to be multiples of 64 bits. I'm willing to explicitly say this in the next revision. It is, of course, polite for an implementation to permit odd-size keys, but an implementation is permitted to reject this. I don't see any reason to restrict the key sizes on Elgamal or RSA keys. And as the owner of a 1723 bit RSA key, I'm against it. Jon Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA13724 for ietf-open-pgp-bks; Wed, 21 Apr 1999 15:10:59 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA13720 for ; Wed, 21 Apr 1999 15:10:58 -0700 (PDT) Received: from jcallas (dhcp-47-64.dhcp.nai.com [161.69.47.64]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id PAA11428; Wed, 21 Apr 1999 15:11:07 -0700 (PDT) Message-Id: <3.0.3.32.19990421150531.030b0a00@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 21 Apr 1999 15:05:31 -0700 To: "James H. Cloos Jr." , ietf-open-pgp@imc.org From: Jon Callas Subject: Re: Mixing rsa and dh/dsa In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 02:31 PM 4/13/99 -0500, James H. Cloos Jr. wrote: |Given a recipient with only an RSA keypair (algo 1), and a sender with |only a DSA/Elgamal pair (algos 17 and 16), should the sender |encrypt+sign, will any extant software be able to decrypt and verify? | If the sender has software that can do RSA, yes. If their software can't do RSA (for example, suppose they had an NAI/PGP freeware version), then the sender cannot encrypt to the recipient. Any OpenPGP-compliant version, though will be able to verify DSA sigs and encrypt to Elgamal keys. Does that answer your question? Really your question is an implementation question, not a standards question. Jon ----- Jon Callas jon@pgp.com CTO, Total Network Security 3965 Freedom Circle Network Associates, Inc. Santa Clara, CA 95054 (408) 346-5860 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA13016 for ietf-open-pgp-bks; Wed, 21 Apr 1999 14:34:14 -0700 (PDT) Received: from exeter.ac.uk (hermes.ex.ac.uk [144.173.6.14]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA13011 for ; Wed, 21 Apr 1999 14:34:13 -0700 (PDT) Received: from cronus [144.173.6.20] by hermes via SMTP (WAA02473); Wed, 21 Apr 1999 22:35:10 +0100 (BST) Date: Wed, 21 Apr 1999 22:35:10 +0100 Message-Id: <8509.199904212135@cronus> From: Adam Back To: ietf-open-pgp@imc.org Cc: cypherpunks@cyberpass.net In-reply-to: <199904211444.PAA05398@server.eternity.org> (message from Adam Back on Wed, 21 Apr 1999 15:44:29 +0100) Subject: DSS shared private key for MDCs (Re: shared private key for MDCs) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: And here is a shared private key for DSS MDCs. I had to modify pgp50i to allow it to generate smaller keys, normally it won't create DSS keys below 768 bits. It doesn't appear to be able to create DSS keys below 512 bits, and I doubt it would verify them or make sigs with them either as DSS is defined to have key sizes from 512 to 1024 bits. So the key is a 512 bit key, being the smallest (for efficiency) valid key. (I had to resort to emacs for removing the Elgamal encryption subkeys, there appears no way to remove them separately, nor create DSS keys without encryption subkeys with unix pgp 50i normally). Type Bits KeyID Created Expires Algorithm Use pub 512 0x0EE50720 1999-04-21 ---------- DSS Sign only -----BEGIN PGP PUBLIC KEY BLOCK----- Armor: arm.pl mQDiBDceN7sRAgDhsbpuoOOFhXYe8WimMwrgH6+V2IecY6mrp8RgfE/grDI3yFc4 Y6TUJirYbsTA/l7vhRBO7yMkg76op/2mF+HDAKD/n1iSgq6e8M0g2++WPUR2UVsl VwH/QRxvbzpoW4247IL8O4eqtgaDnekJg6G6hmZtcdWVX2NAfMdh3iqIK/AXdNkK Yq/P3a47Zu99GGQwZ9Fc227NvgH/bxCPd6AIUFk7orBKwYbYNljjQ1ClVEalQVLv LJTjGwIqSpwqzpvyiz1vFPpQXuhJ6iTX4FvbVqw+JeAbeBXMSbQaSW50ZWdyaXR5 IFZlcmlmaWNhdGlvbiBLZXk= -----END PGP PUBLIC KEY BLOCK----- Type Bits KeyID Created Expires Algorithm Use sec 512 0x0EE50720 1999-04-21 ---------- DSS Sign only -----BEGIN PGP SECRET KEY BLOCK----- Armor: arm.pl lQD7BDceN7sRAgDhsbpuoOOFhXYe8WimMwrgH6+V2IecY6mrp8RgfE/grDI3yFc4 Y6TUJirYbsTA/l7vhRBO7yMkg76op/2mF+HDAKD/n1iSgq6e8M0g2++WPUR2UVsl VwH/QRxvbzpoW4247IL8O4eqtgaDnekJg6G6hmZtcdWVX2NAfMdh3iqIK/AXdNkK Yq/P3a47Zu99GGQwZ9Fc227NvgH/bxCPd6AIUFk7orBKwYbYNljjQ1ClVEalQVLv LJTjGwIqSpwqzpvyiz1vFPpQXuhJ6iTX4FvbVqw+JeAbeBXMSQAAn0+t0HGYxE9p GYtIONiEqv3oJFp+Cvu0GkludGVncml0eSBWZXJpZmljYXRpb24gS2V5 -----END PGP SECRET KEY BLOCK----- And here is a conventionally encrypted message which has been signed with the above key. the conventional encrypt password is "fred" (no quotes). % echo hello world > test % pgpe -csa -zfred test -u 0x0EE50720 % cat test.asc -----BEGIN PGP MESSAGE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: /QiKruEMWv11r/vKHdrywdyCsSnuba7A pGvRemGaX2Mvw1tf2bq7hv9DoBHwPM6nt3Btd93qGJlSR1mK9y3SGBbMuZJJYCCX MxE69+VaDTMJ0+bLWVJRPTIT3J+aoKOS32XoejK5pMTx2BlvW5pWohMcQ2hL9AxA +iPKXlakHKMCT3F7Og== =PZOZ -----END PGP MESSAGE----- % and here is what is displayed by unix pgp50i when you decrypt that: % pgpv -zfred test.asc Message is encrypted. Opening file "test" type binary. Good signature made 1999-04-21 21:24 GMT by key: 512 bits, Key ID 0EE50720, Created 1999-04-21 "Integrity Verification Key" WARNING: The signing key is not trusted to belong to: Integrity Verification Key % Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA12162 for ietf-open-pgp-bks; Wed, 21 Apr 1999 12:50:13 -0700 (PDT) Received: from atanda.com ([204.162.11.9]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA12158 for ; Wed, 21 Apr 1999 12:50:12 -0700 (PDT) From: Dave@DelTor.to Received: from [192.168.248.7] (216.100.248.78) by atanda.com with ESMTP (Eudora Internet Mail Server 1.2.1); Wed, 21 Apr 1999 12:52:01 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Message-Id: In-Reply-To: <199904211307.OAA04701@server.eternity.org> References: <199904211307.OAA04701@server.eternity.org> X-PGPkeyID-Fprnt: 4AAF00E5 - 30d81f34 84e6a83f 6ec8d7f0 cab3d265 Date: Wed, 21 Apr 1999 12:46:01 -0700 To: Adam Back Subject: Re: new approach to MDCs: single shared private key Cc: ietf-open-pgp@imc.org, prz@pgp.com Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 2:07 PM +0100 1999-04-21, Adam Back wrote: >[elided] >- PRZ identified the problem that even with signed messages often the >public key is not present to verify them, so integrity is not assured. >With openPGP and pgp(5|6).x where multiple signatures can be applied, >the document could be signed by both the fixed published RSA key, and >the user's private RSA key. [...] Adam, The parallel signature extension I've added to the forthcoming OpenPGP/MIME draft will make this very easy for MIME-compliant mailers. Thomas Roessler and I are hoping to have the draft ready for the Oslo IETF in July, and we'll have it up on the list for dsicussion fairly soon. dave An excerpt: ................................. cut here ................................. 8. Parallel (Multiple) Signatures Digitally signed messages conforming to this document are denoted by the "multipart/signed" content type, defined in RFC 1847, with a "protocol" parameter which MUST have a value of "multipart/mixed". (MUST be quoted). The "micalg" parameter MUST contain a comma-separated list of hash- symbols. These hash-symbols identify the message integrity check (MIC) algorithm(s) used to generate the subsequent signature(s). Hash-symbols MUST NOT occur more than once in this list. The multipart/signed body MUST consist of exactly two parts. The first part contains the signed data in MIME canonical format, including a set of appropriate content headers describing the data. The second part MUST be of type "multipart/mixed". Each sub-part represents an individual digital signature which has been formed according to RFC 1847 and the specification of the signature protocol used. Example message: From: Dave Del Torto To: Raph Levien Mime-Version: 1.0 Content-Type: multipart/signed; protocol="multipart/mixed"; boundary=0000_031; micalg="pgp-md5,pgp-sha1,rsa-md5" --0000_031 Content-Type: text/plain Hi Raph, Here's some text with parallel (multiple) digital signatures in various formats. dave ______________________________________________________________________ "All email luxuriantly hand-crafted using only the finest ASCII text." --0000_031 Content-Type: multipart/mixed; boundary=0000_032 --0000_032 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 2.6.2 Comment: Hash computed using MD5 micalg. iQCVAwUBM0Iu16HBOF9KrwDlAQGaiQP9EU1YXgMSoNxDAqSmo7UoCE52DuYCfxm7 x8RfRr9+Xz3nPFytSYM2TIWGMeKi1fVr5PhfjdrKvOh9sCq97h6zndZVpGA9x62k mPVn/QY3fz1eOdyJbYvW4ba7WQll5OoA6cqmEb9tWwh4ra4yE8hZMnLS9a0uPpuB 5dpiTTAE/gY= =hD3D -----END PGP SIGNATURE----- --0000_032 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Comment: Hash computed using SHA-1 micalg (FIPS 180-1). iQCVAwUBM0It9qHBOF9KrwDlAQFBaQQAisIzQUgyknT2v729b7MImcUc3ROdRBh6 nwMyAfdewQYCDxqdDWvnD1UWoUjwjA1JNA6qhTXBxs8yPtZdDZaguOG2zWawyat9 Jib556AuSx10psREDC3vNsaJ99MV8SKFF92H53l9w/YhVOA0aMZeNfLE0jJVypkY /so4/7DHhqQ= =/wlj -----END PGP SIGNATURE----- --0000_032 Content-Type: application/x-pkcs7-signature Content-Transfer-Encoding: base64 Comment: Hash computed using S/MIME MD5 micalg. MIAGCSqGSIb3DQEHAqCAMIACAQExDjAMBggqhkiG9w0CBQUAMIAGCSqGSIb3DQEH [ciphertext elided] +kNIWIbxNiNje1wlzIhaGjrGrOnvYc8+tFn2LgAAAAAAAAAA --0000_032-- --0000_031-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA08571 for ietf-open-pgp-bks; Wed, 21 Apr 1999 08:00:42 -0700 (PDT) Received: from mail1.svr.pol.co.uk (mail1.svr.pol.co.uk [195.92.193.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA08566 for ; Wed, 21 Apr 1999 08:00:40 -0700 (PDT) Received: from modem-32.neodymium.dialup.pol.co.uk ([62.136.29.160] helo=server.eternity.org) by mail1.svr.pol.co.uk with esmtp (Exim 2.12 #1) id 10ZyVM-0003Y3-00; Wed, 21 Apr 1999 16:01:36 +0100 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id PAA05398; Wed, 21 Apr 1999 15:44:29 +0100 Date: Wed, 21 Apr 1999 15:44:29 +0100 Message-Id: <199904211444.PAA05398@server.eternity.org> From: Adam Back To: ietf-open-pgp@imc.org Cc: cypherpunks@cyberpass.net Subject: shared private key for MDCs Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I thought I'd have a go at testing out the shared private key approach to implementing an interity check/MDC (MDC=Modification Detection Code). pgp263i won't generate keys below 384 bits. So I compiled one without that restriction, and it seems that the the smallest key that (normal) pgp263i will create signatures for and verify signatures for, empirically is 289 bits. (This is due to the padding that must fit inside the signature: > PGP versions 2.3 and later encode the MD into the MPI as follows: > > MSB . . . LSB > > 0 1 FF(n bytes) 0 ASN(18 bytes) MD(16 bytes) > > See RFC1423 for an explanation of the meaning of the ASN string. > It is the following 18 byte long hex value: > > 3020300c06082a864886f70d020505000410 which it would seem from the above is 2+0+1+18+16=37 bytes, which is 296. It seems that the implementation lets you get away with 289, perhaps because the leading 0 is presumed on odd sized integers.) So here is a 289 bit private and public key: Type Bits/KeyID Date User ID sec 289/AADC77C5 1999/04/21 Integrity Verification Key -----BEGIN PGP SECRET KEY BLOCK----- Version: 2.6.3i lQCYAzcd278AAAEBIQGJDbfjBrve0Ips+daIHWQjgKyn5AUR8fxH6ODUATO0f6rc d8UABREAAR9Q7DxygWLqG+BDnNlYQklSmn1cSDIiDELfP2k2A/ftZzMnITsAkOK8 EHA9EkYOnR//AD2uMfL2vwCRAbvJSkV5XA6mRK2lyGNugHSWewCPRIcJHBV0F/vY OdbY0L5AgJ3RKqO0GkludGVncml0eSBWZXJpZmljYXRpb24gS2V5 =ZDof -----END PGP SECRET KEY BLOCK----- Type Bits/KeyID Date User ID pub 289/AADC77C5 1999/04/21 Integrity Verification Key Type Bits/KeyID Date User ID pub 289/AADC77C5 1999/04/21 Integrity Verification Key -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQAyAzcd278AAAEBIQGJDbfjBrve0Ips+daIHWQjgKyn5AUR8fxH6ODUATO0f6rc d8UABRG0GkludGVncml0eSBWZXJpZmljYXRpb24gS2V5 =52/E -----END PGP PUBLIC KEY BLOCK----- And here is a conventionally encrypted, uncompressed message which has been signed with the above key. the conventional encrypt password is "fred" (no quotes). % echo hello world > test % pgp -csa -zfred test -u 0xAADC77C5 % cat test.asc -----BEGIN PGP MESSAGE----- Version: 2.6.3i pgAAAGNphXbrTqYwlo9KM6gIo4182vQxkm8+cNoFVcLCxgA0x9Ibj+sbims/nFKJ VuXUQGn/MeBwvjULg4OROnz0si5jkCv8/GMOzeoeonOFi9t1twH4en/+lbe9ddV2 vxiVyGJ+Jwc= =hOMd -----END PGP MESSAGE----- and here is what is displayed by pgp263i when you decrypt that: % pgp -zfred test.asc File is conventionally encrypted. Just a moment....Pass phrase appears good. . File has signature. Public key is required to check signature. . Good signature from user "Integrity Verification Key". Signature made 1999/04/21 14:35 GMT using 289-bit key, key ID AADC77C5 % and by pgp50i when you decrypt it: % pgpv -zfred test.asc Message is encrypted. Opening file "test" type binary. Good signature made 1999-04-21 14:34 GMT by key: 289 bits, Key ID AADC77C5, Created 1999-04-21 "Integrity Verification Key" WARNING: The signing key is not trusted to belong to: Integrity Verification Key % I removed the self signature from the key because it seems pointless to self sign a key which has a published private key. Interestingly pgp263i seems to consider this key trusted due to the presence of the private key on the private key ring, whereas pgp50i considers it to have "undefined trust". Adam -- print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Wed, 21 Apr 1999 06:14:56 -0700 (PDT) Received: from modem-102.promethium.dialup.pol.co.uk ([62.136.30.102] helo=server.eternity.org) by mail15.svr.pol.co.uk with esmtp (Exim 2.12 #1) id 10Zwr0-0006Hy-00; Wed, 21 Apr 1999 14:15:50 +0100 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id OAA04701; Wed, 21 Apr 1999 14:07:54 +0100 Date: Wed, 21 Apr 1999 14:07:54 +0100 Message-Id: <199904211307.OAA04701@server.eternity.org> From: Adam Back To: ietf-open-pgp@imc.org Cc: prz@pgp.com Cc: hal@rain.org Subject: new approach to MDCs: single shared private key Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Whilst looking at RFC2440 with a view to defining suitable algorithm ids and minimal backwards compatible changes to try out the verification packet approach, in response to Werner Koch's posts, an insight struck me: all we have to do is publish and agree upon a minimal sized RSA public and private key and publish it. This allows us to provide: - the best backwards compatibility of all (allows even pgp23a to *check* MDCs, which is even better than just "not choking" on them). - the lowest implementation overhead of all (ie none!) This approach: - prevents Gary Howland's encrypted message modification attack because the signature with known public and private key performs the same function as a hash inside the encryption envelope. - it doesn't provide non-repudiation because the private key is shared (which is the whole point, we don't want non-repudiation in this scenario, and some people have good reasons for not wanting it). - any pgp2.3a and forward implementation can "implement" these MDCs merely by adding this public and private key pair to their key ring. - PRZ identified the problem that even with signed messages often the public key is not present to verify them, so integrity is not assured. With openPGP and pgp(5|6).x where multiple signatures can be applied, the document could be signed by both the fixed published RSA key, and the user's private RSA key. - The same approach of a published public and private DSA key can be used to do the same thing with DSA for implementations temporarily avoiding RSA until the patent expires. - The only extra overhead is the signature creation and verification. The key size does not affect security, so using a small a key as possible does not adversely affect security. A 384 bit key, or perhaps even 256 bit key would be perfectly adequate. (The limit will be imposed by the size of RSA block required to hold the minimum sized padded document hash.) The minimum key size that the already deployed DSA and RSA signature verification code would consider a valid signature - The keyid on the keys can be set to the string "Integrity Verification Key" to help ensure that implementations present representative messages. - These public and private keys can be distributed with new implementations, and distrubted widely on the internet. Comments? I think it is a neat, and exciting trick which allows even pgp2.3a to overcome the message modification problem with no implementation work. The only advantages of defining a different MDC packet (which is what I was in the process of doing when this occured to me) is to avoid this small computational and space overhead. Defining an elegant, space and computationally efficiient implementation at our leisure can be done once the standard RSA and DSA private and public keys are agreed upon, as an optimally backwards compatible approach can be used for old implementations. Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA15162 for ietf-open-pgp-bks; Tue, 20 Apr 1999 22:48:09 -0700 (PDT) Received: from 226-132.adsl2.avtel.net (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA15154 for ; Tue, 20 Apr 1999 22:48:07 -0700 (PDT) Received: (from hal@localhost) by 226-132.adsl2.avtel.net (8.8.7/8.8.7) id WAA00726; Tue, 20 Apr 1999 22:48:34 -0700 Date: Tue, 20 Apr 1999 22:48:34 -0700 From: hal@rain.org Message-Id: <199904210548.WAA00726@226-132.adsl2.avtel.net> To: ietf-open-pgp@imc.org, prz@pgp.com, tzeruch@ceddec.com Subject: Re: Phil Zimmermann's suggestion - Implementation? Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I have experimentally implemented the integrated message integrity check within the encryption/decryption layer. It is not difficult to handle the 20-byte trailing hash during decryption. I use a circular buffer in which I put the trailing part of each chunk of decrypted data. It always has the last 20 decrypted bytes in it. The data is passed through the hash as we output it from this decryption layer; once we hit EOF we take the 20 bytes in the buffer and we know those should be matched against the calculated hash. I can't speak for other implementations, but I found doing it this way to be fairly straightforward. I don't see implementation difficulty as being a barrier to this approach, or a reason to put the integrity checking in a pseudo-signature packet. The problem with doing it in a signature packet is that it is a fundamentally different function than signatures. The hash only provides integrity in the context of an encryption envelope. Logically the integrity protection is a property of the encryption layer. Doing the hash without encryption provides no integrity protection. The signature packet is functionally the wrong place to put it. Hal Finney NAI, Inc. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA00507 for ietf-open-pgp-bks; Tue, 20 Apr 1999 09:29:47 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA00502 for ; Tue, 20 Apr 1999 09:29:38 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id SAA06715 for ietf-open-pgp@imc.org; Tue, 20 Apr 1999 18:30:04 +0200 (MET DST) Received: (qmail 7983 invoked from network); 20 Apr 1999 16:20:42 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 20 Apr 1999 16:20:42 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10ZdDs-0001xn-00; Tue, 20 Apr 1999 18:18:08 +0200 Date: Tue, 20 Apr 1999 18:18:08 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: MDC packet Message-ID: <19990420181806.D7486@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <9904132023.AA25802@buoy.watson.ibm.com> <99Apr13.173445edt.42114@brickwall.ceddec.com> <19990414194342.A1826@frodo.isil.d.shuttle.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i In-Reply-To: <19990414194342.A1826@frodo.isil.d.shuttle.de>; from Werner Koch on Wed, Apr 14, 1999 at 07:43:42PM +0200 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Werner Koch writes: > I like Tom's proposal. If someone can define the extension to the > signature packet (or a new one) I'll add it to GnuPG ASAP. Hmmm, no comments on this for a week. Does this mean I should design a new packet or extend the signature packet specs? -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA17421 for ietf-open-pgp-bks; Fri, 16 Apr 1999 09:50:46 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA17406 for ; Fri, 16 Apr 1999 09:50:41 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id SAA26520 for ietf-open-pgp@imc.org; Fri, 16 Apr 1999 18:51:11 +0200 (MET DST) Received: (qmail 657 invoked from network); 16 Apr 1999 16:27:53 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 16 Apr 1999 16:27:53 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10YBPq-0005bc-00; Fri, 16 Apr 1999 18:24:30 +0200 Date: Fri, 16 Apr 1999 18:24:29 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Restricting key sizes to mult of 64 bits Message-ID: <19990416182429.B21536@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904141803.LAA03168@226-132.adsl2.avtel.net> <199904141803.LAA03168@226-132.adsl2.avtel.net> <19990414220947.B19463@frodo.isil.d.shuttle.de> <3.0.5.32.19990416071030.0098f100> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <3.0.5.32.19990416071030.0098f100>; from Michael Marking on Fri, Apr 16, 1999 at 07:10:30AM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Michael Marking writes: > >I can agree on a multiple of 8 bits but I don't the > >an advantage to use any other value. > > Why? Because it is the natural unit of measure on most computers. > For a given maximum key size, this restriction cuts > the available key space in half, approximately. What > effect does it have on the difficulty of an attack? I didn't mean that we need a restriction at all. -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA04032 for ietf-open-pgp-bks; Fri, 16 Apr 1999 07:17:44 -0700 (PDT) Received: from dfw-ix3.ix.netcom.com (dfw-ix3.ix.netcom.com [206.214.98.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA04028 for ; Fri, 16 Apr 1999 07:17:43 -0700 (PDT) Received: (from smap@localhost) by dfw-ix3.ix.netcom.com (8.8.4/8.8.4) id JAA10863; Fri, 16 Apr 1999 09:16:37 -0500 (CDT) Received: from ren-nv4-50.ix.netcom.com(207.94.110.50) by dfw-ix3.ix.netcom.com via smap (V1.3) id rma010726; Fri Apr 16 09:15:48 1999 Message-Id: <3.0.5.32.19990416071030.0098f100> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 16 Apr 1999 07:10:30 -0700 To: Werner Koch From: Michael Marking Subject: Re: Restricting key sizes to mult of 64 bits Cc: ietf-open-pgp@imc.org In-Reply-To: <19990414220947.B19463@frodo.isil.d.shuttle.de> References: <199904141803.LAA03168@226-132.adsl2.avtel.net> <199904141803.LAA03168@226-132.adsl2.avtel.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 10:09 PM 99/04/14 +0200, you wrote: >hal@rain.org writes: > >> At the same time, we are considering requiring that >> newly generated keys of the other types, ElGamal >> and RSA, also be multiple of 64 bits (note > >I can agree on a multiple of 8 bits but I don't the >an advantage to use any other value. Why? For a given maximum key size, this restriction cuts the available key space in half, approximately. What effect does it have on the difficulty of an attack? >> to do the RSA calculations. As it turned out, CAPI >> had a bug which prevented it from working properly >> with unusual key sizes. Those users weren't able >> to use their keys with the CAPI version. > >Working around bugs in one companies new product is a >Bad Thing to do. Discovered errors are an indicator that additional, latent errors are likely to exist. The fringe cases are often the ones which encounter the errors. If we do not permit "odd" key sizes, or other inconvenient usage, then we may allow sloppy practices which ultimately might jeopardize the security of the user. >There are many other issues we could fix for them by >changing the standards ;-). >Adding workarounds for some products which are around >for a long time is a different thing. Yes. A warning to the user, or a documented configuration option, is a much better solution. -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.5.3 iQA/AwUBNxdE1d3xSrdLzmIWEQIC/QCglPlmDWGK1lFvKHgv9I+0e8TvXkwAniSS zfdv4rzgNA1/tourvMQ5l0BO =g6pw -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA08965 for ietf-open-pgp-bks; Wed, 14 Apr 1999 13:14:56 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA08961 for ; Wed, 14 Apr 1999 13:14:54 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id WAA19227 for ietf-open-pgp@imc.org; Wed, 14 Apr 1999 22:15:18 +0200 (MET DST) Received: (qmail 30609 invoked from network); 14 Apr 1999 20:13:32 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 14 Apr 1999 20:13:31 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10XVyl-00054C-00; Wed, 14 Apr 1999 22:09:47 +0200 Date: Wed, 14 Apr 1999 22:09:47 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Restricting key sizes to mult of 64 bits Message-ID: <19990414220947.B19463@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904141803.LAA03168@226-132.adsl2.avtel.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <199904141803.LAA03168@226-132.adsl2.avtel.net>; from hal@rain.org on Wed, Apr 14, 1999 at 11:03:30AM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: hal@rain.org writes: > At the same time, we are considering requiring that newly generated keys > of the other types, ElGamal and RSA, also be multiple of 64 bits (note I can agree on a multiple of 8 bits but I don't the an advantage to use any other value. > to do the RSA calculations. As it turned out, CAPI had a bug which > prevented it from working properly with unusual key sizes. Those users > weren't able to use their keys with the CAPI version. Working around bugs in one companies new product is a Bad Thing to do. There are many other issues we could fix for them by changing the standards ;-). Adding workarounds for some products which are around for a long time is a different thing. Just my 0.02 Euros -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA07502 for ietf-open-pgp-bks; Wed, 14 Apr 1999 11:19:13 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA07498 for ; Wed, 14 Apr 1999 11:19:12 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id UAA09720 for ietf-open-pgp@imc.org; Wed, 14 Apr 1999 20:19:26 +0200 (MET DST) Received: (qmail 29983 invoked from network); 14 Apr 1999 17:45:22 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 14 Apr 1999 17:45:22 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10XThO-0000Tg-00; Wed, 14 Apr 1999 19:43:42 +0200 Date: Wed, 14 Apr 1999 19:43:42 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: MDC packet (was: Phil Zimmermann's suggestion - Implementation?) Message-ID: <19990414194342.A1826@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <9904132023.AA25802@buoy.watson.ibm.com> <99Apr13.173445edt.42114@brickwall.ceddec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <99Apr13.173445edt.42114@brickwall.ceddec.com>; from Tom Zerucha on Tue, Apr 13, 1999 at 05:36:25PM -0400 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Tom Zerucha writes: > Lets see what the other implementors have to say. If expanding the > definition of an existing packet to "verification (signature or MDC)" > packet is easy to do in the existing code base (incl NAI PGP 6.0!), we can > start implementing this now as a test. Then we would have MDCs and be > able to merge them into the spec, and both spec and code would update in I like Tom's proposal. If someone can define the extension to the signature packet (or a new one) I'll add it to GnuPG ASAP. -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA07348 for ietf-open-pgp-bks; Wed, 14 Apr 1999 11:03:36 -0700 (PDT) Received: from 226-132.adsl2.avtel.net (226-132.adsl2.avtel.net [207.71.226.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA07344 for ; Wed, 14 Apr 1999 11:03:35 -0700 (PDT) Received: (from hal@localhost) by 226-132.adsl2.avtel.net (8.8.7/8.8.7) id LAA03168 for ietf-open-pgp@imc.org; Wed, 14 Apr 1999 11:03:30 -0700 Date: Wed, 14 Apr 1999 11:03:30 -0700 From: hal@rain.org Message-Id: <199904141803.LAA03168@226-132.adsl2.avtel.net> To: ietf-open-pgp@imc.org Subject: Restricting key sizes to mult of 64 bits Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: The DSS spec requires that DSS keys be a multiple of 64 bits in size. PGP has not enforced this limitation in the past, but we are adding that now. At the same time, we are considering requiring that newly generated keys of the other types, ElGamal and RSA, also be multiple of 64 bits (note that this is only enforced on keygen). The rationale is that keys of "oddball" sizes may not be properly supported by all implementations. We want users' keys to be able to be used in a wide range of present and future implementations, possibly including non-PGP environments like smartcard systems and X.509 or SPKI. By making the key sizes a nice, round number, we improve the chances of them functioning properly in these other environments. Some users have already encountered a problem with oddly sized keys. We shipped software which used Microsoft's built-in Crypto API (CAPI) to do the RSA calculations. As it turned out, CAPI had a bug which prevented it from working properly with unusual key sizes. Those users weren't able to use their keys with the CAPI version. We would like to reduce the chance of running into similar problems in the future, and keeping keys to round sizes should help. The choice of 64 bits as the multiple is based on trading off the desire for plenty of key sizes versus minimizing the chance of an unsupported key size. The fact that DSS uses 64 bit multiples suggests that this is a reasonable value. However, there is some concern that the user and developer community may be opposed to losing this flexibility in their key size choices. I was hoping to get some feedback here about whether this change seems reasonable. OpenPGP participants have provided valuable feedback in the past regarding design decisions made by NAI, often after the fact. This time it would be helpful to find out beforehand if there will be opposition to restricting newly generated keys in this way. Thanks for your comments, Hal Finney NAI, Inc. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA29745 for ietf-open-pgp-bks; Tue, 13 Apr 1999 15:54:48 -0700 (PDT) Received: from mail1.svr.pol.co.uk (mail1.svr.pol.co.uk [195.92.193.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA29740 for ; Tue, 13 Apr 1999 15:54:47 -0700 (PDT) Received: from modem-15.gadolinium.dialup.pol.co.uk ([62.136.31.143] helo=server.eternity.org) by mail1.svr.pol.co.uk with esmtp (Exim 2.12 #1) id 10XC5A-0006tv-00; Tue, 13 Apr 1999 23:55:04 +0100 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id XAA15183; Tue, 13 Apr 1999 23:43:39 +0100 Date: Tue, 13 Apr 1999 23:43:39 +0100 Message-Id: <199904132243.XAA15183@server.eternity.org> From: Adam Back To: uri@watson.ibm.com CC: hal@rain.org, ietf-open-pgp@imc.org, prz@pgp.com In-reply-to: <9904130006.AA24736@buoy.watson.ibm.com> (message from uri on Mon, 12 Apr 1999 20:06:09 -0400 (EDT)) Subject: MDC symmetric sig type vs new bundled encrypt+MDC (Re: Phil Zimmermann's suggestion for large ciphers) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Uri writes: > > However i think the functionality list has a gap: it doesn't cover > > that many people will want to continue using IDEA, 3DES, blowfish. > > There will remain no way to prevent message modification for unsigned > > messages for these. > > It is bad enough to have to be compatible with the existing > "old" methods - it will be far worse to have to in addition > be compatible with "new old" methods. Enough is enough. We had plenty of warning about the MDC issue. The issue was discussed on this list over a year ago (Jan 98). Even before that Gary Howland presented the problem at Hip in Aug 97. If I recall at the time ita was reported that PGP made a press release or some kind of public statement saying they had a fix for the problem. We have a recently released rfc2440 and people are now finally talking about fixing the MDC problem, yet they want to do it in ways which rfc2440 implementations can't benefit from. > > Now if one adds to PRZs functionality list that we want this to be > > backwards compatible so that non-large ciphers can use it, you need a > > way to send a MDC inside an encryption envelope such that it won't > > cause current implementations to barf. For this the appended hash > > method doesn't work (or at least I can see no elegant way to make it > > work). > > A good enough reason for me to vote down the support for MDC in > "old" ciphers. Not really, the symmetric MDC packet is more elgant, as well as providing the possibility of working with the existing RFC, and so provides more overall security. We only just finished writing 2440, and you want to start obsoleting it. There are I think more pgp2.x implementations than 5.x, 6.x and GPG together. I think your comments about ease of implementation are off-base -- Tom Zerucha, who wrote an OpenPGP implementation votes that symmetric MDCs are easier. I haven't implemented OP, but I have implemented parts of pgp2.x, and I think this change would be easier also. It fits right into the existing framework, and doesn't require buffering tricks. > > I argue that these benefits make it worth favoring the new signature > > type over appended hash approach. > > Let's say that we disagree here. Perhaps if we could list the pros and cons: - ease of implementation (MDC sig wins) - adds security for more implementations (MDC sig wins) What are your arguments against MDC sigs? Note I am not against the "big clean up" phase planned for openPGP 2.0. I am all for it. I think PRZs suggestion that we add a new encryption method (standard CFB etc) is a _good thing_. However I would sooner see MDCs implemented in a way which fits into the existing framework, and thus is backwards compatible! That's what the framework is for -- so that there are defined means for algorithms to get added. Therefore I argue you should do what you can, especially when it is more elegant anyway, within the existing framework. Adam -- print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Tue, 13 Apr 1999 15:54:41 -0700 (PDT) Received: from modem-15.gadolinium.dialup.pol.co.uk ([62.136.31.143] helo=server.eternity.org) by mail1.svr.pol.co.uk with esmtp (Exim 2.12 #1) id 10XC57-0006tv-00; Tue, 13 Apr 1999 23:55:01 +0100 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id XAA15191; Tue, 13 Apr 1999 23:51:26 +0100 Date: Tue, 13 Apr 1999 23:51:26 +0100 Message-Id: <199904132251.XAA15191@server.eternity.org> From: Adam Back To: tzeruch@ceddec.com CC: ietf-open-pgp@imc.org In-reply-to: <99Apr13.173445edt.42114@brickwall.ceddec.com> (message from Tom Zerucha on Tue, 13 Apr 1999 17:36:25 -0400) Subject: Re: Phil Zimmermann's suggestion - Implementation? Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Tom Zerucha writes: > Uri writes: > > > > OK, I don't object as strongly any more. I'm neutral now. > > Lets see what the other implementors have to say. If expanding the > definition of an existing packet to "verification (signature or MDC)" > packet is easy to do in the existing code base (incl NAI PGP 6.0!), we can > start implementing this now as a test. Then we would have MDCs and be > able to merge them into the spec, and both spec and code would update in > synchronization. I think Ian Brown is away from email at present travelling, but perhaps systemics/Ian Grigg would have comments; the cryptix java PGP implementation is heavily object oriented -- I would expect that modifying for MDC sigs would be easy -- just adding a new specialisation signature, with a new reserved number. The append hash method however is all new, and has the buffering problems Tom was identifying, and whilst it is easy to conceptualise and say "oh that's easy just do blah" actually _doing it_ to some code brings out the complexity of it fast. PGP's 5.x and 6.x code is object oriented too. > > > In short, if you really want to do this, then add an MDC-only signature > > > type or subtype. The (non)signature packets will be encrypted with the > > > rest of the stream. In fact, the null cipher type might work as is. > > > > But it's NOT a signature! > > I don't know what else to call it because it is identified as the > "signature packet" in the Spec. Maybe we can start calling it the > "frooble" packet if that would be less confusing. > > I prefer simply renaming "signature packet" to "verification packet" or > whatever it would be - and this nomenclature change should be done. But I > can't use different words right now with out it being even more confusing. The name of the packet in RFC2440 doesn't sound like a big stumbling block here either. Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA29613 for ietf-open-pgp-bks; Tue, 13 Apr 1999 15:51:26 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA29608 for ; Tue, 13 Apr 1999 15:51:25 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id SAA06544; Tue, 13 Apr 1999 18:51:44 -0400 Received: from buoy.watson.ibm.com (buoy.watson.ibm.com [9.2.3.94]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id SAA20876; Tue, 13 Apr 1999 18:51:44 -0400 Received: by buoy.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA26366; Tue, 13 Apr 1999 18:51:44 -0400 From: uri Message-Id: <9904132251.AA26366@buoy.watson.ibm.com> Subject: Re: Phil Zimmermann's suggestion - Implementation? To: tzeruch@ceddec.com (Tom Zerucha) Date: Tue, 13 Apr 1999 18:51:44 -0400 (EDT) Cc: ietf-open-pgp@imc.org In-Reply-To: <99Apr13.173445edt.42114@brickwall.ceddec.com> from "Tom Zerucha" at Apr 13, 99 05:36:25 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Tom Zerucha says: > > Oh, I do assume you don't want to run through the file counting! (:-) > > No, I want to both count and hash at the same time, but I can't because... Yes you can - but you th hash may be one block behind. Still, you run through the file only once, and do a bit of special things at the *end*. > > The practical solution I see is delaying the hash update when decrypting > > by one block. I.e. you decrypt block K+1 and hash block K... Yes, it's > > not going to win a beauty contest. But it will work. > > With the stream format the last block might be less than 20 bytes. A 520 > byte file will be 512+...8 (or for larger values, 5000 would be > 4096+...4). And you can't hold back one "block", at least it would be > difficult if the block is the maximum legal size (2^31 bytes?). You have > to hold back at least 20 bytes at the end of any nonterminal packet. I meant - one cipher or hash block, i.e. 160 bits. So if you got the last *file* block 4 bytes, you figure that these 4 bytes together with the last 16 bytes from the "saved" last cipher-block constitute the MDC. > > Nope! The problem with this is - you'll *have* to run through the file > > on extra time. Undesirable for pipes! > > Only on encryption! I would rather run through one more time there, than > once per decryption. Decryption is really messy but only requires a 20 > byte delay, so it is not quite the same thing. But it seems unnecessary to introduce such "second run". > > > If you want an MDC, and there is already a place for MDCs, then it should > > > go there if the format can be adapted. > > OK, I don't object as strongly any more. I'm neutral now. > Lets see what the other implementors have to say. Sure. > > > In short, if you really want to do this, then add an MDC-only signature > > > type or subtype. The (non)signature packets will be encrypted with the > > > rest of the stream. In fact, the null cipher type might work as is. > > > > But it's NOT a signature! > > I don't know what else to call it because it is identified as the > "signature packet" in the Spec. Maybe we can start calling it the > "frooble" packet if that would be less confusing. A "signature" vouches for the authenticity of the data. MDC vouches only for its integrity... -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26754 for ietf-open-pgp-bks; Tue, 13 Apr 1999 14:48:52 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26749 for ; Tue, 13 Apr 1999 14:48:51 -0700 (PDT) Received: by brickwall.ceddec.com id <42114>; Tue, 13 Apr 1999 17:47:19 -0400 Date: Tue, 13 Apr 1999 17:49:01 -0400 From: Tom Zerucha X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: Re: Phil Zimmermann's suggestion - Implementation? In-Reply-To: <19990413220218.C765@frodo.isil.d.shuttle.de> Message-Id: <99Apr13.174719edt.42114@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Tue, 13 Apr 1999, Werner Koch wrote: > But I think this is still the most simple solution and we should do > it. A more sophisticated solution could be to put MDCs every n byte > into the data to help early detection of modification. However this > has not much to do with offline encryption but with online protocols > like SSH. So I suggest we keep the simple solution but use use a new > packet type for it. This could be implemented with a new packet-stream type, so that the partial packets could append X bytes. Putting an MDC at the packetization level is better than at the crypto level. I.e (1:4096)(4096:data)(MDC:20)...(1:17)(17:data)(MDC:20) > I think it is bad style to change a standard which already defines how > to handle different blocksizes (albeit with some conflicts). Which is why I call it a different "method". The spec already has something for the existing method (PGP/CFB) with larger block sizes, and my implementation is set up to handle these correctly, at least as far as I have been able to verify. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26398 for ietf-open-pgp-bks; Tue, 13 Apr 1999 14:40:49 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26394 for ; Tue, 13 Apr 1999 14:40:48 -0700 (PDT) Received: by brickwall.ceddec.com id <42114>; Tue, 13 Apr 1999 17:39:19 -0400 Date: Tue, 13 Apr 1999 17:41:03 -0400 From: Tom Zerucha X-Sender: nobody@mars To: "James H. Cloos Jr." cc: ietf-open-pgp@imc.org Subject: Re: Mixing rsa and dh/dsa In-Reply-To: Message-Id: <99Apr13.173919edt.42114@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Tue, 13 Apr 1999, James H. Cloos Jr. wrote: > Given a recipient with only an RSA keypair (algo 1), and a sender with > only a DSA/Elgamal pair (algos 17 and 16), should the sender > encrypt+sign, will any extant software be able to decrypt and verify? Yes. The encryption is done using the RSA algorithm, but the signing is done using DSA. The recipient can decrypt using his RSA key and verify from the DSA from a keyserver or keyring. The encryption algorithm is separate and thus can be different from any signature algorithm. My test suite generates every possible combination, so I know it is possible for this to work. Whether any particular implementation handles this depends on that implmementaiton, but there should not be any problems if they simply did things in an obvious manner. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26264 for ietf-open-pgp-bks; Tue, 13 Apr 1999 14:36:18 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26259 for ; Tue, 13 Apr 1999 14:36:17 -0700 (PDT) Received: by brickwall.ceddec.com id <42114>; Tue, 13 Apr 1999 17:34:45 -0400 Date: Tue, 13 Apr 1999 17:36:25 -0400 From: Tom Zerucha X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: Re: Phil Zimmermann's suggestion - Implementation? In-Reply-To: <9904132023.AA25802@buoy.watson.ibm.com> Message-Id: <99Apr13.173445edt.42114@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Tue, 13 Apr 1999, uri wrote: > Oh, I do assume you don't want to run through the file counting! (:-) No, I want to both count and hash at the same time, but I can't because... > The practical solution I see is delaying the hash update when decrypting > by one block. I.e. you decrypt block K+1 and hash block K... Yes, it's > not going to win a beauty contest. But it will work. With the stream format the last block might be less than 20 bytes. A 520 byte file will be 512+...8 (or for larger values, 5000 would be 4096+...4). And you can't hold back one "block", at least it would be difficult if the block is the maximum legal size (2^31 bytes?). You have to hold back at least 20 bytes at the end of any nonterminal packet. > > Or put the MDC at the beginning. This should be just as easy, and you can > > just save those 20 bytes, decrypt/hash and then memcmp(,,20). This is > > only slightly less difficult, but it would be on the encryption side, and > > encryption is done fewer times than decryption. > > Nope! The problem with this is - you'll *have* to run through the file > on extra time. Undesirable for pipes! Only on encryption! I would rather run through one more time there, than once per decryption. Decryption is really messy but only requires a 20 byte delay, so it is not quite the same thing. > > It isn't a signature. It is the same 20 bytes encrypted, except within > > the existing packet structure. No new layers, processing, or code ripups. > > If you want to put 20 bytes of MDC somewhere, these packets have a place > > for it, and it is easier to add one more new signature (non-signature) > > subtype than an entire new layer of processing. > > > > If you want an MDC, and there is already a place for MDCs, then it should > > go there if the format can be adapted. > > OK, I don't object as strongly any more. I'm neutral now. Lets see what the other implementors have to say. If expanding the definition of an existing packet to "verification (signature or MDC)" packet is easy to do in the existing code base (incl NAI PGP 6.0!), we can start implementing this now as a test. Then we would have MDCs and be able to merge them into the spec, and both spec and code would update in synchronization. > > In short, if you really want to do this, then add an MDC-only signature > > type or subtype. The (non)signature packets will be encrypted with the > > rest of the stream. In fact, the null cipher type might work as is. > > But it's NOT a signature! I don't know what else to call it because it is identified as the "signature packet" in the Spec. Maybe we can start calling it the "frooble" packet if that would be less confusing. I prefer simply renaming "signature packet" to "verification packet" or whatever it would be - and this nomenclature change should be done. But I can't use different words right now with out it being even more confusing. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA24192 for ietf-open-pgp-bks; Tue, 13 Apr 1999 13:23:27 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA24186 for ; Tue, 13 Apr 1999 13:23:26 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id QAA10192; Tue, 13 Apr 1999 16:23:45 -0400 Received: from buoy.watson.ibm.com (buoy.watson.ibm.com [9.2.3.94]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id QAA19332; Tue, 13 Apr 1999 16:23:45 -0400 Received: by buoy.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA25802; Tue, 13 Apr 1999 16:23:44 -0400 From: uri Message-Id: <9904132023.AA25802@buoy.watson.ibm.com> Subject: Re: Phil Zimmermann's suggestion - Implementation? To: tzeruch@ceddec.com (Tom Zerucha) Date: Tue, 13 Apr 1999 16:23:44 -0400 (EDT) Cc: ietf-open-pgp@imc.org In-Reply-To: <99Apr13.154552edt.42115@brickwall.ceddec.com> from "Tom Zerucha" at Apr 13, 99 03:47:38 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Tom Zerucha says: > > What's the big deal anyway? You're firing up encryptor > > and at the same time block-by-block computing MDC (SHA-1 hash). When you > > reach the last block, you have your MDC complete and can encrypt it as > > block-after-last... When decrypting you always take the last 20 bytes > > as MDC... What problem am I missing? > > So we are going to require multithreading? No, I'm merely saying that the logical processing would be do get new plaintext block update the hash encrypt plaintext block and spit it out until last block is done spit out the MDC encrypt MDC > If I don't have that > capability, "firing up" multiple filters isn't as simple as you make it > out to be. Can I pass the data through two layers instead of one? Yes, > but I don't want to if I don't have to. Especially since it would be > encrypt(mdc(hash-for-signature(plaintext))) now. PGP is already bloating > as it is. No. It's encrypt(plaintext||hash(plaintext)) where mdc(A) = hash(A) > > > And to ask a question, how do I know where the MAC is? > > > > In the last 20 bytes of the plaintext, where else... > > If you don't know the length of the input, this means it is at which byte? Since you can't avoid getting to the last byte when decrypting, and since you have no business monkeying with MDC until you finished decrypted, telling you that MDC is in the last 20 bytes is both necessary and sufficient... > Saying something is 5 miles east of Kunkle doesn't help if you don't know > where Kunkle is. Since you *are* going to Kunkle, and if you don't get there nothing else matters - the "5 miles east" is as precise as you have to know. > So I keep feeding bytes to the hasher, and then oops, I > only have 10 bytes left. I have to rewind now that I know the length of > the file. Or I have to hold back 20 bytes until I know where the real EOF > is. A very good point, thank you! Yes, it is more complicated on decrypting side, as you spotted (and I confess - I didn't). However, as you yourself point out, the solution is simple, if less than beautiful. > > > I have to decrypt and hold back 20 bytes just in case I see the EOF? > > > > You have to decrypt - then you have to "clip" the last 20 bytes of > > the resulting plaintext and give them to MDC verifier. Of course > > you can be computing the MDC block-by-block as you're > > decrypting the message... > > So if the data is coming through a pipe, how do I know there are going to > be exactly 20 bytes and no more coming through? If I want to run through > the file once to count, fine, but assume that I don't. Oh, I do assume you don't want to run through the file counting! (:-) The practical solution I see is delaying the hash update when decrypting by one block. I.e. you decrypt block K+1 and hash block K... Yes, it's not going to win a beauty contest. But it will work. > Or put the MDC at the beginning. This should be just as easy, and you can > just save those 20 bytes, decrypt/hash and then memcmp(,,20). This is > only slightly less difficult, but it would be on the encryption side, and > encryption is done fewer times than decryption. Nope! The problem with this is - you'll *have* to run through the file on extra time. Undesirable for pipes! > > Yes. It is preferable not to introduce the whole zoo of algorithms. > > So with the move to 128-bit block ciphers I'd expect AND PREFER > > the old 64-bit block ciphers to quietly go away, the sooner > > the better. > > Then why not drop PGP entirely? This you can figure out yourself (:-) > I doubt there is going to be a move to > the new ciphers until everyone has the newer versions, and there are still > people using 2.6.x. In short, they won't go away. Which is why people preserve ugly backwards compatibility, but aren't bending over their backs to modify/improve the old modes. > > I'm strongly against it. Such a signature does not make sense [to me]. > > It isn't a signature. It is the same 20 bytes encrypted, except within > the existing packet structure. No new layers, processing, or code ripups. > If you want to put 20 bytes of MDC somewhere, these packets have a place > for it, and it is easier to add one more new signature (non-signature) > subtype than an entire new layer of processing. > > If you want an MDC, and there is already a place for MDCs, then it should > go there if the format can be adapted. OK, I don't object as strongly any more. I'm neutral now. > In short, if you really want to do this, then add an MDC-only signature > type or subtype. The (non)signature packets will be encrypted with the > rest of the stream. In fact, the null cipher type might work as is. But it's NOT a signature! > Or just define a completely new packet ID for the MDC. It will be > basically a signature packet minus a lot of header and other bytes, but > you would have (plaintext)(MDC) with known boundaries. Hmm... Not qualified to judge this. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA24100 for ietf-open-pgp-bks; Tue, 13 Apr 1999 13:20:52 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA24094 for ; Tue, 13 Apr 1999 13:20:47 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id WAA26404 for ietf-open-pgp@imc.org; Tue, 13 Apr 1999 22:21:06 +0200 (MET DST) Received: (qmail 28678 invoked from network); 13 Apr 1999 20:04:07 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 13 Apr 1999 20:04:07 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10X9Ny-0000D7-00; Tue, 13 Apr 1999 22:02:18 +0200 Date: Tue, 13 Apr 1999 22:02:18 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Phil Zimmermann's suggestion - Implementation? Message-ID: <19990413220218.C765@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <99Apr13.131145edt.42115@brickwall.ceddec.com> <9904131805.AA26446@buoy.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <9904131805.AA26446@buoy.watson.ibm.com>; from uri on Tue, Apr 13, 1999 at 02:05:38PM -0400 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: uri writes: > What is "OOB EOF"? What's the big deal anyway? You're firing up encryptor > and at the same time block-by-block computing MDC (SHA-1 hash). When you > reach the last block, you have your MDC complete and can encrypt it as > block-after-last... When decrypting you always take the last 20 bytes > as MDC... What problem am I missing? Tom already described it. You have always to store the last 20 bytes of what you are decrypting instead of writing it simply to the output. We introduce the onepass signature packets to implementing a stream mode of operation so why add the extra burden for deferring the last bytes? But I think this is still the most simple solution and we should do it. A more sophisticated solution could be to put MDCs every n byte into the data to help early detection of modification. However this has not much to do with offline encryption but with online protocols like SSH. So I suggest we keep the simple solution but use use a new packet type for it. > Yes. It is preferable not to introduce the whole zoo of algorithms. > So with the move to 128-bit block ciphers I'd expect AND PREFER > the old 64-bit block ciphers to quietly go away, the sooner I think it is bad style to change a standard which already defines how to handle different blocksizes (albeit with some conflicts). > > Such as a signature with a "zero" encryption algorithm that would just > > store the 20 bytes of the SHA-1 hash? This could be easily added to the > > existing code (with provisos that it doesn't display as a signature). > > I'm strongly against it. Such a signature does not make sense [to me]. It really does not make sense without a MAC (message authentication code). -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA22624 for ietf-open-pgp-bks; Tue, 13 Apr 1999 12:47:24 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA22619 for ; Tue, 13 Apr 1999 12:47:23 -0700 (PDT) Received: by brickwall.ceddec.com id <42115>; Tue, 13 Apr 1999 15:45:52 -0400 Date: Tue, 13 Apr 1999 15:47:38 -0400 From: Tom Zerucha X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: Re: Phil Zimmermann's suggestion - Implementation? In-Reply-To: <9904131805.AA26446@buoy.watson.ibm.com> Message-Id: <99Apr13.154552edt.42115@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Tue, 13 Apr 1999, uri wrote: > > The IV/CFB box is different. So why not just define a new IV/CFB mode or > > method instead of jamming this definition into the cipher? > > I don't know - does it really matter how to define "this" new way > of processing? It depends a lot if new ciphers are all going to use the new method, or if it will be defined with existing ciphers. If the method is going to be specific to the ciphers, then it makes sense to incorporate it into the ciphers. If there are going to be multiple methods applied to ciphers, it is best to define the methods. The spec has ciphers and the PGPCFB method defined in different areas. If we add a method, it would be applicable to ciphers. Otherwise the method becomes part of the cipher and we should restructure the document (and derivative code) that way. > > Also the MAC gives me some indigestion. There are uses of this for stream > > processing, and the MAC in this format needs an OOB EOF and processing. > > What is "OOB EOF"? Out Of Band End of File, e.g. getting 0xffff instead of 0-0xff in getchar. > What's the big deal anyway? You're firing up encryptor > and at the same time block-by-block computing MDC (SHA-1 hash). When you > reach the last block, you have your MDC complete and can encrypt it as > block-after-last... When decrypting you always take the last 20 bytes > as MDC... What problem am I missing? So we are going to require multithreading? If I don't have that capability, "firing up" multiple filters isn't as simple as you make it out to be. Can I pass the data through two layers instead of one? Yes, but I don't want to if I don't have to. Especially since it would be encrypt(mdc(hash-for-signature(plaintext))) now. PGP is already bloating as it is. > > And to ask a question, how do I know where the MAC is? > > In the last 20 bytes of the plaintext, where else... If you don't know the length of the input, this means it is at which byte? Saying something is 5 miles east of Kunkle doesn't help if you don't know where Kunkle is. So I keep feeding bytes to the hasher, and then oops, I only have 10 bytes left. I have to rewind now that I know the length of the file. Or I have to hold back 20 bytes until I know where the real EOF is. > > I have to decrypt and hold back 20 bytes just in case I see the EOF? > > You have to decrypt - then you have to "clip" the last 20 bytes of > the resulting plaintext and give them to MDC verifier. Of course > you can be computing the MDC block-by-block as you're > decrypting the message... So if the data is coming through a pipe, how do I know there are going to be exactly 20 bytes and no more coming through? If I want to run through the file once to count, fine, but assume that I don't. Either that or require the old style CTB prefixes - the ones that give the length instead of the new ones designed to do streaming. Streaming does have disadvantages. Or put the MDC at the beginning. This should be just as easy, and you can just save those 20 bytes, decrypt/hash and then memcmp(,,20). This is only slightly less difficult, but it would be on the encryption side, and encryption is done fewer times than decryption. > > Is there a particular reason not to use the old ciphers with the new > > format (if it is available)? Other than backwards compatibility - which > > you won't have anyway? > > Yes. It is preferable not to introduce the whole zoo of algorithms. > So with the move to 128-bit block ciphers I'd expect AND PREFER > the old 64-bit block ciphers to quietly go away, the sooner > the better. Then why not drop PGP entirely? I doubt there is going to be a move to the new ciphers until everyone has the newer versions, and there are still people using 2.6.x. In short, they won't go away. > > Such as a signature with a "zero" encryption algorithm that would just > > store the 20 bytes of the SHA-1 hash? This could be easily added to the > > existing code (with provisos that it doesn't display as a signature). > > I'm strongly against it. Such a signature does not make sense [to me]. It isn't a signature. It is the same 20 bytes encrypted, except within the existing packet structure. No new layers, processing, or code ripups. If you want to put 20 bytes of MDC somewhere, these packets have a place for it, and it is easier to add one more new signature (non-signature) subtype than an entire new layer of processing. If you want an MDC, and there is already a place for MDCs, then it should go there if the format can be adapted. > > Since you can have multiple signature packets, adding the symmetric MAC > > "non-signature" adds this function without the layer. > > In short, I'm against it. And I am against adding an MDC to the "inside" of the symmetric encryption packet. There is already a defined place for one outside, although only in the context of either null or PK encryption. In short, if you really want to do this, then add an MDC-only signature type or subtype. The (non)signature packets will be encrypted with the rest of the stream. In fact, the null cipher type might work as is. Does anyone have a reason that (plaintext+20) is going to be worse than (1passhdr)(plaintext)(sig-MDC)? The code for the latter already exists - simply bypass the PK encryption. This also adds the MDC capability to the old ciphers. The spec already warned about PK alg ID 0, or we can add a new one, but I don't know what the various implementations do. If MDC is that useful, it will be useful with the old ciphers. Or just define a completely new packet ID for the MDC. It will be basically a signature packet minus a lot of header and other bytes, but you would have (plaintext)(MDC) with known boundaries. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA21750 for ietf-open-pgp-bks; Tue, 13 Apr 1999 12:30:57 -0700 (PDT) Received: from jhcloos.com (cloos@austin.jhcloos.com [206.224.83.202]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA21744 for ; Tue, 13 Apr 1999 12:30:55 -0700 (PDT) Received: (from cloos@localhost) by jhcloos.com (8.8.7/8.8.7) id OAA06395; Tue, 13 Apr 1999 14:31:12 -0500 To: ietf-open-pgp@imc.org Subject: Mixing rsa and dh/dsa From: "James H. Cloos Jr." MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: 13 Apr 1999 14:31:12 -0500 Message-ID: Lines: 21 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Given a recipient with only an RSA keypair (algo 1), and a sender with only a DSA/Elgamal pair (algos 17 and 16), should the sender encrypt+sign, will any extant software be able to decrypt and verify? - -JimC - -- James H. Cloos, Jr. 1024D/ED7DAEA6 E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 -----BEGIN PGP SIGNATURE----- Version: GnuPG v0.9.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE3E5t/mXqfF+19rqYRAhDGAJ0WlNorTuD1CV7CfvXMt3LwfdKGCgCgpVWs 9cAHPeSAjZn6NiJn3KXRjHM= =2o8F -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA18987 for ietf-open-pgp-bks; Tue, 13 Apr 1999 11:05:22 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA18983 for ; Tue, 13 Apr 1999 11:05:21 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id OAA09638; Tue, 13 Apr 1999 14:05:39 -0400 Received: from buoy.watson.ibm.com (buoy.watson.ibm.com [9.2.3.94]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id OAA08946; Tue, 13 Apr 1999 14:05:39 -0400 Received: by buoy.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA26446; Tue, 13 Apr 1999 14:05:39 -0400 From: uri Message-Id: <9904131805.AA26446@buoy.watson.ibm.com> Subject: Re: Phil Zimmermann's suggestion - Implementation? To: tzeruch@ceddec.com (Tom Zerucha) Date: Tue, 13 Apr 1999 14:05:38 -0400 (EDT) Cc: ietf-open-pgp@imc.org In-Reply-To: <99Apr13.131145edt.42115@brickwall.ceddec.com> from "Tom Zerucha" at Apr 13, 99 01:13:31 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Tom Zerucha says: > The new model becomes (please correct ommissions) > > Plaintext -> MAC append -> IV/CFB xor -> Ciphertext > ^ > | > Secret -> Cipher It's not MAc - it's MDC. Otherwise your diagram looks correct to me. > The IV/CFB box is different. So why not just define a new IV/CFB mode or > method instead of jamming this definition into the cipher? I don't know - does it really matter how to define "this" new way of processing? > Also the MAC gives me some indigestion. There are uses of this for stream > processing, and the MAC in this format needs an OOB EOF and processing. What is "OOB EOF"? What's the big deal anyway? You're firing up encryptor and at the same time block-by-block computing MDC (SHA-1 hash). When you reach the last block, you have your MDC complete and can encrypt it as block-after-last... When decrypting you always take the last 20 bytes as MDC... What problem am I missing? > And to ask a question, how do I know where the MAC is? In the last 20 bytes of the plaintext, where else... > I have to decrypt and hold back 20 bytes just in case I see the EOF? You have to decrypt - then you have to "clip" the last 20 bytes of the resulting plaintext and give them to MDC verifier. Of course you can be computing the MDC block-by-block as you're decrypting the message... > Is there a particular reason not to use the old ciphers with the new > format (if it is available)? Other than backwards compatibility - which > you won't have anyway? Yes. It is preferable not to introduce the whole zoo of algorithms. So with the move to 128-bit block ciphers I'd expect AND PREFER the old 64-bit block ciphers to quietly go away, the sooner the better. > > We have also discussed providing integrity protection via some > > modification to the signature packet format rather than by a new form > > of encrypted packet. There would be a special kind of "signature" which > > would just consist of a hash of the message to protect its integrity. > > Such as a signature with a "zero" encryption algorithm that would just > store the 20 bytes of the SHA-1 hash? This could be easily added to the > existing code (with provisos that it doesn't display as a signature). I'm strongly against it. Such a signature does not make sense [to me]. > Doing a MAC within the encryption packet now adds a layer on the inside, > which will be there even for signed messages. It is NOT a MAC - it's MDC (Modification Detection Code). Different type, different application, different security considerations. > I really don't like extra layers if an existing layer can provide the > functionality. (:-) > Since you can have multiple signature packets, adding the symmetric MAC > "non-signature" adds this function without the layer. In short, I'm against it. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA17387 for ietf-open-pgp-bks; Tue, 13 Apr 1999 10:13:20 -0700 (PDT) Received: from ceddec.com (brickwall.ceddec.com [207.91.200.193]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA17383 for ; Tue, 13 Apr 1999 10:13:19 -0700 (PDT) Received: by brickwall.ceddec.com id <42115>; Tue, 13 Apr 1999 13:11:45 -0400 Date: Tue, 13 Apr 1999 13:13:31 -0400 From: Tom Zerucha X-Sender: nobody@mars To: ietf-open-pgp@imc.org Subject: Re: Phil Zimmermann's suggestion - Implementation? In-Reply-To: <199904122159.OAA02053@hal.sb.rain.org> Message-Id: <99Apr13.131145edt.42115@brickwall.ceddec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: On Mon, 12 Apr 1999 hal@rain.org wrote: > I spoke with Phil Zimmermann on the phone about the issues raised by > moving to larger block ciphers, and he made the following proposal. > These concerns include - > > - The non-standard sync operation after the check bytes are handled > > - The non-standard treatment of IV > > - The lack of detection of message modification unless the message is > signed (many people don't like to sign their messages for legal reasons, > but they don't want them altered). > > We would define a new encrypted packet format which would be similar to > the current one but which would resolve these problems. Note that what you are defining is a different "method" or processing layer. This is NOT best implemented using different cipher numbers, but with a range of cipher numbers or some other key indicating the new usage. The current structure could be described as follows: Plaintext -> IV/CFB xor -> Ciphertext ^ | Secret -> Cipher (By secret I mean all material, both key and initial IV if nonzero, etc.). The IV/CFB xor box resets at 10. The new model becomes (please correct ommissions) Plaintext -> MAC append -> IV/CFB xor -> Ciphertext ^ | Secret -> Cipher The IV/CFB box is different. So why not just define a new IV/CFB mode or method instead of jamming this definition into the cipher? For now, I would prefer looking at a way of specifying the new IV/CFB or whatever *method* as different from specifying the underlying cipher. Also the MAC gives me some indigestion. There are uses of this for stream processing, and the MAC in this format needs an OOB EOF and processing. And to ask a question, how do I know where the MAC is? I have to decrypt and hold back 20 bytes just in case I see the EOF? The new stream format might have EOF detect problems there, i.e. I don't know where the MAC is until I am past it. (This is easily addressed, so should be before proceeding). (See my comments following) > With this approach, rather than patching the spec to deal with large > block ciphers in the existing packet format, we would say that the > existing packets should only be used for ciphers with 64 bit blocks. > Larger ciphers must use the new format. Again, this is a perfect > opportunity to make this change because large ciphers won't be backwards > compatible, anyway. Is there a particular reason not to use the old ciphers with the new format (if it is available)? Other than backwards compatibility - which you won't have anyway? > We have also discussed providing integrity protection via some > modification to the signature packet format rather than by a new form > of encrypted packet. There would be a special kind of "signature" which > would just consist of a hash of the message to protect its integrity. Such as a signature with a "zero" encryption algorithm that would just store the 20 bytes of the SHA-1 hash? This could be easily added to the existing code (with provisos that it doesn't display as a signature). > However, Phil argues that this kind of integrity protection is inherently > tied to the use of encryption. It has no functional effect if not used > in conjunction with encryption. This is unlike our other signatures, > which are cryptographically useful transformations even on their own. > Because of this close tie to the encryption functionality it makes most > sense to make it part of the encrypted packet. Or simply encrypt the signature with the symmetric algorithm the message was encrypted with (instead of the PK signature algorithms). This leaves all the existing hashing code where it is and only requires a mod to the final stage (and perhaps preservation of the cipher state on EOF). Doing a MAC within the encryption packet now adds a layer on the inside, which will be there even for signed messages. I really don't like extra layers if an existing layer can provide the functionality. > However, Phil points out that it is often the case that a signature > cannot be verified because the signing key is not available. In that case > there is no integrity protection at all. Putting integrity protection in > the encryption layer ensures that all encrypted messages have integrity > protection. Since you can have multiple signature packets, adding the symmetric MAC "non-signature" adds this function without the layer. > Summing up, we have an opportunity now to move to a new encrypted packet > format at the same time as we begin supporting new ciphers. We can > fix some of the problems which people have been complaining about for > years, without facing backwards compatibility issues. Please fix the symmetrical encryption packet lack-of-checksum while you are at it. (This is when you have a pass phrase protecting more key material - the second has no checksum so you can't tell if the key is good without decrypting some of the ciphertext). Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA13610 for ietf-open-pgp-bks; Tue, 13 Apr 1999 08:22:12 -0700 (PDT) Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA13605 for ; Tue, 13 Apr 1999 08:22:11 -0700 (PDT) Received: from xedia.com by relay5.UU.NET with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgktx21231; Tue, 13 Apr 1999 11:21:12 -0400 (EDT) Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA04789; Tue, 13 Apr 99 11:20:59 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA11395; Tue, 13 Apr 1999 11:21:07 -0400 Date: Tue, 13 Apr 1999 11:21:07 -0400 Message-Id: <199904131521.LAA11395@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: wk@isil.d.shuttle.de Cc: ietf-open-pgp@imc.org Subject: Re: Phil Zimmermann's suggestion for large ciphers References: <199904122159.OAA02053@hal.sb.rain.org> <9904122321.AA24998@buoy.watson.ibm.com> <19990413094814.B221@frodo.isil.d.shuttle.de> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: >>>>> "Werner" == Werner Koch writes: Werner> uri writes: >> So? Compared to cost of one RSA or DSA operation, one SHA-1 is >> negligible. Who cares? Werner> Hashing 700 Mges takes a while and sometimes conventional Werner> only encryption is used. True, but compared to conventional crypto SHA-1 is still a small component. I've measured it at 4-5 times the speed of single DES. paul Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA26729 for ietf-open-pgp-bks; Tue, 13 Apr 1999 01:20:59 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA26724 for ; Tue, 13 Apr 1999 01:20:56 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id KAA13923 for ietf-open-pgp@imc.org; Tue, 13 Apr 1999 10:21:11 +0200 (MET DST) Received: (qmail 26980 invoked from network); 13 Apr 1999 07:56:47 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 13 Apr 1999 07:56:47 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10Wy21-00004V-00; Tue, 13 Apr 1999 09:54:53 +0200 Date: Tue, 13 Apr 1999 09:54:52 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Packet 5,7 and blocksizes Message-ID: <19990413095452.C221@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Just a reminder that we have to change the specs to increase the size of the IV in the secrek key material encryption from 8 bytes to the blocksize. And I still like to have a length of the IV in the packet (okay, for the next version of the packet) becuase it makes parsing more easier. Now I have to use a table of blocksizes for each cipher to do correct parsing of the data; adding one byte for this should not be a problem. -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA25371 for ietf-open-pgp-bks; Tue, 13 Apr 1999 00:51:02 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA25366 for ; Tue, 13 Apr 1999 00:51:00 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id JAA09766 for ietf-open-pgp@imc.org; Tue, 13 Apr 1999 09:51:10 +0200 (MET DST) Received: (qmail 26878 invoked from network); 13 Apr 1999 07:43:46 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 13 Apr 1999 07:43:46 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10WxpP-00004I-00; Tue, 13 Apr 1999 09:41:51 +0200 Date: Tue, 13 Apr 1999 09:41:51 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Phil Zimmermann's suggestion for large ciphers Message-ID: <19990413094151.A221@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904122159.OAA02053@hal.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <199904122159.OAA02053@hal.sb.rain.org>; from hal@rain.org on Mon, Apr 12, 1999 at 02:59:59PM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: hal@rain.org writes: > Phil suggests that we take advantage of the fact that when we go to large > block ciphers like Twofish, there are no backwards-compatibility issues. Please note that the RFC already handles ciphers with different blocksizes; the only problem ist that there are some glitches in the specification. > The plaintext would be followed by a SHA-1 hash of the plaintext data. To avoid the need to create new packet types in the future (maybe there will be a demand for a larger sized digest algorithm or someone likes to replace SHA-1 by RIPE-MD160) we should at least encode a version number in the encrypted data packet. > This gives us a standard CFB mode, with a standard IV; a simple form of > redundancy at the beginning to verify the correct key; and a SHA-1 hash Keep the Zero-IV and extend the current scheme. Implementions must already cope with this to be compatible with rfc2440 and there is no security risk with this. > Larger ciphers must use the new format. Again, this is a perfect If a cipher with id >= 7 is listed in the preferences an implementations SHOULD use the new format. I think there are no implementations which are yet using those ciphers, so we can easily fix it without breaking rfc2440 too much. > opportunity to make this change because large ciphers won't be backwards > compatible, anyway. But they are compatible with rfc2440 - despite the fact that we don't have a cipher id for those official assigned (except the reserved ones for AES). > originated with the other. What we want is simple integrity protection. > For this purpose there is no need for a shared secret and it is Right. > Another issue is whether to use a fixed hash like SHA-1 rather than > allowing the specification of a hash algorithm in the header. There is > no need for variable hash algorithms in this context. The attacker does "There will never be the need for more than 640k of RAM" ;-) We have already specified hash preferences which may be utilized to use a different hash algorithm. So it would be wise to encrypt a version number, the type of MDC used and the hash algorithm with the encrypted text. We are already prefixing the message with some random bytes and a kind of checksum; we can simple add those additional information and don't increase the risk of a known plaintext attack as the structure of the data which follows is anyway known (literal data packet or compressed data packet). -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA25365 for ietf-open-pgp-bks; Tue, 13 Apr 1999 00:51:00 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA25361 for ; Tue, 13 Apr 1999 00:50:58 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id JAA09773 for ietf-open-pgp@imc.org; Tue, 13 Apr 1999 09:51:13 +0200 (MET DST) Received: (qmail 26894 invoked from network); 13 Apr 1999 07:50:09 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 13 Apr 1999 07:50:09 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10Wxva-00004N-00; Tue, 13 Apr 1999 09:48:14 +0200 Date: Tue, 13 Apr 1999 09:48:14 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Phil Zimmermann's suggestion for large ciphers Message-ID: <19990413094814.B221@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904122159.OAA02053@hal.sb.rain.org> <9904122321.AA24998@buoy.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <9904122321.AA24998@buoy.watson.ibm.com>; from uri on Mon, Apr 12, 1999 at 07:21:13PM -0400 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: uri writes: > Make the "pseudo-IV" prefix partially non-random - i.e. the last two > bytes being checksum for the other 14. No big deal security-wise and > noticeable help in detecting the right key. I aggree as this will help detecting bad keys for conventional-only encrypted data. > So? Compared to cost of one RSA or DSA operation, one SHA-1 is negligible. > Who cares? Hashing 700 Mges takes a while and sometimes conventional only encryption is used. But IMHO it is worth this time. If someone does not like it, he can still use packet type 9 and the specs shoudl say that an implemention SHOULD display a notice if a cipher >= 7 is used without a MDC. -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA01275 for ietf-open-pgp-bks; Mon, 12 Apr 1999 19:37:47 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.8/8.8.5) with SMTP id TAA01265 for ; Mon, 12 Apr 1999 19:37:45 -0700 (PDT) Received: (qmail 4407 invoked by uid 666); 13 Apr 1999 02:38:13 -0000 Date: 13 Apr 1999 02:38:13 -0000 Message-ID: <19990413023813.4405.qmail@cr.yp.to> From: "D. J. Bernstein" To: ietf-open-pgp@imc.org Subject: Re: Phil Zimmermann's suggestion for large ciphers Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hal Finney writes: > The plaintext would be followed by a SHA-1 hash of the plaintext data. I have an unconditionally secure MAC that's much faster than SHA-1---in fact, even faster than MD5. The alpha implementation is available from http://pobox.com/~djb/hash127.html Please send any comments or questions to the hash127 mailing list. To subscribe, send an empty message to hash127-subscribe@list.cr.yp.to. > many people don't like to sign their messages for legal reasons, Why? Because signatures can't be repudiated? One easy solution, under the original Diffie-Hellman system, is to use a MAC as above, where the MAC key is generated from the Diffie-Hellman shared secret. The receiver can generate new MACs under the same key, so he can't prove to a judge that a message came from you. (There are similar solutions using RSA, but Diffie-Hellman is faster.) ---Dan Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA23033 for ietf-open-pgp-bks; Mon, 12 Apr 1999 17:06:00 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA23029 for ; Mon, 12 Apr 1999 17:05:59 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id UAA06244; Mon, 12 Apr 1999 20:06:10 -0400 Received: from buoy.watson.ibm.com (buoy.watson.ibm.com [9.2.3.94]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id UAA22562; Mon, 12 Apr 1999 20:06:10 -0400 Received: by buoy.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA24736; Mon, 12 Apr 1999 20:06:09 -0400 From: uri Message-Id: <9904130006.AA24736@buoy.watson.ibm.com> Subject: Re: Phil Zimmermann's suggestion for large ciphers To: aba@dcs.ex.ac.uk (Adam Back) Date: Mon, 12 Apr 1999 20:06:09 -0400 (EDT) Cc: hal@rain.org, ietf-open-pgp@imc.org, prz@pgp.com In-Reply-To: <199904122341.AAA10973@server.eternity.org> from "Adam Back" at Apr 13, 99 00:41:53 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Adam Back says: > Starting from PRZs functionality list, I agree with the design. (:-) > However i think the functionality list has a gap: it doesn't cover > that many people will want to continue using IDEA, 3DES, blowfish. > There will remain no way to prevent message modification for unsigned > messages for these. And there's absolutely no protection for those who continue using unencrypted unsigned e-mail. I say - the world is moving forward. It is bad enough to have to be compatible with the existing "old" methods - it will be far worse to have to in addition be compatible with "new old" methods. Enough is enough. > is important too, and I therefore think it would be quite useful to > have a MDC in signed and encrypted messages (as well as just encrypted > messages) for the non-large ciphers too. We agree here. > Now if one adds to PRZs functionality list that we want this to be > backwards compatible so that non-large ciphers can use it, you need a > way to send a MDC inside an encryption envelope such that it won't > cause current implementations to barf. For this the appended hash > method doesn't work (or at least I can see no elegant way to make it > work). A good enough reason for me to vote down the support for MDC in "old" ciphers. > For this reason I would argue for a new signature type `symmetric > MDC', where you put a hash (or a MAC) in a signature packet. No MAC - as MAC will require yet another key. > I argue that these benefits make it worth favoring the new signature > type over appended hash approach. Let's say that we disagree here. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA22774 for ietf-open-pgp-bks; Mon, 12 Apr 1999 16:45:32 -0700 (PDT) Received: from mail9.svr.pol.co.uk (mail9.svr.pol.co.uk [195.92.193.22]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA22770 for ; Mon, 12 Apr 1999 16:45:31 -0700 (PDT) Received: from modem-38.barium.dialup.pol.co.uk ([62.136.27.166] helo=server.eternity.org) by mail9.svr.pol.co.uk with esmtp (Exim 2.12 #1) id 10WqOX-0007ri-00; Tue, 13 Apr 1999 00:45:38 +0100 Received: (from aba@localhost) by server.eternity.org (8.8.3/8.6.12) id AAA10973; Tue, 13 Apr 1999 00:41:53 +0100 Date: Tue, 13 Apr 1999 00:41:53 +0100 Message-Id: <199904122341.AAA10973@server.eternity.org> From: Adam Back To: hal@rain.org Cc: ietf-open-pgp@imc.org Cc: prz@pgp.com In-reply-to: <199904122159.OAA02053@hal.sb.rain.org> Subject: Re: Phil Zimmermann's suggestion for large ciphers Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I just spent a bit of time reviewing the previous discussions on fixes for Gary Howland's message modification attack. In general I like PRZs proposal, and it seems well thought out. Starting from PRZs functionality list, I agree with the design. However i think the functionality list has a gap: it doesn't cover that many people will want to continue using IDEA, 3DES, blowfish. There will remain no way to prevent message modification for unsigned messages for these. The point that PRZ made: > However, Phil points out that it is often the case that a signature > cannot be verified because the signing key is not available. In > that case there is no integrity protection at all. is important too, and I therefore think it would be quite useful to have a MDC in signed and encrypted messages (as well as just encrypted messages) for the non-large ciphers too. Now if one adds to PRZs functionality list that we want this to be backwards compatible so that non-large ciphers can use it, you need a way to send a MDC inside an encryption envelope such that it won't cause current implementations to barf. For this the appended hash method doesn't work (or at least I can see no elegant way to make it work). For this reason I would argue for a new signature type `symmetric MDC', where you put a hash (or a MAC) in a signature packet. in previous discussions Tom Zerucha made this point: : a signature algorithm : of 0 means the message digest is stored in the clear (maybe as a : MPI), and leave the rest of the format alone. Old implmentations : should fail gracefully with "unknown signature algorithm". The : onepass signature header lets the "MAC" be at the end yet insures : that someone can't just delete the "MAC". Some additional benefits of a symmetric signature are that: - the attacker is left guessing whether or not the recipient will check the MDC, even for all existing pgp2.x, pgp5.x and pgp6.x implementations - if the recipient later upgrades he can at that later time check the MDCs and detect the modification after the fact I argue that these benefits make it worth favoring the new signature type over appended hash approach. I agree that the addition of large ciphers would be a good time to phase in the other proposed changes. Perhaps even, we could clean up the length business at the same time, which would allow eventual deprecation of sections 4.2.1, 4.2.2 and 4.2.3 The new-format packet lengths (4.2.2, 4.2.3) are even more complicated than the old ones (4.2.1). Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA22609 for ietf-open-pgp-bks; Mon, 12 Apr 1999 16:21:01 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA22605 for ; Mon, 12 Apr 1999 16:21:00 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id TAA08946; Mon, 12 Apr 1999 19:21:13 -0400 Received: from buoy.watson.ibm.com (buoy.watson.ibm.com [9.2.3.94]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id TAA22576; Mon, 12 Apr 1999 19:21:13 -0400 Received: by buoy.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA24998; Mon, 12 Apr 1999 19:21:13 -0400 From: uri Message-Id: <9904122321.AA24998@buoy.watson.ibm.com> Subject: Re: Phil Zimmermann's suggestion for large ciphers To: hal@rain.org Date: Mon, 12 Apr 1999 19:21:13 -0400 (EDT) Cc: ietf-open-pgp@imc.org In-Reply-To: <199904122159.OAA02053@hal.sb.rain.org> from "hal@rain.org" at Apr 12, 99 02:59:59 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: hal@rain.org says: > Phil suggests that we take advantage of the fact that when we go to large > block ciphers like Twofish, there are no backwards-compatibility issues. > ...................... Rather than trying to tweak the current symmetric > encrypted data packet spec, let us define a new encrypted data packet > which would be used for large ciphers and would solve some of the concerns > people have had with our existing encrypted data packets. Good. About time. > These concerns include - > > - The non-standard sync operation after the check bytes are handled Kill it. > - The non-standard treatment of IV Later. > - The lack of detection of message modification unless the message is > signed (many people don't like to sign their messages for legal reasons, > but they don't want them altered). Fix it. > The first thing in the packet would be the IV, of a size equal to the > block size of the cipher. It would be followed by the ciphertext, which > would be handled in CFB-n mode, where n is the block size of the cipher. > There would be no special shift or sync operations. I kinda like the idea of constant zero IV and plaintext prefixed with 128 random bits... Looks better than the "traditional" IV to me... > The plaintext would be prepended with a header consisting of check bytes > so that the proper key can be detected. The check bytes could be two > random bytes, followed by the same two bytes, repeated. Make the "pseudo-IV" prefix partially non-random - i.e. the last two bytes being checksum for the other 14. No big deal security-wise and noticeable help in detecting the right key. > The plaintext would be followed by a SHA-1 hash of the plaintext data. > This would be checked after decryption and detect message modification > attacks. Good enough. > This gives us a standard CFB mode, with a standard IV; a simple form of > redundancy at the beginning to verify the correct key; and a SHA-1 hash > at the end to protect the integrity of the data. Sure - but I still prefer "hidden" IV in the shape of plaintext prefix, and "visible" IV all zeroized... > One question is whether to use a keyed MAC, like an HMAC, for integrity > protection. A MAC is a Message Authentication Code, and is useful when > the two sides have authenticated themselves to each other. Exactly. And this is not a MAC - it's an MDC at best (Modification Detection Code). I do not think MAC is warranted here. In short - IMnotsoHM no need for keyed MAC or MDC. Plain SHA-1. > Another issue is whether to use a fixed hash like SHA-1 rather than > allowing the specification of a hash algorithm in the header. Shooting from the hip - no need for plenty of hashes. SHA-1 is good enough for this purpose. > The threat model is very different from the > case of cryptographic signatures, and a fixed hash like SHA-1 should > be suitable. It is. > We have also discussed providing integrity protection via some > modification to the signature packet format rather than by a new form > of encrypted packet. There would be a special kind of "signature" which > would just consist of a hash of the message to protect its integrity. Nah, IMNSHO isn't worth it. > One objection to this linkage is that if the message is both signed and > encrypted, there is redundancy, since we compute an integrity protection > hash in the encryption layer, and also a signature verification hash > in the signature layer. So? Compared to cost of one RSA or DSA operation, one SHA-1 is negligible. Who cares? > The signature provides integrity protection as > well as authentication, and so it is wasteful to also provide integrity > protection as part of the encryption. "Penny-wise, pound-foolish". I'd rather not do things in dozens of different ways. Phil is correct here - it is better to have that extra "wasteful" protection. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA22504 for ietf-open-pgp-bks; Mon, 12 Apr 1999 16:09:00 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA22500 for ; Mon, 12 Apr 1999 16:08:59 -0700 (PDT) Received: from jcallas (dhcp-47-64.dhcp.nai.com [161.69.47.64]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id QAA19851; Mon, 12 Apr 1999 16:08:14 -0700 (PDT) Message-Id: <3.0.3.32.19990412160709.0336ed40@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 12 Apr 1999 16:07:09 -0700 To: hal@rain.org, ietf-open-pgp@imc.org From: Jon Callas Subject: Re: Phil Zimmermann's suggestion for large ciphers In-Reply-To: <199904122159.OAA02053@hal.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Is Phil suggesting that we *NOT* use Twofish with packet 9, that we hold off on large blocks until the new encrypted data packet gets defined? Jon ----- Jon Callas jon@pgp.com CTO, Total Network Security 3965 Freedom Circle Network Associates, Inc. Santa Clara, CA 95054 (408) 346-5860 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA21861 for ietf-open-pgp-bks; Mon, 12 Apr 1999 15:00:43 -0700 (PDT) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA21856 for ; Mon, 12 Apr 1999 15:00:42 -0700 (PDT) Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.3/8.9.3) with ESMTP id PAA22448 for ; Mon, 12 Apr 1999 15:00:55 -0700 (PDT) Received: (from hal@localhost) by hal.sb.rain.org (8.8.7/8.8.7) id OAA02053 for ietf-open-pgp@imc.org; Mon, 12 Apr 1999 14:59:59 -0700 Date: Mon, 12 Apr 1999 14:59:59 -0700 From: hal@rain.org Message-Id: <199904122159.OAA02053@hal.sb.rain.org> To: ietf-open-pgp@imc.org Subject: Phil Zimmermann's suggestion for large ciphers Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I spoke with Phil Zimmermann on the phone about the issues raised by moving to larger block ciphers, and he made the following proposal. Phil suggests that we take advantage of the fact that when we go to large block ciphers like Twofish, there are no backwards-compatibility issues. We know that we need to make some adjustments to the spec with regard to the large block size. Rather than trying to tweak the current symmetric encrypted data packet spec, let us define a new encrypted data packet which would be used for large ciphers and would solve some of the concerns people have had with our existing encrypted data packets. These concerns include - - The non-standard sync operation after the check bytes are handled - The non-standard treatment of IV - The lack of detection of message modification unless the message is signed (many people don't like to sign their messages for legal reasons, but they don't want them altered). We would define a new encrypted packet format which would be similar to the current one but which would resolve these problems. The first thing in the packet would be the IV, of a size equal to the block size of the cipher. It would be followed by the ciphertext, which would be handled in CFB-n mode, where n is the block size of the cipher. There would be no special shift or sync operations. The plaintext would be prepended with a header consisting of check bytes so that the proper key can be detected. The check bytes could be two random bytes, followed by the same two bytes, repeated. The plaintext would be followed by a SHA-1 hash of the plaintext data. This would be checked after decryption and detect message modification attacks. This gives us a standard CFB mode, with a standard IV; a simple form of redundancy at the beginning to verify the correct key; and a SHA-1 hash at the end to protect the integrity of the data. With this approach, rather than patching the spec to deal with large block ciphers in the existing packet format, we would say that the existing packets should only be used for ciphers with 64 bit blocks. Larger ciphers must use the new format. Again, this is a perfect opportunity to make this change because large ciphers won't be backwards compatible, anyway. We have talked about variants on this idea in the past. Let me briefly try to address some of the issues which have come up. One question is whether to use a keyed MAC, like an HMAC, for integrity protection. A MAC is a Message Authentication Code, and is useful when the two sides have authenticated themselves to each other. They have some shared secret and they use that to authenticate the data as having originated with the other. What we want is simple integrity protection. For this purpose there is no need for a shared secret and it is appropriate simply to use a hash to provide the protection. Another issue is whether to use a fixed hash like SHA-1 rather than allowing the specification of a hash algorithm in the header. There is no need for variable hash algorithms in this context. The attacker does not have access to the plaintext of the message. The SHA-1 hash is being used essentially as a complicated checksum. There are certain limited changes which an attacker can make to an encrypted message, and all we need is that the hash function has a complex enough structure that the attacker would not be able to alter the message and checksum to allow it to continue to verify. The threat model is very different from the case of cryptographic signatures, and a fixed hash like SHA-1 should be suitable. Allowing the specification of a hash algorithm would actually allow some new attacks, as an attacker could potentially modify the message to change the hash algorithm specification, at the cost of damaging some other parts of the message. The recipient would then find that the message had apparently been integrity-protected with an unknown hash algorithm, and the integrity protection would be lost. We have also discussed providing integrity protection via some modification to the signature packet format rather than by a new form of encrypted packet. There would be a special kind of "signature" which would just consist of a hash of the message to protect its integrity. However, Phil argues that this kind of integrity protection is inherently tied to the use of encryption. It has no functional effect if not used in conjunction with encryption. This is unlike our other signatures, which are cryptographically useful transformations even on their own. Because of this close tie to the encryption functionality it makes most sense to make it part of the encrypted packet. One objection to this linkage is that if the message is both signed and encrypted, there is redundancy, since we compute an integrity protection hash in the encryption layer, and also a signature verification hash in the signature layer. The signature provides integrity protection as well as authentication, and so it is wasteful to also provide integrity protection as part of the encryption. However, Phil points out that it is often the case that a signature cannot be verified because the signing key is not available. In that case there is no integrity protection at all. Putting integrity protection in the encryption layer ensures that all encrypted messages have integrity protection. Summing up, we have an opportunity now to move to a new encrypted packet format at the same time as we begin supporting new ciphers. We can fix some of the problems which people have been complaining about for years, without facing backwards compatibility issues. Hal Finney NAI, Inc. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA19859 for ietf-open-pgp-bks; Mon, 12 Apr 1999 12:04:11 -0700 (PDT) Received: from public.uni-hamburg.de (public.rrz.uni-hamburg.de [134.100.32.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA19854 for ; Mon, 12 Apr 1999 12:04:02 -0700 (PDT) Received: from paris.public.uni-hamburg.de (max2-021.public.uni-hamburg.de [134.100.45.21]) by public.uni-hamburg.de (8.8.8/8.8.8) with SMTP id VAA78996; Mon, 12 Apr 1999 21:03:59 +0200 Received: by ulf.mali.sub.org (Smail3.1.28.1 #1) id m10WlVG-0003bDC; Mon, 12 Apr 99 20:32 +0200 Message-Id: Date: Mon, 12 Apr 99 20:32 +0200 From: ulf@fitug.de (Ulf =?iso-8859-1?Q?M=F6ller?=) To: bleichen@research.bell-labs.com Subject: Re: Decrypting ElGamal messages Newsgroups: ulf.open-pgp In-Reply-To: <199904091656.MAA27520@aura.research.bell-labs.com> Organization: HR13 Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: >> Upon decryption, the recipient needs to check the PKCS-1 formatting, >> the checksum, and that the symmetric algorithm byte is one of the >> supported algorithms. It then tries to decrypt the following message >> block using that algorithm and session key, which block also has in >> it a two-byte redundancy at the beginning to further detect bad keys. > >Thanks a lot for the information. Would have missed the checksum >in the bulk data otherwise. I don't think you can count it in. While the semantics of a (Session Key Packet, Literal Packet) message is not defined in the RFC, a naïve implementor may very well try to be "generous in what they accept", as is suggested elsewhere in the document. PGP 5 does not accept such messages, but prints an "assertion failed" message only if the PKCS #1 padding and the Session Key Packet checksum are correct. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA03401 for ietf-open-pgp-bks; Fri, 9 Apr 1999 15:46:00 -0700 (PDT) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA03397 for ; Fri, 9 Apr 1999 15:45:58 -0700 (PDT) Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.3/8.9.3) with ESMTP id PAA17943; Fri, 9 Apr 1999 15:45:55 -0700 (PDT) Received: (from hal@localhost) by hal.sb.rain.org (8.8.7/8.8.7) id PAA00841; Fri, 9 Apr 1999 15:45:02 -0700 Date: Fri, 9 Apr 1999 15:45:02 -0700 From: hal@rain.org Message-Id: <199904092245.PAA00841@hal.sb.rain.org> To: ietf-open-pgp@imc.org, wk@isil.d.shuttle.de Subject: Re: Sample Twofish message Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Werner Koch, , writes: > hal@rain.org writes: > > > I believe Uri was referring to the passphrase-protected secret key > > data, which does use an IV in the conventional sense. > > Hmmm, from the pgp 2.6.3 documentation about secret key certificates: > > | and the checksum is used to tell if the password was good. The CFB > | IV field is just encrypted random data, assuming the "true" IV was > | zero. > > This is what is done in GnuPG too and I have checked interoperability > against pgp 5.0beta. This is actually pretty funny. We're both interpreting it differently, but we interoperate. By my interpretation, the first 8 bytes are an IV. We encrypt those with the key, and XOR into the next 8 bytes to get the first 8 bytes of plaintext. With your interpretation, the IV is zero. You encrypt that with the key and XOR into the first 8 bytes to get 8 random bytes, which you discard. You then take the first block of ciphertext, whiich is the first 8 bytes of data, encrypt it with the key, and XOR into the next 8 bytes to get the first 8 bytes of plaintext. The result is exactly the same. That's why it interoperates. With CFB mode, each ciphertext block acts like an "IV" for the next block. The situation is different for encrypted data blocks, because there we have the extra two bytes of check data which must be compared against the decrypted form of the first 8 bytes. So we must use the convention of a zero IV to successfully decrypt that. But with the encrypted secret keys there are no check bytes and the two descriptions are equivalent (as long as the IV size == the block size). Sorry I have not yet sent out Phil's proposal, I've been having connectivity problems today. Hal Finney Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA01878 for ietf-open-pgp-bks; Fri, 9 Apr 1999 13:31:18 -0700 (PDT) Received: from relay6.UU.NET (relay6.UU.NET [192.48.96.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA01874 for ; Fri, 9 Apr 1999 13:31:16 -0700 (PDT) Received: from xedia.com by relay6.UU.NET with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgkfy21116; Fri, 9 Apr 1999 16:30:19 -0400 (EDT) Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA22231; Fri, 9 Apr 99 16:30:08 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id QAA06095; Fri, 9 Apr 1999 16:30:12 -0400 Date: Fri, 9 Apr 1999 16:30:12 -0400 Message-Id: <199904092030.QAA06095@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: uri@watson.ibm.com Cc: hal@rain.org, ietf-open-pgp@imc.org Subject: Re: Sample Twofish message References: <199904091624.JAA02411@hal.sb.rain.org> <9904091829.AA28528@buoy.watson.ibm.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: >>>>> "Uri" == Uri Blumenthal writes: Uri> hal@rain.org says: >> > IV length normally is equal to the block size. I see no reason >> to > divert from this. >> >> With regard to the secret key encryption: The only real >> requirement on an IV is that it is unique for that key, that it >> does not match any other IV's and it doesn't match any of the >> ciphertext blocks which are used with that key. For this purpose, >> 64 bits should be adequate unless we store more than 4 billion >> (2^32) private keys using the same passphrase (and even then the >> unique salt would save us). So a 64 bit IV is plenty big. Uri> True. But: >> However in the interests of convenience and consistency it would >> probably make more sense to use the block size. This avoids any >> ambiguities about whether a shorter IV should be left or right >> justified and how the remaining bits of the block should be filled >> in. Uri> Exactly! I'm very hard pressed to see ANY valid argument for making an IV smaller than the blocksize. Even if it technically possible (which I guess it is with CFB mode) it should not be done. There is no benefit I can see, and a very clear issue: if you have a cypher with 128 bit blocks, 128 bit strength, etc., what conceivable cryptographic merit is there in introducing a 64 bit component into the puzzle? Why go through the process of analyzing the security implications and demonstrating that there aren't any when there is no benefit to be had? Or of there is one, certainly not one that justifies months of analysis? My impression from watching AES discussions is that weaknesses that open up O(2^64) attacks of any kind are considered things to be concerned about. Not being an academically trained cryptographer I may be reading too much into the discussion, but even so, that seems like a logical position to take. paul Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA00811 for ietf-open-pgp-bks; Fri, 9 Apr 1999 11:40:21 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA00807 for ; Fri, 9 Apr 1999 11:40:19 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id UAA13433 for ietf-open-pgp@imc.org; Fri, 9 Apr 1999 20:40:17 +0200 (MET DST) Received: (qmail 21392 invoked from network); 9 Apr 1999 18:33:00 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 9 Apr 1999 18:33:00 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10Vg2q-0004ZE-00; Fri, 9 Apr 1999 20:30:24 +0200 Date: Fri, 9 Apr 1999 20:30:24 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Sample Twofish message Message-ID: <19990409203024.B17482@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904091624.JAA02411@hal.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <199904091624.JAA02411@hal.sb.rain.org>; from hal@rain.org on Fri, Apr 09, 1999 at 09:24:19AM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: hal@rain.org writes: > block size. Can we consider keeping the language to use the extra > sync only for 64 bit block ciphers? Yes. -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA00805 for ietf-open-pgp-bks; Fri, 9 Apr 1999 11:40:17 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA00801 for ; Fri, 9 Apr 1999 11:40:16 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id UAA13426 for ietf-open-pgp@imc.org; Fri, 9 Apr 1999 20:40:14 +0200 (MET DST) Received: (qmail 21386 invoked from network); 9 Apr 1999 18:31:09 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 9 Apr 1999 18:31:09 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10Vg13-0004Z8-00; Fri, 9 Apr 1999 20:28:33 +0200 Date: Fri, 9 Apr 1999 20:28:33 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Sample Twofish message Message-ID: <19990409202833.A17482@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904091702.KAA02554@hal.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <199904091702.KAA02554@hal.sb.rain.org>; from hal@rain.org on Fri, Apr 09, 1999 at 10:02:52AM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: hal@rain.org writes: > I believe Uri was referring to the passphrase-protected secret key > data, which does use an IV in the conventional sense. Hmmm, from the pgp 2.6.3 documentation about secret key certificates: | and the checksum is used to tell if the password was good. The CFB | IV field is just encrypted random data, assuming the "true" IV was | zero. This is what is done in GnuPG too and I have checked interoperability against pgp 5.0beta. > the rest of the packet anyway, so there is no need to parse it. You do > have information about the overall packet size from the packet headers, > so you can just skip past the encrypted data. Sure, it adds extra complexity to the already complex issue with S2K and pgp2 mode - but no problem ;-) > approach for this problem. I will post a summary later this morning. This means late evening in Europe :-( -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA00614 for ietf-open-pgp-bks; Fri, 9 Apr 1999 11:30:09 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA00610 for ; Fri, 9 Apr 1999 11:30:07 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id OAA09716; Fri, 9 Apr 1999 14:29:54 -0400 Received: from buoy.watson.ibm.com (buoy.watson.ibm.com [9.2.3.94]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id OAA18272; Fri, 9 Apr 1999 14:29:22 -0400 Received: by buoy.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA28528; Fri, 9 Apr 1999 14:29:12 -0400 From: Uri Blumenthal Message-Id: <9904091829.AA28528@buoy.watson.ibm.com> Subject: Re: Sample Twofish message To: hal@rain.org Date: Fri, 9 Apr 1999 14:29:12 -0400 (EDT) Cc: ietf-open-pgp@imc.org In-Reply-To: <199904091624.JAA02411@hal.sb.rain.org> from "hal@rain.org" at Apr 9, 99 09:24:19 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: hal@rain.org says: > > IV length normally is equal to the block size. I see no reason to > > divert from this. > > With regard to the secret key encryption: > The only real requirement on an IV is that it is unique for that key, > that it does not match any other IV's and it doesn't match any of the > ciphertext blocks which are used with that key. For this purpose, > 64 bits should be adequate unless we store more than 4 billion (2^32) > private keys using the same passphrase (and even then the unique salt > would save us). So a 64 bit IV is plenty big. True. But: > However in the interests of convenience and consistency it would probably > make more sense to use the block size. This avoids any ambiguities > about whether a shorter IV should be left or right justified and how > the remaining bits of the block should be filled in. Exactly! > With regard to message encryption, the symmetrically encrypted data > packets: > > The 8+2 bytes which precede the message are not technically an IV; the > IV is zero, and the 8+2 bytes are used in place of an IV to accomplish > the same purpose. However this size does not work properly in the case > of 128 bit blocks. In essence those 8+2 bytes *are* performing the function of IV. > [...description of a problem....] This is a serious leak. Probably. (:-) > .........But still there is no reason to take this chance. > Therefore we should increase the 8 bytes to be the size of the block > cipher. (:-) My wish precisely! > It is not difficult to code the CFB sync to be optional based on > block size. Can we consider keeping the language to use the extra > sync only for 64 bit block ciphers? Probably. No strong preference either way. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA29774 for ietf-open-pgp-bks; Fri, 9 Apr 1999 10:03:02 -0700 (PDT) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA29770 for ; Fri, 9 Apr 1999 10:03:02 -0700 (PDT) Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.3/8.9.3) with ESMTP id KAA12337; Fri, 9 Apr 1999 10:02:55 -0700 (PDT) Received: (from hal@localhost) by hal.sb.rain.org (8.8.7/8.8.7) id KAA02554; Fri, 9 Apr 1999 10:02:52 -0700 Date: Fri, 9 Apr 1999 10:02:52 -0700 From: hal@rain.org Message-Id: <199904091702.KAA02554@hal.sb.rain.org> To: ietf-open-pgp@imc.org, wk@isil.d.shuttle.de Subject: Re: Sample Twofish message Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Werner Koch, , writes: > Uri Blumenthal writes: > > IV length normally is equal to the block size. I see no reason to > > divert from this. > > Actually it is not the IV (which is always zero) but the random bytes > prepended to the plaintext. However I think you are right and we > should agree to use an IV of the blocksize instead of 8. The problem > with this is that an application needs to know the blocksize of all > possible algorithms to parse the packet - maybe it is better to change > it only if we specify a new version number of the packet, Hmmm... I believe Uri was referring to the passphrase-protected secret key data, which does use an IV in the conventional sense. As far as the need to know the block size, this would only be a problem if you faced an unknown cipher ID. But in that case you can't decrypt the rest of the packet anyway, so there is no need to parse it. You do have information about the overall packet size from the packet headers, so you can just skip past the encrypted data. I just spoke on the phone with Phil Zimmermann, who suggested a different approach for this problem. I will post a summary later this morning. Hal Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29706 for ietf-open-pgp-bks; Fri, 9 Apr 1999 09:58:04 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA29702 for ; Fri, 9 Apr 1999 09:58:02 -0700 (PDT) Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Fri Apr 9 12:56:45 EDT 1999 Received: from aura.research.bell-labs.com ([135.104.46.10]) by research; Fri Apr 9 12:56:44 EDT 1999 Received: (from bleichen@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id MAA27520; Fri, 9 Apr 1999 12:56:43 -0400 (EDT) Date: Fri, 9 Apr 1999 12:56:43 -0400 (EDT) From: Daniel Bleichenbacher Message-Id: <199904091656.MAA27520@aura.research.bell-labs.com> To: bleichen@research.bell-labs.com, ietf-open-pgp@imc.org, hal@rain.org Subject: Re: Decrypting ElGamal messages X-Sun-Charset: US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hal Finney , writes: > Daniel Bleichenbacher, , writes: > > Can anyone tell me how an ElGamal encrypted message has to be > > decrypted? The open-pgp documentation doesn't give the answer. > > I'm specially interested in how padding and checksums are handled. > > With both RSA and ElGamal messages, the session key is prepended with a > byte identifying the symmetric algorithm used to encrypt the bulk message > data (typically one of three or four supported symmetric algorithm > values can go here). It is then appended with a two-byte checksum. > The resulting string is PKCS-1 padded and encrypted. > > Upon decryption, the recipient needs to check the PKCS-1 formatting, > the checksum, and that the symmetric algorithm byte is one of the > supported algorithms. It then tries to decrypt the following message > block using that algorithm and session key, which block also has in > it a two-byte redundancy at the beginning to further detect bad keys. Thanks a lot for the information. Would have missed the checksum in the bulk data otherwise. > > I'm asking this question, because ElGamal encryption has the > > same multiplicative properties as RSA. In particular, given > > the encryption of a message M (including padding), it is easy > > to generate the encryption of M*S (mod p) for a given S, without > > knowing M. Hence the same attack that was possible against SSL > > potentially works against ElGamal, when used with PKCS #1 v1.5 > > padding. > > It would be good to mention this attack in a future version of the draft. > It is important not to leak information about which step in the decryption > process fails. > > Then, in order to fake a successful encrypted session key, it must not > only be properly PKCS-1 padded, it must also have a correct two-byte > checksum (adding 16 bits of difficulty), it must have a legal symmetric > algorithm byte (adding about 6 bits of difficulty), and it must pass the > checksum test when the payload data is decrypted (adding another 16 bits). > This would make the attack in total about 2^38 times harder than against > a bare PKCS-1 leaking decryptor, which should be a significant barrier > in most practical situations. I'm not sure about this "2^38 times harder...", but estimating this number is exactly the goal of the whole exercise. Are there any publications considering the security of the openpgp message format against chosen ciphertext attacks? As Peter Gutmann pointed out, a chosen ciphertext attacks would be almost impossible against plain PGP. The openpgp standard should however be useful for any application using the same message format, and client-server applications should not be prevented. > > BTW, is there any reason why PKCS #1 v1.5 padding is used and > > not PKCS #1 v2? > > Although the RFC came out recently, it documents existing practice which > was developed in 1996. At that time version 1.5 of PKCS 1 was extant. > > Hal Finney > NAI, Inc. Daniel Bleichenbacher Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29695 for ietf-open-pgp-bks; Fri, 9 Apr 1999 09:56:21 -0700 (PDT) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29691 for ; Fri, 9 Apr 1999 09:56:20 -0700 (PDT) Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.3/8.9.3) with ESMTP id JAA11632; Fri, 9 Apr 1999 09:56:15 -0700 (PDT) Received: (from hal@localhost) by hal.sb.rain.org (8.8.7/8.8.7) id JAA02411; Fri, 9 Apr 1999 09:24:19 -0700 Date: Fri, 9 Apr 1999 09:24:19 -0700 From: hal@rain.org Message-Id: <199904091624.JAA02411@hal.sb.rain.org> To: uri@watson.ibm.com Subject: Re: Sample Twofish message Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Uri Blumenthal, , writes: > Werner Koch says: > > We use a 8 byte IV for encrypting the secret key material; see > > section 5.5.3. Do we keep this 8 bytes or extend it to the blocksize? > > IV length normally is equal to the block size. I see no reason to > divert from this. With regard to the secret key encryption: The only real requirement on an IV is that it is unique for that key, that it does not match any other IV's and it doesn't match any of the ciphertext blocks which are used with that key. For this purpose, 64 bits should be adequate unless we store more than 4 billion (2^32) private keys using the same passphrase (and even then the unique salt would save us). So a 64 bit IV is plenty big. However in the interests of convenience and consistency it would probably make more sense to use the block size. This avoids any ambiguities about whether a shorter IV should be left or right justified and how the remaining bits of the block should be filled in. With regard to message encryption, the symmetrically encrypted data packets: The 8+2 bytes which precede the message are not technically an IV; the IV is zero, and the 8+2 bytes are used in place of an IV to accomplish the same purpose. However this size does not work properly in the case of 128 bit blocks. If we had two messages encrypted with the same key, then for each of them we would encrypt a block of zeros and XOR that with the first 16 bytes of the message, to form the ciphertext. Only the first 10 bytes are random; the remaining 6 are plaintext. Therefore the last 6 bytes of this first block of data would be the first 6 bytes of plaintext, xored with a value which was the same for each encryption where that same key was used. This would allow an attacker to recover the XOR of the first 6 bytes of the plaintexts of multiple messages, and possibly therefore to find these 6 bytes of plaintext. This is a serious leak. We would possibly be saved by the fact that the spec says to use salt in hashing the passphrase, so it is unlikely that any two messages are encrypted with the same key even if the same passphrase is used. But still there is no reason to take this chance. Therefore we should increase the 8 bytes to be the size of the block cipher. Several people have commented that they don't like the extra CFB sync operation which is done after the first 8+2 (or now 16+2) bytes are read. It is a nonstandard operation and requires special code in the CFB module. I had suggested that we skip the CFB for larger blocks, on the theory that we would eventually migrate to larger block ciphers throughout, and then we could retire the CFB sync along with the support of 64 bit block ciphers. This would be perhaps four or five years from now. It is not difficult to code the CFB sync to be optional based on block size. Can we consider keeping the language to use the extra sync only for 64 bit block ciphers? Hal Finney NAI, Inc. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29370 for ietf-open-pgp-bks; Fri, 9 Apr 1999 09:20:58 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29366 for ; Fri, 9 Apr 1999 09:20:56 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id SAA04463 for ietf-open-pgp@imc.org; Fri, 9 Apr 1999 18:20:55 +0200 (MET DST) Received: (qmail 21240 invoked from network); 9 Apr 1999 16:13:57 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 9 Apr 1999 16:13:57 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10VdsH-0004XI-00; Fri, 9 Apr 1999 18:11:21 +0200 Date: Fri, 9 Apr 1999 18:11:21 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Sample Twofish message Message-ID: <19990409181120.A17264@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <19990409113321.F14298@frodo.isil.d.shuttle.de> <9904091544.AA16968@buoy.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <9904091544.AA16968@buoy.watson.ibm.com>; from Uri Blumenthal on Fri, Apr 09, 1999 at 11:44:12AM -0400 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Uri Blumenthal writes: > IV length normally is equal to the block size. I see no reason to > divert from this. Actually it is not the IV (which is always zero) but the random bytes prepended to the plaintext. However I think you are right and we should agree to use an IV of the blocksize instead of 8. The problem with this is that an application needs to know the blocksize of all possible algorithms to parse the packet - maybe it is better to change it only if we specify a new version number of the packet, Hmmm... -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA29017 for ietf-open-pgp-bks; Fri, 9 Apr 1999 08:44:55 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA29013 for ; Fri, 9 Apr 1999 08:44:54 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id LAA11148; Fri, 9 Apr 1999 11:44:14 -0400 Received: from buoy.watson.ibm.com (buoy.watson.ibm.com [9.2.3.94]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id LAA09668; Fri, 9 Apr 1999 11:44:14 -0400 Received: by buoy.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA16968; Fri, 9 Apr 1999 11:44:13 -0400 From: Uri Blumenthal Message-Id: <9904091544.AA16968@buoy.watson.ibm.com> Subject: Re: Sample Twofish message To: wk@isil.d.shuttle.de (Werner Koch) Date: Fri, 9 Apr 1999 11:44:12 -0400 (EDT) Cc: ietf-open-pgp@imc.org In-Reply-To: <19990409113321.F14298@frodo.isil.d.shuttle.de> from "Werner Koch" at Apr 9, 99 11:33:21 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Werner Koch says: > We use a 8 byte IV for encrypting the secret key material; see > section 5.5.3. Do we keep this 8 bytes or extend it to the blocksize? IV length normally is equal to the block size. I see no reason to divert from this. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA24400 for ietf-open-pgp-bks; Fri, 9 Apr 1999 04:28:54 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA24390 for ; Fri, 9 Apr 1999 04:28:46 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id NAA11740 for ietf-open-pgp@imc.org; Fri, 9 Apr 1999 13:28:42 +0200 (MET DST) Received: (qmail 20805 invoked from network); 9 Apr 1999 11:24:15 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 9 Apr 1999 11:24:15 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10VZLs-0004Rr-00; Fri, 9 Apr 1999 13:21:36 +0200 Date: Fri, 9 Apr 1999 13:21:35 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: New sample message Message-ID: <19990409132135.A17074@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904080539.WAA02648@hal.sb.rain.org> <3.0.3.32.19990408143618.03cb97f0@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <3.0.3.32.19990408143618.03cb97f0@mail.pgp.com>; from Jon Callas on Thu, Apr 08, 1999 at 02:36:18PM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi, Here is a new sample message for 256 bit block ciphers. Can anyone please check it? Note, that the message is preceded by 16 random bytes, then two more bytes which are copies of the last two of the random ones. A CFB sync is done after encrypting these 18 bytes. The message is encrypted using the one-letter passphrase "x". -----BEGIN PGP MESSAGE----- jA0ECgMCTwlMs52octhgyTEFgAUN6FWXpPHkYLqajQoEL0nK6G43N7aOKtfvAI7c faEmtImxBUrnq+P1a+PgWjiu =xKas -----END PGP MESSAGE----- The structure of this message is: :symkey enc packet: version 4, cipher 10, s2k 3, hash 2 salt 4f094cb39da872d8, count 96 :encrypted data packet: length: 49 :literal data packet: mode b, created 923655302, name="tf2", raw data: 20 bytes The 256 bit key is: D5 13 A1 FA 34 9C 99 71 55 EC 8A 48 76 F8 BD 2E A1 24 D8 78 75 0C 86 04 49 DF 3E 6F 85 56 25 D5 The begin of the plaintext messsage is: 81 3D D9 FE 58 35 62 7A 1E 0D 1C 6F 4D 10 04 4C 04 4C -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA18958 for ietf-open-pgp-bks; Fri, 9 Apr 1999 02:51:03 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA18946 for ; Fri, 9 Apr 1999 02:50:58 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id LAA03703 for ietf-open-pgp@imc.org; Fri, 9 Apr 1999 11:50:54 +0200 (MET DST) Received: (qmail 20190 invoked from network); 9 Apr 1999 09:36:01 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 9 Apr 1999 09:36:01 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10VXf7-0003mw-00; Fri, 9 Apr 1999 11:33:21 +0200 Date: Fri, 9 Apr 1999 11:33:21 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Sample Twofish message Message-ID: <19990409113321.F14298@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904080539.WAA02648@hal.sb.rain.org> <3.0.3.32.19990408143618.03cb97f0@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <3.0.3.32.19990408143618.03cb97f0@mail.pgp.com>; from Jon Callas on Thu, Apr 08, 1999 at 02:36:18PM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Jon Callas writes: > Do we agree now that the right thing to do is to start with a 16-byte IV, > encrypt 16 bytes, sync with 2 and then continue? That's what I thought we ACK. > all agreed on. If we agree that, then we don't have a problem, we have an > elided description that needs to be expanded when we revise the RFC. I > believe, though, that that's the right thing to do, work with full blocksizes. We use a 8 byte IV for encrypting the secret key material; see section 5.5.3. Do we keep this 8 bytes or extend it to the blocksize? -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA22761 for ietf-open-pgp-bks; Thu, 8 Apr 1999 18:18:02 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA22757 for ; Thu, 8 Apr 1999 18:18:01 -0700 (PDT) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id VAA06678; Thu, 8 Apr 1999 21:17:53 -0400 Received: from buoy.watson.ibm.com (buoy.watson.ibm.com [9.2.3.94]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id VAA07832; Thu, 8 Apr 1999 21:17:52 -0400 Received: by buoy.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA28494; Thu, 8 Apr 1999 21:17:46 -0400 From: Uri Blumenthal Message-Id: <9904090117.AA28494@buoy.watson.ibm.com> Subject: Re: Sample Twofish message To: wk@isil.d.shuttle.de (Werner Koch) Date: Thu, 8 Apr 1999 21:17:36 -0400 (EDT) Cc: ietf-open-pgp@imc.org In-Reply-To: <19990408074957.B5540@frodo.isil.d.shuttle.de> from "Werner Koch" at Apr 8, 99 07:49:57 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Werner Koch says: > Okay, how can we resolve this conflict: > >From section 5.7: > The data is encrypted in CFB mode, with a CFB shift size equal to the > cipher's block size. The Initial Vector (IV) is specified as all > zeros. Instead of using an IV, OpenPGP prefixes a 10-octet string to > the data before it is encrypted. The first eight octets are random, > and the 9th and 10th octets are copies of the 7th and 8th octets, > respectively. After encrypting the first 10 octets, the CFB state is > resynchronized if the cipher block size is 8 octets or less. The > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > last 8 octets of ciphertext are passed through the cipher and the > block boundary is reset. 1. For 128-bit block ciphers shouldn't the prefix be increased to, say, 18 bytes? 2. Shouldn't all procedures be adjusted to 16 octets for such ciphers? > >From section 12.8:......... > > 5.7 says that resync is only done for a blocksize <= 64 but 12.8 says > that is done always (the following step by step list also says this). I'd abandon (or fix :-) 12.8. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA22682 for ietf-open-pgp-bks; Thu, 8 Apr 1999 18:11:29 -0700 (PDT) Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA22678 for ; Thu, 8 Apr 1999 18:11:25 -0700 (PDT) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id NAA06463; Fri, 9 Apr 1999 13:10:56 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92362025506148>; Fri, 9 Apr 1999 13:10:55 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: bleichen@research.bell-labs.com, ietf-open-pgp@imc.org Subject: Re: Decrypting ElGamal messages Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Fri, 9 Apr 1999 13:10:55 (NZST) Message-ID: <92362025506148@cs26.cs.auckland.ac.nz> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: >>1. The implementor has managed to design a protocol which will accept >> arbitrary numbers of chosen-ciphertext messages and reply to each one with >> an exact indication of how the decrypt failed, leaking information about >> the decrypted message to an attacker. This is a fairly remarkable feat, >> but let's say, just for arguments sake, that someone did do this. >I'm not sure how remarkable this would be. Quite a large number of SSL servers >actually returned the necessary error messages for an attack there. I think >one shouldn't leave the chance here that the implementor makes mistakes and >add some quidelines to the standard. That's what I'd proposed earlier on in the same thread. In addition you have to remember that S/MIME and PGP are very different beasties from SSL, unless you go out of your way to design a protocol which returns decryption results you'd never get this situation, the best you can hope for is an SMTP-level "Your mail probably got to some machine from which the recipient can collect it" which never gets near the security layer. Even though S/MIME has provisions for signed receipts, the most they can communicate is "I got your message", which is just a glorified form of the SMTP-level response and doesn't help with this particular attack. >>4. A typical query+response takes half a second (this means opening a >> connecting, generating a chosen-ciphertext message, transmitting it, having >> the victim decode and try to decrypt it, generating a response, wrapping up >> an exact indication of the decryption error it encountered, and sending it >> back to the attacker). >The latest that I heard of was a server presented at the RSA conference that >can do 1500 SSL connections per second. Again, it's a special case for SSL. For it to affect S/MIME or PGP you'd need to set up an autoresponder running a custom protocol designed to facilitate the attack (since it can't be done using any feature of standard S/MIME or PGP). Peter. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA22056 for ietf-open-pgp-bks; Thu, 8 Apr 1999 17:18:15 -0700 (PDT) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA22052 for ; Thu, 8 Apr 1999 17:18:14 -0700 (PDT) Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.3/8.9.3) with ESMTP id RAA27738; Thu, 8 Apr 1999 17:18:03 -0700 (PDT) Received: (from hal@localhost) by hal.sb.rain.org (8.8.7/8.8.7) id RAA01291; Thu, 8 Apr 1999 17:17:58 -0700 Date: Thu, 8 Apr 1999 17:17:58 -0700 From: hal@rain.org Message-Id: <199904090017.RAA01291@hal.sb.rain.org> To: bleichen@research.bell-labs.com, ietf-open-pgp@imc.org Subject: Re: Decrypting ElGamal messages Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Daniel Bleichenbacher, , writes: > Can anyone tell me how an ElGamal encrypted message has to be > decrypted? The open-pgp documentation doesn't give the answer. > I'm specially interested in how padding and checksums are handled. With both RSA and ElGamal messages, the session key is prepended with a byte identifying the symmetric algorithm used to encrypt the bulk message data (typically one of three or four supported symmetric algorithm values can go here). It is then appended with a two-byte checksum. The resulting string is PKCS-1 padded and encrypted. Upon decryption, the recipient needs to check the PKCS-1 formatting, the checksum, and that the symmetric algorithm byte is one of the supported algorithms. It then tries to decrypt the following message block using that algorithm and session key, which block also has in it a two-byte redundancy at the beginning to further detect bad keys. > I'm asking this question, because ElGamal encryption has the > same multiplicative properties as RSA. In particular, given > the encryption of a message M (including padding), it is easy > to generate the encryption of M*S (mod p) for a given S, without > knowing M. Hence the same attack that was possible against SSL > potentially works against ElGamal, when used with PKCS #1 v1.5 > padding. It would be good to mention this attack in a future version of the draft. It is important not to leak information about which step in the decryption process fails. Then, in order to fake a successful encrypted session key, it must not only be properly PKCS-1 padded, it must also have a correct two-byte checksum (adding 16 bits of difficulty), it must have a legal symmetric algorithm byte (adding about 6 bits of difficulty), and it must pass the checksum test when the payload data is decrypted (adding another 16 bits). This would make the attack in total about 2^38 times harder than against a bare PKCS-1 leaking decryptor, which should be a significant barrier in most practical situations. > BTW, is there any reason why PKCS #1 v1.5 padding is used and > not PKCS #1 v2? Although the RFC came out recently, it documents existing practice which was developed in 1996. At that time version 1.5 of PKCS 1 was extant. Hal Finney NAI, Inc. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA20984 for ietf-open-pgp-bks; Thu, 8 Apr 1999 15:28:08 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA20979 for ; Thu, 8 Apr 1999 15:28:06 -0700 (PDT) Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Thu Apr 8 18:26:40 EDT 1999 Received: from aura.research.bell-labs.com ([135.104.46.10]) by research; Thu Apr 8 18:26:39 EDT 1999 Received: (from bleichen@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id SAA21909; Thu, 8 Apr 1999 18:26:39 -0400 (EDT) Date: Thu, 8 Apr 1999 18:26:39 -0400 (EDT) From: Daniel Bleichenbacher Message-Id: <199904082226.SAA21909@aura.research.bell-labs.com> To: bleichen@research.bell-labs.com, ietf-open-pgp@imc.org, pgut001@cs.auckland.ac.nz Subject: Re: Decrypting ElGamal messages X-Sun-Charset: US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > From: pgut001@cs.auckland.ac.nz (Peter Gutmann) > Date: Fri, 9 Apr 1999 09:46:07 (NZST) > > Daniel Bleichenbacher writes: > > >I'm asking this question, because ElGamal encryption has the same > >multiplicative properties as RSA. In particular, given the encryption of a > >message M (including padding), it is easy to generate the encryption of M*S > >(mod p) for a given S, without knowing M. Hence the same attack that was > >possible against SSL potentially works against ElGamal, when used with PKCS > >#1 v1.5 padding. > > > >BTW, is there any reason why PKCS #1 v1.5 padding is used and not PKCS #1 v2? > > This exact issue was debated on the ietf-smime list when I asked why X9.42 > (which looks like the winning candidate from a 'Worst way to apply the DLP to > solving a key transport problem' competition... [remainder bobbitted to avoid > another flamewar over this :-]) was being used instead of the far more logical > Elgamal, which would be a direct, patent-free drop-in replacement for the > existing RSA key transport. The only reason anyone could put up against > Elgamal was "You need to use OAEP because PKCS #1 padding is insecure". In > response to this (at the end of a longish debate) I posted the following > back-of-the-envelope analysis: > > -- Snip -- > > The second approach is to see just what it would take to implement this attack > on CMS (not S/MIME, but anything involving CMS). For this analysis I'll make > several assumptions: > > 1. The implementor has managed to design a protocol which will accept > arbitrary numbers of chosen-ciphertext messages and reply to each one with > an exact indication of how the decrypt failed, leaking information about > the decrypted message to an attacker. This is a fairly remarkable feat, > but let's say, just for arguments sake, that someone did do this. I'm not sure how remarkable this would be. Quite a large number of SSL servers actually returned the necessary error messages for an attack there. I think one shouldn't leave the chance here that the implementor makes mistakes and add some quidelines to the standard. > 2. The implementor and any third-party reviewers have somehow missed the CERT > advisory, RSA labs bulletin, publicity about the attack, and whatever else > is around there which tells people about the problem and (very simple) fix. They also have to know that ElGamal and RSA have similar mathematical properties. But, again wouldn't it be better if these people were informed via the standard? > 3. The PKCS #1 implementation being used is correct (that is, it doesn't have > the implementation bug which was found and fixed in the SSL implementations). Sure. You need to include a message digest. But if I'm correct then open-pgp uses a 2 byte modular checksum. > 4. A typical query+response takes half a second (this means opening a > connecting, generating a chosen-ciphertext message, transmitting it, having > the victim decode and try to decrypt it, generating a response, wrapping up > an exact indication of the decryption error it encountered, and sending it > back to the attacker). The latest that I heard of was a server presented at the RSA conference that can do 1500 SSL connections per second. > OK, so we have a server which does all of the above sitting there ready for > attack. With a correct PKCS #1 implementation (that is, it checks the padding > as per the PKCS #1 spec), the complexity is approximately 1 million attempts > (for the 00 02 padding) x 20 (for the second 00 before the MEK) x 2 (for the > minimum of 8 nonzero bytes), or 40 million attempts (the 1 million attempts > requires the presence of the SSL implementation bug mentioned above). > > This requires just under 8 months of CPU time to perform, after which you've > recovered a single MEK [S/MIME jargon for "message encryption key"]. The 1 million messages was an estimate for my algorithm for 1024 bit RSA moduli. This algorithm is not optimal. 100'000 is probably reachable with some work. Also for some strange moduli (e.g. 1025 bit) some experiments required less than 10'000 messages. It's not hard to imagine that someone configures a server that can be broken in much less than 1 hour. (Please note, this is an estimate for plain PKCS #1 v 1.5 formatting. I don't know anything about ElGamal padding yet.) > I would suggest that anyone who doesn't notice that their server is under > continuous attack for 8 solid months has more than simple crypto problems to > worry about. > > -- Snip -- > > Peter. Intrusion detection tricks like this are certainly worth considering. But I'd prefer a protocol that doesn't rely on this. Daniel Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA20590 for ietf-open-pgp-bks; Thu, 8 Apr 1999 14:46:30 -0700 (PDT) Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20585 for ; Thu, 8 Apr 1999 14:46:27 -0700 (PDT) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id JAA28258; Fri, 9 Apr 1999 09:46:08 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92360796703112>; Fri, 9 Apr 1999 09:46:07 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: bleichen@research.bell-labs.com, ietf-open-pgp@imc.org Subject: Re: Decrypting ElGamal messages Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Fri, 9 Apr 1999 09:46:07 (NZST) Message-ID: <92360796703112@cs26.cs.auckland.ac.nz> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Daniel Bleichenbacher writes: >I'm asking this question, because ElGamal encryption has the same >multiplicative properties as RSA. In particular, given the encryption of a >message M (including padding), it is easy to generate the encryption of M*S >(mod p) for a given S, without knowing M. Hence the same attack that was >possible against SSL potentially works against ElGamal, when used with PKCS >#1 v1.5 padding. > >BTW, is there any reason why PKCS #1 v1.5 padding is used and not PKCS #1 v2? This exact issue was debated on the ietf-smime list when I asked why X9.42 (which looks like the winning candidate from a 'Worst way to apply the DLP to solving a key transport problem' competition... [remainder bobbitted to avoid another flamewar over this :-]) was being used instead of the far more logical Elgamal, which would be a direct, patent-free drop-in replacement for the existing RSA key transport. The only reason anyone could put up against Elgamal was "You need to use OAEP because PKCS #1 padding is insecure". In response to this (at the end of a longish debate) I posted the following back-of-the-envelope analysis: -- Snip -- The second approach is to see just what it would take to implement this attack on CMS (not S/MIME, but anything involving CMS). For this analysis I'll make several assumptions: 1. The implementor has managed to design a protocol which will accept arbitrary numbers of chosen-ciphertext messages and reply to each one with an exact indication of how the decrypt failed, leaking information about the decrypted message to an attacker. This is a fairly remarkable feat, but let's say, just for arguments sake, that someone did do this. 2. The implementor and any third-party reviewers have somehow missed the CERT advisory, RSA labs bulletin, publicity about the attack, and whatever else is around there which tells people about the problem and (very simple) fix. 3. The PKCS #1 implementation being used is correct (that is, it doesn't have the implementation bug which was found and fixed in the SSL implementations). 4. A typical query+response takes half a second (this means opening a connecting, generating a chosen-ciphertext message, transmitting it, having the victim decode and try to decrypt it, generating a response, wrapping up an exact indication of the decryption error it encountered, and sending it back to the attacker). OK, so we have a server which does all of the above sitting there ready for attack. With a correct PKCS #1 implementation (that is, it checks the padding as per the PKCS #1 spec), the complexity is approximately 1 million attempts (for the 00 02 padding) x 20 (for the second 00 before the MEK) x 2 (for the minimum of 8 nonzero bytes), or 40 million attempts (the 1 million attempts requires the presence of the SSL implementation bug mentioned above). This requires just under 8 months of CPU time to perform, after which you've recovered a single MEK [S/MIME jargon for "message encryption key"]. I would suggest that anyone who doesn't notice that their server is under continuous attack for 8 solid months has more than simple crypto problems to worry about. -- Snip -- Peter. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA20510 for ietf-open-pgp-bks; Thu, 8 Apr 1999 14:39:53 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20506 for ; Thu, 8 Apr 1999 14:39:52 -0700 (PDT) Received: from jcallas (dhcp-47-64.dhcp.nai.com [161.69.47.64]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id OAA20279; Thu, 8 Apr 1999 14:38:43 -0700 (PDT) Message-Id: <3.0.3.32.19990408143618.03cb97f0@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 08 Apr 1999 14:36:18 -0700 To: hal@rain.org, ietf-open-pgp@imc.org, jcallas@NAI.com From: Jon Callas Subject: Re: Sample Twofish message In-Reply-To: <199904080539.WAA02648@hal.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 10:39 PM 4/7/99 -0700, hal@rain.org wrote: |Yes, you're right, that is inconsistent with section 5.7. I don't |know how we should resolve it. | When we were working on the RFC, the question of larger blocks came up, and there were some suggestions of changing all the 8s to Ns, and 10s to N+2s etc. There was the concern that we would make a mistake. We had the advantage the first time that people (like Tom) coded to the original description, and thus we had a check that it actually worked. So I put in the paragraph in 12.8, as a quick way to describe how to do the right thing. Do we agree now that the right thing to do is to start with a 16-byte IV, encrypt 16 bytes, sync with 2 and then continue? That's what I thought we all agreed on. If we agree that, then we don't have a problem, we have an elided description that needs to be expanded when we revise the RFC. I believe, though, that that's the right thing to do, work with full blocksizes. Jon ----- Jon Callas jon@pgp.com CTO, Total Network Security 3965 Freedom Circle Network Associates, Inc. Santa Clara, CA 95054 (408) 346-5860 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA19501 for ietf-open-pgp-bks; Thu, 8 Apr 1999 12:52:08 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA19497 for ; Thu, 8 Apr 1999 12:52:07 -0700 (PDT) Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Thu Apr 8 15:51:45 EDT 1999 Received: from aura.research.bell-labs.com ([135.104.46.10]) by research; Thu Apr 8 15:51:43 EDT 1999 Received: (from bleichen@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id PAA11284 for ietf-open-pgp@imc.org; Thu, 8 Apr 1999 15:51:42 -0400 (EDT) Date: Thu, 8 Apr 1999 15:51:42 -0400 (EDT) From: Daniel Bleichenbacher Message-Id: <199904081951.PAA11284@aura.research.bell-labs.com> To: ietf-open-pgp@imc.org Subject: Decrypting ElGamal messages X-Sun-Charset: US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Can anyone tell me how an ElGamal encrypted message has to be decrypted? The open-pgp documentation doesn't give the answer. I'm specially interested in how padding and checksums are handled. I'm asking this question, because ElGamal encryption has the same multiplicative properties as RSA. In particular, given the encryption of a message M (including padding), it is easy to generate the encryption of M*S (mod p) for a given S, without knowing M. Hence the same attack that was possible against SSL potentially works against ElGamal, when used with PKCS #1 v1.5 padding. BTW, is there any reason why PKCS #1 v1.5 padding is used and not PKCS #1 v2? -- Daniel Bleichenbacher Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA09939 for ietf-open-pgp-bks; Thu, 8 Apr 1999 01:53:42 -0700 (PDT) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA09935 for ; Thu, 8 Apr 1999 01:53:40 -0700 (PDT) Received: (from news@localhost) by grannus.iks-jena.de (8.9.3/8.9.2) id KAA10278 for ietf-open-pgp@imc.org; Thu, 8 Apr 1999 10:54:20 +0200 To: ietf-open-pgp@imc.org Path: lutz From: lutz@taranis.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Sample Twofish message Date: 8 Apr 1999 08:54:19 GMT Organization: IKS GmbH Jena Lines: 6 Message-ID: References: <199904052044.NAA25365@hal.sb.rain.org> <199904052044.NAA25365@hal.sb.rain.org> <19990406194710.E16314@frodo.isil.d.shuttle.de> <3.0.3.32.19990407132425.03c74010@mail.pgp.com> <199904052044.NAA25365@hal.sb.rain.org> <19990408074957.B5540@frodo.isil.d.shuttle.de> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: slrn/0.9.5.4 (UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: * Werner Koch wrote: >We should agree on an interpretation of these questions: > * Use resyncing at all for ciphers with a blocksize > 64 ? Use it if the processed cipher text is larger as the block size. Do not concat ciphers of different message parts. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA07783 for ietf-open-pgp-bks; Wed, 7 Apr 1999 23:20:13 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA07779 for ; Wed, 7 Apr 1999 23:20:11 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id IAA03634 for ietf-open-pgp@imc.org; Thu, 8 Apr 1999 08:20:51 +0200 (MET DST) Received: (qmail 17556 invoked from network); 8 Apr 1999 05:52:51 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 8 Apr 1999 05:52:51 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10V7hN-0001WD-00; Thu, 8 Apr 1999 07:49:57 +0200 Date: Thu, 8 Apr 1999 07:49:57 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Sample Twofish message Message-ID: <19990408074957.B5540@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904052044.NAA25365@hal.sb.rain.org> <199904052044.NAA25365@hal.sb.rain.org> <19990406194710.E16314@frodo.isil.d.shuttle.de> <3.0.3.32.19990407132425.03c74010@mail.pgp.com> <199904052044.NAA25365@hal.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <199904052044.NAA25365@hal.sb.rain.org>; from hal@rain.org on Mon, Apr 05, 1999 at 01:44:40PM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Okay, how can we resolve this conflict: >From section 5.7: The data is encrypted in CFB mode, with a CFB shift size equal to the cipher's block size. The Initial Vector (IV) is specified as all zeros. Instead of using an IV, OpenPGP prefixes a 10-octet string to the data before it is encrypted. The first eight octets are random, and the 9th and 10th octets are copies of the 7th and 8th octets, respectively. After encrypting the first 10 octets, the CFB state is resynchronized if the cipher block size is 8 octets or less. The ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ last 8 octets of ciphertext are passed through the cipher and the block boundary is reset. >From section 12.8: OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and prefixes the plaintext with ten octets of random data, such that octets 9 and 10 match octets 7 and 8. It does a CFB "resync" after ^^^^^^^^^^^^^^^^^^^^^ encrypting those ten octets. Note that for an algorithm that has a larger block size than 64 bits, the equivalent function will be done with that entire block. For example, a 16-octet block algorithm would operate on 16 octets, and then produce two octets of check, and then work on 16-octet blocks. 5.7 says that resync is only done for a blocksize <= 64 but 12.8 says that is done always (the following step by step list also says this). Please, can we agree on one version - I don't care which one, but it is a bad idea to change this after the first message/secret-key has been enciphered with a >64 bit blocksize cipher. We should agree on an interpretation of these questions: * Use resyncing at all for ciphers with a blocksize > 64 ? * Use it for encryption of secret key material in V3 packets ? * Use the blocksize or 64 bits for the CFB shift ? * Prepend 8+2 or blocksize+2 random bytes to the plaintext? * Keep the 8 byte salt for S2K modes? -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA07433 for ietf-open-pgp-bks; Wed, 7 Apr 1999 22:39:15 -0700 (PDT) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA07429 for ; Wed, 7 Apr 1999 22:39:15 -0700 (PDT) Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.3/8.9.3) with ESMTP id WAA22907; Wed, 7 Apr 1999 22:39:53 -0700 (PDT) Received: (from hal@localhost) by hal.sb.rain.org (8.8.7/8.8.7) id WAA02648; Wed, 7 Apr 1999 22:39:55 -0700 Date: Wed, 7 Apr 1999 22:39:55 -0700 From: hal@rain.org Message-Id: <199904080539.WAA02648@hal.sb.rain.org> To: ietf-open-pgp@imc.org, jcallas@NAI.com Subject: Re: Sample Twofish message Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Jon Callas, , writes: > What about section 12.8 which says: > > Note that for an algorithm that has a larger block size than 64 bits, > the equivalent function will be done with that entire block. For > example, a 16-octet block algorithm would operate on 16 octets, and > then produce two octets of check, and then work on 16-octet blocks. Yes, you're right, that is inconsistent with section 5.7. I don't know how we should resolve it. Hal Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA02022 for ietf-open-pgp-bks; Wed, 7 Apr 1999 13:32:49 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA02018 for ; Wed, 7 Apr 1999 13:32:49 -0700 (PDT) Received: from jcallas ([38.232.7.55]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id NAA11447 for ; Wed, 7 Apr 1999 13:33:01 -0700 (PDT) Message-Id: <3.0.3.32.19990407132425.03c74010@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 07 Apr 1999 13:24:25 -0700 To: ietf-open-pgp@imc.org From: Jon Callas Subject: Re: Sample Twofish message In-Reply-To: <19990406194710.E16314@frodo.isil.d.shuttle.de> References: <199904052044.NAA25365@hal.sb.rain.org> <199904052044.NAA25365@hal.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: What about section 12.8 which says: Note that for an algorithm that has a larger block size than 64 bits, the equivalent function will be done with that entire block. For example, a 16-octet block algorithm would operate on 16 octets, and then produce two octets of check, and then work on 16-octet blocks. ----- Jon Callas jon@pgp.com CTO, Total Network Security 3965 Freedom Circle Network Associates, Inc. Santa Clara, CA 95054 (408) 346-5860 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA08334 for ietf-open-pgp-bks; Tue, 6 Apr 1999 21:02:58 -0700 (PDT) Received: from ixpres.com (AM3-10-53-206.ixpres.com [209.75.53.206]) by mail.proper.com (8.8.8/8.8.5) with SMTP id UAA07726; Tue, 6 Apr 1999 20:53:14 -0700 (PDT) Date: Tue, 6 Apr 1999 20:53:14 -0700 (PDT) From: bizusa@ixpres.com Message-Id: <199904070353.UAA07726@mail.proper.com> Reply-To: bizusa@ixpres.com To: bizusa@ixpres.com Subject: Organize Web Info... Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% This message is sent in compliance of the new Email bill: SECTION 301. Sender: INFOtrepreneur, 11012 Avenida De Los Lobos, San Diego, California, CA 92127 - Fax: (619) 672-1000 Email: webmaster@infotrepreneur.com Per Section 301, Paragraph (a)(2)(C) of S.1618, further transmissions to you by the sender of this email may be stopped at no cost to you by ending a reply to this email address with the word "remove" in the subject line. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% NO MORE! BACKTRACKING OF LOST AND CONFUSING WEB BOOKMARKS AND TEXT DATA FILES... Based upon your Internet interests, I thought that you would be interesed in Web Info Catcher which allows you to capture and store text data from various sources, index, categorize and edit it instantly on screen while online. Access all your reference and source material instantly at a click of a button, while you are working, browsing, searching or offline. It's the fastest, up-to-date, and most efficient means to "RECALL" your data. * No need... to bookmark a multitude of web sites * No need... to search for misplaced or lost text files * No need... to print out endless reports * No need... for a web browser to reference data - Perfect for academics, researchers, business, info junkies, etc. - Create your own projects, reports, topics, favorites, research, etc. - Open numerous projects and setup your own index references - Attach and Capture text information from various sources - Edit your projects - Effectively organize your information - Categorize your information - Add custom indexes - Automatic alpha indexing - Searchable index - Scrollable index - View information on screen while working - A Stand alone program - Add and delete information - Print out data in your own time WHY BOOKMARK OR SAVE YOUR TEXT FILES? DON'T DELAY!  Visit INFOtrepreneur today and discover a whole new way to capture and store your information sources, we will be happy to assist you. DOWNLOAD your software demo: ftp://ftp.infotrepreneur.com/pub/wicdemo.exe OR for more info: http://www.infotrepreneur.com/webcth.htm Sincerely Gail van der Merwe Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA20420 for ietf-open-pgp-bks; Tue, 6 Apr 1999 11:01:45 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA20416 for ; Tue, 6 Apr 1999 11:01:44 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id UAA01308 for ietf-open-pgp@imc.org; Tue, 6 Apr 1999 20:02:21 +0200 (MET DST) Received: (qmail 13318 invoked from network); 6 Apr 1999 17:50:20 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 6 Apr 1999 17:50:20 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10UZwM-0004Qb-00; Tue, 6 Apr 1999 19:47:10 +0200 Date: Tue, 6 Apr 1999 19:47:10 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Sample Twofish message Message-ID: <19990406194710.E16314@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199904052044.NAA25365@hal.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <199904052044.NAA25365@hal.sb.rain.org>; from hal@rain.org on Mon, Apr 05, 1999 at 01:44:40PM -0700 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: hal@rain.org writes: > The relevant paragraph from section 5.7 is: [...] > resynchronized if the cipher block size is 8 octets or less. The ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Ooops, I really missed that. I only remembered from the discussion, that we keep the special CFB mode. Many thanks - I hope I can decipher your mail in a few days. Werner -- Werner Koch at guug.de www.gnupg.org keyid 621CC013 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA08028 for ietf-open-pgp-bks; Mon, 5 Apr 1999 13:53:35 -0700 (PDT) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA08024 for ; Mon, 5 Apr 1999 13:53:34 -0700 (PDT) Received: from hal.sb.rain.org (hal.sb.rain.org [198.68.144.57]) by coyote.rain.org (8.9.3/8.9.3) with ESMTP id NAA04441; Mon, 5 Apr 1999 13:53:55 -0700 (PDT) Received: (from hal@localhost) by hal.sb.rain.org (8.8.7/8.8.7) id NAA25365; Mon, 5 Apr 1999 13:44:40 -0700 Date: Mon, 5 Apr 1999 13:44:40 -0700 From: hal@rain.org Message-Id: <199904052044.NAA25365@hal.sb.rain.org> To: ietf-open-pgp@imc.org, wk@isil.d.shuttle.de Subject: Re: Sample Twofish message Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Werner Koch, , writes: > > hal@rain.org writes: > > > Note also that the special CFB "sync" operation (after processing these 10 > > bytes) is not to be done with block ciphers whose block size is greater > > than 8 bytes, hence is not done for Twofish. > > Hmmm, section 5.7 states that encryption is done in PGP's special CFB > mode and there is no exception mentioned. > > If I remember correct, we discussed this 128 bit block cipher issue > last year and changed the draft accordingly. The relevant paragraph from section 5.7 is: The data is encrypted in CFB mode, with a CFB shift size equal to the cipher's block size. The Initial Vector (IV) is specified as all zeros. Instead of using an IV, OpenPGP prefixes a 10-octet string to the data before it is encrypted. The first eight octets are random, and the 9th and 10th octets are copies of the 7th and 8th octets, respectively. After encrypting the first 10 octets, the CFB state is resynchronized if the cipher block size is 8 octets or less. The last 8 octets of ciphertext are passed through the cipher and the block boundary is reset. It only resynchronizes the CFB state if the cipher block size is 8 octets or less. Twofish has a block size of 16 octets, hence the CFB state does not get resynchronized. Hal Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA07693 for ietf-open-pgp-bks; Mon, 5 Apr 1999 13:09:27 -0700 (PDT) Received: from koeln.shuttle.de (uucp@koeln.shuttle.de [194.95.247.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA07689 for ; Mon, 5 Apr 1999 13:09:25 -0700 (PDT) Received: (from uucp@localhost) by koeln.shuttle.de (8.9.3/8.9.3) with UUCP id WAA10097 for ietf-open-pgp@imc.org; Mon, 5 Apr 1999 22:09:49 +0200 (MET DST) Received: (qmail 11734 invoked from network); 5 Apr 1999 20:00:19 -0000 Received: from frodo.isil.d.shuttle.de (mail@172.20.1.4) by beren.isil.d.shuttle.de with SMTP; 5 Apr 1999 20:00:19 -0000 Received: from wk by frodo.isil.d.shuttle.de with local (Exim 1.92 #1 (Debian)) id 10UFUQ-0003yo-00; Mon, 5 Apr 1999 21:56:58 +0200 Date: Mon, 5 Apr 1999 21:56:58 +0200 From: Werner Koch To: ietf-open-pgp@imc.org Subject: Re: Sample Twofish message Message-ID: <19990405215658.I14996@frodo.isil.d.shuttle.de> Mail-Followup-To: ietf-open-pgp@imc.org References: <199903292241.OAA04352@hal.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.96i In-Reply-To: <199903292241.OAA04352@hal.sb.rain.org>; from hal@rain.org on Mon, Mar 29, 1999 at 02:41:39PM -0800 X-URL: http://www.d.shuttle.de/isil Sender: owner-ietf-open-pgp@imc.org Precedence: bulk List-Archive: List-Unsubscribe: hal@rain.org writes: > Note also that the special CFB "sync" operation (after processing these 10 > bytes) is not to be done with block ciphers whose block size is greater > than 8 bytes, hence is not done for Twofish. Hmmm, section 5.7 states that encryption is done in PGP's special CFB mode and there is no exception mentioned. If I remember correct, we discussed this 128 bit block cipher issue last year and changed the draft accordingly. -- Werner Koch at guug.de www.gnupg.org keyid 621CC013