From owner-ietf-openpgp@mail.imc.org Tue Apr 1 10:15:35 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18617 for ; Tue, 1 Apr 2003 10:15:34 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31EkYJM028068 for ; Tue, 1 Apr 2003 06:46:34 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31EkY3N028067 for ietf-openpgp-bks; Tue, 1 Apr 2003 06:46:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.33]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31EkXJM028053 for ; Tue, 1 Apr 2003 06:46:33 -0800 (PST) Received: from mailserver2.hushmail.com (mailserver2.hushmail.com [65.39.178.21]) by smtp3.hushmail.com (Postfix) with ESMTP id 747D273C7 for ; Tue, 1 Apr 2003 06:46:28 -0800 (PST) Received: from mailserver2.hushmail.com (localhost.hushmail.com [127.0.0.1]) by mailserver2.hushmail.com (8.12.6/8.12.3) with ESMTP id h31EkSKs083870 for ; Tue, 1 Apr 2003 06:46:28 -0800 (PST) (envelope-from vedaal@hush.com) Received: (from nobody@localhost) by mailserver2.hushmail.com (8.12.6/8.12.3/Submit) id h31EkSeU083869 for ietf-openpgp@imc.org; Tue, 1 Apr 2003 06:46:28 -0800 (PST) Message-Id: <200304011446.h31EkSeU083869@mailserver2.hushmail.com> Date: Tue, 1 Apr 2003 06:46:28 -0800 To: ietf-openpgp@imc.org Subject: gnupg/pgp symmetric encryption incompatibility report From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: the following demonstration of an incompatiblity in symmetric encryption was reported in alt.security.pgp: ----- Original Message ----- From: "Falissard" Newsgroups: alt.security.pgp,comp.security.pgp.tech Sent: Monday, March 31, 2003 4:24 PM Subject: GnuPG (good) and PGP (bad) encryption > For specialists only... > Here is one case where PGP is not as clever as GnuPG... > The following conventionally encrypted data > decrypts well with GnuPG, ** not ** with PGP ("bad packet"). > The passphrase is "test". > Nothing special here regarding algorithms (Cast5 + MD5). > The thing that I suspect is that PGP does not always > accept packets with indeterminate length, while > it's OK for GnuPG. > (I deliberately encrypted a compressed > packet with indeterminate length.) > -----BEGIN PGP MESSAGE----- Version: GnuPG v1.0.6 (MingW32) Comment: For info see http://www.gnupg.org wwQEAwAByf8AAAAyEXrKTVH2DEz0lKVsP6ZpFJySpLkH+ha6WY3EXlj7Phjgdm0c cRg0WUWFpllUCMJqzPk= =hHJq -----END PGP MESSAGE----- is the 'indeterminate packet length' issue a contrived exception, that would not be expected to occur with ordinary use, or is it something that needs to be addressed? tia, vedaal Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Big $$$ to be made with the HushMail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 From owner-ietf-openpgp@mail.imc.org Mon Apr 7 02:53:08 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03895 for ; Mon, 7 Apr 2003 02:53:07 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h376VHJM016087 for ; Sun, 6 Apr 2003 23:31:17 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h376VHh9016085 for ietf-openpgp-bks; Sun, 6 Apr 2003 23:31:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.fabiand.net (postfix@cm107-58.liwest.at [212.241.107.58]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h376VFJM016072 for ; Sun, 6 Apr 2003 23:31:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.fabiand.net (Postfix) with ESMTP id 1B5FB1496CC for ; Mon, 7 Apr 2003 08:28:11 +0200 (CEST) Received: from mail.fabiand.net ([127.0.0.1]) by localhost (server [127.0.0.1:10024]) (amavisd-new) with ESMTP id 06348-10 for ; Mon, 7 Apr 2003 08:26:28 +0200 (CEST) Received: from dflt (cm107-56.liwest.at [212.241.107.56]) by mail.fabiand.net (Postfix) with SMTP id 3C4771496BD for ; Mon, 7 Apr 2003 08:25:52 +0200 (CEST) From: "Daniel Fabian" To: Subject: Please Help with OpenPGP's CFB Mode Date: Mon, 7 Apr 2003 08:28:44 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Virus-Scanned: by amavisd-new Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi, I'm having some troubles implementing OpenPGP's CFB Mode. It seems I got the resync step wrong. Could someone perhaps be so kind and check this? I'm trying to decrypt the following message: -----BEGIN PGP MESSAGE----- Version: PGP 8.0 qANQR1DDDQQJAwLltQFZpPdHImDJSb9TnpRJDlDh0oydzuQLj3OjHbGpTONhx9sH xA4cFrk8bKHxtnyfDqN0IMK604l+qbZJXnrK8qAtMobe5z4unnS6kOwSWrtbDHo= =mq0f -----END PGP MESSAGE----- This is the line "The MD5 hash algorithm has been found to have " from the RFC, symmetrically encrypted with the passphrase "test". This should be the ciphertext 191;83;158;148;73;14;80;225;210;140;157;206;228;11;143;115;163;29;177;169;76 ;227;97;199;219;7;196;14;28;22;185;60;108;161;241;182;124;159;14;163;116;32; 194;186;211;137;126;169;182;73;94;122;202;242;160;45;50;134;222;231;62;46;15 8;116;186;144;236;18;90;187;91;12;122 encrypted with the symmetrical key 165;250;150;68;115;173;70;173;212;104;208;113;241;231;223;29;28;118;235;208; 188;166;157;28;51;170;81;64;96;73;144;105 and the AES256 cipher. Here's what I do: - I load FR 0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0 with all 0's - I encrypt to get FRE: 67;169;145;216;194;226;251;238;246;15;184;187;87;67;190;101; - This gives me the Plaintext: 252;250;15;76;139;236;171;15;36;131;37;117;179;72;49;22; - Load C0-C15 into the FR: 191;83;158;148;73;14;80;225;210;140;157;206;228;11;143;115; - FRE: 146;11;98;243;113;121;142;86;23;188;60;49;76;14;194;225; - Plaintext: 49;22 So this part should have worked fine, because as stated in the rfc, the bytes c14 and c15 are the same as c16 and c17. However here comes the trouble: - I load the FR with c2 - c17: 158;148;73;14;80;225;210;140;157;206;228;11;143;115;163;29; - Encrypt it: FRE: 121;156;77;216;12;149;25;199;12;206;220;6;43;173;198;65; - And get the WRONG plaintext block 200;53;1;59;109;82;194;192;200;192;192;16;146;145;170;224; This is definitly not the UTF-8 representation of "The MD5 hash alg". Could someone please tell me what I'm doing wrong? Thanks in advance, Daniel From owner-ietf-openpgp@mail.imc.org Mon Apr 7 13:34:55 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28639 for ; Mon, 7 Apr 2003 13:34:54 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37HBKJM016441 for ; Mon, 7 Apr 2003 10:11:20 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37HBK7E016440 for ietf-openpgp-bks; Mon, 7 Apr 2003 10:11:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37HBJJM016435 for ; Mon, 7 Apr 2003 10:11:19 -0700 (PDT) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id h37HA7r24019; Mon, 7 Apr 2003 10:10:07 -0700 Date: Mon, 7 Apr 2003 10:10:07 -0700 From: "Hal Finney" Message-Id: <200304071710.h37HA7r24019@finney.org> To: df@fabiand.net, ietf-openpgp@imc.org Subject: Re: Please Help with OpenPGP's CFB Mode Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel Fabian writes: > ... > - I load the FR with c2 - c17: > 158;148;73;14;80;225;210;140;157;206;228;11;143;115;163;29; > - Encrypt it: FRE: 121;156;77;216;12;149;25;199;12;206;220;6;43;173;198;65; > - And get the WRONG plaintext block > 200;53;1;59;109;82;194;192;200;192;192;16;146;145;170;224; > > This is definitly not the UTF-8 representation of "The MD5 hash alg". > Could someone please tell me what I'm doing wrong? You have done the decryption properly. Your plaintext when expressed in hex form is: c8 35 01 3b 6d 52 c2 c0 c8 c0 c0 10 92 91 aa e0 You have to interpret this as PGP data per RFC2440. C8 is the tag byte for a Compressed Data Packet (see section 5.6). 35 is its length. 01 is the type of compression, namely ZIP (see section 9.3). The remaining data is to be input to the decompression algorithm. The output of that will be a PGP Literal Data Packet, and the contents of that packet will include your text. Hal Finney From subs-reminder@imc.org Mon Apr 7 15:03:51 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01022 for ; Mon, 7 Apr 2003 15:03:51 -0400 (EDT) From: subs-reminder@imc.org Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37J6KJM011123 for ; Mon, 7 Apr 2003 12:06:20 -0700 (PDT) Received: (from root@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37J6KKl011122; Mon, 7 Apr 2003 12:06:20 -0700 (PDT) Date: Mon, 7 Apr 2003 12:06:20 -0700 (PDT) Message-Id: <200304071906.h37J6KKl011122@above.proper.com> To: openpgp-archive@ietf.org Subject: [[407566062]] Subscription to ietf-openpgp for openpgp-archive@lists.ietf.org Greetings. This message is a periodic reminder that openpgp-archive@lists.ietf.org is subscribed to the ietf-openpgp mailing list. *** SEE BELOW: PLEASE DO NOT RESPOND TO THIS MESSAGE. *** There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-openpgp mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-openpgp-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "openpgp-archive@lists.ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-openpgp@mail.imc.org Tue Apr 8 22:30:29 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12648 for ; Tue, 8 Apr 2003 22:30:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h392DEJM001590 for ; Tue, 8 Apr 2003 19:13:14 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h392DEK6001589 for ietf-openpgp-bks; Tue, 8 Apr 2003 19:13:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.33]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h392DCJM001585 for ; Tue, 8 Apr 2003 19:13:12 -0700 (PDT) Received: from mailserver1.hushmail.com (mailserver1.hushmail.com [65.39.178.20]) by smtp3.hushmail.com (Postfix) with ESMTP id EFC197409 for ; Tue, 8 Apr 2003 19:12:25 -0700 (PDT) Received: from mailserver1.hushmail.com (localhost.hushmail.com [127.0.0.1]) by mailserver1.hushmail.com (8.12.6/8.12.3) with ESMTP id h392CQbW031486 for ; Tue, 8 Apr 2003 19:12:26 -0700 (PDT) (envelope-from sbs@hush.ai) Received: (from nobody@localhost) by mailserver1.hushmail.com (8.12.6/8.12.3/Submit) id h392CQ3M031484 for OpenPGP ; Tue, 8 Apr 2003 19:12:26 -0700 (PDT) Message-Id: <200304090212.h392CQ3M031484@mailserver1.hushmail.com> Date: Tue, 8 Apr 2003 19:12:25 -0700 To: OpenPGP Subject: partial packet lengths in PGP 8 From: "Brian Smith" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It seems to me that PGP 8 does not support partial packet lengths for a a symmetrically encrypted data packet. Is this a known bug, and if so is there a work-around? There are some situations where it would be very useful for me to be able to generate messages from a stream where I don't know the length ahead of time and have them still decrypt under PGP 8. Specifically, the following packet seems to break it: c9e39697376314f4fbede026e0bae28397cc98e16881e0ece0f2e2095e6bfee12680e056e000e0cc00 Or broken down into lengths: c9 (tag indicating symmetrically encrypted data packet) e3 (partial length of 8) 9697376314f4fbed e0 (partial length of 1) 26 e0 (partial length of 1) ba e2 (partial length of 4) 8397cc98 e1 (partial length of 2) 6881 e0 (partial length of 1) ec e0 (partial length of 1) f2 e2 (partial length of 4) 095e6bfe e1 (partial length of 2) 2680 e0 (partial length of 1) 56 e0 (partial length of 1) 00 e0 (partial length of 1) cc 00 (final zero length tag) Here's the actual message that was generated from. It's just the message "xx" encrypted with the password "test". Decrypts fine with gpg. -----BEGIN PGP MESSAGE----- jA0EAwMCPAgVwxrjQWlgyeOWlzdjFPT77eAm4Lrig5fMmOFogeDs4PLiCV5r/uEmgOBW 4ADgzAA= =N9CU -----END PGP MESSAGE----- Thanks, Brian Smith From owner-ietf-openpgp@mail.imc.org Tue Apr 8 23:33:31 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13955 for ; Tue, 8 Apr 2003 23:33:30 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h393KfJM004705 for ; Tue, 8 Apr 2003 20:20:41 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h393Kfhx004704 for ietf-openpgp-bks; Tue, 8 Apr 2003 20:20:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h393KdJM004699 for ; Tue, 8 Apr 2003 20:20:40 -0700 (PDT) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id h393JZv00366; Tue, 8 Apr 2003 20:19:35 -0700 Date: Tue, 8 Apr 2003 20:19:35 -0700 From: "Hal Finney" Message-Id: <200304090319.h393JZv00366@finney.org> To: ietf-openpgp@imc.org, sbs@hush.ai Subject: Re: partial packet lengths in PGP 8 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Brian Smith" writes: > It seems to me that PGP 8 does not support partial packet lengths for > a a symmetrically encrypted data packet. Is this a known bug, and if > so is there a work-around? I worked on predecessors to PGP 8, and based on your test data I can confirm that there is a bug in the packet parsing code relating to partial body lengths. It's not specific to symmetrically encrypted data packets, but rather to the "initial" portion of the packets. Many of the PGP data packets have an initial part which is of more or less fixed length, followed by the rest of the body which can be of arbitrary length. The parser first assembles the initial portion and extracts the data from that, then falls into some relatively generic code which handles the rest of the data. There is a bug in the parser which won't work properly if the initial portion spans two or more partial-body-length packets. In the case of symmetrically encrypted data packets, the initial portion is the first 10 bytes (for 8-byte ciphers; 18 bytes for 16-byte block ciphers). In your case you had a PBL of 8 followed by two PBL's of 1 each to fill out the first 10 bytes, but the code messes up and doesn't assemble the packets correctly. It doesn't do what you might think and include the e0's in the packet, but it fails to update the buffer pointer and so replicates the contents of the previous PBL, the 96 and 97 bytes, as the 9th and 10th. So the work-around in this case is to make sure the first partial body length is at least 16 bytes, for 8 byte block ciphers, and 32 bytes, for 16 byte block ciphers. That will mean buffering up the first 16 or 32 bytes of your stream before emitting your first block. Hal Finney From owner-ietf-openpgp@mail.imc.org Wed Apr 9 11:15:16 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02308 for ; Wed, 9 Apr 2003 11:15:16 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39Es2JM004618 for ; Wed, 9 Apr 2003 07:54:02 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39Es2tD004617 for ietf-openpgp-bks; Wed, 9 Apr 2003 07:54:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39Es0JM004608 for ; Wed, 9 Apr 2003 07:54:00 -0700 (PDT) Received: from mwyoung (dhcp-197-42.transarc.ibm.com [9.38.197.42]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id KAA13384 for ; Wed, 9 Apr 2003 10:54:00 -0400 (EDT) Message-ID: <000e01c2fea7$db061e40$2ac52609@transarc.ibm.com> From: "Michael Young" To: References: <200304090319.h393JZv00366@finney.org> Subject: Re: partial packet lengths in PGP 8 Date: Wed, 9 Apr 2003 10:53:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "Hal Finney" answers "Brian Smith" with: > So the work-around in this case is to make sure the first partial body > length is at least 16 bytes, for 8 byte block ciphers, and 32 bytes, The specification includes a stronger requirement, in section 4.2.3: "The first partial length MUST be at least 512 octets long." Separately, I might suggest avoid using a zero-length packet at the end, if you can. It's not illegal, but it's the kind of thing that might tickle a bug in another implementation. I'd be conservative. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPpQz9ec3iHYL8FknEQLonwCfZZw7j5XoTpjpbT1nk3HdHQWybpoAoPY+ p1BGzXA9pX7Tp3yD/JgUZ86D =jnM+ -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Apr 9 18:23:24 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18213 for ; Wed, 9 Apr 2003 18:23:23 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39M3rJM024606 for ; Wed, 9 Apr 2003 15:03:53 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39M3qKq024605 for ietf-openpgp-bks; Wed, 9 Apr 2003 15:03:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39M3pJM024601 for ; Wed, 9 Apr 2003 15:03:51 -0700 (PDT) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id h39M2mM05835 for ietf-openpgp@imc.org; Wed, 9 Apr 2003 15:02:48 -0700 Date: Wed, 9 Apr 2003 15:02:48 -0700 From: "Hal Finney" Message-Id: <200304092202.h39M2mM05835@finney.org> To: ietf-openpgp@imc.org Subject: Re: partial packet lengths in PGP 8 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Michael Young writes: > The specification includes a stronger requirement, in section 4.2.3: > "The first partial length MUST be at least 512 octets long." I hadn't noticed that. I think that requirement is not in a very good place, buried in section 4.2.3 which is titled "Packet Length Examples". That's not where an implementor would expect to find MUST rules regarding partial body lengths. I suggest that the following text: An implementation MAY use Partial Body Lengths for data packets, be they literal, compressed, or encrypted. The first partial length MUST be at least 512 octets long. Partial Body Lengths MUST NOT be used for any other packet types. Note also that the last Body Length header can be a zero-length header. be moved from 4.2.3 to section 4.2.2.4, Partial Body Lengths. Also I moved the "Note also" sentence to after the paragraph as you see. I am using section numbers from RFC2440, I don't have the new version in front of me at the moment, so they might have different numbers there. Hal From owner-ietf-openpgp@mail.imc.org Wed Apr 9 19:01:07 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19607 for ; Wed, 9 Apr 2003 19:01:07 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39MjlJM027437 for ; Wed, 9 Apr 2003 15:45:47 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39MjlNB027436 for ietf-openpgp-bks; Wed, 9 Apr 2003 15:45:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39MjjJM027432 for ; Wed, 9 Apr 2003 15:45:46 -0700 (PDT) Received: from [63.251.255.205] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2); Wed, 9 Apr 2003 15:45:47 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 09 Apr 2003 15:45:44 -0700 Subject: Re: partial packet lengths in PGP 8 From: Jon Callas To: Hal Finney , OpenPGP Message-ID: In-Reply-To: <200304092202.h39M2mM05835@finney.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4/9/03 3:02 PM, "Hal Finney" wrote: > I suggest that the following text: > > An implementation MAY use Partial Body Lengths for data packets, be > they literal, compressed, or encrypted. The first partial length MUST > be at least 512 octets long. Partial Body Lengths MUST NOT be used > for any other packet types. > > Note also that the last Body Length header can be a zero-length header. > > be moved from 4.2.3 to section 4.2.2.4, Partial Body Lengths. Also I > moved the "Note also" sentence to after the paragraph as you see. I moved them. Jon From owner-ietf-openpgp@mail.imc.org Thu Apr 10 19:24:00 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11614 for ; Thu, 10 Apr 2003 19:23:59 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AN6QJM015110 for ; Thu, 10 Apr 2003 16:06:26 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AN6QnG015109 for ietf-openpgp-bks; Thu, 10 Apr 2003 16:06:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.33]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AN6OJM015098 for ; Thu, 10 Apr 2003 16:06:24 -0700 (PDT) Received: from mailserver1.hushmail.com (mailserver1.hushmail.com [65.39.178.20]) by smtp3.hushmail.com (Postfix) with ESMTP id 2CC8F5E29 for ; Thu, 10 Apr 2003 16:05:45 -0700 (PDT) Received: from mailserver1.hushmail.com (localhost.hushmail.com [127.0.0.1]) by mailserver1.hushmail.com (8.12.6/8.12.3) with ESMTP id h3AN5jbW058086 for ; Thu, 10 Apr 2003 16:05:45 -0700 (PDT) (envelope-from sbs@hush.ai) Received: (from nobody@localhost) by mailserver1.hushmail.com (8.12.6/8.12.3/Submit) id h3AN5job058078 for ietf-openpgp@imc.org; Thu, 10 Apr 2003 16:05:45 -0700 (PDT) Message-Id: <200304102305.h3AN5job058078@mailserver1.hushmail.com> Date: Thu, 10 Apr 2003 16:05:45 -0700 To: ietf-openpgp@imc.org Subject: Re: partial packet lengths in PGP 8 From: "Brian Smith" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: What's the reason for requiring that the first partial length be so long? 512 octets is considerably more than the headers, IV, etc of any data packet would be. Brian On Wed, 09 Apr 2003 15:45:44 -0700 Jon Callas wrote: > >On 4/9/03 3:02 PM, "Hal Finney" wrote: > >> I suggest that the following text: >> >> An implementation MAY use Partial Body Lengths for data packets, > be >> they literal, compressed, or encrypted. The first partial length >MUST >> be at least 512 octets long. Partial Body Lengths MUST NOT be >used >> for any other packet types. >> >> Note also that the last Body Length header can be a zero-length >header. >> >> be moved from 4.2.3 to section 4.2.2.4, Partial Body Lengths. > Also I >> moved the "Note also" sentence to after the paragraph as you see. > >I moved them. > > Jon > > > From owner-ietf-openpgp@mail.imc.org Thu Apr 10 19:39:44 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12214 for ; Thu, 10 Apr 2003 19:39:43 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ANSEJM016634 for ; Thu, 10 Apr 2003 16:28:14 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3ANSE0s016633 for ietf-openpgp-bks; Thu, 10 Apr 2003 16:28:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ANSCJM016629 for ; Thu, 10 Apr 2003 16:28:13 -0700 (PDT) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id h3ANRAg11229; Thu, 10 Apr 2003 16:27:10 -0700 Date: Thu, 10 Apr 2003 16:27:10 -0700 From: "Hal Finney" Message-Id: <200304102327.h3ANRAg11229@finney.org> To: ietf-openpgp@imc.org, sbs@hush.ai Subject: Re: partial packet lengths in PGP 8 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Brian Smith writes: > What's the reason for requiring that the first partial length be so long? > 512 octets is considerably more than the headers, IV, etc of any data > packet would be. A literal data packet could have up to a 256 byte long filename plus a few more bytes for the other data, so you need it to be bigger than that. And 512 is the next size up. Hal From owner-ietf-openpgp@mail.imc.org Thu Apr 10 21:27:27 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14577 for ; Thu, 10 Apr 2003 21:27:26 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B1CVJM022203 for ; Thu, 10 Apr 2003 18:12:31 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3B1CV5H022202 for ietf-openpgp-bks; Thu, 10 Apr 2003 18:12:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B1CSJM022191 for ; Thu, 10 Apr 2003 18:12:29 -0700 (PDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3B1CS3r022938; Thu, 10 Apr 2003 21:12:28 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3B1CR06029399; Thu, 10 Apr 2003 21:12:27 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h3B1CQFJ010387; Thu, 10 Apr 2003 21:12:26 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id VAA23310; Thu, 10 Apr 2003 21:12:26 -0400 (EDT) To: "Brian Smith" Cc: ietf-openpgp@imc.org From: Derek Atkins Subject: Re: partial packet lengths in PGP 8 References: <200304102305.h3AN5job058078@mailserver1.hushmail.com> Date: 10 Apr 2003 21:12:26 -0400 In-Reply-To: <200304102305.h3AN5job058078@mailserver1.hushmail.com> Message-ID: Lines: 45 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A better question to be asking yourself is why do you feel you need to break the packet up any SMALLER than 512 bytes? -derek "Brian Smith" writes: > What's the reason for requiring that the first partial length be so long? > 512 octets is considerably more than the headers, IV, etc of any data > packet would be. > > Brian > > On Wed, 09 Apr 2003 15:45:44 -0700 Jon Callas wrote: > > > >On 4/9/03 3:02 PM, "Hal Finney" wrote: > > > >> I suggest that the following text: > >> > >> An implementation MAY use Partial Body Lengths for data packets, > > be > >> they literal, compressed, or encrypted. The first partial length > >MUST > >> be at least 512 octets long. Partial Body Lengths MUST NOT be > >used > >> for any other packet types. > >> > >> Note also that the last Body Length header can be a zero-length > >header. > >> > >> be moved from 4.2.3 to section 4.2.2.4, Partial Body Lengths. > > Also I > >> moved the "Note also" sentence to after the paragraph as you see. > > > >I moved them. > > > > Jon > > > > > > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ietf-openpgp@mail.imc.org Fri Apr 11 04:42:48 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04028 for ; Fri, 11 Apr 2003 04:42:48 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B8QaJM024881 for ; Fri, 11 Apr 2003 01:26:36 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3B8Qa7l024880 for ietf-openpgp-bks; Fri, 11 Apr 2003 01:26:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B8QYJM024875 for ; Fri, 11 Apr 2003 01:26:34 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 3.35 #1 (Debian)) id 193trf-0005GN-00 for ; Fri, 11 Apr 2003 10:26:27 +0200 Received: from wk by alberti.g10code.de with local (Exim 3.36 #1 (Debian)) id 193tuK-0004BP-00; Fri, 11 Apr 2003 10:29:12 +0200 To: "Hal Finney" Cc: ietf-openpgp@imc.org, sbs@hush.ai Subject: Re: partial packet lengths in PGP 8 References: <200304102327.h3ANRAg11229@finney.org> From: Werner Koch Organisation: g10 Code GmbH X-Request-PGP: finger:wk@g10code.com X-PGP-KeyID: 621CC013 X-FSFE-Info: http://fsfeurope.org Date: Fri, 11 Apr 2003 10:29:07 +0200 In-Reply-To: <200304102327.h3ANRAg11229@finney.org> ("Hal Finney"'s message of "Thu, 10 Apr 2003 16:27:10 -0700") Message-ID: <87u1d530a4.fsf@alberti.g10code.de> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 10 Apr 2003 16:27:10 -0700, Hal Finney said: > A literal data packet could have up to a 256 byte long filename plus a > few more bytes for the other data, so you need it to be bigger than that. > And 512 is the next size up. and signature packets can be of any size ... -- Nonviolence is the greatest force at the disposal of mankind. It is mightier than the mightiest weapon of destruction devised by the ingenuity of man. -Gandhi From owner-ietf-openpgp@mail.imc.org Fri Apr 11 12:05:39 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19365 for ; Fri, 11 Apr 2003 12:05:38 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BFdhJM002294 for ; Fri, 11 Apr 2003 08:39:43 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BFdhsv002293 for ietf-openpgp-bks; Fri, 11 Apr 2003 08:39:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BFdfJM002286 for ; Fri, 11 Apr 2003 08:39:41 -0700 (PDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3BFdLnF006621; Fri, 11 Apr 2003 11:39:21 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3BFdK80006101; Fri, 11 Apr 2003 11:39:20 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h3BFdJFJ025673; Fri, 11 Apr 2003 11:39:19 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id LAA25044; Fri, 11 Apr 2003 11:39:19 -0400 (EDT) To: Werner Koch Cc: "Hal Finney" , ietf-openpgp@imc.org, sbs@hush.ai Subject: Re: partial packet lengths in PGP 8 References: <200304102327.h3ANRAg11229@finney.org> <87u1d530a4.fsf@alberti.g10code.de> From: Derek Atkins Date: 11 Apr 2003 11:39:19 -0400 In-Reply-To: <87u1d530a4.fsf@alberti.g10code.de> Message-ID: Lines: 21 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner Koch writes: > On Thu, 10 Apr 2003 16:27:10 -0700, Hal Finney said: > > > A literal data packet could have up to a 256 byte long filename plus a > > few more bytes for the other data, so you need it to be bigger than that. > > And 512 is the next size up. > > and signature packets can be of any size ... IIRC signature packets MUST use a determinate length and are limited to about 8192 bytes (unless this was changed somewhere along the line). -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-openpgp@mail.imc.org Fri Apr 11 14:04:53 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23071 for ; Fri, 11 Apr 2003 14:04:52 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BHl2JM006616 for ; Fri, 11 Apr 2003 10:47:02 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BHl2mq006615 for ietf-openpgp-bks; Fri, 11 Apr 2003 10:47:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BHl0JM006608 for ; Fri, 11 Apr 2003 10:47:00 -0700 (PDT) Received: from mwyoung (dhcp-197-42.transarc.ibm.com [9.38.197.42]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id NAA16582 for ; Fri, 11 Apr 2003 13:46:49 -0400 (EDT) Message-ID: <003001c30052$4e3329c0$2ac52609@transarc.ibm.com> From: "Michael Young" To: References: <200304102327.h3ANRAg11229@finney.org><87u1d530a4.fsf@alberti.g10code.de> Subject: Re: partial packet lengths in PGP 8 Date: Fri, 11 Apr 2003 13:46:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 From: "Derek Atkins" > IIRC signature packets MUST use a determinate length and are limited > to about 8192 bytes (unless this was changed somewhere along the > line). The current draft does require that they be determinate, but I don't see a numeric limit. There are hard limits to the hashed and unhashed subpackets (2^16-1 each) and (arguably) practical limits to the size of the MPIs that form the signature, but that comes to well more than 8192. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPpb/Juc3iHYL8FknEQKezwCgmV7iXLZMWSOjQYzjsz9MDilwZzYAoJL8 CsGYRO2oPg6Fj/AFOcuiCaOg =Nv9i -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Apr 11 15:33:16 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26571 for ; Fri, 11 Apr 2003 15:33:15 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BJA8JM010760 for ; Fri, 11 Apr 2003 12:10:08 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BJA7j4010759 for ietf-openpgp-bks; Fri, 11 Apr 2003 12:10:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BJA5JM010755 for ; Fri, 11 Apr 2003 12:10:05 -0700 (PDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3BJA7vc021434; Fri, 11 Apr 2003 15:10:07 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3BJA6vK007126; Fri, 11 Apr 2003 15:10:06 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h3BJA6U8006028; Fri, 11 Apr 2003 15:10:06 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id PAA25430; Fri, 11 Apr 2003 15:10:06 -0400 (EDT) To: "Michael Young" Cc: Subject: Re: partial packet lengths in PGP 8 References: <200304102327.h3ANRAg11229@finney.org> <87u1d530a4.fsf@alberti.g10code.de> <003001c30052$4e3329c0$2ac52609@transarc.ibm.com> From: Derek Atkins Date: 11 Apr 2003 15:10:06 -0400 In-Reply-To: <003001c30052$4e3329c0$2ac52609@transarc.ibm.com> Message-ID: Lines: 30 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Perhaps it's my flakey memory, but I recall that when Colin and I were working on PGP3/5, when we were designing what eventually turned into 2440, we had some packets that required a 2-bit LoL implementation due to compatibility reasons with PGP 2.x... I could be totally off my rocker, here -- this work was done 8 years ago so it's been a while and I've tried to forget that part of my life ;) -derek "Michael Young" writes: > From: "Derek Atkins" > > IIRC signature packets MUST use a determinate length and are limited > > to about 8192 bytes (unless this was changed somewhere along the > > line). > > The current draft does require that they be determinate, but I don't > see a numeric limit. There are hard limits to the hashed and unhashed > subpackets (2^16-1 each) and (arguably) practical limits to the size of > the MPIs that form the signature, but that comes to well more than 8192. > > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-openpgp@mail.imc.org Fri Apr 11 16:20:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28465 for ; Fri, 11 Apr 2003 16:20:28 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BJpWJM014702 for ; Fri, 11 Apr 2003 12:51:32 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BJpWW9014701 for ietf-openpgp-bks; Fri, 11 Apr 2003 12:51:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BJpUJM014681 for ; Fri, 11 Apr 2003 12:51:30 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 3.35 #1 (Debian)) id 1944Yc-0002yS-00 for ; Fri, 11 Apr 2003 21:51:30 +0200 Received: from wk by alberti.g10code.de with local (Exim 3.36 #1 (Debian)) id 1944c9-0004rI-00; Fri, 11 Apr 2003 21:55:09 +0200 To: Derek Atkins Cc: "Hal Finney" , ietf-openpgp@imc.org, sbs@hush.ai Subject: Re: partial packet lengths in PGP 8 References: <200304102327.h3ANRAg11229@finney.org> <87u1d530a4.fsf@alberti.g10code.de> From: Werner Koch Organisation: g10 Code GmbH X-Request-PGP: finger:wk@g10code.com X-PGP-KeyID: 621CC013 X-FSFE-Info: http://fsfeurope.org Date: Fri, 11 Apr 2003 21:55:07 +0200 In-Reply-To: (Derek Atkins's message of "11 Apr 2003 11:39:19 -0400") Message-ID: <87d6js3j38.fsf@alberti.g10code.de> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 11 Apr 2003 11:39:19 -0400, Derek Atkins said: > IIRC signature packets MUST use a determinate length and are limited > to about 8192 bytes (unless this was changed somewhere along the Right. I had only the length headers of the subpackets in mind which indeed would allow up to 2^32 bytes for a subpacket. However, the total length of all subpackets is limited to 2 * 2^16 bytes. Sorry for the confusion, Salam-Shalom, Werner -- Nonviolence is the greatest force at the disposal of mankind. It is mightier than the mightiest weapon of destruction devised by the ingenuity of man. -Gandhi From owner-ietf-openpgp@mail.imc.org Sat Apr 12 21:00:47 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08813 for ; Sat, 12 Apr 2003 21:00:47 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3D0dAJM007013 for ; Sat, 12 Apr 2003 17:39:10 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3D0dAMg007012 for ietf-openpgp-bks; Sat, 12 Apr 2003 17:39:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3D0d9JM007008 for ; Sat, 12 Apr 2003 17:39:09 -0700 (PDT) Received: from [63.73.97.181] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2); Sat, 12 Apr 2003 17:39:09 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 12 Apr 2003 17:39:12 -0700 Subject: Re: partial packet lengths in PGP 8 From: Jon Callas To: Brian Smith , OpenPGP Message-ID: In-Reply-To: <200304102305.h3AN5job058078@mailserver1.hushmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4/10/03 4:05 PM, "Brian Smith" wrote: > What's the reason for requiring that the first partial length be so long? > 512 octets is considerably more than the headers, IV, etc of any data > packet would be. It was to discourage its use for common things. The partial length feature was created so you could use PGP as a streaming protocol. Networks, tape backups, other things were all described to me as hypothetical uses for them. It's a cool thing, but you don't want to have to force everyone's decoder to deal with the case were the first bytes of some packet are all delivered in one-byte partials. So you want to have some minimum. You want it to be longer than a block size of a cipher, and after that, it's all handwaving. 512 was picked because it's a reasonable size of buffer, even on a very limited computer. Jon From owner-ietf-openpgp@mail.imc.org Mon Apr 14 21:46:17 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29980 for ; Mon, 14 Apr 2003 21:46:16 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3F1MdbP016418 for ; Mon, 14 Apr 2003 18:22:39 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3F1MdBi016417 for ietf-openpgp-bks; Mon, 14 Apr 2003 18:22:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3F1MbbP016407 for ; Mon, 14 Apr 2003 18:22:38 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from claude.jabberwocky.com (ppp-216-158-60-40.cust.oldcity.dca.net [216.158.60.40]) by walrus.jabberwocky.com (8.11.6/8.11.6) with ESMTP id h3F1MM419498 for ; Mon, 14 Apr 2003 21:22:32 -0400 Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h3F0DwG03282 for ietf-openpgp@imc.org; Mon, 14 Apr 2003 20:13:58 -0400 Date: Mon, 14 Apr 2003 20:13:58 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Signature targets and where they should be used Message-ID: <20030415001358.GH16969@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Gibbous (94% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In section 5.2.1 of bis-07, in the paragraph about notary signatures, the draft reads: Note that a notary signature SHOULD include a Signature Target subpacket to give easy identification. I disagree this is necessary. As I see it, the point of a signature target subpacket is to identify a signature *when that identification is not obvious from the new signature*. A signature target can be necessary or useful when issuing a certification revocation signature (i.e. 0x30). This case is signature A (the 0x30 signature), on data B (primary key + user ID), referring to signature C (the original 0x10-0x13 signature). In this case, a signature target is required to specify which signature C is. In the case of notary signatures, there is no "C" to specify. It is merely signature A (the 0x50 signature), on data B (the signature to be notarized). There is no benefit in specifying B twice as the data to be signed and then again as an additional subpacket. In the interest of simplicity, I would like to strike the sentence above. Note that this does not prevent someone from using a signature target for notary signatures if they still choose to. All I am advocating is removing any requirement (even a SHOULD) that they do so. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2rc1 (GNU/Linux) Comment: http://www.jabberwocky.com/david/keys.asc iD8DBQE+m07G4mZch0nhy8kRAneIAKDWDHMkNgXbt9YmR+Acp5o84yIruACffB9S qIhseBuc0zLd+CT5aW90eVY= =pPba -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Apr 16 16:00:42 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15013 for ; Wed, 16 Apr 2003 16:00:41 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GJflt2073123 for ; Wed, 16 Apr 2003 12:41:47 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GJflVB073122 for ietf-openpgp-bks; Wed, 16 Apr 2003 12:41:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GJfft2073116 for ; Wed, 16 Apr 2003 12:41:43 -0700 (PDT) (envelope-from mwy-opgp97@the-youngs.org) Received: from mwyoung (dhcp-197-42.transarc.ibm.com [9.38.197.42]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id PAA23275 for ; Wed, 16 Apr 2003 15:41:24 -0400 (EDT) Message-ID: <003601c30450$06bc3bc0$2ac52609@transarc.ibm.com> From: "Michael Young" To: References: <20030415001358.GH16969@jabberwocky.com> Subject: Re: Signature targets and where they should be used Date: Wed, 16 Apr 2003 15:40:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 From: "David Shaw" > Note that a notary signature SHOULD include a Signature Target > subpacket to give easy identification. > > I disagree this is necessary. As I see it, the point of a signature The SHOULD language suggests best practice, not strict requirement. For notary signatures, that's still quite a stretch, though. On the other hand, I'd love to see a SHOULD clause for revocations. The Target subpacket eliminates an ambiguity -- without it, the revocation could refer to any original signature for the same key/uid. (There is no such ambiguity for notary packets, as the whole original signature is hashed.) I think that unambiguous identification is surely a best practice. So, could you simply move the SHOULD clause from the notary signature section to revocations :-? > In the case of notary signatures, there is no "C" to specify. It is > merely signature A (the 0x50 signature), on data B (the signature to > be notarized). There is no benefit in specifying B twice as the data > to be signed and then again as an additional subpacket. I'd agree that the benefit is slight at best. I suppose if you had "B" and the material it covered (so that you could generate B's hash), and you had a disorganized bunch of notary signatures, then you could pick out the matching ones faster if they had target subpackets. This doesn't seem like a compelling scenario. :-) -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPp2xmuc3iHYL8FknEQKhyACfeOMthTZOJvKLGkza1p0jYV27IQ4AoMGL cAwzpSaFeHAleyGDte8Jtz97 =eV36 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Apr 16 17:56:26 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18230 for ; Wed, 16 Apr 2003 17:56:26 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GLd6t2077536 for ; Wed, 16 Apr 2003 14:39:06 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GLd6tZ077535 for ietf-openpgp-bks; Wed, 16 Apr 2003 14:39:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GLd5t2077530 for ; Wed, 16 Apr 2003 14:39:05 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from claude.jabberwocky.com (ppp-216-158-59-78.cust.oldcity.dca.net [216.158.59.78]) by walrus.jabberwocky.com (8.11.6/8.11.6) with ESMTP id h3GLd1426947 for ; Wed, 16 Apr 2003 17:39:01 -0400 Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h3GLcbW31340 for ietf-openpgp@imc.org; Wed, 16 Apr 2003 17:38:37 -0400 Date: Wed, 16 Apr 2003 17:38:37 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Signature targets and where they should be used Message-ID: <20030416213837.GE1184@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20030415001358.GH16969@jabberwocky.com> <003601c30450$06bc3bc0$2ac52609@transarc.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <003601c30450$06bc3bc0$2ac52609@transarc.ibm.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Gibbous (99% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Apr 16, 2003 at 03:40:24PM -0400, Michael Young wrote: > > From: "David Shaw" > > In the case of notary signatures, there is no "C" to specify. It is > > merely signature A (the 0x50 signature), on data B (the signature to > > be notarized). There is no benefit in specifying B twice as the data > > to be signed and then again as an additional subpacket. > > I'd agree that the benefit is slight at best. I suppose if > you had "B" and the material it covered (so that you could generate > B's hash), and you had a disorganized bunch of notary signatures, > then you could pick out the matching ones faster if they had > target subpackets. This doesn't seem like a compelling scenario. :-) There is actually another reason why using targets for notary signatures is not really good: one of the nice features of notary signatures is that the notarizer doesn't need the original signer's public key or the material the original signature covered. All the notarizer needs is the signature packet. Unfortunately, to use a signature target in the notary signature, the notarizer needs the original signer's public key to extract the hash from the original signature packet... I suppose we could solve that problem by defining a signature target to be the canonical hash of the signature being targeted, but even then there is still no good reason why using a target for notary signatures needs to be a SHOULD. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2rc2 (GNU/Linux) Comment: http://www.jabberwocky.com/david/keys.asc iD8DBQE+nc1c4mZch0nhy8kRAjTQAJ42SnhAoD42MFWJjin3KJXBxZrMDACeNDqK hGj20/LjG6I8lBPGqigWOlA= =a8B8 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Thu Apr 17 11:11:49 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24897 for ; Thu, 17 Apr 2003 11:11:48 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HEPht2046615 for ; Thu, 17 Apr 2003 07:25:43 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HEPhWZ046614 for ietf-openpgp-bks; Thu, 17 Apr 2003 07:25:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from public.uni-hamburg.de (public.rrz.uni-hamburg.de [134.100.32.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HEPft2046609 for ; Thu, 17 Apr 2003 07:25:42 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from public.uni-hamburg.de (loopback [127.0.0.1]) by public.uni-hamburg.de (8.12.6/8.12.6) with ESMTP id h3HEPcAv023380 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 17 Apr 2003 16:25:39 +0200 Received: (from root@localhost) by public.uni-hamburg.de (8.12.6/8.12.6/Submit) id h3HEPcAb064572; Thu, 17 Apr 2003 16:25:38 +0200 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GLd6t2077536 for ; Wed, 16 Apr 2003 14:39:06 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GLd6tZ077535 for ietf-openpgp-bks; Wed, 16 Apr 2003 14:39:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GLd5t2077530 for ; Wed, 16 Apr 2003 14:39:05 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from claude.jabberwocky.com (ppp-216-158-59-78.cust.oldcity.dca.net [216.158.59.78]) by walrus.jabberwocky.com (8.11.6/8.11.6) with ESMTP id h3GLd1426947 for ; Wed, 16 Apr 2003 17:39:01 -0400 Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h3GLcbW31340 for ietf-openpgp@imc.org; Wed, 16 Apr 2003 17:38:37 -0400 Date: Wed, 16 Apr 2003 17:38:37 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Signature targets and where they should be used Message-ID: <20030416213837.GE1184@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20030415001358.GH16969@jabberwocky.com> <003601c30450$06bc3bc0$2ac52609@transarc.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <003601c30450$06bc3bc0$2ac52609@transarc.ibm.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Gibbous (99% of Full) User-Agent: Mutt/1.5.4i List-Archive: List-Unsubscribe: List-ID: X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Apr 16, 2003 at 03:40:24PM -0400, Michael Young wrote: > > From: "David Shaw" > > In the case of notary signatures, there is no "C" to specify. It is > > merely signature A (the 0x50 signature), on data B (the signature to > > be notarized). There is no benefit in specifying B twice as the data > > to be signed and then again as an additional subpacket. > > I'd agree that the benefit is slight at best. I suppose if > you had "B" and the material it covered (so that you could generate > B's hash), and you had a disorganized bunch of notary signatures, > then you could pick out the matching ones faster if they had > target subpackets. This doesn't seem like a compelling scenario. :-) There is actually another reason why using targets for notary signatures is not really good: one of the nice features of notary signatures is that the notarizer doesn't need the original signer's public key or the material the original signature covered. All the notarizer needs is the signature packet. Unfortunately, to use a signature target in the notary signature, the notarizer needs the original signer's public key to extract the hash from the original signature packet... I suppose we could solve that problem by defining a signature target to be the canonical hash of the signature being targeted, but even then there is still no good reason why using a target for notary signatures needs to be a SHOULD. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2rc2 (GNU/Linux) Comment: http://www.jabberwocky.com/david/keys.asc iD8DBQE+nc1c4mZch0nhy8kRAjTQAJ42SnhAoD42MFWJjin3KJXBxZrMDACeNDqK hGj20/LjG6I8lBPGqigWOlA= =a8B8 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Apr 30 15:24:47 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21317 for ; Wed, 30 Apr 2003 15:24:47 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UIsIi2091050 for ; Wed, 30 Apr 2003 11:54:18 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UIsIPU091049 for ietf-openpgp-bks; Wed, 30 Apr 2003 11:54:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp1.kodak.com (smtp1.kodak.com [192.232.121.200]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UIsHi2091044 for ; Wed, 30 Apr 2003 11:54:17 -0700 (PDT) (envelope-from john.dlugosz@kodak.com) Received: from knotes3.kodak.com (knotes3.kp.kodak.com [150.103.137.52]) by smtp1.kodak.com (8.11.3/8.11.1) with ESMTP id h3UIsI103493 for ; Wed, 30 Apr 2003 14:54:18 -0400 (EDT) Subject: Low-level question about OpenPGP - why CFB mode? To: OpenPGP X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: john.dlugosz@kodak.com Date: Wed, 30 Apr 2003 13:54:16 -0500 X-MIMETrack: Serialize by Router on KNOTES3/ISBP/EKC(Release 5.0.11 |July 24, 2002) at 04/30/2003 02:53:37 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Why does OpenPGP use a custom CFB mode instead of CBC mode? CFB with the slide equal to the blocksize is basically different from CBC in that the encryption is done before combining, rather than after. I presume its simply always been that way, and it's not a problem so it was never changed in an update. But why was that chosen initially, if anybody knows, and are there any propblems with CBC that this avoids? --John From owner-ietf-openpgp@mail.imc.org Wed Apr 30 16:05:36 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22460 for ; Wed, 30 Apr 2003 16:05:36 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UJi0i2092918 for ; Wed, 30 Apr 2003 12:44:00 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UJi0wN092917 for ietf-openpgp-bks; Wed, 30 Apr 2003 12:44:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UJhxi2092910 for ; Wed, 30 Apr 2003 12:43:59 -0700 (PDT) (envelope-from hal@finney.org) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id h3UJhG310433; Wed, 30 Apr 2003 12:43:16 -0700 Date: Wed, 30 Apr 2003 12:43:16 -0700 From: "Hal Finney" Message-Id: <200304301943.h3UJhG310433@finney.org> To: ietf-openpgp@imc.org, john.dlugosz@kodak.com Subject: Re: Low-level question about OpenPGP - why CFB mode? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: CFB has two advantages over CBC that might have led to its choice. First, it only requires the underlying cipher to be run in one direction. Even in the decryption mode, CFB runs the cipher in encryption mode. This means that you don't need to implement decryption in the cipher. However I believe that the first ciphers used in PGP, Bassomatic and IDEA, had both encryption and decryption implementations. This is more of an advantage with ciphers which have asymmetric speed in one direction, but I don't think either of those early ciphers had that property. The second advantage of CFB relates to block padding. It is easy and natural in CFB to handle messages which are not a multiple of the cipher block length (8 bytes for the early ciphers). You simply truncate the ciphertext so it is the same length as the plaintext, and apply the same rule in reverse for decryption. At the time, I don't think we were aware of an analogous technique for CBC. Most people then (and many now) pad the CBC message to a multiple of 8 bytes, encrypt, and then remove the padding upon decryption. Since then we have become aware of the "ciphertext stealing" technique which lets you truncate CBC messages. But it is a bit complicated, and does not apply very readily to messages shorter than the block length. Given these disadvantages, ciphertext stealing is not very widely used for CBC encryption, rather padding is still used instead. I think this may have been the reason that Phil chose CFB. As for the non-standard "sync" operation, I don't remember why he did that. Probably it just seemed to be a natural way of handling CFB given his understanding of its rationale in terms of the way it interfaced with the underlying cipher. Hal Finney From owner-ietf-openpgp@mail.imc.org Wed Apr 30 16:27:15 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22885 for ; Wed, 30 Apr 2003 16:27:14 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UK5pi2093482 for ; Wed, 30 Apr 2003 13:05:53 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UK5pSY093481 for ietf-openpgp-bks; Wed, 30 Apr 2003 13:05:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UK5oi2093476 for ; Wed, 30 Apr 2003 13:05:50 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3UK5pQM009804; Wed, 30 Apr 2003 16:05:51 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3UK5o3u013435; Wed, 30 Apr 2003 16:05:50 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h3UK5nU8005885; Wed, 30 Apr 2003 16:05:50 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id QAA19775; Wed, 30 Apr 2003 16:05:49 -0400 (EDT) To: john.dlugosz@kodak.com Cc: OpenPGP From: Derek Atkins Subject: Re: Low-level question about OpenPGP - why CFB mode? References: Date: 30 Apr 2003 16:05:49 -0400 In-Reply-To: Message-ID: Lines: 25 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: One benefit of using CFB is that you don't need to pad your plaintext. As for why it was chosen... I think that answer is probably lost in the mystery of time (read: it was like that in PGP 2.0 and nobody had a good reason to change it). -derek john.dlugosz@kodak.com writes: > Why does OpenPGP use a custom CFB mode instead of CBC mode? CFB with the > slide equal to the blocksize is basically different from CBC in that the > encryption is done before combining, rather than after. > > I presume its simply always been that way, and it's not a problem so it was > never changed in an update. But why was that chosen initially, if anybody > knows, and are there any propblems with CBC that this avoids? > > --John > > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ietf-openpgp@mail.imc.org Wed Apr 30 16:50:53 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23692 for ; Wed, 30 Apr 2003 16:50:53 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UKRAi2093930 for ; Wed, 30 Apr 2003 13:27:10 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UKRA9Z093929 for ietf-openpgp-bks; Wed, 30 Apr 2003 13:27:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.infoseccorp.com ([12.2.121.3]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UKR8i2093924 for ; Wed, 30 Apr 2003 13:27:08 -0700 (PDT) (envelope-from markowitz@infoseccorp.com) Received: from mjm340.infoseccorp.com (mjm [12.2.121.12]) by mail.infoseccorp.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA15608; Wed, 30 Apr 2003 15:27:56 -0500 Message-Id: <5.2.0.9.2.20030430151934.02622ee0@12.2.121.3> X-Sender: mjm@12.2.121.3 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 30 Apr 2003 15:26:08 -0500 To: "Hal Finney" From: Mike Markowitz Subject: Re: Low-level question about OpenPGP - why CFB mode? Cc: ietf-openpgp@imc.org In-Reply-To: <200304301943.h3UJhG310433@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:43 PM 4/30/2003 -0700, Hal Finney wrote: >CFB has two advantages over CBC that might have led to its choice. Hal: While we're on the subject of CFB can you possibly share with us the argument you used to convince NIST the method is good? In http://cert.uni-stuttgart.de/archive/ietf-openpgp/1999/05/msg00005.html you wrote: "The "pseudo IV" we have now is hard to explain. I had to go to some lengths in getting our FIPS 140 certification (a standard security certification) to show that our way was just as good as the regular way." Thanks. -mjm From owner-ietf-openpgp@mail.imc.org Wed Apr 30 17:44:20 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25164 for ; Wed, 30 Apr 2003 17:44:20 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ULQmi2096050 for ; Wed, 30 Apr 2003 14:26:48 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3ULQlEu096049 for ietf-openpgp-bks; Wed, 30 Apr 2003 14:26:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp1.kodak.com (smtp1.kodak.com [192.232.121.200]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ULQki2096044 for ; Wed, 30 Apr 2003 14:26:46 -0700 (PDT) (envelope-from john.dlugosz@kodak.com) Received: from knotes3.kodak.com (knotes3.kp.kodak.com [150.103.137.52]) by smtp1.kodak.com (8.11.3/8.11.1) with ESMTP id h3ULQj104667; Wed, 30 Apr 2003 17:26:45 -0400 (EDT) Subject: Re: Low-level question about OpenPGP - why CFB mode? To: hal@finney.org Cc: ietf-openpgp@imc.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: john.dlugosz@kodak.com Date: Wed, 30 Apr 2003 16:26:44 -0500 X-MIMETrack: Serialize by Router on KNOTES3/ISBP/EKC(Release 5.0.11 |July 24, 2002) at 04/30/2003 05:26:04 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > The second advantage of CFB relates to block padding. It is easy and > natural in CFB to handle messages which are not a multiple of the cipher > block length (8 bytes for the early ciphers). You simply truncate the > ciphertext so it is the same length as the plaintext, and apply the same > rule in reverse for decryption. I know that CFB can encode one byte (or even one bit) at a time, rather than waiting for the whole block or requiring a multiple of the blocksize. But in PGP the step is performed on a size that's equal to the block size. Are you saying that for the last block, you can change that to a size equal to how much you have left? I don't think that was clear in the OpenPGP spec section 12. It says it loads BlockSize at a time until the plaintext is used up, implying that the "given plaintext" is a multiple of the blocksize. I see that it will work, though: step 12 consumes the remainder of the plaintext if there are ferwer than BS octets remaining, and it never has to encode again so the truncation doesn't matter when decoding. An issue with the document (I'm reading bis-07): step 12 includes "the process is repeated...". It doesn't say "this process" means steps 10 through 12 (only 10 must contain n*BS+3 etc instead of BS+3, etc.). And is that really part of step 12? --John From owner-ietf-openpgp@mail.imc.org Wed Apr 30 17:50:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25327 for ; Wed, 30 Apr 2003 17:50:59 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ULXoi2096339 for ; Wed, 30 Apr 2003 14:33:50 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3ULXoxP096338 for ietf-openpgp-bks; Wed, 30 Apr 2003 14:33:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailman.research.att.com (H-135-207-24-32.research.att.com [135.207.24.32]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ULXmi2096322 for ; Wed, 30 Apr 2003 14:33:48 -0700 (PDT) (envelope-from smb@research.att.com) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mailman.research.att.com (8.12.8/8.12.8) with ESMTP id h3ULUqZZ012016 for ; Wed, 30 Apr 2003 17:31:02 -0400 Received: from berkshire.research.att.com (guard.research.att.com [135.207.1.20]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h3ULXOV15326 for ; Wed, 30 Apr 2003 17:33:24 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 48DD87B4D for ; Wed, 30 Apr 2003 17:33:24 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Steve Bellovin To: ietf-openpgp@imc.org Subject: new chair Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Apr 2003 17:33:24 -0400 Message-Id: <20030430213324.48DD87B4D@berkshire.research.att.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As most of you know, John Noerenberg has asked to step down as chair of OpenPGP. I've asked Derek Atkins to take over as chair, to get the remaining work finished. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) From owner-ietf-openpgp@mail.imc.org Wed Apr 30 18:01:58 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25715 for ; Wed, 30 Apr 2003 18:01:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ULksi2096732 for ; Wed, 30 Apr 2003 14:46:54 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3ULks2a096731 for ietf-openpgp-bks; Wed, 30 Apr 2003 14:46:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ULkri2096724 for ; Wed, 30 Apr 2003 14:46:53 -0700 (PDT) (envelope-from hal@finney.org) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id h3ULk4o10986; Wed, 30 Apr 2003 14:46:04 -0700 Date: Wed, 30 Apr 2003 14:46:04 -0700 From: "Hal Finney" Message-Id: <200304302146.h3ULk4o10986@finney.org> To: hal@finney.org, markowitz@infoseccorp.com Subject: Re: Low-level question about OpenPGP - why CFB mode? Cc: ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mike Markowitz writes: > At 12:43 PM 4/30/2003 -0700, Hal Finney wrote: > >CFB has two advantages over CBC that might have led to its choice. > > Hal: While we're on the subject of CFB can you possibly share with us the > argument > you used to convince NIST the method is good? > > In http://cert.uni-stuttgart.de/archive/ietf-openpgp/1999/05/msg00005.html > you wrote: > > "The "pseudo IV" we have now is hard to explain. I had to go to some > lengths in > getting our FIPS 140 certification (a standard security certification) to show > that our way was just as good as the regular way." The problem was that PGP uses a fixed IV of 0 and then prepends some random data to the plaintext. Basically anything non-standard like this had to be justified. The way FIPS 140 certification works, you don't deal directly with NIST or NSA. Instead there are a few companies which are authorized to do a sort of pre-screening of your application and who then present it for certification. In practice you have to hire one of these companies to work with you and help you get your application into shape. There was a consultant who was assigned to our case and who reviewed it and worked with us. He was the one we had to convince about any questionable issues. So he brought up this issue about the IV, and we basically had to show that the purpose of the IV was satisfied by our approach. In CFB or CBC, the point of the IV is to make sure that the first block of the ciphertext will be different even though the first block of plaintext is the same. We get the same effect because for us, the first block of ciphertext comes out to be Enc(0) ^ randomddata. This then acts as a de facto IV, as it is then encrypted and xored with the first block of true plaintext. Basically our random data prefix acts as an IV, except it gets xored with the encryption of zero, which won't hurt its randomness. Anyway, our consultant was knowledgeable enough that after some extended discussion about this, drawing some diagrams on the whiteboard and showing how it worked, he was convinced that it was as good as the regular IV. BTW, this reminds me of another advantage of CFB over CBC. In CBC, the IV gets XOR'd with the plaintext and then encrypted. This means that there is a greater chance that IV and plaintext changes can cancel each other out. For example, if you do something simple with the IV like increment it for each message, only a few bits change each time. Half the time, only the low order bit of the IV changes. It might happen that the plaintext changed in a similar small way, say with just the low order bit changing. Like, if the plaintext changed from "Dear Casper" to "Dear Cathy", that is a change of just the low order bit in the first block of 8 bytes. If you sent these two messages consecutively using CBC, with the IV incrementing between them, and it happened to be even for the first block, then the first ciphertext blocks would be identical, thereby leaking information. In CFB the IV gets encrypted and then XOR'd, so in general half the bits will change each time, and it is exceedingly unlikely that this would produce any patterns in the ciphertext. Hal Finney P.S. Here is a list I made a couple of years ago illustrating some similarities and differences between CBC and full-width CFB: - With CFB if you flip a bit in block N of ciphertext, the same bit gets flipped in block N of the plaintext, but block N+1 of the plaintext becomes garbage. - With CBC if you flip a bit in block N of ciphertext, the same bit gets flipped in block N+1 of the plaintext, but block N of the plaintext becomes garbage. - With CFB you can flip a bit in the last block of the ciphertext and have the same bit get flipped in the last block of plaintext, without producing any garbage. - With CBC you can flip a bit in the IV and have the same bit get flipped in the first block of plaintext, without producing any garbage. - With CFB you can handle messages that are an uneven multiple of block size without using padding, by truncating the last block of ciphertext. - With CBC you can handle messages that are an uneven multiple of block size without using padding, by doing ciphertext stealing. - With CFB you can handle messages that are shorter than one block without using padding, by truncating the one block of ciphertext. - With CBC you can handle messages that are shorter than one block without using padding, by involving the IV in the ciphertext stealing algorithm. This requires altering the IV in the encryption phase. - With CFB decryption runs the base cipher in its encrypting direction. - With CBC decryption runs the base cipher in its decrypting direction. - With CFB encrypting does the following steps in order: encrypt the IV, XOR plaintext block 1, encrypt the result, XOR plaintext block 2, encrypt the result, XOR plaintext block 3, .... The ciphertext is what results after each encrypt step. - With CBC encrypting does the following steps in order: start with IV, XOR plaintext block 1, encrypt the result, XOR plaintext block 2, encrypt the result, XOR plaintext block 3, .... The ciphertext is what results after each XOR step. In many ways CFB and CBC are very similar. It follows from the last two points that except for the first block, a CBC ciphertext stream can be turned into CFB mode (and vice versa) by XORing the plaintext into the ciphertext. From owner-ietf-openpgp@mail.imc.org Wed Apr 30 18:32:02 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27810 for ; Wed, 30 Apr 2003 18:32:01 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UMAYi2097305 for ; Wed, 30 Apr 2003 15:10:34 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UMAYKK097304 for ietf-openpgp-bks; Wed, 30 Apr 2003 15:10:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UMAXi2097299 for ; Wed, 30 Apr 2003 15:10:33 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3UMAVgL000743; Wed, 30 Apr 2003 18:10:31 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3UMAUTt028322; Wed, 30 Apr 2003 18:10:30 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h3UMAUFJ018159; Wed, 30 Apr 2003 18:10:30 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id SAA19994; Wed, 30 Apr 2003 18:10:30 -0400 (EDT) To: john.dlugosz@kodak.com Cc: hal@finney.org, ietf-openpgp@imc.org From: Derek Atkins Subject: Re: Low-level question about OpenPGP - why CFB mode? References: Date: 30 Apr 2003 18:10:30 -0400 In-Reply-To: Message-ID: Lines: 63 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: john.dlugosz@kodak.com writes: > I know that CFB can encode one byte (or even one bit) at a time, rather > than waiting for the whole block or requiring a multiple of the blocksize. > But in PGP the step is performed on a size that's equal to the block size. > Are you saying that for the last block, you can change that to a size equal > to how much you have left? I don't think that was clear in the OpenPGP > spec section 12. It says it loads BlockSize at a time until the plaintext > is used up, implying that the "given plaintext" is a multiple of the > blocksize. I think you've got it backwards. Due to the way PGP uses the IV, you've always got a full blocksize of pre-encrypted (ready to X-OR) data waiting for your plaintext. In other words, the IV is used to seed the CFB pipeline with enough data so you don't have to wait for plaintext before you turn the crypto-crank that first time. And I see no such implication in the text. It does load the CFB buffer a full blocksize at a time when it needs to turn the crank, but the final "block" of plaintext does not need to be a blocksize. That's because the crank is never turned at that point. Think about it this way for a plaintext that is > 2 blocksizes but < 3: IV --+ +----+ +----+ | | | | | Ciph | Ciph | Ciph | | | | | P0+---+ P1+---+ P2+ | | | C0 C1 C2 Note that you do perform 3 cipher cycles, but they are performed BEFORE you feed the plaintext into the cipher. In other words: Ci = Pi XOR Ciph(Ci-1) where C-1 = IV so C0 = P0 XOR Ciph(IV) C1 = P1 XOR Ciph(C0) C2 = P2 XOR Ciph(C1) > I see that it will work, though: step 12 consumes the remainder of the > plaintext if there are ferwer than BS octets remaining, and it never has to > encode again so the truncation doesn't matter when decoding. Or when ENCODING. Remember, the CFB chain works the exact same way when encoding or decoding. > An issue with the document (I'm reading bis-07): step 12 includes "the > process is repeated...". It doesn't say "this process" means steps 10 > through 12 (only 10 must contain n*BS+3 etc instead of BS+3, etc.). And is > that really part of step 12? I need to look at the document again to answer this question > --John -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ietf-openpgp@mail.imc.org Wed Apr 30 18:41:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28145 for ; Wed, 30 Apr 2003 18:41:40 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UMKmi2097499 for ; Wed, 30 Apr 2003 15:20:48 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UMKmGD097498 for ietf-openpgp-bks; Wed, 30 Apr 2003 15:20:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UMKli2097493 for ; Wed, 30 Apr 2003 15:20:47 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h3UMKkYY003071; Wed, 30 Apr 2003 18:20:46 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3UMKkTt029170; Wed, 30 Apr 2003 18:20:46 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h3UMKjU8014506; Wed, 30 Apr 2003 18:20:45 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id SAA20015; Wed, 30 Apr 2003 18:20:45 -0400 (EDT) To: john.dlugosz@kodak.com Cc: hal@finney.org, ietf-openpgp@imc.org From: Derek Atkins Subject: Re: Low-level question about OpenPGP - why CFB mode? References: Date: 30 Apr 2003 18:20:45 -0400 In-Reply-To: Message-ID: Lines: 38 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: john.dlugosz@kodak.com writes: > An issue with the document (I'm reading bis-07): step 12 includes "the > process is repeated...". It doesn't say "this process" means steps 10 > through 12 (only 10 must contain n*BS+3 etc instead of BS+3, etc.). And is > that really part of step 12? Having just looked at -07, I agree that step 12 should be re-worded to make it more clear. Right now it says: 11. FR is encrypted to produce FRE. 12. FRE is xored with the next BS octets of plaintext, to produce the next BS octets of ciphertext. These are loaded into FR and the process is repeated until the plaintext is used up. I would suggest: 12. FRE is xored with the next BS (or fewer) octets of plaintext, to produce the next BS (or fewer) octets of ciphertext. If this step has used all the remaining plaintext, the process is complete. Otherwise, the BS octets of ciphertext are loaded into FR and the process is repeated (go back to step 11). Is this more clear? It makes it clear that the final block can be smaller than BS octets, and it's explicit about what part of the process is repeated (for those who couldn't intuit it from what to do after 'these are loaded into FR' ;). > --John -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ietf-openpgp@mail.imc.org Wed Apr 30 19:17:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29284 for ; Wed, 30 Apr 2003 19:17:59 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UMxri2098414 for ; Wed, 30 Apr 2003 15:59:53 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UMxrcH098413 for ietf-openpgp-bks; Wed, 30 Apr 2003 15:59:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UMxqi2098406 for ; Wed, 30 Apr 2003 15:59:52 -0700 (PDT) (envelope-from jon@callas.org) Received: from [208.54.115.249] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2); Wed, 30 Apr 2003 15:59:50 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 30 Apr 2003 15:59:59 -0700 Subject: Re: Low-level question about OpenPGP - why CFB mode? From: Jon Callas To: , OpenPGP Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4/30/03 11:54 AM, "john.dlugosz@kodak.com" wrote: > Why does OpenPGP use a custom CFB mode instead of CBC mode? CFB with the > slide equal to the blocksize is basically different from CBC in that the > encryption is done before combining, rather than after. > > I presume its simply always been that way, and it's not a problem so it was > never changed in an update. But why was that chosen initially, if anybody > knows, and are there any propblems with CBC that this avoids? It has, in fact, always been that way. The reason is that CFB mode doesn't require padding. The resync is there so you can easily tell if you have (most likely -- 1 in 64K chance of a miss) decrypted properly with the right key. The downside is that there are attacks on CFB mode that don't exist on CBC mode. The Jallal/Katz/Schneier attack of last summer is really an attack on CFB mode. It's possible there are interesting CBC attacks (one was published at last year's Crypto), but no one's made anything practical with it yet. (But heck, the JKS attack is almost impractical.) Jon From owner-ietf-openpgp@mail.imc.org Wed Apr 30 19:57:48 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00268 for ; Wed, 30 Apr 2003 19:57:48 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UNfHi2099286 for ; Wed, 30 Apr 2003 16:41:17 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UNfHjW099285 for ietf-openpgp-bks; Wed, 30 Apr 2003 16:41:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UNfGi2099280 for ; Wed, 30 Apr 2003 16:41:16 -0700 (PDT) (envelope-from hal@finney.org) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id h3UNeYI11681 for ietf-openpgp@imc.org; Wed, 30 Apr 2003 16:40:34 -0700 Date: Wed, 30 Apr 2003 16:40:34 -0700 From: "Hal Finney" Message-Id: <200304302340.h3UNeYI11681@finney.org> To: ietf-openpgp@imc.org Subject: Re: Low-level question about OpenPGP - why CFB mode? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas writes: > The downside is that there are attacks on CFB mode that don't exist on CBC > mode. The Jallal/Katz/Schneier attack of last summer is really an attack on > CFB mode. It's possible there are interesting CBC attacks (one was published > at last year's Crypto), but no one's made anything practical with it yet. > (But heck, the JKS attack is almost impractical.) I think that attack will work on CBC mode as well. Basically that paper is an implementation of Katz and Schneier, http://www.counterpane.com/chotext.html. That earlier paper described attacks on both CFB and CBC mail systems. Let's consider a simple full-shift-width CFB message, not including any of PGP's peculiarities like resynching or using a 0 IV: Encryption: IV P1 P2 -> C1 C2 CFB: C1 = E(IV) ^ P1 C2 = E(C1) ^ P2 CBC: C1 = E(IV ^ P1) C2 = E(C1 ^ P2) Decryption: IV C1 C2 -> P1 P2 CFB: P1 = E(IV) ^ C1 P2 = E(C1) ^ C2 CBC: P1 = D(C1) ^ IV P2 = D(C2) ^ C1 For CFB, to recover P2 using a chosen ciphertext attack, supply IV C1 R, and you will get P2' = E(C1) ^ R. You want P2 = E(C1) ^ C2, which is P2' ^ R ^ C2. For CBC, to recover P2 using a chosen ciphertext attack, supply IV R C2, and you will get P2' = D(C2) ^ R. You want P2 = D(C2) ^ C1, which is P2' ^ R ^ C1. Notice how similar the descriptions are. It's exactly the same attack, with the roles of C1 and C2 interchanged. Of course in practice the PGP attack had to deal with the complexities of PGP, but they were still able to make it work. I don't think it would have been much different if PGP used CBC, although I have not thought that through in detail. Hal Finney Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h414rui2007088 for ; Wed, 30 Apr 2003 21:53:56 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h414ruZD007087 for ietf-openpgp-bks; Wed, 30 Apr 2003 21:53:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h414rsi2007078 for ; Wed, 30 Apr 2003 21:53:55 -0700 (PDT) (envelope-from A.Back@exeter.ac.uk) Received: from [144.173.6.20] (helo=cronus.ex.ac.uk) by mercury.ex.ac.uk with esmtp (Exim 4.14) id 19B64r-00O8nr-NR; Thu, 01 May 2003 05:53:49 +0100 Date: Thu, 1 May 2003 05:53:40 +0100 From: Adam Back To: Peter Gutmann Cc: hal@finney.org, ietf-openpgp@imc.org, john.dlugosz@kodak.com, Adam Back Subject: Re: Low-level question about OpenPGP - why CFB mode? Message-ID: <20030501055340.A8413562@exeter.ac.uk> References: <200305010418.h414IlM07649@medusa01.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.2i In-Reply-To: <200305010418.h414IlM07649@medusa01.cs.auckland.ac.nz>; from pgut001@cs.auckland.ac.nz on Thu, May 01, 2003 at 04:18:47PM +1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I seem to remeber some comments in the 2.x code tree from Colin Plumb discussing the merits of the CFB resync. Here we go: * That is, the last 4 bytes of a 12-byte field are en/decrypted using * the first 4 bytes of IDEA(previous 8 bytes of ciphertext), but then * the last 4 bytes of that IDEA computation are thrown away, and the * first 8 bytes of the next field are en/decrypted using * IDEA(last 8 bytes of ciphertext). This is equivalent to using a * shorter feedback length (if you're familiar with the general CFB * technique) briefly, and doesn't weaken the cipher any (using shorter * CFB lengths makes it stronger, actually), it just makes it a bit unusual. from idea.c; actually it looks to be just a comment about the security of different feedback lengths in CFB mode. On use of CFB instead of CBC, I think this is actually goos because it avoids the whole padding issue which people frequently get wrong with bad security implications. Plus it's simpler to not have to pad. Error recovery is a phantom property, as in no mode is it secure. Adam On Thu, May 01, 2003 at 04:18:47PM +1200, Peter Gutmann wrote: > > "Hal Finney" writes: > > >I think this may have been the reason that Phil chose CFB. As for the non- > >standard "sync" operation, I don't remember why he did that. Probably it just > >seemed to be a natural way of handling CFB given his understanding of its > >rationale in terms of the way it interfaced with the underlying cipher. > > I believe it was an implementation bug/quirk, not a deliberate design > decision. > > Peter. > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h414J5i2006051 for ; Wed, 30 Apr 2003 21:19:05 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h414J5FC006050 for ietf-openpgp-bks; Wed, 30 Apr 2003 21:19:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h414J0i2006042 for ; Wed, 30 Apr 2003 21:19:03 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h414InMB026316; Thu, 1 May 2003 16:18:49 +1200 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h414IlM07649; Thu, 1 May 2003 16:18:47 +1200 Date: Thu, 1 May 2003 16:18:47 +1200 Message-Id: <200305010418.h414IlM07649@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: hal@finney.org, ietf-openpgp@imc.org, john.dlugosz@kodak.com Subject: Re: Low-level question about OpenPGP - why CFB mode? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Hal Finney" writes: >I think this may have been the reason that Phil chose CFB. As for the non- >standard "sync" operation, I don't remember why he did that. Probably it just >seemed to be a natural way of handling CFB given his understanding of its >rationale in terms of the way it interfaced with the underlying cipher. I believe it was an implementation bug/quirk, not a deliberate design decision. Peter. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UNfHi2099286 for ; Wed, 30 Apr 2003 16:41:17 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UNfHjW099285 for ietf-openpgp-bks; Wed, 30 Apr 2003 16:41:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UNfGi2099280 for ; Wed, 30 Apr 2003 16:41:16 -0700 (PDT) (envelope-from hal@finney.org) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id h3UNeYI11681 for ietf-openpgp@imc.org; Wed, 30 Apr 2003 16:40:34 -0700 Date: Wed, 30 Apr 2003 16:40:34 -0700 From: "Hal Finney" Message-Id: <200304302340.h3UNeYI11681@finney.org> To: ietf-openpgp@imc.org Subject: Re: Low-level question about OpenPGP - why CFB mode? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas writes: > The downside is that there are attacks on CFB mode that don't exist on CBC > mode. The Jallal/Katz/Schneier attack of last summer is really an attack on > CFB mode. It's possible there are interesting CBC attacks (one was published > at last year's Crypto), but no one's made anything practical with it yet. > (But heck, the JKS attack is almost impractical.) I think that attack will work on CBC mode as well. Basically that paper is an implementation of Katz and Schneier, http://www.counterpane.com/chotext.html. That earlier paper described attacks on both CFB and CBC mail systems. Let's consider a simple full-shift-width CFB message, not including any of PGP's peculiarities like resynching or using a 0 IV: Encryption: IV P1 P2 -> C1 C2 CFB: C1 = E(IV) ^ P1 C2 = E(C1) ^ P2 CBC: C1 = E(IV ^ P1) C2 = E(C1 ^ P2) Decryption: IV C1 C2 -> P1 P2 CFB: P1 = E(IV) ^ C1 P2 = E(C1) ^ C2 CBC: P1 = D(C1) ^ IV P2 = D(C2) ^ C1 For CFB, to recover P2 using a chosen ciphertext attack, supply IV C1 R, and you will get P2' = E(C1) ^ R. You want P2 = E(C1) ^ C2, which is P2' ^ R ^ C2. For CBC, to recover P2 using a chosen ciphertext attack, supply IV R C2, and you will get P2' = D(C2) ^ R. You want P2 = D(C2) ^ C1, which is P2' ^ R ^ C1. Notice how similar the descriptions are. It's exactly the same attack, with the roles of C1 and C2 interchanged. Of course in practice the PGP attack had to deal with the complexities of PGP, but they were still able to make it work. I don't think it would have been much different if PGP used CBC, although I have not thought that through in detail. Hal Finney Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UMxri2098414 for ; Wed, 30 Apr 2003 15:59:53 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UMxrcH098413 for ietf-openpgp-bks; Wed, 30 Apr 2003 15:59:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UMxqi2098406 for ; Wed, 30 Apr 2003 15:59:52 -0700 (PDT) (envelope-from jon@callas.org) Received: from [208.54.115.249] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2); Wed, 30 Apr 2003 15:59:50 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 30 Apr 2003 15:59:59 -0700 Subject: Re: Low-level question about OpenPGP - why CFB mode? From: Jon Callas To: , OpenPGP Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 4/30/03 11:54 AM, "john.dlugosz@kodak.com" wrote: > Why does OpenPGP use a custom CFB mode instead of CBC mode? CFB with the > slide equal to the blocksize is basically different from CBC in that the > encryption is done before combining, rather than after. > > I presume its simply always been that way, and it's not a problem so it was > never changed in an update. But why was that chosen initially, if anybody > knows, and are there any propblems with CBC that this avoids? It has, in fact, always been that way. The reason is that CFB mode doesn't require padding. The resync is there so you can easily tell if you have (most likely -- 1 in 64K chance of a miss) decrypted properly with the right key. The downside is that there are attacks on CFB mode that don't exist on CBC mode. The Jallal/Katz/Schneier attack of last summer is really an attack on CFB mode. It's possible there are interesting CBC attacks (one was published at last year's Crypto), but no one's made anything practical with it yet. (But heck, the JKS attack is almost impractical.) Jon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UMKmi2097499 for ; Wed, 30 Apr 2003 15:20:48 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UMKmGD097498 for ietf-openpgp-bks; Wed, 30 Apr 2003 15:20:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UMKli2097493 for ; Wed, 30 Apr 2003 15:20:47 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h3UMKkYY003071; Wed, 30 Apr 2003 18:20:46 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3UMKkTt029170; Wed, 30 Apr 2003 18:20:46 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h3UMKjU8014506; Wed, 30 Apr 2003 18:20:45 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id SAA20015; Wed, 30 Apr 2003 18:20:45 -0400 (EDT) To: john.dlugosz@kodak.com Cc: hal@finney.org, ietf-openpgp@imc.org From: Derek Atkins Subject: Re: Low-level question about OpenPGP - why CFB mode? References: Date: 30 Apr 2003 18:20:45 -0400 In-Reply-To: Message-ID: Lines: 38 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: john.dlugosz@kodak.com writes: > An issue with the document (I'm reading bis-07): step 12 includes "the > process is repeated...". It doesn't say "this process" means steps 10 > through 12 (only 10 must contain n*BS+3 etc instead of BS+3, etc.). And is > that really part of step 12? Having just looked at -07, I agree that step 12 should be re-worded to make it more clear. Right now it says: 11. FR is encrypted to produce FRE. 12. FRE is xored with the next BS octets of plaintext, to produce the next BS octets of ciphertext. These are loaded into FR and the process is repeated until the plaintext is used up. I would suggest: 12. FRE is xored with the next BS (or fewer) octets of plaintext, to produce the next BS (or fewer) octets of ciphertext. If this step has used all the remaining plaintext, the process is complete. Otherwise, the BS octets of ciphertext are loaded into FR and the process is repeated (go back to step 11). Is this more clear? It makes it clear that the final block can be smaller than BS octets, and it's explicit about what part of the process is repeated (for those who couldn't intuit it from what to do after 'these are loaded into FR' ;). > --John -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UMAYi2097305 for ; Wed, 30 Apr 2003 15:10:34 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UMAYKK097304 for ietf-openpgp-bks; Wed, 30 Apr 2003 15:10:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UMAXi2097299 for ; Wed, 30 Apr 2003 15:10:33 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3UMAVgL000743; Wed, 30 Apr 2003 18:10:31 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3UMAUTt028322; Wed, 30 Apr 2003 18:10:30 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h3UMAUFJ018159; Wed, 30 Apr 2003 18:10:30 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id SAA19994; Wed, 30 Apr 2003 18:10:30 -0400 (EDT) To: john.dlugosz@kodak.com Cc: hal@finney.org, ietf-openpgp@imc.org From: Derek Atkins Subject: Re: Low-level question about OpenPGP - why CFB mode? References: Date: 30 Apr 2003 18:10:30 -0400 In-Reply-To: Message-ID: Lines: 63 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: john.dlugosz@kodak.com writes: > I know that CFB can encode one byte (or even one bit) at a time, rather > than waiting for the whole block or requiring a multiple of the blocksize. > But in PGP the step is performed on a size that's equal to the block size. > Are you saying that for the last block, you can change that to a size equal > to how much you have left? I don't think that was clear in the OpenPGP > spec section 12. It says it loads BlockSize at a time until the plaintext > is used up, implying that the "given plaintext" is a multiple of the > blocksize. I think you've got it backwards. Due to the way PGP uses the IV, you've always got a full blocksize of pre-encrypted (ready to X-OR) data waiting for your plaintext. In other words, the IV is used to seed the CFB pipeline with enough data so you don't have to wait for plaintext before you turn the crypto-crank that first time. And I see no such implication in the text. It does load the CFB buffer a full blocksize at a time when it needs to turn the crank, but the final "block" of plaintext does not need to be a blocksize. That's because the crank is never turned at that point. Think about it this way for a plaintext that is > 2 blocksizes but < 3: IV --+ +----+ +----+ | | | | | Ciph | Ciph | Ciph | | | | | P0+---+ P1+---+ P2+ | | | C0 C1 C2 Note that you do perform 3 cipher cycles, but they are performed BEFORE you feed the plaintext into the cipher. In other words: Ci = Pi XOR Ciph(Ci-1) where C-1 = IV so C0 = P0 XOR Ciph(IV) C1 = P1 XOR Ciph(C0) C2 = P2 XOR Ciph(C1) > I see that it will work, though: step 12 consumes the remainder of the > plaintext if there are ferwer than BS octets remaining, and it never has to > encode again so the truncation doesn't matter when decoding. Or when ENCODING. Remember, the CFB chain works the exact same way when encoding or decoding. > An issue with the document (I'm reading bis-07): step 12 includes "the > process is repeated...". It doesn't say "this process" means steps 10 > through 12 (only 10 must contain n*BS+3 etc instead of BS+3, etc.). And is > that really part of step 12? I need to look at the document again to answer this question > --John -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ULksi2096732 for ; Wed, 30 Apr 2003 14:46:54 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3ULks2a096731 for ietf-openpgp-bks; Wed, 30 Apr 2003 14:46:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ULkri2096724 for ; Wed, 30 Apr 2003 14:46:53 -0700 (PDT) (envelope-from hal@finney.org) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id h3ULk4o10986; Wed, 30 Apr 2003 14:46:04 -0700 Date: Wed, 30 Apr 2003 14:46:04 -0700 From: "Hal Finney" Message-Id: <200304302146.h3ULk4o10986@finney.org> To: hal@finney.org, markowitz@infoseccorp.com Subject: Re: Low-level question about OpenPGP - why CFB mode? Cc: ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mike Markowitz writes: > At 12:43 PM 4/30/2003 -0700, Hal Finney wrote: > >CFB has two advantages over CBC that might have led to its choice. > > Hal: While we're on the subject of CFB can you possibly share with us the > argument > you used to convince NIST the method is good? > > In http://cert.uni-stuttgart.de/archive/ietf-openpgp/1999/05/msg00005.html > you wrote: > > "The "pseudo IV" we have now is hard to explain. I had to go to some > lengths in > getting our FIPS 140 certification (a standard security certification) to show > that our way was just as good as the regular way." The problem was that PGP uses a fixed IV of 0 and then prepends some random data to the plaintext. Basically anything non-standard like this had to be justified. The way FIPS 140 certification works, you don't deal directly with NIST or NSA. Instead there are a few companies which are authorized to do a sort of pre-screening of your application and who then present it for certification. In practice you have to hire one of these companies to work with you and help you get your application into shape. There was a consultant who was assigned to our case and who reviewed it and worked with us. He was the one we had to convince about any questionable issues. So he brought up this issue about the IV, and we basically had to show that the purpose of the IV was satisfied by our approach. In CFB or CBC, the point of the IV is to make sure that the first block of the ciphertext will be different even though the first block of plaintext is the same. We get the same effect because for us, the first block of ciphertext comes out to be Enc(0) ^ randomddata. This then acts as a de facto IV, as it is then encrypted and xored with the first block of true plaintext. Basically our random data prefix acts as an IV, except it gets xored with the encryption of zero, which won't hurt its randomness. Anyway, our consultant was knowledgeable enough that after some extended discussion about this, drawing some diagrams on the whiteboard and showing how it worked, he was convinced that it was as good as the regular IV. BTW, this reminds me of another advantage of CFB over CBC. In CBC, the IV gets XOR'd with the plaintext and then encrypted. This means that there is a greater chance that IV and plaintext changes can cancel each other out. For example, if you do something simple with the IV like increment it for each message, only a few bits change each time. Half the time, only the low order bit of the IV changes. It might happen that the plaintext changed in a similar small way, say with just the low order bit changing. Like, if the plaintext changed from "Dear Casper" to "Dear Cathy", that is a change of just the low order bit in the first block of 8 bytes. If you sent these two messages consecutively using CBC, with the IV incrementing between them, and it happened to be even for the first block, then the first ciphertext blocks would be identical, thereby leaking information. In CFB the IV gets encrypted and then XOR'd, so in general half the bits will change each time, and it is exceedingly unlikely that this would produce any patterns in the ciphertext. Hal Finney P.S. Here is a list I made a couple of years ago illustrating some similarities and differences between CBC and full-width CFB: - With CFB if you flip a bit in block N of ciphertext, the same bit gets flipped in block N of the plaintext, but block N+1 of the plaintext becomes garbage. - With CBC if you flip a bit in block N of ciphertext, the same bit gets flipped in block N+1 of the plaintext, but block N of the plaintext becomes garbage. - With CFB you can flip a bit in the last block of the ciphertext and have the same bit get flipped in the last block of plaintext, without producing any garbage. - With CBC you can flip a bit in the IV and have the same bit get flipped in the first block of plaintext, without producing any garbage. - With CFB you can handle messages that are an uneven multiple of block size without using padding, by truncating the last block of ciphertext. - With CBC you can handle messages that are an uneven multiple of block size without using padding, by doing ciphertext stealing. - With CFB you can handle messages that are shorter than one block without using padding, by truncating the one block of ciphertext. - With CBC you can handle messages that are shorter than one block without using padding, by involving the IV in the ciphertext stealing algorithm. This requires altering the IV in the encryption phase. - With CFB decryption runs the base cipher in its encrypting direction. - With CBC decryption runs the base cipher in its decrypting direction. - With CFB encrypting does the following steps in order: encrypt the IV, XOR plaintext block 1, encrypt the result, XOR plaintext block 2, encrypt the result, XOR plaintext block 3, .... The ciphertext is what results after each encrypt step. - With CBC encrypting does the following steps in order: start with IV, XOR plaintext block 1, encrypt the result, XOR plaintext block 2, encrypt the result, XOR plaintext block 3, .... The ciphertext is what results after each XOR step. In many ways CFB and CBC are very similar. It follows from the last two points that except for the first block, a CBC ciphertext stream can be turned into CFB mode (and vice versa) by XORing the plaintext into the ciphertext. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ULXoi2096339 for ; Wed, 30 Apr 2003 14:33:50 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3ULXoxP096338 for ietf-openpgp-bks; Wed, 30 Apr 2003 14:33:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailman.research.att.com (H-135-207-24-32.research.att.com [135.207.24.32]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ULXmi2096322 for ; Wed, 30 Apr 2003 14:33:48 -0700 (PDT) (envelope-from smb@research.att.com) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mailman.research.att.com (8.12.8/8.12.8) with ESMTP id h3ULUqZZ012016 for ; Wed, 30 Apr 2003 17:31:02 -0400 Received: from berkshire.research.att.com (guard.research.att.com [135.207.1.20]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h3ULXOV15326 for ; Wed, 30 Apr 2003 17:33:24 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 48DD87B4D for ; Wed, 30 Apr 2003 17:33:24 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Steve Bellovin To: ietf-openpgp@imc.org Subject: new chair Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Apr 2003 17:33:24 -0400 Message-Id: <20030430213324.48DD87B4D@berkshire.research.att.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As most of you know, John Noerenberg has asked to step down as chair of OpenPGP. I've asked Derek Atkins to take over as chair, to get the remaining work finished. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ULQmi2096050 for ; Wed, 30 Apr 2003 14:26:48 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3ULQlEu096049 for ietf-openpgp-bks; Wed, 30 Apr 2003 14:26:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp1.kodak.com (smtp1.kodak.com [192.232.121.200]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3ULQki2096044 for ; Wed, 30 Apr 2003 14:26:46 -0700 (PDT) (envelope-from john.dlugosz@kodak.com) Received: from knotes3.kodak.com (knotes3.kp.kodak.com [150.103.137.52]) by smtp1.kodak.com (8.11.3/8.11.1) with ESMTP id h3ULQj104667; Wed, 30 Apr 2003 17:26:45 -0400 (EDT) Subject: Re: Low-level question about OpenPGP - why CFB mode? To: hal@finney.org Cc: ietf-openpgp@imc.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: john.dlugosz@kodak.com Date: Wed, 30 Apr 2003 16:26:44 -0500 X-MIMETrack: Serialize by Router on KNOTES3/ISBP/EKC(Release 5.0.11 |July 24, 2002) at 04/30/2003 05:26:04 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > The second advantage of CFB relates to block padding. It is easy and > natural in CFB to handle messages which are not a multiple of the cipher > block length (8 bytes for the early ciphers). You simply truncate the > ciphertext so it is the same length as the plaintext, and apply the same > rule in reverse for decryption. I know that CFB can encode one byte (or even one bit) at a time, rather than waiting for the whole block or requiring a multiple of the blocksize. But in PGP the step is performed on a size that's equal to the block size. Are you saying that for the last block, you can change that to a size equal to how much you have left? I don't think that was clear in the OpenPGP spec section 12. It says it loads BlockSize at a time until the plaintext is used up, implying that the "given plaintext" is a multiple of the blocksize. I see that it will work, though: step 12 consumes the remainder of the plaintext if there are ferwer than BS octets remaining, and it never has to encode again so the truncation doesn't matter when decoding. An issue with the document (I'm reading bis-07): step 12 includes "the process is repeated...". It doesn't say "this process" means steps 10 through 12 (only 10 must contain n*BS+3 etc instead of BS+3, etc.). And is that really part of step 12? --John Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UKRAi2093930 for ; Wed, 30 Apr 2003 13:27:10 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UKRA9Z093929 for ietf-openpgp-bks; Wed, 30 Apr 2003 13:27:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.infoseccorp.com ([12.2.121.3]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UKR8i2093924 for ; Wed, 30 Apr 2003 13:27:08 -0700 (PDT) (envelope-from markowitz@infoseccorp.com) Received: from mjm340.infoseccorp.com (mjm [12.2.121.12]) by mail.infoseccorp.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA15608; Wed, 30 Apr 2003 15:27:56 -0500 Message-Id: <5.2.0.9.2.20030430151934.02622ee0@12.2.121.3> X-Sender: mjm@12.2.121.3 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 30 Apr 2003 15:26:08 -0500 To: "Hal Finney" From: Mike Markowitz Subject: Re: Low-level question about OpenPGP - why CFB mode? Cc: ietf-openpgp@imc.org In-Reply-To: <200304301943.h3UJhG310433@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:43 PM 4/30/2003 -0700, Hal Finney wrote: >CFB has two advantages over CBC that might have led to its choice. Hal: While we're on the subject of CFB can you possibly share with us the argument you used to convince NIST the method is good? In http://cert.uni-stuttgart.de/archive/ietf-openpgp/1999/05/msg00005.html you wrote: "The "pseudo IV" we have now is hard to explain. I had to go to some lengths in getting our FIPS 140 certification (a standard security certification) to show that our way was just as good as the regular way." Thanks. -mjm Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UK5pi2093482 for ; Wed, 30 Apr 2003 13:05:53 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UK5pSY093481 for ietf-openpgp-bks; Wed, 30 Apr 2003 13:05:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UK5oi2093476 for ; Wed, 30 Apr 2003 13:05:50 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3UK5pQM009804; Wed, 30 Apr 2003 16:05:51 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3UK5o3u013435; Wed, 30 Apr 2003 16:05:50 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h3UK5nU8005885; Wed, 30 Apr 2003 16:05:50 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id QAA19775; Wed, 30 Apr 2003 16:05:49 -0400 (EDT) To: john.dlugosz@kodak.com Cc: OpenPGP From: Derek Atkins Subject: Re: Low-level question about OpenPGP - why CFB mode? References: Date: 30 Apr 2003 16:05:49 -0400 In-Reply-To: Message-ID: Lines: 25 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: One benefit of using CFB is that you don't need to pad your plaintext. As for why it was chosen... I think that answer is probably lost in the mystery of time (read: it was like that in PGP 2.0 and nobody had a good reason to change it). -derek john.dlugosz@kodak.com writes: > Why does OpenPGP use a custom CFB mode instead of CBC mode? CFB with the > slide equal to the blocksize is basically different from CBC in that the > encryption is done before combining, rather than after. > > I presume its simply always been that way, and it's not a problem so it was > never changed in an update. But why was that chosen initially, if anybody > knows, and are there any propblems with CBC that this avoids? > > --John > > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UJi0i2092918 for ; Wed, 30 Apr 2003 12:44:00 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UJi0wN092917 for ietf-openpgp-bks; Wed, 30 Apr 2003 12:44:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UJhxi2092910 for ; Wed, 30 Apr 2003 12:43:59 -0700 (PDT) (envelope-from hal@finney.org) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id h3UJhG310433; Wed, 30 Apr 2003 12:43:16 -0700 Date: Wed, 30 Apr 2003 12:43:16 -0700 From: "Hal Finney" Message-Id: <200304301943.h3UJhG310433@finney.org> To: ietf-openpgp@imc.org, john.dlugosz@kodak.com Subject: Re: Low-level question about OpenPGP - why CFB mode? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: CFB has two advantages over CBC that might have led to its choice. First, it only requires the underlying cipher to be run in one direction. Even in the decryption mode, CFB runs the cipher in encryption mode. This means that you don't need to implement decryption in the cipher. However I believe that the first ciphers used in PGP, Bassomatic and IDEA, had both encryption and decryption implementations. This is more of an advantage with ciphers which have asymmetric speed in one direction, but I don't think either of those early ciphers had that property. The second advantage of CFB relates to block padding. It is easy and natural in CFB to handle messages which are not a multiple of the cipher block length (8 bytes for the early ciphers). You simply truncate the ciphertext so it is the same length as the plaintext, and apply the same rule in reverse for decryption. At the time, I don't think we were aware of an analogous technique for CBC. Most people then (and many now) pad the CBC message to a multiple of 8 bytes, encrypt, and then remove the padding upon decryption. Since then we have become aware of the "ciphertext stealing" technique which lets you truncate CBC messages. But it is a bit complicated, and does not apply very readily to messages shorter than the block length. Given these disadvantages, ciphertext stealing is not very widely used for CBC encryption, rather padding is still used instead. I think this may have been the reason that Phil chose CFB. As for the non-standard "sync" operation, I don't remember why he did that. Probably it just seemed to be a natural way of handling CFB given his understanding of its rationale in terms of the way it interfaced with the underlying cipher. Hal Finney Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UIsIi2091050 for ; Wed, 30 Apr 2003 11:54:18 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3UIsIPU091049 for ietf-openpgp-bks; Wed, 30 Apr 2003 11:54:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp1.kodak.com (smtp1.kodak.com [192.232.121.200]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3UIsHi2091044 for ; Wed, 30 Apr 2003 11:54:17 -0700 (PDT) (envelope-from john.dlugosz@kodak.com) Received: from knotes3.kodak.com (knotes3.kp.kodak.com [150.103.137.52]) by smtp1.kodak.com (8.11.3/8.11.1) with ESMTP id h3UIsI103493 for ; Wed, 30 Apr 2003 14:54:18 -0400 (EDT) Subject: Low-level question about OpenPGP - why CFB mode? To: OpenPGP X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: john.dlugosz@kodak.com Date: Wed, 30 Apr 2003 13:54:16 -0500 X-MIMETrack: Serialize by Router on KNOTES3/ISBP/EKC(Release 5.0.11 |July 24, 2002) at 04/30/2003 02:53:37 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Why does OpenPGP use a custom CFB mode instead of CBC mode? CFB with the slide equal to the blocksize is basically different from CBC in that the encryption is done before combining, rather than after. I presume its simply always been that way, and it's not a problem so it was never changed in an update. But why was that chosen initially, if anybody knows, and are there any propblems with CBC that this avoids? --John Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HEPht2046615 for ; Thu, 17 Apr 2003 07:25:43 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3HEPhWZ046614 for ietf-openpgp-bks; Thu, 17 Apr 2003 07:25:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from public.uni-hamburg.de (public.rrz.uni-hamburg.de [134.100.32.55]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3HEPft2046609 for ; Thu, 17 Apr 2003 07:25:42 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from public.uni-hamburg.de (loopback [127.0.0.1]) by public.uni-hamburg.de (8.12.6/8.12.6) with ESMTP id h3HEPcAv023380 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 17 Apr 2003 16:25:39 +0200 Received: (from root@localhost) by public.uni-hamburg.de (8.12.6/8.12.6/Submit) id h3HEPcAb064572; Thu, 17 Apr 2003 16:25:38 +0200 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GLd6t2077536 for ; Wed, 16 Apr 2003 14:39:06 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GLd6tZ077535 for ietf-openpgp-bks; Wed, 16 Apr 2003 14:39:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GLd5t2077530 for ; Wed, 16 Apr 2003 14:39:05 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from claude.jabberwocky.com (ppp-216-158-59-78.cust.oldcity.dca.net [216.158.59.78]) by walrus.jabberwocky.com (8.11.6/8.11.6) with ESMTP id h3GLd1426947 for ; Wed, 16 Apr 2003 17:39:01 -0400 Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h3GLcbW31340 for ietf-openpgp@imc.org; Wed, 16 Apr 2003 17:38:37 -0400 Date: Wed, 16 Apr 2003 17:38:37 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Signature targets and where they should be used Message-ID: <20030416213837.GE1184@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20030415001358.GH16969@jabberwocky.com> <003601c30450$06bc3bc0$2ac52609@transarc.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <003601c30450$06bc3bc0$2ac52609@transarc.ibm.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Gibbous (99% of Full) User-Agent: Mutt/1.5.4i List-Archive: List-Unsubscribe: List-ID: X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Apr 16, 2003 at 03:40:24PM -0400, Michael Young wrote: > > From: "David Shaw" > > In the case of notary signatures, there is no "C" to specify. It is > > merely signature A (the 0x50 signature), on data B (the signature to > > be notarized). There is no benefit in specifying B twice as the data > > to be signed and then again as an additional subpacket. > > I'd agree that the benefit is slight at best. I suppose if > you had "B" and the material it covered (so that you could generate > B's hash), and you had a disorganized bunch of notary signatures, > then you could pick out the matching ones faster if they had > target subpackets. This doesn't seem like a compelling scenario. :-) There is actually another reason why using targets for notary signatures is not really good: one of the nice features of notary signatures is that the notarizer doesn't need the original signer's public key or the material the original signature covered. All the notarizer needs is the signature packet. Unfortunately, to use a signature target in the notary signature, the notarizer needs the original signer's public key to extract the hash from the original signature packet... I suppose we could solve that problem by defining a signature target to be the canonical hash of the signature being targeted, but even then there is still no good reason why using a target for notary signatures needs to be a SHOULD. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2rc2 (GNU/Linux) Comment: http://www.jabberwocky.com/david/keys.asc iD8DBQE+nc1c4mZch0nhy8kRAjTQAJ42SnhAoD42MFWJjin3KJXBxZrMDACeNDqK hGj20/LjG6I8lBPGqigWOlA= =a8B8 -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GLd6t2077536 for ; Wed, 16 Apr 2003 14:39:06 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GLd6tZ077535 for ietf-openpgp-bks; Wed, 16 Apr 2003 14:39:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GLd5t2077530 for ; Wed, 16 Apr 2003 14:39:05 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from claude.jabberwocky.com (ppp-216-158-59-78.cust.oldcity.dca.net [216.158.59.78]) by walrus.jabberwocky.com (8.11.6/8.11.6) with ESMTP id h3GLd1426947 for ; Wed, 16 Apr 2003 17:39:01 -0400 Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h3GLcbW31340 for ietf-openpgp@imc.org; Wed, 16 Apr 2003 17:38:37 -0400 Date: Wed, 16 Apr 2003 17:38:37 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Signature targets and where they should be used Message-ID: <20030416213837.GE1184@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20030415001358.GH16969@jabberwocky.com> <003601c30450$06bc3bc0$2ac52609@transarc.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <003601c30450$06bc3bc0$2ac52609@transarc.ibm.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Gibbous (99% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Apr 16, 2003 at 03:40:24PM -0400, Michael Young wrote: > > From: "David Shaw" > > In the case of notary signatures, there is no "C" to specify. It is > > merely signature A (the 0x50 signature), on data B (the signature to > > be notarized). There is no benefit in specifying B twice as the data > > to be signed and then again as an additional subpacket. > > I'd agree that the benefit is slight at best. I suppose if > you had "B" and the material it covered (so that you could generate > B's hash), and you had a disorganized bunch of notary signatures, > then you could pick out the matching ones faster if they had > target subpackets. This doesn't seem like a compelling scenario. :-) There is actually another reason why using targets for notary signatures is not really good: one of the nice features of notary signatures is that the notarizer doesn't need the original signer's public key or the material the original signature covered. All the notarizer needs is the signature packet. Unfortunately, to use a signature target in the notary signature, the notarizer needs the original signer's public key to extract the hash from the original signature packet... I suppose we could solve that problem by defining a signature target to be the canonical hash of the signature being targeted, but even then there is still no good reason why using a target for notary signatures needs to be a SHOULD. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2rc2 (GNU/Linux) Comment: http://www.jabberwocky.com/david/keys.asc iD8DBQE+nc1c4mZch0nhy8kRAjTQAJ42SnhAoD42MFWJjin3KJXBxZrMDACeNDqK hGj20/LjG6I8lBPGqigWOlA= =a8B8 -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GJflt2073123 for ; Wed, 16 Apr 2003 12:41:47 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3GJflVB073122 for ietf-openpgp-bks; Wed, 16 Apr 2003 12:41:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3GJfft2073116 for ; Wed, 16 Apr 2003 12:41:43 -0700 (PDT) (envelope-from mwy-opgp97@the-youngs.org) Received: from mwyoung (dhcp-197-42.transarc.ibm.com [9.38.197.42]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id PAA23275 for ; Wed, 16 Apr 2003 15:41:24 -0400 (EDT) Message-ID: <003601c30450$06bc3bc0$2ac52609@transarc.ibm.com> From: "Michael Young" To: References: <20030415001358.GH16969@jabberwocky.com> Subject: Re: Signature targets and where they should be used Date: Wed, 16 Apr 2003 15:40:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 From: "David Shaw" > Note that a notary signature SHOULD include a Signature Target > subpacket to give easy identification. > > I disagree this is necessary. As I see it, the point of a signature The SHOULD language suggests best practice, not strict requirement. For notary signatures, that's still quite a stretch, though. On the other hand, I'd love to see a SHOULD clause for revocations. The Target subpacket eliminates an ambiguity -- without it, the revocation could refer to any original signature for the same key/uid. (There is no such ambiguity for notary packets, as the whole original signature is hashed.) I think that unambiguous identification is surely a best practice. So, could you simply move the SHOULD clause from the notary signature section to revocations :-? > In the case of notary signatures, there is no "C" to specify. It is > merely signature A (the 0x50 signature), on data B (the signature to > be notarized). There is no benefit in specifying B twice as the data > to be signed and then again as an additional subpacket. I'd agree that the benefit is slight at best. I suppose if you had "B" and the material it covered (so that you could generate B's hash), and you had a disorganized bunch of notary signatures, then you could pick out the matching ones faster if they had target subpackets. This doesn't seem like a compelling scenario. :-) -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPp2xmuc3iHYL8FknEQKhyACfeOMthTZOJvKLGkza1p0jYV27IQ4AoMGL cAwzpSaFeHAleyGDte8Jtz97 =eV36 -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3F1MdbP016418 for ; Mon, 14 Apr 2003 18:22:39 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3F1MdBi016417 for ietf-openpgp-bks; Mon, 14 Apr 2003 18:22:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3F1MbbP016407 for ; Mon, 14 Apr 2003 18:22:38 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from claude.jabberwocky.com (ppp-216-158-60-40.cust.oldcity.dca.net [216.158.60.40]) by walrus.jabberwocky.com (8.11.6/8.11.6) with ESMTP id h3F1MM419498 for ; Mon, 14 Apr 2003 21:22:32 -0400 Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h3F0DwG03282 for ietf-openpgp@imc.org; Mon, 14 Apr 2003 20:13:58 -0400 Date: Mon, 14 Apr 2003 20:13:58 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Signature targets and where they should be used Message-ID: <20030415001358.GH16969@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Gibbous (94% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In section 5.2.1 of bis-07, in the paragraph about notary signatures, the draft reads: Note that a notary signature SHOULD include a Signature Target subpacket to give easy identification. I disagree this is necessary. As I see it, the point of a signature target subpacket is to identify a signature *when that identification is not obvious from the new signature*. A signature target can be necessary or useful when issuing a certification revocation signature (i.e. 0x30). This case is signature A (the 0x30 signature), on data B (primary key + user ID), referring to signature C (the original 0x10-0x13 signature). In this case, a signature target is required to specify which signature C is. In the case of notary signatures, there is no "C" to specify. It is merely signature A (the 0x50 signature), on data B (the signature to be notarized). There is no benefit in specifying B twice as the data to be signed and then again as an additional subpacket. In the interest of simplicity, I would like to strike the sentence above. Note that this does not prevent someone from using a signature target for notary signatures if they still choose to. All I am advocating is removing any requirement (even a SHOULD) that they do so. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2rc1 (GNU/Linux) Comment: http://www.jabberwocky.com/david/keys.asc iD8DBQE+m07G4mZch0nhy8kRAneIAKDWDHMkNgXbt9YmR+Acp5o84yIruACffB9S qIhseBuc0zLd+CT5aW90eVY= =pPba -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3D0dAJM007013 for ; Sat, 12 Apr 2003 17:39:10 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3D0dAMg007012 for ietf-openpgp-bks; Sat, 12 Apr 2003 17:39:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3D0d9JM007008 for ; Sat, 12 Apr 2003 17:39:09 -0700 (PDT) Received: from [63.73.97.181] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2); Sat, 12 Apr 2003 17:39:09 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 12 Apr 2003 17:39:12 -0700 Subject: Re: partial packet lengths in PGP 8 From: Jon Callas To: Brian Smith , OpenPGP Message-ID: In-Reply-To: <200304102305.h3AN5job058078@mailserver1.hushmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 4/10/03 4:05 PM, "Brian Smith" wrote: > What's the reason for requiring that the first partial length be so long? > 512 octets is considerably more than the headers, IV, etc of any data > packet would be. It was to discourage its use for common things. The partial length feature was created so you could use PGP as a streaming protocol. Networks, tape backups, other things were all described to me as hypothetical uses for them. It's a cool thing, but you don't want to have to force everyone's decoder to deal with the case were the first bytes of some packet are all delivered in one-byte partials. So you want to have some minimum. You want it to be longer than a block size of a cipher, and after that, it's all handwaving. 512 was picked because it's a reasonable size of buffer, even on a very limited computer. Jon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BJpWJM014702 for ; Fri, 11 Apr 2003 12:51:32 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BJpWW9014701 for ietf-openpgp-bks; Fri, 11 Apr 2003 12:51:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BJpUJM014681 for ; Fri, 11 Apr 2003 12:51:30 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 3.35 #1 (Debian)) id 1944Yc-0002yS-00 for ; Fri, 11 Apr 2003 21:51:30 +0200 Received: from wk by alberti.g10code.de with local (Exim 3.36 #1 (Debian)) id 1944c9-0004rI-00; Fri, 11 Apr 2003 21:55:09 +0200 To: Derek Atkins Cc: "Hal Finney" , ietf-openpgp@imc.org, sbs@hush.ai Subject: Re: partial packet lengths in PGP 8 References: <200304102327.h3ANRAg11229@finney.org> <87u1d530a4.fsf@alberti.g10code.de> From: Werner Koch Organisation: g10 Code GmbH X-Request-PGP: finger:wk@g10code.com X-PGP-KeyID: 621CC013 X-FSFE-Info: http://fsfeurope.org Date: Fri, 11 Apr 2003 21:55:07 +0200 In-Reply-To: (Derek Atkins's message of "11 Apr 2003 11:39:19 -0400") Message-ID: <87d6js3j38.fsf@alberti.g10code.de> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 11 Apr 2003 11:39:19 -0400, Derek Atkins said: > IIRC signature packets MUST use a determinate length and are limited > to about 8192 bytes (unless this was changed somewhere along the Right. I had only the length headers of the subpackets in mind which indeed would allow up to 2^32 bytes for a subpacket. However, the total length of all subpackets is limited to 2 * 2^16 bytes. Sorry for the confusion, Salam-Shalom, Werner -- Nonviolence is the greatest force at the disposal of mankind. It is mightier than the mightiest weapon of destruction devised by the ingenuity of man. -Gandhi Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BJA8JM010760 for ; Fri, 11 Apr 2003 12:10:08 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BJA7j4010759 for ietf-openpgp-bks; Fri, 11 Apr 2003 12:10:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BJA5JM010755 for ; Fri, 11 Apr 2003 12:10:05 -0700 (PDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3BJA7vc021434; Fri, 11 Apr 2003 15:10:07 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3BJA6vK007126; Fri, 11 Apr 2003 15:10:06 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h3BJA6U8006028; Fri, 11 Apr 2003 15:10:06 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id PAA25430; Fri, 11 Apr 2003 15:10:06 -0400 (EDT) To: "Michael Young" Cc: Subject: Re: partial packet lengths in PGP 8 References: <200304102327.h3ANRAg11229@finney.org> <87u1d530a4.fsf@alberti.g10code.de> <003001c30052$4e3329c0$2ac52609@transarc.ibm.com> From: Derek Atkins Date: 11 Apr 2003 15:10:06 -0400 In-Reply-To: <003001c30052$4e3329c0$2ac52609@transarc.ibm.com> Message-ID: Lines: 30 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Perhaps it's my flakey memory, but I recall that when Colin and I were working on PGP3/5, when we were designing what eventually turned into 2440, we had some packets that required a 2-bit LoL implementation due to compatibility reasons with PGP 2.x... I could be totally off my rocker, here -- this work was done 8 years ago so it's been a while and I've tried to forget that part of my life ;) -derek "Michael Young" writes: > From: "Derek Atkins" > > IIRC signature packets MUST use a determinate length and are limited > > to about 8192 bytes (unless this was changed somewhere along the > > line). > > The current draft does require that they be determinate, but I don't > see a numeric limit. There are hard limits to the hashed and unhashed > subpackets (2^16-1 each) and (arguably) practical limits to the size of > the MPIs that form the signature, but that comes to well more than 8192. > > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BHl2JM006616 for ; Fri, 11 Apr 2003 10:47:02 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BHl2mq006615 for ietf-openpgp-bks; Fri, 11 Apr 2003 10:47:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BHl0JM006608 for ; Fri, 11 Apr 2003 10:47:00 -0700 (PDT) Received: from mwyoung (dhcp-197-42.transarc.ibm.com [9.38.197.42]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id NAA16582 for ; Fri, 11 Apr 2003 13:46:49 -0400 (EDT) Message-ID: <003001c30052$4e3329c0$2ac52609@transarc.ibm.com> From: "Michael Young" To: References: <200304102327.h3ANRAg11229@finney.org><87u1d530a4.fsf@alberti.g10code.de> Subject: Re: partial packet lengths in PGP 8 Date: Fri, 11 Apr 2003 13:46:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 From: "Derek Atkins" > IIRC signature packets MUST use a determinate length and are limited > to about 8192 bytes (unless this was changed somewhere along the > line). The current draft does require that they be determinate, but I don't see a numeric limit. There are hard limits to the hashed and unhashed subpackets (2^16-1 each) and (arguably) practical limits to the size of the MPIs that form the signature, but that comes to well more than 8192. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPpb/Juc3iHYL8FknEQKezwCgmV7iXLZMWSOjQYzjsz9MDilwZzYAoJL8 CsGYRO2oPg6Fj/AFOcuiCaOg =Nv9i -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BFdhJM002294 for ; Fri, 11 Apr 2003 08:39:43 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3BFdhsv002293 for ietf-openpgp-bks; Fri, 11 Apr 2003 08:39:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3BFdfJM002286 for ; Fri, 11 Apr 2003 08:39:41 -0700 (PDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3BFdLnF006621; Fri, 11 Apr 2003 11:39:21 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3BFdK80006101; Fri, 11 Apr 2003 11:39:20 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h3BFdJFJ025673; Fri, 11 Apr 2003 11:39:19 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id LAA25044; Fri, 11 Apr 2003 11:39:19 -0400 (EDT) To: Werner Koch Cc: "Hal Finney" , ietf-openpgp@imc.org, sbs@hush.ai Subject: Re: partial packet lengths in PGP 8 References: <200304102327.h3ANRAg11229@finney.org> <87u1d530a4.fsf@alberti.g10code.de> From: Derek Atkins Date: 11 Apr 2003 11:39:19 -0400 In-Reply-To: <87u1d530a4.fsf@alberti.g10code.de> Message-ID: Lines: 21 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner Koch writes: > On Thu, 10 Apr 2003 16:27:10 -0700, Hal Finney said: > > > A literal data packet could have up to a 256 byte long filename plus a > > few more bytes for the other data, so you need it to be bigger than that. > > And 512 is the next size up. > > and signature packets can be of any size ... IIRC signature packets MUST use a determinate length and are limited to about 8192 bytes (unless this was changed somewhere along the line). -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B8QaJM024881 for ; Fri, 11 Apr 2003 01:26:36 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3B8Qa7l024880 for ietf-openpgp-bks; Fri, 11 Apr 2003 01:26:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B8QYJM024875 for ; Fri, 11 Apr 2003 01:26:34 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 3.35 #1 (Debian)) id 193trf-0005GN-00 for ; Fri, 11 Apr 2003 10:26:27 +0200 Received: from wk by alberti.g10code.de with local (Exim 3.36 #1 (Debian)) id 193tuK-0004BP-00; Fri, 11 Apr 2003 10:29:12 +0200 To: "Hal Finney" Cc: ietf-openpgp@imc.org, sbs@hush.ai Subject: Re: partial packet lengths in PGP 8 References: <200304102327.h3ANRAg11229@finney.org> From: Werner Koch Organisation: g10 Code GmbH X-Request-PGP: finger:wk@g10code.com X-PGP-KeyID: 621CC013 X-FSFE-Info: http://fsfeurope.org Date: Fri, 11 Apr 2003 10:29:07 +0200 In-Reply-To: <200304102327.h3ANRAg11229@finney.org> ("Hal Finney"'s message of "Thu, 10 Apr 2003 16:27:10 -0700") Message-ID: <87u1d530a4.fsf@alberti.g10code.de> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 10 Apr 2003 16:27:10 -0700, Hal Finney said: > A literal data packet could have up to a 256 byte long filename plus a > few more bytes for the other data, so you need it to be bigger than that. > And 512 is the next size up. and signature packets can be of any size ... -- Nonviolence is the greatest force at the disposal of mankind. It is mightier than the mightiest weapon of destruction devised by the ingenuity of man. -Gandhi Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B1CVJM022203 for ; Thu, 10 Apr 2003 18:12:31 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3B1CV5H022202 for ietf-openpgp-bks; Thu, 10 Apr 2003 18:12:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3B1CSJM022191 for ; Thu, 10 Apr 2003 18:12:29 -0700 (PDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3B1CS3r022938; Thu, 10 Apr 2003 21:12:28 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3B1CR06029399; Thu, 10 Apr 2003 21:12:27 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h3B1CQFJ010387; Thu, 10 Apr 2003 21:12:26 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id VAA23310; Thu, 10 Apr 2003 21:12:26 -0400 (EDT) To: "Brian Smith" Cc: ietf-openpgp@imc.org From: Derek Atkins Subject: Re: partial packet lengths in PGP 8 References: <200304102305.h3AN5job058078@mailserver1.hushmail.com> Date: 10 Apr 2003 21:12:26 -0400 In-Reply-To: <200304102305.h3AN5job058078@mailserver1.hushmail.com> Message-ID: Lines: 45 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A better question to be asking yourself is why do you feel you need to break the packet up any SMALLER than 512 bytes? -derek "Brian Smith" writes: > What's the reason for requiring that the first partial length be so long? > 512 octets is considerably more than the headers, IV, etc of any data > packet would be. > > Brian > > On Wed, 09 Apr 2003 15:45:44 -0700 Jon Callas wrote: > > > >On 4/9/03 3:02 PM, "Hal Finney" wrote: > > > >> I suggest that the following text: > >> > >> An implementation MAY use Partial Body Lengths for data packets, > > be > >> they literal, compressed, or encrypted. The first partial length > >MUST > >> be at least 512 octets long. Partial Body Lengths MUST NOT be > >used > >> for any other packet types. > >> > >> Note also that the last Body Length header can be a zero-length > >header. > >> > >> be moved from 4.2.3 to section 4.2.2.4, Partial Body Lengths. > > Also I > >> moved the "Note also" sentence to after the paragraph as you see. > > > >I moved them. > > > > Jon > > > > > > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ANSEJM016634 for ; Thu, 10 Apr 2003 16:28:14 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3ANSE0s016633 for ietf-openpgp-bks; Thu, 10 Apr 2003 16:28:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3ANSCJM016629 for ; Thu, 10 Apr 2003 16:28:13 -0700 (PDT) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id h3ANRAg11229; Thu, 10 Apr 2003 16:27:10 -0700 Date: Thu, 10 Apr 2003 16:27:10 -0700 From: "Hal Finney" Message-Id: <200304102327.h3ANRAg11229@finney.org> To: ietf-openpgp@imc.org, sbs@hush.ai Subject: Re: partial packet lengths in PGP 8 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Brian Smith writes: > What's the reason for requiring that the first partial length be so long? > 512 octets is considerably more than the headers, IV, etc of any data > packet would be. A literal data packet could have up to a 256 byte long filename plus a few more bytes for the other data, so you need it to be bigger than that. And 512 is the next size up. Hal Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AN6QJM015110 for ; Thu, 10 Apr 2003 16:06:26 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h3AN6QnG015109 for ietf-openpgp-bks; Thu, 10 Apr 2003 16:06:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.33]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h3AN6OJM015098 for ; Thu, 10 Apr 2003 16:06:24 -0700 (PDT) Received: from mailserver1.hushmail.com (mailserver1.hushmail.com [65.39.178.20]) by smtp3.hushmail.com (Postfix) with ESMTP id 2CC8F5E29 for ; Thu, 10 Apr 2003 16:05:45 -0700 (PDT) Received: from mailserver1.hushmail.com (localhost.hushmail.com [127.0.0.1]) by mailserver1.hushmail.com (8.12.6/8.12.3) with ESMTP id h3AN5jbW058086 for ; Thu, 10 Apr 2003 16:05:45 -0700 (PDT) (envelope-from sbs@hush.ai) Received: (from nobody@localhost) by mailserver1.hushmail.com (8.12.6/8.12.3/Submit) id h3AN5job058078 for ietf-openpgp@imc.org; Thu, 10 Apr 2003 16:05:45 -0700 (PDT) Message-Id: <200304102305.h3AN5job058078@mailserver1.hushmail.com> Date: Thu, 10 Apr 2003 16:05:45 -0700 To: ietf-openpgp@imc.org Cc: Subject: Re: partial packet lengths in PGP 8 From: "Brian Smith" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: What's the reason for requiring that the first partial length be so long? 512 octets is considerably more than the headers, IV, etc of any data packet would be. Brian On Wed, 09 Apr 2003 15:45:44 -0700 Jon Callas wrote: > >On 4/9/03 3:02 PM, "Hal Finney" wrote: > >> I suggest that the following text: >> >> An implementation MAY use Partial Body Lengths for data packets, > be >> they literal, compressed, or encrypted. The first partial length >MUST >> be at least 512 octets long. Partial Body Lengths MUST NOT be >used >> for any other packet types. >> >> Note also that the last Body Length header can be a zero-length >header. >> >> be moved from 4.2.3 to section 4.2.2.4, Partial Body Lengths. > Also I >> moved the "Note also" sentence to after the paragraph as you see. > >I moved them. > > Jon > > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39MjlJM027437 for ; Wed, 9 Apr 2003 15:45:47 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39MjlNB027436 for ietf-openpgp-bks; Wed, 9 Apr 2003 15:45:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39MjjJM027432 for ; Wed, 9 Apr 2003 15:45:46 -0700 (PDT) Received: from [63.251.255.205] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2); Wed, 9 Apr 2003 15:45:47 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 09 Apr 2003 15:45:44 -0700 Subject: Re: partial packet lengths in PGP 8 From: Jon Callas To: Hal Finney , OpenPGP Message-ID: In-Reply-To: <200304092202.h39M2mM05835@finney.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 4/9/03 3:02 PM, "Hal Finney" wrote: > I suggest that the following text: > > An implementation MAY use Partial Body Lengths for data packets, be > they literal, compressed, or encrypted. The first partial length MUST > be at least 512 octets long. Partial Body Lengths MUST NOT be used > for any other packet types. > > Note also that the last Body Length header can be a zero-length header. > > be moved from 4.2.3 to section 4.2.2.4, Partial Body Lengths. Also I > moved the "Note also" sentence to after the paragraph as you see. I moved them. Jon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39M3rJM024606 for ; Wed, 9 Apr 2003 15:03:53 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39M3qKq024605 for ietf-openpgp-bks; Wed, 9 Apr 2003 15:03:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39M3pJM024601 for ; Wed, 9 Apr 2003 15:03:51 -0700 (PDT) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id h39M2mM05835 for ietf-openpgp@imc.org; Wed, 9 Apr 2003 15:02:48 -0700 Date: Wed, 9 Apr 2003 15:02:48 -0700 From: "Hal Finney" Message-Id: <200304092202.h39M2mM05835@finney.org> To: ietf-openpgp@imc.org Subject: Re: partial packet lengths in PGP 8 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Michael Young writes: > The specification includes a stronger requirement, in section 4.2.3: > "The first partial length MUST be at least 512 octets long." I hadn't noticed that. I think that requirement is not in a very good place, buried in section 4.2.3 which is titled "Packet Length Examples". That's not where an implementor would expect to find MUST rules regarding partial body lengths. I suggest that the following text: An implementation MAY use Partial Body Lengths for data packets, be they literal, compressed, or encrypted. The first partial length MUST be at least 512 octets long. Partial Body Lengths MUST NOT be used for any other packet types. Note also that the last Body Length header can be a zero-length header. be moved from 4.2.3 to section 4.2.2.4, Partial Body Lengths. Also I moved the "Note also" sentence to after the paragraph as you see. I am using section numbers from RFC2440, I don't have the new version in front of me at the moment, so they might have different numbers there. Hal Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39Es2JM004618 for ; Wed, 9 Apr 2003 07:54:02 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h39Es2tD004617 for ietf-openpgp-bks; Wed, 9 Apr 2003 07:54:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h39Es0JM004608 for ; Wed, 9 Apr 2003 07:54:00 -0700 (PDT) Received: from mwyoung (dhcp-197-42.transarc.ibm.com [9.38.197.42]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id KAA13384 for ; Wed, 9 Apr 2003 10:54:00 -0400 (EDT) Message-ID: <000e01c2fea7$db061e40$2ac52609@transarc.ibm.com> From: "Michael Young" To: References: <200304090319.h393JZv00366@finney.org> Subject: Re: partial packet lengths in PGP 8 Date: Wed, 9 Apr 2003 10:53:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "Hal Finney" answers "Brian Smith" with: > So the work-around in this case is to make sure the first partial body > length is at least 16 bytes, for 8 byte block ciphers, and 32 bytes, The specification includes a stronger requirement, in section 4.2.3: "The first partial length MUST be at least 512 octets long." Separately, I might suggest avoid using a zero-length packet at the end, if you can. It's not illegal, but it's the kind of thing that might tickle a bug in another implementation. I'd be conservative. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPpQz9ec3iHYL8FknEQLonwCfZZw7j5XoTpjpbT1nk3HdHQWybpoAoPY+ p1BGzXA9pX7Tp3yD/JgUZ86D =jnM+ -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h393KfJM004705 for ; Tue, 8 Apr 2003 20:20:41 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h393Kfhx004704 for ietf-openpgp-bks; Tue, 8 Apr 2003 20:20:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h393KdJM004699 for ; Tue, 8 Apr 2003 20:20:40 -0700 (PDT) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id h393JZv00366; Tue, 8 Apr 2003 20:19:35 -0700 Date: Tue, 8 Apr 2003 20:19:35 -0700 From: "Hal Finney" Message-Id: <200304090319.h393JZv00366@finney.org> To: ietf-openpgp@imc.org, sbs@hush.ai Subject: Re: partial packet lengths in PGP 8 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Brian Smith" writes: > It seems to me that PGP 8 does not support partial packet lengths for > a a symmetrically encrypted data packet. Is this a known bug, and if > so is there a work-around? I worked on predecessors to PGP 8, and based on your test data I can confirm that there is a bug in the packet parsing code relating to partial body lengths. It's not specific to symmetrically encrypted data packets, but rather to the "initial" portion of the packets. Many of the PGP data packets have an initial part which is of more or less fixed length, followed by the rest of the body which can be of arbitrary length. The parser first assembles the initial portion and extracts the data from that, then falls into some relatively generic code which handles the rest of the data. There is a bug in the parser which won't work properly if the initial portion spans two or more partial-body-length packets. In the case of symmetrically encrypted data packets, the initial portion is the first 10 bytes (for 8-byte ciphers; 18 bytes for 16-byte block ciphers). In your case you had a PBL of 8 followed by two PBL's of 1 each to fill out the first 10 bytes, but the code messes up and doesn't assemble the packets correctly. It doesn't do what you might think and include the e0's in the packet, but it fails to update the buffer pointer and so replicates the contents of the previous PBL, the 96 and 97 bytes, as the 9th and 10th. So the work-around in this case is to make sure the first partial body length is at least 16 bytes, for 8 byte block ciphers, and 32 bytes, for 16 byte block ciphers. That will mean buffering up the first 16 or 32 bytes of your stream before emitting your first block. Hal Finney Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h392DEJM001590 for ; Tue, 8 Apr 2003 19:13:14 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h392DEK6001589 for ietf-openpgp-bks; Tue, 8 Apr 2003 19:13:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.33]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h392DCJM001585 for ; Tue, 8 Apr 2003 19:13:12 -0700 (PDT) Received: from mailserver1.hushmail.com (mailserver1.hushmail.com [65.39.178.20]) by smtp3.hushmail.com (Postfix) with ESMTP id EFC197409 for ; Tue, 8 Apr 2003 19:12:25 -0700 (PDT) Received: from mailserver1.hushmail.com (localhost.hushmail.com [127.0.0.1]) by mailserver1.hushmail.com (8.12.6/8.12.3) with ESMTP id h392CQbW031486 for ; Tue, 8 Apr 2003 19:12:26 -0700 (PDT) (envelope-from sbs@hush.ai) Received: (from nobody@localhost) by mailserver1.hushmail.com (8.12.6/8.12.3/Submit) id h392CQ3M031484 for OpenPGP ; Tue, 8 Apr 2003 19:12:26 -0700 (PDT) Message-Id: <200304090212.h392CQ3M031484@mailserver1.hushmail.com> Date: Tue, 8 Apr 2003 19:12:25 -0700 To: OpenPGP Cc: Subject: partial packet lengths in PGP 8 From: "Brian Smith" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It seems to me that PGP 8 does not support partial packet lengths for a a symmetrically encrypted data packet. Is this a known bug, and if so is there a work-around? There are some situations where it would be very useful for me to be able to generate messages from a stream where I don't know the length ahead of time and have them still decrypt under PGP 8. Specifically, the following packet seems to break it: c9e39697376314f4fbede026e0bae28397cc98e16881e0ece0f2e2095e6bfee12680e056e000e0cc00 Or broken down into lengths: c9 (tag indicating symmetrically encrypted data packet) e3 (partial length of 8) 9697376314f4fbed e0 (partial length of 1) 26 e0 (partial length of 1) ba e2 (partial length of 4) 8397cc98 e1 (partial length of 2) 6881 e0 (partial length of 1) ec e0 (partial length of 1) f2 e2 (partial length of 4) 095e6bfe e1 (partial length of 2) 2680 e0 (partial length of 1) 56 e0 (partial length of 1) 00 e0 (partial length of 1) cc 00 (final zero length tag) Here's the actual message that was generated from. It's just the message "xx" encrypted with the password "test". Decrypts fine with gpg. -----BEGIN PGP MESSAGE----- jA0EAwMCPAgVwxrjQWlgyeOWlzdjFPT77eAm4Lrig5fMmOFogeDs4PLiCV5r/uEmgOBW 4ADgzAA= =N9CU -----END PGP MESSAGE----- Thanks, Brian Smith Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37HBKJM016441 for ; Mon, 7 Apr 2003 10:11:20 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h37HBK7E016440 for ietf-openpgp-bks; Mon, 7 Apr 2003 10:11:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h37HBJJM016435 for ; Mon, 7 Apr 2003 10:11:19 -0700 (PDT) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id h37HA7r24019; Mon, 7 Apr 2003 10:10:07 -0700 Date: Mon, 7 Apr 2003 10:10:07 -0700 From: "Hal Finney" Message-Id: <200304071710.h37HA7r24019@finney.org> To: df@fabiand.net, ietf-openpgp@imc.org Subject: Re: Please Help with OpenPGP's CFB Mode Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel Fabian writes: > ... > - I load the FR with c2 - c17: > 158;148;73;14;80;225;210;140;157;206;228;11;143;115;163;29; > - Encrypt it: FRE: 121;156;77;216;12;149;25;199;12;206;220;6;43;173;198;65; > - And get the WRONG plaintext block > 200;53;1;59;109;82;194;192;200;192;192;16;146;145;170;224; > > This is definitly not the UTF-8 representation of "The MD5 hash alg". > Could someone please tell me what I'm doing wrong? You have done the decryption properly. Your plaintext when expressed in hex form is: c8 35 01 3b 6d 52 c2 c0 c8 c0 c0 10 92 91 aa e0 You have to interpret this as PGP data per RFC2440. C8 is the tag byte for a Compressed Data Packet (see section 5.6). 35 is its length. 01 is the type of compression, namely ZIP (see section 9.3). The remaining data is to be input to the decompression algorithm. The output of that will be a PGP Literal Data Packet, and the contents of that packet will include your text. Hal Finney Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h376VHJM016087 for ; Sun, 6 Apr 2003 23:31:17 -0700 (PDT) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h376VHh9016085 for ietf-openpgp-bks; Sun, 6 Apr 2003 23:31:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.fabiand.net (postfix@cm107-58.liwest.at [212.241.107.58]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h376VFJM016072 for ; Sun, 6 Apr 2003 23:31:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.fabiand.net (Postfix) with ESMTP id 1B5FB1496CC for ; Mon, 7 Apr 2003 08:28:11 +0200 (CEST) Received: from mail.fabiand.net ([127.0.0.1]) by localhost (server [127.0.0.1:10024]) (amavisd-new) with ESMTP id 06348-10 for ; Mon, 7 Apr 2003 08:26:28 +0200 (CEST) Received: from dflt (cm107-56.liwest.at [212.241.107.56]) by mail.fabiand.net (Postfix) with SMTP id 3C4771496BD for ; Mon, 7 Apr 2003 08:25:52 +0200 (CEST) From: "Daniel Fabian" To: Subject: Please Help with OpenPGP's CFB Mode Date: Mon, 7 Apr 2003 08:28:44 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Virus-Scanned: by amavisd-new Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I'm having some troubles implementing OpenPGP's CFB Mode. It seems I got the resync step wrong. Could someone perhaps be so kind and check this? I'm trying to decrypt the following message: -----BEGIN PGP MESSAGE----- Version: PGP 8.0 qANQR1DDDQQJAwLltQFZpPdHImDJSb9TnpRJDlDh0oydzuQLj3OjHbGpTONhx9sH xA4cFrk8bKHxtnyfDqN0IMK604l+qbZJXnrK8qAtMobe5z4unnS6kOwSWrtbDHo= =mq0f -----END PGP MESSAGE----- This is the line "The MD5 hash algorithm has been found to have " from the RFC, symmetrically encrypted with the passphrase "test". This should be the ciphertext 191;83;158;148;73;14;80;225;210;140;157;206;228;11;143;115;163;29;177;169;76 ;227;97;199;219;7;196;14;28;22;185;60;108;161;241;182;124;159;14;163;116;32; 194;186;211;137;126;169;182;73;94;122;202;242;160;45;50;134;222;231;62;46;15 8;116;186;144;236;18;90;187;91;12;122 encrypted with the symmetrical key 165;250;150;68;115;173;70;173;212;104;208;113;241;231;223;29;28;118;235;208; 188;166;157;28;51;170;81;64;96;73;144;105 and the AES256 cipher. Here's what I do: - I load FR 0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0 with all 0's - I encrypt to get FRE: 67;169;145;216;194;226;251;238;246;15;184;187;87;67;190;101; - This gives me the Plaintext: 252;250;15;76;139;236;171;15;36;131;37;117;179;72;49;22; - Load C0-C15 into the FR: 191;83;158;148;73;14;80;225;210;140;157;206;228;11;143;115; - FRE: 146;11;98;243;113;121;142;86;23;188;60;49;76;14;194;225; - Plaintext: 49;22 So this part should have worked fine, because as stated in the rfc, the bytes c14 and c15 are the same as c16 and c17. However here comes the trouble: - I load the FR with c2 - c17: 158;148;73;14;80;225;210;140;157;206;228;11;143;115;163;29; - Encrypt it: FRE: 121;156;77;216;12;149;25;199;12;206;220;6;43;173;198;65; - And get the WRONG plaintext block 200;53;1;59;109;82;194;192;200;192;192;16;146;145;170;224; This is definitly not the UTF-8 representation of "The MD5 hash alg". Could someone please tell me what I'm doing wrong? Thanks in advance, Daniel Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31EkYJM028068 for ; Tue, 1 Apr 2003 06:46:34 -0800 (PST) Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h31EkY3N028067 for ietf-openpgp-bks; Tue, 1 Apr 2003 06:46:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordomo set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.33]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h31EkXJM028053 for ; Tue, 1 Apr 2003 06:46:33 -0800 (PST) Received: from mailserver2.hushmail.com (mailserver2.hushmail.com [65.39.178.21]) by smtp3.hushmail.com (Postfix) with ESMTP id 747D273C7 for ; Tue, 1 Apr 2003 06:46:28 -0800 (PST) Received: from mailserver2.hushmail.com (localhost.hushmail.com [127.0.0.1]) by mailserver2.hushmail.com (8.12.6/8.12.3) with ESMTP id h31EkSKs083870 for ; Tue, 1 Apr 2003 06:46:28 -0800 (PST) (envelope-from vedaal@hush.com) Received: (from nobody@localhost) by mailserver2.hushmail.com (8.12.6/8.12.3/Submit) id h31EkSeU083869 for ietf-openpgp@imc.org; Tue, 1 Apr 2003 06:46:28 -0800 (PST) Message-Id: <200304011446.h31EkSeU083869@mailserver2.hushmail.com> Date: Tue, 1 Apr 2003 06:46:28 -0800 To: ietf-openpgp@imc.org Cc: Subject: gnupg/pgp symmetric encryption incompatibility report From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: the following demonstration of an incompatiblity in symmetric encryption was reported in alt.security.pgp: ----- Original Message ----- From: "Falissard" Newsgroups: alt.security.pgp,comp.security.pgp.tech Sent: Monday, March 31, 2003 4:24 PM Subject: GnuPG (good) and PGP (bad) encryption > For specialists only... > Here is one case where PGP is not as clever as GnuPG... > The following conventionally encrypted data > decrypts well with GnuPG, ** not ** with PGP ("bad packet"). > The passphrase is "test". > Nothing special here regarding algorithms (Cast5 + MD5). > The thing that I suspect is that PGP does not always > accept packets with indeterminate length, while > it's OK for GnuPG. > (I deliberately encrypted a compressed > packet with indeterminate length.) > -----BEGIN PGP MESSAGE----- Version: GnuPG v1.0.6 (MingW32) Comment: For info see http://www.gnupg.org wwQEAwAByf8AAAAyEXrKTVH2DEz0lKVsP6ZpFJySpLkH+ha6WY3EXlj7Phjgdm0c cRg0WUWFpllUCMJqzPk= =hHJq -----END PGP MESSAGE----- is the 'indeterminate packet length' issue a contrived exception, that would not be expected to occur with ordinary use, or is it something that needs to be addressed? tia, vedaal Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Big $$$ to be made with the HushMail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427