From nobody Wed Dec 30 03:51:48 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5691AC425 for ; Wed, 30 Dec 2015 03:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.612 X-Spam-Level: X-Spam-Status: No, score=-1.612 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zqbsb3-aRfkB for ; Wed, 30 Dec 2015 03:51:43 -0800 (PST) Received: from outgoing.fripost.org (giraff.fripost.org [178.16.208.44]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB40D1AC416 for ; Wed, 30 Dec 2015 03:51:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by outgoing.fripost.org (Postfix) with ESMTP id 7C3C434A11C for ; Wed, 30 Dec 2015 12:51:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fripost.org; h= user-agent:content-disposition:content-type:content-type :mime-version:message-id:subject:subject:from:from:date:date; s= 20140703; t=1451476301; x=1453290702; bh=I3KGSWAFWu/3yeRLrhmyePp U7Ou47ARTUcvbGWaONNE=; b=048qBlO0n2GB2Eq9dS1InfoAGdZ4v7LYm6GsiZr n8KI24ImQnjPvn/ufRI1Kiggh7K0okBUgezAsoH+RTXr27TZtpQcPCWiJOjj+LEw 3RkckRDsq/jb+fybd0Ba4vJWzKGXIjtMJHp5coi2gFrgHZkFpw7N9HgIFSoOU2Un 8+1c= X-Virus-Scanned: Debian amavisd-new at fripost.org Received: from outgoing.fripost.org ([127.0.0.1]) by localhost (giraff.fripost.org [127.0.0.1]) (amavisd-new, port 10040) with LMTP id hpZ1ZGq4RPDk for ; Wed, 30 Dec 2015 12:51:41 +0100 (CET) Received: from smtp.fripost.org (mistral.fripost.org [178.16.208.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mistral.fripost.org", Issuer "mistral.fripost.org" (not verified)) by outgoing.fripost.org (Postfix) with ESMTPS id 4B25334A116 for ; Wed, 30 Dec 2015 12:51:41 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by smtp.fripost.org (Postfix) with ESMTPSA id 20E4B982641 for ; Wed, 30 Dec 2015 12:51:34 +0100 (CET) Received: by localhost.localdomain (Postfix, from userid 1000) id 00728AD85D; Wed, 30 Dec 2015 12:51:30 +0100 (CET) Date: Wed, 30 Dec 2015 12:51:30 +0100 From: Guilhem Moulin To: openpgp@ietf.org Message-ID: <20151230115130.GA17604@localhost.localdomain> Mail-Followup-To: openpgp@ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [openpgp] Chunked OpenPGP streams X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 11:51:46 -0000 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi there, It's convenient to use OpenPGP streams to avoid creation of temporary files, as illustrated in the following pipeline: tar -c / | gpg -r $KEYID --sign --encrypt | ssh remote.example.org 'cat= >backup.tar.gpg' (using GnuPG [0] as OpenPGP implementation). Unfortunately, since integrity mechanisms are appended at the very end of the data stream, the same technique cannot be used when decrypting and/or verifying a data stream. For instance gpg --decrypt backup.tar.gpg | tar -C /restore -x could crash the system if an attacker has replaced =E2=80=98backup.tar.gpg= =E2=80=99 with a tar bomb. The problem arises because unverified data is written to the standard output, which is hard to avoid since the hash is computed on the full data stream and is not available until the very end of the stream. I wonder if chunked streams could make their way to RFC4880bis instead. The verification mechanism (MDC or data signature) would be added to each chunk using the intermediate hash value, and a compatible implementation would cache each chunk, update the hash context, and *then* write down the chunk to the output File Descriptor *only* after verifying its integrity. (If there is not enough RAM to cache a chunk one could always fallback to the creation of a temporary file.) AFAICT using intermediate hash values is enough to cryptographically glue the chunks together in an order preserving way. What do you folks think? --=20 Guilhem. [0] https://gnupg.org/ --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWg8VBAAoJENOaSZw8IaVSwzwP/i2Fc+Mck0kmX4K0uoxR9m41 Q7xYh2Ae2brgJhMHTY0wzJoEZ5u3yF69Xd0YZIZeTRMC8KYHOWnINsmkXCVmORw5 9LRGJcqkVB90gDMezbsosIN42K1MDtKcFU3BLMq8CGm7xD1ELj8yAxklvlLODMHj AAsEva96IsI2Iz6+mEx4HNR/G2SdMl0cxHuvlfNQhlHN1Q7sgLZHno0aKyjjvjSX U+e31tskrc9g9uJqnVAysjJcvisYJIoJf4YVSbCUVNrRG0FtqS29iYuU3T/viopR g259hfzCsEttcdmVVIoGw+7LyESXgGTh08HsVz275yuWc4b0KBqOondQJ3FBosXt 0aNXB8PAOTQY/RpPNyVtI2I+tJZ4BG3eyrgtKk1ZXxM75DhUaEy8UYHSilDtYMCu mdNqrhPtl24UxfwTJhKbd8DIDKtQOV/GjsCYXGns/UZhD2m0sh8te2XWlZ6mZFTr XpWE9xlm7qtmngXdzdDjgimgf0/i7lBYEkeDMx5IynabwycCUe/1MtsKOWmaa61D 5dccXMjKJ+g5tE25fLaIE/Jwujgw5F81GIJGfDGCU0T7Ynx5KgXUmBceVHL3VF1R wc23ekeMqyrSkJtvmkEa08lQVlmfvqHcdUOTDHwpafOfNnfBHlDWyEkXkgffndY6 D+b+tkGZE5sjI63CnS3Q =JSAy -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- From nobody Wed Dec 30 05:01:58 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22451A8763 for ; Wed, 30 Dec 2015 05:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asw7eEpCMzY0 for ; Wed, 30 Dec 2015 05:01:51 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A3D1A0021 for ; Wed, 30 Dec 2015 05:01:51 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id u188so38783665wmu.1 for ; Wed, 30 Dec 2015 05:01:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=FYtn5AAJ4+0n1I5YAjGyI5AWR1py2ATMutBQG660oxI=; b=1G62bWxZnHB86CsDYU9i0hnZVtotHggArlsA5JNXRFGzufOk3/SL/SR67/85YfK3bt 16FFrlNldgu0ESN6rUQVwc+t0i6NzSeQOfqMOrs+lW03+ydHpBxjUs4ibw1YB/Vd77FE 7zEACrW2xzdl41ZNjoSVJT9qg/mY54LYY/B/Jy9O40kYRsywYmV0l1w8mqt3rNzkjjPZ rw1VMJIy1YiCY/7oST4qo4uWqtSQc8nXuNG8sAxuXkMBAA3lzaLmSc2uCMMf5MAGwd8m cgKXnr6ZFAzzn3dzZ0WCMtbBOxoPdi/3Omd+ge2bLGSfSwEi//Tvul5PGSUu3bB4+q6n XcNA== X-Received: by 10.194.95.199 with SMTP id dm7mr69757070wjb.15.1451480510110; Wed, 30 Dec 2015 05:01:50 -0800 (PST) Received: from ?IPv6:2001:67c:20a1:1192:9ad:3d4b:fb2:11aa? ([2001:67c:20a1:1192:9ad:3d4b:fb2:11aa]) by smtp.googlemail.com with ESMTPSA id q6sm65458703wjx.28.2015.12.30.05.01.48 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Dec 2015 05:01:49 -0800 (PST) To: openpgp@ietf.org References: <20151230115130.GA17604@localhost.localdomain> From: Nils Durner X-Enigmail-Draft-Status: N1110 Message-ID: <5683D5BA.8050208@googlemail.com> Date: Wed, 30 Dec 2015 14:01:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151230115130.GA17604@localhost.localdomain> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: guilhem@fripost.org Subject: Re: [openpgp] Chunked OpenPGP streams X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 13:01:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, > I wonder if chunked streams could make their way to RFC4880bis instead.= > The verification mechanism (MDC or data signature) would be added to > each chunk using the intermediate hash value, I think this goes in the same direction that OAED or online authenticating cipher modes are being considered for - see the recording of the last IETF meeting at http://recs.conf.meetecho.com/Playout/watch.jsp?recording=3DIETF94_OPENPG= P&chapter=3Dchapter_1 Regarding the potential use of online authenticating cipher modes, it was discussed during that meeting that there is *some* research on modes that *might* be usable with PGP. If anyone can share papers (or references), I would appreciate it. Regards, Nils -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWg9W6AAoJEM2vZ+BQCpt2OL4P/2UZZmwSEfvOTTdIfkq668WH 4UAS7qRYH9R760XYq3RkcRoYu8QbL6A86oafbhChHEzGVFyjyzYJqknQ5PUJW6kF 7wBdOieMF3xeMqw9wSwMsW13B/k2AULVc1HCOEeiHRAm40B1cvALltuYKK2G5Ipz KWBKGfnLzNHe/iL1vrZzecht++U1/DDCT/MpCd9ULZu5zZvc3TAVULQ4poVh3/Hw B/lAeRHZElYOAMIwxnY+5PHwecNqskN3k+R6NWO3+7OkiJrYhxb9YvkOM/qgY5h5 CoBLai0RG9K7T39GYMuMObXEjidyv/rG3XFJGNc/SQTIquRChyyQdm13dOO3z92C VxcsoWdrS30YhHKVnBdySlZNLHXgUW0rLikbki5bz5wSmRLLjy1+bDhze3ikRCN9 rSV5ZrIQxOvIw88/RpwVxaOjgEBaCsq9DWRsqg3o4DCo/5KDkqEpcLmcyhcrSVCK cK+aA+FOjSZ1Z8rz8VfQ2dL0kItKoos7MLtVMjTjdzSMXAWHbnLjlXxAL8P1RqBG diRGRgI0dVnXcW43MPHCnFvFOk4L9T77n7LM2QN0Kbko7aNf2Y/Sp4xKsN1MEfv2 z8ruLYfquDaRVU85iCztwJsxWf0DfRgj14QWgEPngwPpn2cVEXy+5/1lkVC4LNrl 9Ziu77Pw1Ur63GRFq/7d =3DqUMc -----END PGP SIGNATURE----- From nobody Wed Dec 30 06:28:27 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4541A882A for ; Wed, 30 Dec 2015 06:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.312 X-Spam-Level: X-Spam-Status: No, score=-4.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ex7JPvJwyrkY for ; Wed, 30 Dec 2015 06:28:23 -0800 (PST) Received: from outgoing.fripost.org (giraff.fripost.org [178.16.208.44]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E961A8821 for ; Wed, 30 Dec 2015 06:28:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by outgoing.fripost.org (Postfix) with ESMTP id 8790734A71A; Wed, 30 Dec 2015 15:28:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fripost.org; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date; s=20140703; t=1451485701; x=1453300102; bh=+DwIK/IANZ4lOBzgXn2HHo1I7Qub+GNdYDsPwNtr8EA=; b=EO2F66cgS6Uu NgiswyMMJuW1AjVscFgAigQY3jjSpzdSxMtjQUtAxC0W5EWO14rrZoyRBKCAXvyu MgSMpMI3eMIOOH1UwGnhSbcgYaYfnGZ8V2alx6DVtCzsvkZVra4A0Gd+6ZKeWBRh MsFYaFrNVO0Wgiv673xaSb474Mad1Bo= X-Virus-Scanned: Debian amavisd-new at fripost.org Received: from outgoing.fripost.org ([127.0.0.1]) by localhost (giraff.fripost.org [127.0.0.1]) (amavisd-new, port 10040) with LMTP id wj7RT4znTShv; Wed, 30 Dec 2015 15:28:21 +0100 (CET) Received: from smtp.fripost.org (mistral.fripost.org [178.16.208.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mistral.fripost.org", Issuer "mistral.fripost.org" (not verified)) by outgoing.fripost.org (Postfix) with ESMTPS id 36A7A34A715; Wed, 30 Dec 2015 15:28:21 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by smtp.fripost.org (Postfix) with ESMTPSA id C7C5F982EA6; Wed, 30 Dec 2015 15:28:13 +0100 (CET) Received: by localhost.localdomain (Postfix, from userid 1000) id 1B4D2ADA40; Wed, 30 Dec 2015 15:28:12 +0100 (CET) Date: Wed, 30 Dec 2015 15:28:12 +0100 From: Guilhem Moulin To: Nils Durner Message-ID: <20151230142812.GA16011@localhost.localdomain> Mail-Followup-To: Nils Durner , openpgp@ietf.org References: <20151230115130.GA17604@localhost.localdomain> <5683D5BA.8050208@googlemail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline In-Reply-To: <5683D5BA.8050208@googlemail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Chunked OpenPGP streams X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 14:28:26 -0000 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, 30 Dec 2015 at 14:01:46 +0100, Nils Durner wrote: >> I wonder if chunked streams could make their way to RFC4880bis instead. >> The verification mechanism (MDC or data signature) would be added to >> each chunk using the intermediate hash value, >=20 > I think this goes in the same direction that OAED or online > authenticating cipher modes are being considered for - see the recording > of the last IETF meeting at > http://recs.conf.meetecho.com/Playout/watch.jsp?recording=3DIETF94_OPENPG= P&chapter=3Dchapter_1 Thanks for the pointer. I think however that this could be useful for detached sigs, too. For instance assuming a remote tarball, a local detached signature, and an OpenPGP implementation that would copy *verified* data to the output File Descriptor, one could write ssh remote.example.org cat /path/to/backup | gpg --verify /path/to/backup.sig - | tar -x without fear of race condition and without the inconvenience of creating a temporary local file. Cheers, --=20 Guilhem. --J/dobhs11T7y2rNN Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWg+n6AAoJENOaSZw8IaVSih0QAMIoBbFeZZrVBHtx2t0BPlSB 0/nhwDtXx9XJYP7qi/8KJtL0m65haXDYSLtZftRftjv8ml+1R1Wnt+ejyzU/S+LO O24bdmbxZUXqPssTKuSrUpVH3fcj5ujs4Jy7jJSt3QwtRT1JHzFIxhd9EF4tCsMV OCcZjiCFmAlhsUzLCnqmflEyWbG4L4t8ijbN3YqIT/TE47sdiGVQVNeAXdWzGMEn Evh3w9o9jGKdoLyT+8J/lE/owtIZQo2LtCrFd/338wHhDIFhQUDHupum6nPGL43U OIWx6RkqeylsiOXk+Vjqq3/I5QnCsIVyI3iwIbywEfm4b1VYOcTFluygvzVDgS8W UXqoPAEUo29TdYp6VuZVGUcvM9f7i/v3RopCmwBwzUQyj/47M6fG1hE8KEkikeeq rDTDNRQRIKBdCIHwThLlQlHeR4sh3fKI2U+wJZYxGbzGEZhdIcT0Bzh2547M0EUP QuLAf6l7Qhtdr1EOMmvYcXy+UzKZ0zMCICYGiq9uZJQqsVLS6lJ/CZb2pBelSQCX B3+rUG+CHlmzC7IRmDkWGICqFtcqsPi9Sy3o7w06s/ukrHLfYu6T0HH+MKmSBBRC 530U+Glnr6xK7Hx9qiiMz4mJeMyyoOfDz1HxlFzUpFmNLcTeRe49jc9Az0a6A2M3 JaTsnRc6DbAGY6YBdHd1 =l78G -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN--