From nobody Fri Jan 12 02:35:18 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5631267BB for ; Fri, 12 Jan 2018 02:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no 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 AJLghwC5-Dgs for ; Fri, 12 Jan 2018 02:35:15 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20109124E15 for ; Fri, 12 Jan 2018 02:35:14 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1eZwg5-0002Ko-KZ for ; Fri, 12 Jan 2018 11:35:13 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1eZwaM-0000pI-Il; Fri, 12 Jan 2018 11:29:18 +0100 From: Werner Koch To: openpgp@ietf.org cc: brian m. carlson Organisation: The GnuPG Project X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: openpgp@ietf.org, brian m. carlson Date: Fri, 12 Jan 2018 11:29:12 +0100 Message-ID: <87a7xjfk07.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=terrorism_Abu_Ghraib_Israel_White_House_NATO_CNCIS_CDMA_ammunition=l"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] v5 Secret-Key Packet Formats X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 10:35:17 -0000 --=terrorism_Abu_Ghraib_Israel_White_House_NATO_CNCIS_CDMA_ammunition=l Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi! The protection of secret keys usning AEAD has this requirement: If the string-to-key usage octet is 253, the encrypted MPI values are encrypted as one combined plaintext exactly as an AEAD Encrypted Data packet with a chunk size octet of 10 would be. This implicit chunk ^^^^^^^^^^^^^^^^^^^^^^ size octet is included in the normal calculations of additional data. Given chunk_size =3D ((uint64_t)1 << (c + 6)) this works only for keys requiring less than 64 KiByte for the secret parameters. This may not be enough in the future and thus I suggest to increase the default chunk size. A value of 20 would allow for 64 MiByte which should be enough, but 25, resulting in 2^31 would be more logical. However, there is a practical problem using chunks for secret key (and also with Symmetric-Key Encrypted Session Key Packets): we need to run two AEAD encryptions for those commonly short key packets because our description of the AEAD says: After the final chunk, the AEAD algorithm is used to produce a final authentication tag encrypting the empty string. This AEAD instance is given the additional data specified above, plus an eight-octet, big-endian value specifying the total number of plaintext octets encrypted. This allows detection of a truncated ciphertext. This is overhead in the implementation and the specification (question of the default chunk size). I would prefer that we remove the use of the chunked AEAD encryption from Secret-Key and Symmetric-Key Encrypted Session Key Packets. Thus instead of For each chunk, the AEAD construction is given the packet header, version number, cipher algorithm octet, AEAD algorithm octet, chunk size octet, and an eight-octet, big-endian chunk index as additional data. The index of the first chunk is zero. we make use of the parameters already in the Secret-Key Packet: * [Optional] If string-to-key usage octet was 255, 254, or 253, a one- octet symmetric encryption algorithm. * [Optional] If string-to-key usage octet was 253, a one-octet AEAD algorithm. [...] * [Optional] If secret data is encrypted (string-to-key usage octet not zero), an Initial Vector (IV) of the same length as the cipher's block size. The IV already matches our requirement for EAX and for OCB we would set its LSByte to zero. The description of the AEAD mode needs to be changed to explain the chunked and the non-chunked mode. What do you think? Salam-Shalom, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=terrorism_Abu_Ghraib_Israel_White_House_NATO_CNCIS_CDMA_ammunition=l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCWliN+AAKCRD/gK6dHew1 jdCqAQDp8e1bVKzHq8FqGYntiK+e3TW9KPz1+jnasVoaCJn6EAD5ATvRl7EpdDRR ANrjI5t2FCVFcic30YnLoXYrVk/O4As= =RBDF -----END PGP SIGNATURE----- --=terrorism_Abu_Ghraib_Israel_White_House_NATO_CNCIS_CDMA_ammunition=l-- From nobody Fri Jan 12 07:23:10 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C9012E881 for ; Fri, 12 Jan 2018 07:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg 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 JoAaAWdAY8u3 for ; Fri, 12 Jan 2018 07:23:06 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 C811C127775 for ; Fri, 12 Jan 2018 07:23:06 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id q1so9037564qkb.9 for ; Fri, 12 Jan 2018 07:23:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=QKvz2raReYVMvvoGlJGpnvB1X/gmxwJ4gLo7TwxTVAE=; b=yTY+NkMmx7BqPfsUyqX1jyUZ1jHX47Z8WnYSxB523P+m3rjEaHBMA6mGtYzcdRZWN+ x1dVGv1CRfHn73T/LFY93c/nN2uNnc9D8J0nuI9e9U4pmhbtXSkSlcgzG5HKuljoQtwE 2aXcvjD2av3rDb8j40AKad/O1ImZLDUB4J3fI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=QKvz2raReYVMvvoGlJGpnvB1X/gmxwJ4gLo7TwxTVAE=; b=nNXJ/GWRF8+EwQ1n40TO3QhOpBaC24wuL1J8G0I+UMxWnKTSJywCV7846emzBmyhGS X5INE9UCaELCDQPJwFgJcivG3vfK9bWADjxD+BUr9x5j+DoYWqlmTUyZB/eySmlCIS9g w7hn99FOUm1zy6WVg0oUr/V0nVsIF5vCqrn4uCSw7IcQ0duNbc2Wb1o1tztIEkLRWgPn iB4gUyPWev9/vIvMdHHC5BjWBocDlE7tFa3SZqCo9ih1A2vqA4exaayduaTNOmbJ2MuQ rR5PFJBvUg6yAvL494zOkb58xGFi2URAFDmN3kUpQZ++DRThGeK6OzL2wBTJ8BAs6/us Xupg== X-Gm-Message-State: AKwxytfLA0KLn/ZKPTqcKAmH2T3hH+64RZx4tV5kBVEI8Cgb7RYPzGQu JzIJruJrZkGipOveK23eWqXWzlxqvogcZYPWYmuGCufL X-Google-Smtp-Source: ACJfBos+daL6UrFA2EGoUrb1zZ4eHstuDzR3QtB2JXU8XmnxGEzehGQXlp6lzM4kF/+6cOssARs1rcfgP2G7YAPFuFg= X-Received: by 10.55.214.75 with SMTP id t72mr38757246qki.12.1515770585449; Fri, 12 Jan 2018 07:23:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.27.242 with HTTP; Fri, 12 Jan 2018 07:22:44 -0800 (PST) In-Reply-To: <87a7xjfk07.fsf@wheatstone.g10code.de> References: <87a7xjfk07.fsf@wheatstone.g10code.de> From: Tom Ritter Date: Fri, 12 Jan 2018 09:22:44 -0600 Message-ID: To: IETF OpenPGP , "brian m. carlson" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [openpgp] v5 Secret-Key Packet Formats X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 15:23:08 -0000 On 12 January 2018 at 04:29, Werner Koch wrote: > What do you think? Would this be adding a new mode that would have to be implemented? That is in addition to adding chunked AEAD we're now also adding non-chunked AEAD? -tom From nobody Fri Jan 12 08:30:20 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3837A12D943 for ; Fri, 12 Jan 2018 08:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no 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 idPtA2EBmV33 for ; Fri, 12 Jan 2018 08:30:16 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 070DC12420B for ; Fri, 12 Jan 2018 08:30:16 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1ea2De-0004pr-VN for ; Fri, 12 Jan 2018 17:30:14 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ea26V-0002Xk-0w; Fri, 12 Jan 2018 17:22:51 +0100 From: Werner Koch To: Tom Ritter Cc: IETF OpenPGP , "brian m. carlson" In-Reply-To: (Tom Ritter's message of "Fri, 12 Jan 2018 09:22:44 -0600") References: <87a7xjfk07.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) Organisation: The GnuPG Project X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Tom Ritter , IETF OpenPGP , "brian m. carlson" Date: Fri, 12 Jan 2018 17:22:45 +0100 Message-ID: <87y3l3dp2i.fsf@wheatstone.g10code.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Comirex_EuroFed_INS_Centro_Aladdin_crypto_anarchy_Bush_Wired_Mossad="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] v5 Secret-Key Packet Formats X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 16:30:18 -0000 --=Comirex_EuroFed_INS_Centro_Aladdin_crypto_anarchy_Bush_Wired_Mossad= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 12 Jan 2018 16:22, tom@ritter.vg said: > Would this be adding a new mode that would have to be implemented? > That is in addition to adding chunked AEAD we're now also adding > non-chunked AEAD? No. Like the current CFB mode, AEAD will be used at 3 places: 1. Bulk data encryption 2. Encryption used by the secret-key session key packet (which makes it possible to encrypt to several passphrases) 3. Encryption of the secret key. My claim is that the chunked mode is only used for 1. For 2 and 3 we can avoid any chunked mode and thus do not need to assume a certain chunk size. Sure, we could also keep on using CFB for 2 and 3 but that would require a minimalist implementation to implement CFB and AEAD(EAX). Shalom-Salam, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Comirex_EuroFed_INS_Centro_Aladdin_crypto_anarchy_Bush_Wired_Mossad= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCWljg1QAKCRD/gK6dHew1 jenoAP9Oj8bgfuPPQux48jQjjhB/MX5YWRiN4CDU8uZT+EQWHAD+NWjgVp4fwJii BOApjsgA97kklRoW3O+2DdLV7s4Iowc= =QcjL -----END PGP SIGNATURE----- --=Comirex_EuroFed_INS_Centro_Aladdin_crypto_anarchy_Bush_Wired_Mossad=-- From nobody Fri Jan 12 16:38:40 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7CE1241FC for ; Fri, 12 Jan 2018 16:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (3072-bit key) header.d=crustytoothpaste.net 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 c2Mrgn_FEJGN for ; Fri, 12 Jan 2018 16:38:36 -0800 (PST) Received: from injection.crustytoothpaste.net (injection.crustytoothpaste.net [192.241.140.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C74E1200C5 for ; Fri, 12 Jan 2018 16:38:35 -0800 (PST) Received: from genre.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:e6b3:18ff:fe98:41a3]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id D21D56045C; Sat, 13 Jan 2018 00:38:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1515803883; bh=kImGJSsLfrH3+M1HbNk2BILxr7wokyPD1ExF0xqo5dA=; h=Date:From:To:Subject:References:Content-Type:Content-Disposition: In-Reply-To:From:Reply-To:Subject:Date:To:CC:Resent-Date: Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=JfJ3kD3jSqF2z4yV5Xt26fJcgALWbyn2Lr24AMTCVXmVaJnqQuOF0uoXYYoUvI7o+ GQlvowQx7F4ABdD/erQA3MAcrWaeyvCSqzFm77M7b1P7lXeN5OHk3G8jifvoeb7XVe iojvnlmYzerQEubJWq2ccBLo8kAvD0IRUGRTrgcE2Q49ovo7E5amrofn83aMEyBNHX vYwh3WjKIUnHedtJWGNWnhxVthI+Xf2QHCC4y0Ao7vpnD2QnVJ7P/5BxAJPtUkIBn8 zbiH4kUPkSLo/K0DC69nZvtCXT3eMkYHAo4EyAa9DxtO/cNqQetdlfNprl+J4NJbuQ z+RqlTyKacawFO1QZ7PSIjNX35/Lx8qTZkYYw6n6nGM2nuQb1Qmlq+qOI/aa2vygDw xPtsBx2GBzv5crOC0Z4hUSlZ1xl1C6tRonJBnr1kTNj+W5wP9lKk9Jwdwax3WdB6tx DcF78GvvgV1qR0aKSWVg6gXVMzErhKIMAQF3cTt8t6iA1O/3OD9 Date: Sat, 13 Jan 2018 00:37:57 +0000 From: "brian m. carlson" To: Tom Ritter , IETF OpenPGP Message-ID: <20180113003757.GD5946@genre.crustytoothpaste.net> References: <87a7xjfk07.fsf@wheatstone.g10code.de> <87y3l3dp2i.fsf@wheatstone.g10code.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qGV0fN9tzfkG3CxV" Content-Disposition: inline In-Reply-To: <87y3l3dp2i.fsf@wheatstone.g10code.de> X-Machine: Running on genre using GNU/Linux on x86_64 (Linux kernel 4.9.0-5-amd64) User-Agent: Mutt/1.9.2 (2017-12-15) X-Scanned-By: MIMEDefang 2.79 on 127.0.1.1 Archived-At: Subject: Re: [openpgp] v5 Secret-Key Packet Formats X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 00:38:39 -0000 --qGV0fN9tzfkG3CxV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 12, 2018 at 05:22:45PM +0100, Werner Koch wrote: > On Fri, 12 Jan 2018 16:22, tom@ritter.vg said: >=20 > > Would this be adding a new mode that would have to be implemented? > > That is in addition to adding chunked AEAD we're now also adding > > non-chunked AEAD? >=20 > No. Like the current CFB mode, AEAD will be used at 3 places: >=20 > 1. Bulk data encryption >=20 > 2. Encryption used by the secret-key session key packet (which makes it > possible to encrypt to several passphrases) >=20 > 3. Encryption of the secret key. >=20 > My claim is that the chunked mode is only used for 1. For 2 and 3 we > can avoid any chunked mode and thus do not need to assume a certain > chunk size. >=20 > Sure, we could also keep on using CFB for 2 and 3 but that would require > a minimalist implementation to implement CFB and AEAD(EAX). I don't have a strong preference between non-chunked or chunked, although I do quite want to avoid relying on CFB for the future. I wrote it the way I did for a couple of reasons: * We have various uses of CFB throughout the document, some using an all-zero IV and random prefix and some using a real IV. I wanted to provide one consistent technique for encrypting to reduce complexity. * The chunk size was large enough to cover most current keys, and it could be arbitrarily extended (using multiple chunks) to any future keys. * The chunk size was small enough to be practical for low-resource devices without having to release ciphertext before tag verification, even if we have large keys. (I know the non-chunked nature of the MDC packet has had DoS implications in GnuPG in the past.) * The extra block at the end is required to avoid truncation attacks in chunked mode, and the cost of 16 bytes in the secret key packets didn't seem like a huge cost given the other constraints. This is just a rationale, and if implementers or other folks think a non-chunked approach for key material is better, I'm happy to go along. --=20 brian m. carlson / brian with sandals: Houston, Texas, US https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204 --qGV0fN9tzfkG3CxV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.4 (GNU/Linux) iQIzBAABCgAdFiEEX8OngXdrJt+H9ww3v1NdgR9S9osFAlpZVOUACgkQv1NdgR9S 9ov6ig//ZnsNTybSBantbtV9bASAKKsR9YVyovy7r54m4MDSKJwtvFIbAursgGqx SlCPArZ7A8WlrMo6iiTPs8ZbVmjMNeGOy7Bjs91QNIiVArNxJV4LTrHUHSfjQXzI r/NhY3znnh5lSRw/9hbO053lKytP3MNEeLjz2GRdrCVzxqqLpV+MdQYK4OBcTBnN SmVEetslxLd5wKLzWFRAIOjS/hmlGOH7cPkEyypUrnpSAiEuWwon/IGEHky+o3c8 olHvPH/sY7gJyodEBcIdqIMtXBdUm2Sx0163tTaIVQlKi3jnNEEFQ1gNjiFs0tNv CtkXP6rfxIIu452r4j+a+fzlSiO1eyN30NCjURS6/3GZ+8LUekFpXvDdEmqa6QRg pM9b/CtM8tL9fBQgt3E22zJe9nXh9szDwdWxpXFnt7wdjVQiMqLZ9pY3TGP4lAoj fn+U43fSSi62b5a3dSS0/3bcYTtIdqtXDjF7qu1iaulpmrz6KxtXcvJIKOhx2aKf 0pB1NdLEWDbWxNWeCkH4QKck+uu3B8edsuNNqAnjMvzL6rLKb4ukkr0pKU0WttZF KmXO2tnAobWYbr25vdoug/KXpamyn++ij7lRDVvEhozHcHBLslHIKuu3ERwHj2vb x5Ti8UCRlBM5MjSYcIYFtgIl/e7KukhFF7KvLzKXnBP64PCOklw= =XEO0 -----END PGP SIGNATURE----- --qGV0fN9tzfkG3CxV-- From nobody Thu Jan 18 01:50:42 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E19312EB0F for ; Thu, 18 Jan 2018 01:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no 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 HMOWe-SHyLUA for ; Thu, 18 Jan 2018 01:50:30 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 815E012EB2A for ; Thu, 18 Jan 2018 01:50:24 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1ec6py-00049a-I1 for ; Thu, 18 Jan 2018 10:50:22 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ec6hl-0000cn-Di; Thu, 18 Jan 2018 10:41:53 +0100 From: Werner Koch To: "brian m. carlson" Cc: Tom Ritter , IETF OpenPGP References: <87a7xjfk07.fsf@wheatstone.g10code.de> <87y3l3dp2i.fsf@wheatstone.g10code.de> <20180113003757.GD5946@genre.crustytoothpaste.net> Organisation: The GnuPG Project X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: "brian m. carlson" , Tom Ritter , IETF OpenPGP Date: Thu, 18 Jan 2018 10:41:47 +0100 In-Reply-To: <20180113003757.GD5946@genre.crustytoothpaste.net> (brian m. carlson's message of "Sat, 13 Jan 2018 00:37:57 +0000") Message-ID: <87r2qn8pwk.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Cohiba_target_UFO_crypto_anarchy_Qaddafi_Yukon_number_key_militia_M-"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] v5 Secret-Key Packet Formats X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 09:50:36 -0000 --=Cohiba_target_UFO_crypto_anarchy_Qaddafi_Yukon_number_key_militia_M- Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello! On Sat, 13 Jan 2018 01:37, sandals@crustytoothpaste.net said: > I don't have a strong preference between non-chunked or chunked, > although I do quite want to avoid relying on CFB for the future. I fully agree. > * We have various uses of CFB throughout the document, some using an > all-zero IV and random prefix and some using a real IV. I wanted to > provide one consistent technique for encrypting to reduce complexity. I understand this. I am right now implementing this and figured a couple of minor problems. See below. > * The chunk size was large enough to cover most current keys, and it > could be arbitrarily extended (using multiple chunks) to any future > keys. Okay. But that makes simple processing of secret key material more complicated than needed. I can imagine application which do not implement encryption but want to handle protected secret keys. A non-chunked AEAD encryption makes this much easier. > * The extra block at the end is required to avoid truncation attacks in > chunked mode, and the cost of 16 bytes in the secret key packets > didn't seem like a huge cost given the other constraints. This is not a problem for bulk encryption , but blows up secret ECC keys protecion. But that is really minor. > This is just a rationale, and if implementers or other folks think a > non-chunked approach for key material is better, I'm happy to go along. I have not seen other comments but let me prepare a patch to use non-chunked AEAD for non-bulk data. What I noticed in the AEAD mode: 1. There is a problem including the entire packet header in the additional data: When using partial length encoding we would need to use the first partial length here. gpg uses a a pipeline of functions as data structure. Thus the encryption layer does not know how the next function down the line will block the data to emit the partial length encoding. Sure this can be hacked around but it would be ugly. Thus I propose this change: =2D-8<---------------cut here---------------start------------->8--- =2DFor each chunk, the AEAD construction is given the packet header, =2Dversion number, cipher algorithm octet, AEAD algorithm octet, chunk size =2Doctet, and an eight-octet, big-endian chunk index as additional =2Ddata. The index of the first chunk is zero. +For each chunk, the AEAD construction is given the Packet Tag, version +number, cipher algorithm octet, AEAD algorithm octet, chunk size +octet, and an eight-octet, big-endian chunk index as additional data. +The index of the first chunk is zero. Note that the Packet Tag has +the value 0xd4 and that the length octets are not included because +they may vary in case of a partial body length. =2D-8<---------------cut here---------------end--------------->8--- 2. The above immediately raises the question why we need the Packet Tag at all. After all it will be a constant (the AEAD packet requires a new style CTB and thus there is only one encoding). I assume you did this to prepare against a future rollback attack in case we ever introduce a new style AEAD encryption. But then, why do we have the version number as first item in the AEAD packet? It can serve the same purpose. Or is this to distinguish between AEAD used for bulk encryption and secret key encryption? What packet tag would we use for the latter (with old-style CTB we can have several encodings)? Shouldn't we either drop the packet header from the additional data or can we define fixed values depending on the use like: 0xd4 :=3D AEAD Encrypted Data Packet (tag 20) 0xc3 :=3D SKESK (Symmetric-Key Encrypted Session Key Packet, tag 3) 0xc5 :=3D Secret-Key Packet (tag 5) and Secret-Subkey Packet (tag 7) 3. The AEAD Encrypted Data Packet specifies the cipher algorithm to use. The old encryption modes had no way to specify the algorithm. Instead they take the algorithm either from the SKESK or the PKESK (Public-Key Encryption Session Key Packet, tag 1). For simple encryption without even an SKESK it is implementation defined how to get the algorithm. I like that algorithm id in the AEAD packet. But should we specify what to do on a conflict and whether it is allowed that the SKESK uses a different algorithm than that in the AEAD packet? I currently print a warning and continue but I am not sure whether this is really needed. The potential for a conflict has always been in OpenPGP: A faulty implementation may encrypt to several keys giving different algorithms in each PKESK and thus not all recipients would be able to decrypt the message. I am not ware of such bug, though. Shalom-Salam, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Cohiba_target_UFO_crypto_anarchy_Qaddafi_Yukon_number_key_militia_M- Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCWmBr2wAKCRD/gK6dHew1 jb9IAQCO/qsYsDllC8PdYhbcxVH8SsBJFf0LLwzN+1Vjecw1/QEA+NtYBTAqu5CG vEQ3YgVm/SuNr1LnmVjKdq4BCDGr9wY= =/5fZ -----END PGP SIGNATURE----- --=Cohiba_target_UFO_crypto_anarchy_Qaddafi_Yukon_number_key_militia_M--- From nobody Thu Jan 18 03:38:54 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E231E12D871 for ; Thu, 18 Jan 2018 03:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EfLj3UHIBZeh for ; Thu, 18 Jan 2018 03:38:51 -0800 (PST) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (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 AA8A712D80F for ; Thu, 18 Jan 2018 03:38:50 -0800 (PST) Received: by mail-wr0-x22d.google.com with SMTP id f11so11711297wre.4 for ; Thu, 18 Jan 2018 03:38:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:mime-version:subject:date:references:to:in-reply-to :message-id; bh=j48sBDWwBFW4I/C7veULWc9FXeW7rLL+sZunCiaFjD8=; b=KAr4oqOqs+Suqklarw7HOM0Lw14VrtpAxRwwvDXL+m7hRYBvwk+My3dFy4Xn2ByU0H QM6Gba828cqrPls2HMGNe0u6c9q6qWTJt+YYRzV8Berj1Lr02OEnqFRpCvNoaa5diaoo W4zMCEicrp65T56a8tWHruVstgV+ugDuzZ8CLJqxWthPsMwhIDHQfHhVm6VCfnRFlErI adkAE8pnlmQPLpI3gjjAW6mpn/5vgFuHYOsr5wADepl1GpgpgHcBcnMNfLxF2tw65DaR Tz3kAdsLYoeZW6pMYoT231g/dSCh+fylcmfiLVkMQl5L6LwuQXrutTNIh231PrdhUkU8 eVbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:mime-version:subject:date:references :to:in-reply-to:message-id; bh=j48sBDWwBFW4I/C7veULWc9FXeW7rLL+sZunCiaFjD8=; b=FQPIz5wWLX/J2cHIWl9eCAVZLvz5c8B7wpq6We1cPLMNyEWGbne9QKu7ng+SUrccQ6 RNf7Zbo3gAxxW3dC0RhWAlz41nLT0pXpe7Msr8rG2KOW7lodzQm77UCib7LABn6Zt/t1 CVZjxUdzuBAB3sSN4l9RBHI2fkXgGuJmRYXoNcgdyDqiS67UneuDH2ie845IUInb/JyJ ywA+uSDGp1qBE/D98C12kEGgPlYNZuFltgeoYDHLEK5KdQSho1TV7/KNrwiOejOD/myJ g/C2yTnSPhLUELOUhiCRlBZ6D1MBkslECOWdrv1lt5pHMqANzMwii6C5R7EvbFThSHK2 /kOw== X-Gm-Message-State: AKwxytfGIY7rbaWUD4JLf9ywcOxfplqhjd46Fhy8elUrQN9H9LAvdMfv GGh4rOaPxsp424JbJ7TbLMKhPKih X-Google-Smtp-Source: ACJfBovmHYSX8K5Ba/exSnVPf12oQl1fizbHjFvTmKg8a4Hb/GAnhEUXQaDjbLhwCz1vTUH6QICPfQ== X-Received: by 10.223.134.242 with SMTP id 47mr6172080wry.227.1516275528835; Thu, 18 Jan 2018 03:38:48 -0800 (PST) Received: from [192.168.1.5] ([134.17.162.77]) by smtp.gmail.com with ESMTPSA id p32sm11068805wrc.9.2018.01.18.03.38.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jan 2018 03:38:47 -0800 (PST) Sender: Nickolay Olshevsky From: Nickolay Olshevsky Content-Type: multipart/alternative; boundary="Apple-Mail=_E6472E7F-9CFF-4BEB-9426-F03DE823820F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 18 Jan 2018 14:38:43 +0300 References: <87a7xjfk07.fsf@wheatstone.g10code.de> <87y3l3dp2i.fsf@wheatstone.g10code.de> <20180113003757.GD5946@genre.crustytoothpaste.net> <87r2qn8pwk.fsf@wheatstone.g10code.de> To: IETF OpenPGP In-Reply-To: <87r2qn8pwk.fsf@wheatstone.g10code.de> Message-Id: <488ABDFC-DDC8-4D43-A475-3E7CBC79B9ED@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [openpgp] v5 Secret-Key Packet Formats X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 11:38:53 -0000 --Apple-Mail=_E6472E7F-9CFF-4BEB-9426-F03DE823820F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello! > On Jan 18, 2018, at 12:41, Werner Koch wrote: >=20 > I have not seen other comments but let me prepare a patch to use > non-chunked AEAD for non-bulk data. >=20 > What I noticed in the AEAD mode: >=20 > 1. There is a problem including the entire packet header in the > additional data: When using partial length encoding we would need to > use the first partial length here. gpg uses a a pipeline of > functions as data structure. Thus the encryption layer does not = know > how the next function down the line will block the data to emit the > partial length encoding. Sure this can be hacked around but it = would > be ugly. Thus I propose this change: Would like to add that I got the same problem that you described during = implementation of the AEAD. With partial packet lengths you=E2=80=99d need to cache first partial = chunk on the encryption layer to set the additional data. It can be worked around but removing packet=E2=80=99s length from ad = will make things easier without loosing any security properties. So agree with the proposed changes. > 2. The above immediately raises the question why we need the Packet = Tag > at all. After all it will be a constant (the AEAD packet requires a > new style CTB and thus there is only one encoding). I assume you = did > this to prepare against a future rollback attack in case we ever > introduce a new style AEAD encryption. But then, why do we have the > version number as first item in the AEAD packet? It can serve the > same purpose. Or is this to distinguish between AEAD used for bulk > encryption and secret key encryption? What packet tag would we use > for the latter (with old-style CTB we can have several encodings)? >=20 > Shouldn't we either drop the packet header from the additional data > or can we define fixed values depending on the use like: >=20 > 0xd4 :=3D AEAD Encrypted Data Packet (tag 20) > 0xc3 :=3D SKESK (Symmetric-Key Encrypted Session Key Packet, tag = 3) > 0xc5 :=3D Secret-Key Packet (tag 5) and Secret-Subkey Packet (tag = 7) Also agree - this will make things more clear. And should not make an = impact on the security as well. > 3. The AEAD Encrypted Data Packet specifies the cipher algorithm to = use. > The old encryption modes had no way to specify the algorithm. > Instead they take the algorithm either from the SKESK or the PKESK > (Public-Key Encryption Session Key Packet, tag 1). For simple > encryption without even an SKESK it is implementation defined how to > get the algorithm. >=20 > I like that algorithm id in the AEAD packet. But should we specify > what to do on a conflict and whether it is allowed that the SKESK > uses a different algorithm than that in the AEAD packet? I = currently > print a warning and continue but I am not sure whether this is = really > needed. The potential for a conflict has always been in OpenPGP: A > faulty implementation may encrypt to several keys giving different > algorithms in each PKESK and thus not all recipients would be able = to > decrypt the message. I am not ware of such bug, though. Yep, some statement like =E2=80=98symmetric algorithm in previous v4 = SKESK/v3 PKESK packets should be ignored for AEAD packet=E2=80=99 will = make things more clear. However, should it be allowed to use v4 SKESK with AEAD encrypted data = packet? Best regards, Nickolay Olshevsky o.nickolay@gmail.com --Apple-Mail=_E6472E7F-9CFF-4BEB-9426-F03DE823820F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello!


On Jan 18, 2018, at 12:41, Werner Koch <wk@gnupg.org> = wrote:

I have not = seen other comments but let me prepare a patch to use
non-chunked AEAD for non-bulk data.

What I noticed in the AEAD mode:

1. There is a problem including the entire packet header in = the
  additional data: When using partial = length encoding we would need to
  use the = first partial length here.  gpg uses a a pipeline of
=   functions as data structure.  Thus the encryption layer = does not know
  how the next function down the = line will block the data to emit the
  partial = length encoding.  Sure this can be hacked around but it would
  be ugly.  Thus I propose this change:

Would like to add that I got the same problem that you = described during implementation of the AEAD.
With = partial packet lengths you=E2=80=99d need to cache first partial chunk = on the encryption layer to set the additional data.
It can be worked around but removing packet=E2=80=99s length = from ad will make things easier without loosing any security = properties.
So agree with the proposed = changes.

2. The above immediately = raises the question why we need the Packet Tag
=   at all.  After all it will be a constant (the AEAD = packet requires a
  new style CTB and thus = there is only one encoding).  I assume you did
=   this to prepare against a future rollback attack in case we = ever
  introduce a new style AEAD encryption. =  But then, why do we have the
  version = number as first item in the AEAD packet?  It can serve the
  same purpose.  Or is this to distinguish = between AEAD used for bulk
  encryption and = secret key encryption?  What packet tag would we use
=   for the latter (with old-style CTB we can have several = encodings)?

  Shouldn't we = either drop the packet header from the additional data
=   or can we define fixed values depending on the use like:

    0xd4 :=3D AEAD = Encrypted Data Packet  (tag 20)
=     0xc3 :=3D SKESK (Symmetric-Key Encrypted Session = Key Packet, tag 3)
    0xc5 :=3D = Secret-Key Packet (tag 5) and Secret-Subkey Packet (tag 7)

Also = agree - this will make things more clear. And should not make an impact = on the security as well.

3. The AEAD Encrypted Data = Packet specifies the cipher algorithm to use.
=   The old encryption modes had no way to specify the = algorithm.
  Instead they take the algorithm = either from the SKESK or the PKESK
=   (Public-Key Encryption Session Key Packet, tag 1).  For = simple
  encryption without even an SKESK it is = implementation defined how to
  get the = algorithm.

  I like that = algorithm id in the AEAD packet.  But should we specify
  what to do on a conflict and whether it is = allowed that the SKESK
  uses a different = algorithm than that in the AEAD packet?  I currently
=   print a warning and continue but I am not sure whether this = is really
  needed.  The potential for a = conflict has always been in OpenPGP: A
  faulty = implementation may encrypt to several keys giving different
=   algorithms in each PKESK and thus not all recipients would = be able to
  decrypt the message.  I am = not ware of such bug, though.

Yep, = some statement like =E2=80=98symmetric algorithm in previous v4 SKESK/v3 = PKESK packets should be ignored for AEAD packet=E2=80=99 will make = things more clear.
However, should it be allowed to use v4 = SKESK with AEAD encrypted data packet?


Best = regards,
Nickolay Olshevsky


= --Apple-Mail=_E6472E7F-9CFF-4BEB-9426-F03DE823820F-- From nobody Thu Jan 18 05:25:40 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8071B12700F for ; Thu, 18 Jan 2018 05:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no 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 HBvBphR2seFp for ; Thu, 18 Jan 2018 05:25:23 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC2D7126CE8 for ; Thu, 18 Jan 2018 05:25:23 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1ecAC2-0005kp-PS for ; Thu, 18 Jan 2018 14:25:22 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ecA2B-0002Ip-Me; Thu, 18 Jan 2018 14:15:11 +0100 From: Werner Koch To: Nickolay Olshevsky Cc: IETF OpenPGP References: <87a7xjfk07.fsf@wheatstone.g10code.de> <87y3l3dp2i.fsf@wheatstone.g10code.de> <20180113003757.GD5946@genre.crustytoothpaste.net> <87r2qn8pwk.fsf@wheatstone.g10code.de> <488ABDFC-DDC8-4D43-A475-3E7CBC79B9ED@gmail.com> Organisation: The GnuPG Project X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Nickolay Olshevsky , IETF OpenPGP Date: Thu, 18 Jan 2018 14:15:04 +0100 In-Reply-To: <488ABDFC-DDC8-4D43-A475-3E7CBC79B9ED@gmail.com> (Nickolay Olshevsky's message of "Thu, 18 Jan 2018 14:38:43 +0300") Message-ID: <87bmhr8g13.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Fortezza_Geraldton_passwd_illuminati_Adriatic_.400_million_in_gold=b"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] v5 Secret-Key Packet Formats X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 13:25:39 -0000 --=Fortezza_Geraldton_passwd_illuminati_Adriatic_.400_million_in_gold=b Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, 18 Jan 2018 12:38, o.nickolay@gmail.com said: > Yep, some statement like =E2=80=98symmetric algorithm in previous v4 SKES= K/v3 PKESK packets should be ignored for AEAD packet=E2=80=99 will make thi= ngs more clear. > However, should it be allowed to use v4 SKESK with AEAD encrypted data pa= cket? It won't harm but it is useless to allow this because implementations supporting AEAD should not have any problem to support a v5 SKESK. The only reason I can imagine that this is useful is to allow re-encryption of existing data to an existing session key. For example to move from CFB to AEAD. So a SHOULD use v5 SKESK would be appropriate. Shalom-Salam, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Fortezza_Geraldton_passwd_illuminati_Adriatic_.400_million_in_gold=b Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCWmCd2AAKCRD/gK6dHew1 jWwhAP9QAHnDfEhuGO06er/H4rvf/RVtd02fpdGRG83QidpT2gEAspgH4uf/2pOo Zo7g1oVx+M0SmY+AcFG+PYIAZ7OwrwM= =7orx -----END PGP SIGNATURE----- --=Fortezza_Geraldton_passwd_illuminati_Adriatic_.400_million_in_gold=b-- From nobody Fri Jan 19 15:08:32 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC28212D876 for ; Fri, 19 Jan 2018 15:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (3072-bit key) header.d=crustytoothpaste.net 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 hYKJRmoe29zz for ; Fri, 19 Jan 2018 15:08:28 -0800 (PST) Received: from injection.crustytoothpaste.net (injection.crustytoothpaste.net [192.241.140.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B82F126C19 for ; Fri, 19 Jan 2018 15:08:28 -0800 (PST) Received: from genre.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:e6b3:18ff:fe98:41a3]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 533486052F; Fri, 19 Jan 2018 23:08:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1516403306; bh=HPzghJVIdpwGy1JcpEa+frPZa3uwXzkuw+OyVtFS18w=; h=Date:From:To:Cc:Subject:References:Content-Type: Content-Disposition:In-Reply-To:From:Reply-To:Subject:Date:To:CC: Resent-Date:Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=TwpX9e8+6mn9pq6DcQLOsvzA6djdVnrxEjDlNLto40iKNlsjavod0WU6GZO3UGdC8 7jmBp5ljW8C0gvLNBNlFzA7u7dZh/ZfGyVNZ0eLgVp2GacOQ4vRCQODAT3RVU6N/7i PTx/QHAazL6nTpgajo2Y1OxAic3LB1o9SZ4TuzEpkQvkm/P3ouwQ3ioXbG/mHJ7krZ t2xzHWhwWfKazNTnKSMuPNpSr0uj4iKbzq8gQHb7WPskK7vk+lIiAZaFTChGL1ulQt DvdZOUsvkdK9ihCV51xEsq2g5P91xItm2z1XiSU7jACEinKjcSySVufTaxD2Scyelt plq3/2NebsaTi6Uyj1b+uG1v+lR9ZgspE7hJ8EnlR5INDCnGzraMWjrn7tEQlPy/m2 GdJ25Fp+RaWzthuCPRmeS5K+VRBM4Lf1Dsh3GnYBtSYAVl/bdZWIJZeysoidsgHfa0 jxCZTI441P5XBAJ5my84tuB6G76ydYpnHdaBpbOdJd0cJciSGpB Date: Fri, 19 Jan 2018 23:08:21 +0000 From: "brian m. carlson" To: openpgp@ietf.org Cc: Tom Ritter Message-ID: <20180119230821.GD222163@genre.crustytoothpaste.net> References: <87a7xjfk07.fsf@wheatstone.g10code.de> <87y3l3dp2i.fsf@wheatstone.g10code.de> <20180113003757.GD5946@genre.crustytoothpaste.net> <87r2qn8pwk.fsf@wheatstone.g10code.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AkbCVLjbJ9qUtAXD" Content-Disposition: inline In-Reply-To: <87r2qn8pwk.fsf@wheatstone.g10code.de> X-Machine: Running on genre using GNU/Linux on x86_64 (Linux kernel 4.14.0-3-amd64) User-Agent: Mutt/1.9.2 (2017-12-15) X-Scanned-By: MIMEDefang 2.79 on 127.0.1.1 Archived-At: Subject: Re: [openpgp] v5 Secret-Key Packet Formats X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 23:08:31 -0000 --AkbCVLjbJ9qUtAXD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 18, 2018 at 10:41:47AM +0100, Werner Koch wrote: > 1. There is a problem including the entire packet header in the > additional data: When using partial length encoding we would need to > use the first partial length here. gpg uses a a pipeline of > functions as data structure. Thus the encryption layer does not know > how the next function down the line will block the data to emit the > partial length encoding. Sure this can be hacked around but it would > be ugly. Thus I propose this change: >=20 > --8<---------------cut here---------------start------------->8--- > -For each chunk, the AEAD construction is given the packet header, > -version number, cipher algorithm octet, AEAD algorithm octet, chunk size > -octet, and an eight-octet, big-endian chunk index as additional > -data. The index of the first chunk is zero. > +For each chunk, the AEAD construction is given the Packet Tag, version > +number, cipher algorithm octet, AEAD algorithm octet, chunk size > +octet, and an eight-octet, big-endian chunk index as additional data. > +The index of the first chunk is zero. Note that the Packet Tag has > +the value 0xd4 and that the length octets are not included because > +they may vary in case of a partial body length. > --8<---------------cut here---------------end--------------->8--- That should be fine. We detect truncation elsewhere anyway. > 2. The above immediately raises the question why we need the Packet Tag > at all. After all it will be a constant (the AEAD packet requires a > new style CTB and thus there is only one encoding). I assume you did > this to prepare against a future rollback attack in case we ever > introduce a new style AEAD encryption. But then, why do we have the > version number as first item in the AEAD packet? It can serve the > same purpose. Or is this to distinguish between AEAD used for bulk > encryption and secret key encryption? What packet tag would we use > for the latter (with old-style CTB we can have several encodings)? >=20 > Shouldn't we either drop the packet header from the additional data > or can we define fixed values depending on the use like: >=20 > 0xd4 :=3D AEAD Encrypted Data Packet (tag 20) > 0xc3 :=3D SKESK (Symmetric-Key Encrypted Session Key Packet, tag 3) > 0xc5 :=3D Secret-Key Packet (tag 5) and Secret-Subkey Packet (tag 7) It's a good idea to use domain separation to ensure that packets can't be copied and pasted between packet types. It prevents cases where someone accidentally creates a decryption oracle and reuses keys or passphrases. The packet tag should be enough for this, since the authentication tag will flag the failure immediately if it changes. I tried to model the AEAD authenticated data after TLS, since that has generally been a successful model that's been resistant to attacks involving the MAC. The TLS model is "authenticate the entire packet". > 3. The AEAD Encrypted Data Packet specifies the cipher algorithm to use. > The old encryption modes had no way to specify the algorithm. > Instead they take the algorithm either from the SKESK or the PKESK > (Public-Key Encryption Session Key Packet, tag 1). For simple > encryption without even an SKESK it is implementation defined how to > get the algorithm. >=20 > I like that algorithm id in the AEAD packet. But should we specify > what to do on a conflict and whether it is allowed that the SKESK > uses a different algorithm than that in the AEAD packet? I currently > print a warning and continue but I am not sure whether this is really > needed. The potential for a conflict has always been in OpenPGP: A > faulty implementation may encrypt to several keys giving different > algorithms in each PKESK and thus not all recipients would be able to > decrypt the message. I am not ware of such bug, though. I would just say a hard error is the right thing to do. Clearly if there's disagreement, we can't be sure what the sender intended. It would be better to fail than produce a bunch of junk data. --=20 brian m. carlson / brian with sandals: Houston, Texas, US https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204 --AkbCVLjbJ9qUtAXD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.4 (GNU/Linux) iQIzBAABCgAdFiEEX8OngXdrJt+H9ww3v1NdgR9S9osFAlpiemUACgkQv1NdgR9S 9ovYZg//RavejCy8jV1L9h9YlViI0gL3LvtV2QPF5eK6AuKOi+qT9ZxuphZwEcgG BV7n2mRQVPxdbLRduH0hFH55nhVBEJMYO5drDqquy7t2Rws9S86/gPmAQFQj8AQG 3TldulcmvNcjpJ8jHAo8+JLyqqhHundO325ZjV69eHE08JbeS8cVDfqzcWJS29kT bmiu3ZYEalbFUGyk/SKOED7YOj/+yGfuTpCJ+eGtHO0q2Rx2Pv0SDstNCw7h8BfD tyEEULWBVJh63KhRdsWrvvp6lFAO8ErpLR0r3Rw50nkr7TLNPP2rz/86AdZNZGBq Z6CCWQgW6WKj3dlmdlyWEjX+iW2u3+54sj7eM0TcmYfs78QnjzDEpM7etQPHDNSG Ek5H2mvaugNUpGLKNZPF1lcn86XSO9Lhw7iC/hoYMRTEHG+ccYlU9UxyE84cqYeW 1YWBbeKKmO5CchVxc4gWACx/8/c2R7VbdpMv+wZROSs4IhU7zaZJde/AJE/6ozk+ Acw0krsXtGVA9cBZotb3KMEWvMDWlUwhdUJQ/QQoSd4FSzsG1Pti/0P/Q75sSecy 3vaWfoeBnIEy65pVsD1HFZfFyVhJ+pPGMjkOZ7kmaiFBtmZr6eg6yIvJlq/G4CEb +4G1yp4uYB4sSsNNKe8NoggWhxkCbwRcC3hYenxD6VQA1j62zzk= =t3z8 -----END PGP SIGNATURE----- --AkbCVLjbJ9qUtAXD-- From nobody Sun Jan 21 08:20:33 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF6A1241F3 for ; Sun, 21 Jan 2018 08:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no 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 E8QepPCRNMCX for ; Sun, 21 Jan 2018 08:20:28 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93320126D73 for ; Sun, 21 Jan 2018 08:20:28 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1edIM6-0007Pj-Ou for ; Sun, 21 Jan 2018 17:20:26 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1edIDt-0000Le-HL for ; Sun, 21 Jan 2018 17:11:57 +0100 From: Werner Koch To: openpgp@ietf.org Organisation: The GnuPG Project X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: openpgp@ietf.org Date: Sun, 21 Jan 2018 17:11:57 +0100 Message-ID: <877esb42eq.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Yukon_RSA_Watergate_Albright_MILSATCOM_explosion_Osama_covert_video="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] Very basic support for the AEAD proposal in GnuPG X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2018 16:20:31 -0000 --=Yukon_RSA_Watergate_Albright_MILSATCOM_explosion_Osama_covert_video= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi! I just pushed my first take on AEAD support for bulk data encryption to GnuPG master. Not well tested and only tested with OCB. Fortunately patches for EAX also landed in Libgcrypt master this weekend. Thus using libgcrypt from master with the lasted patches should allow for EAX encryption as well (no need for --aead-algo in this case). This code has seen only a very few manual tests. Encrypting always uses a 64k chunks and decryption has not been tested with larger chunks. Those small chunks make debugging much faster. =20=20=20=20 Tests can be done using: =20=20=20=20 gpg --rfc4880bis --pinentry-mode=3Dloopback --passphrase abc \ --force-aead --aead-algo ocb --s2k-mode 0 --cipher AES \ -v -z 0 --status-fd 2 -c OUTFILE =20=20=20=20 and =20=20=20=20 gpg --rfc4880bis --pinentry-mode=3Dloopback --passphrase=3Dabc \ --status-fd 2 -v -d OUTFILE =20=20=20=20 Public key encryption should also work but I didn't test that yet. Shalom-Salam, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Yukon_RSA_Watergate_Albright_MILSATCOM_explosion_Osama_covert_video= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCWmS7zQAKCRD/gK6dHew1 jQQsAP9AfWiyR3JsMi0WwypPpeUAw2v3eNH8H2RejqNsFKJn7gD/f5iMZ5J6fwCI MtCDlvS4X9wRL23YgjCKZhQ5TYbYFwA= =PKad -----END PGP SIGNATURE----- --=Yukon_RSA_Watergate_Albright_MILSATCOM_explosion_Osama_covert_video=-- From nobody Mon Jan 22 01:25:33 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C93124B17 for ; Mon, 22 Jan 2018 01:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no 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 jl2mA8ExsYrv for ; Mon, 22 Jan 2018 01:25:29 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2EFC1243F6 for ; Mon, 22 Jan 2018 01:25:29 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1edYM4-0007yN-QS for ; Mon, 22 Jan 2018 10:25:28 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1edYEG-0005MK-7M; Mon, 22 Jan 2018 10:17:24 +0100 From: Werner Koch To: "brian m. carlson" Cc: openpgp@ietf.org, Tom Ritter References: <87a7xjfk07.fsf@wheatstone.g10code.de> <87y3l3dp2i.fsf@wheatstone.g10code.de> <20180113003757.GD5946@genre.crustytoothpaste.net> <87r2qn8pwk.fsf@wheatstone.g10code.de> <20180119230821.GD222163@genre.crustytoothpaste.net> Organisation: The GnuPG Project X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: "brian m. carlson" , openpgp@ietf.org, Tom Ritter Date: Mon, 22 Jan 2018 10:17:16 +0100 In-Reply-To: <20180119230821.GD222163@genre.crustytoothpaste.net> (brian m. carlson's message of "Fri, 19 Jan 2018 23:08:21 +0000") Message-ID: <87efmi2qxv.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=oil_passwd_Afghanistan_USDOJ_terrorism_FSF_Juiliett_Class_Submarine="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] v5 Secret-Key Packet Formats X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 09:25:32 -0000 --=oil_passwd_Afghanistan_USDOJ_terrorism_FSF_Juiliett_Class_Submarine= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 20 Jan 2018 00:08, sandals@crustytoothpaste.net said: > generally been a successful model that's been resistant to attacks > involving the MAC. The TLS model is "authenticate the entire packet". Well, we do basically the same except that we need to leave out the packet lengths because OpenPGP different here form TLS. Find below my changes on using non-chunked AEAD for secret keys and the SKESK. > I would just say a hard error is the right thing to do. Clearly if > there's disagreement, we can't be sure what the sender intended. It > would be better to fail than produce a bunch of junk data. Well, it won't be junk data if the implementaion supports all required algorithms. For example the SKESK uses AES-256 to encrypt the session key and the AEAD Encrypted Data Packet uses AES-128. I can't see a security problem here. Salam-Shalom, Werner =2D-8<---------------cut here---------------start------------->8--- Do not used chunked AEAD encryption for secret keys and SKESK. =20=20=20=20 This also gives examples on how to encode the additional data. Modified middle.mkd diff --git a/middle.mkd b/middle.mkd index a48a6fb..b7be5c6 100644 =2D-- a/middle.mkd +++ b/middle.mkd @@ -1801,11 +1801,17 @@ ## {5.3} Symmetric-Key Encrypted Session Key Packet= s (Tag 3) * The encrypted session key itself, which is decrypted with the string-to-key object using the given cipher and AEAD mode. =20 =2D * A final, summary authentication tag for the AEAD mode. + * An authentication tag for the AEAD mode. + +The encrypted session key is encrypted using one of the AEAD +algorithms specified for the AEAD Encrypted Packet. Note that no +chunks are used and that there is only one authentication tag. The +Packet Tag in new format encoding (bits 7 and 6 set, bits 5-0 carry +the packet tag), the packet version number, the cipher algorithm +octet, and the AEAD algorithm octet are given as additional data. For +example, the additional data used with EAX and AES-128 consists of the +octets 0xC3, 0x05, 0x07, and 0x01. =20 =2DThe encrypted session key is encrypted exactly as an AEAD Encrypted Data =2Dpacket with a chunk size octet of 10 would be. This implicit chunk size =2Doctet is included in the normal calculations of additional data. =20 ## {5.4} One-Pass Signature Packets (Tag 4) =20 @@ -1990,9 +1996,12 @@ ### {5.5.3} Secret-Key Packet Formats string-to-key specifier. The length of the string-to-key specifier is implied by its type, as described above. =20 =2D * [Optional] If secret data is encrypted (string-to-key usage =2D octet not zero), an Initial Vector (IV) of the same length as =2D the cipher's block size. + * [Optional] If secret data is encrypted (string-to-key usage octet + not zero), an Initial Vector (IV) of the same length as the + cipher's block size. If string-to-key usage octet was 253 the IV + is used as the nonce for the AEAD algorithm. If the AEAD + algorithm requires a shorter nonce, the high-order bits of the IV + are used and the remaining bits MUST be zero. =20 * Only for a version 5 packet, a four-octet scalar octet count for the following key material. @@ -2037,9 +2046,15 @@ ### {5.5.3} Secret-Key Packet Formats are encrypted, including the MPI bitcount prefix. =20 If the string-to-key usage octet is 253, the encrypted MPI values are =2Dencrypted as one combined plaintext exactly as an AEAD Encrypted Data =2Dpacket with a chunk size octet of 10 would be. This implicit chunk size =2Doctet is included in the normal calculations of additional data. +encrypted as one combined plaintext using one of the AEAD algorithms +specified for the AEAD Encrypted Packet. Note that no chunks are used +and that there is only one authentication tag. The Packet Tag in new +format encoding (bits 7 and 6 set, bits 5-0 carry the packet tag), the +packet version number, the cipher algorithm octet, and the AEAD +algorithm octet are given as additional data. For example, the +additional data used with EAX and AES-128 in a Secret-Key Packet of +version 4 consists of the octets 0xC5, 0x04, 0x07, and 0x01; in a +Secret-Subkey Packet the first octet would be 0xC7. =20 The two-octet checksum that follows the algorithm-specific portion is the algebraic sum, mod 65536, of the plaintext of all the algorithm- @@ -2050,7 +2065,9 @@ ### {5.5.3} Secret-Key Packet Formats deprecated; an implementation SHOULD NOT use it, but should rather use the SHA-1 hash denoted with a usage octet of 254. The reason for this is that there are some attacks that involve undetectably modifying the =2Dsecret key. +secret key. If the string-to-key usage octet is 253 no checksum or +SHA-1 hash is used but the authentication tag of the AEAD algorithm +follows. =20 =20 ## Algorithm-specific Parts of Keys @@ -2640,7 +2657,10 @@ ## AEAD Encrypted Data Packet (Tag 20) format encoding (bits 7 and 6 set, bits 5-0 carry the packet tag), version number, cipher algorithm octet, AEAD algorithm octet, chunk size octet, and an eight-octet, big-endian chunk index as additional =2Ddata. The index of the first chunk is zero. +data. The index of the first chunk is zero. For example, the +additional data of the first chunk using EAX and AES-128 with a chunk +size of 64 kiByte consists of the octets 0xD4, 0x01, 0x07, 0x01, 0x10, +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, and 0x00. =20 After the final chunk, the AEAD algorithm is used to produce a final authentication tag encrypting the empty string. This AEAD instance is =2D-8<---------------cut here---------------end--------------->8--- =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=oil_passwd_Afghanistan_USDOJ_terrorism_FSF_Juiliett_Class_Submarine= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCWmWsHAAKCRD/gK6dHew1 jTGaAP9cF86Ia8gheq5MB5OhMjLhwVNFfY2U7RlA2YiLDKI+JgEAk2KU2j4Jz14b UmgCxOG+vH66OJi+3JOZ6oamnqt1gAc= =fd3Y -----END PGP SIGNATURE----- --=oil_passwd_Afghanistan_USDOJ_terrorism_FSF_Juiliett_Class_Submarine=-- From nobody Thu Jan 25 09:35:40 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59992126DFF for ; Thu, 25 Jan 2018 09:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 NeO3hmYzmMlY for ; Thu, 25 Jan 2018 09:35:34 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B930D124D68 for ; Thu, 25 Jan 2018 09:35:34 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1eelQz-00021d-J5 for ; Thu, 25 Jan 2018 18:35:33 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1eelL7-0000Gs-6i; Thu, 25 Jan 2018 18:29:29 +0100 From: Werner Koch To: openpgp@ietf.org Mail-Followup-To: openpgp@ietf.org cc: gnupg-devel@gnupg.org Organisation: The GnuPG Project X-message-flag: Mails containing HTML will not be read! Please send only plain text. Date: Thu, 25 Jan 2018 18:29:22 +0100 Message-ID: <871sidzw25.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=bluebird_Uzbekistan_blackjack_Uzi_data_haven_passwd_Sundevil_jihad=2"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] draft-ietf-openpgp-rfc4880bis-04 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 17:35:38 -0000 --=bluebird_Uzbekistan_blackjack_Uzi_data_haven_passwd_Sundevil_jihad=2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi! I just published version 04 of rfc4880bis: In case you want to look at the diff to -03 in a browser: See https://gitlab.com/openpgp-wg/rfc4880bis for the repo. Changes since -03: =2D Additional data for AEAD has been changed to include only the packet tag but not the packet length. =2D Chunked AEAD mode is not used with SKESK and Secret-Key packets. =2D Examples for AD are provided. =2D Protocol numbers for AEDH and AEDSA are reserved. =2D TripleDES as implicit preference and mandatory algorithm has been replaced by AES-128. =2D RSA and ECDSA are now mandatory. =2D DSA and Elgamal are now optional. Note that the last 3 changes have not explicitly been discussed in the WG. The reservation of AEDH and AEDSA was requested by Derek back in April 2016, I decided to include them so that they don't get lost. Current GnuPG master has support for AEAD encryption except for the protection of secret-keys. Shalom-Salam, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=bluebird_Uzbekistan_blackjack_Uzi_data_haven_passwd_Sundevil_jihad=2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCWmoT8wAKCRD/gK6dHew1 jZdYAPwLhWo/jG/5yz30lXCC6eZVQfcsUCFze1F0pr0jUEE1JAD+Os0jHkB/fpLM RtS5Wc/89QzUg72NU6r6DFjbeFZJogw= =X3Oh -----END PGP SIGNATURE----- --=bluebird_Uzbekistan_blackjack_Uzi_data_haven_passwd_Sundevil_jihad=2--