From nobody Thu Oct 1 15:39:15 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 A58A11A8BC4 for ; Thu, 1 Oct 2015 15:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 JTNPfJzH9R6L for ; Thu, 1 Oct 2015 15:39:13 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::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 D5FDF1A8AF9 for ; Thu, 1 Oct 2015 15:39:12 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so10626804wic.1 for ; Thu, 01 Oct 2015 15:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=vg8cfoT9yzhT/6fT+tzaLOiSwacNtqymAFA/hqXSlK8=; b=cxdtAUl3F5aunCj1K0rl/9ACmX7US72TsY3Ez74bmkoe0GGBHdjSAT1agvHYVMp2jx BrTLsA7Qbg6feeqi0gn1craCmU/uc1U0KEmBHOqnHajYTCawfAUmUpYqNN7f+/hzsaIT 0zx2wALFATEE4O6P3ODyR10PI3RQM8YofaS5R8sZ0FtBt29o5pi/jxNnBWfr4N47XnNt Gmqugwr7n3Xz/FHFD0+0nXO41diP9XaNkL6CD13FDpnJyO/FiAOdwiElQujfvom4PeXV U6v3bBmWNI+i5T0V/vtmprSEnIDQUA6MJscLJ3khnf+aU1+HDspaSPUuT2O+24U7j8RR b/nQ== MIME-Version: 1.0 X-Received: by 10.194.250.40 with SMTP id yz8mr15182381wjc.37.1443739151429; Thu, 01 Oct 2015 15:39:11 -0700 (PDT) Received: by 10.28.51.145 with HTTP; Thu, 1 Oct 2015 15:39:11 -0700 (PDT) In-Reply-To: <87r3lgcup8.fsf@vigenere.g10code.de> References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> Date: Thu, 1 Oct 2015 18:39:11 -0400 Message-ID: From: Watson Ladd To: Daniel Kahn Gillmor , IETF OpenPGP Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Thu, 01 Oct 2015 22:39:14 -0000 On Wed, Sep 30, 2015 at 2:00 AM, Werner Koch wrote: > On Tue, 29 Sep 2015 20:40, dkg@fifthhorseman.net said: > >> v4 key and wrap it in a v5 packet, thereby producing a "new key" that's >> actually the "same key". So claiming that key material can only be used >> as *either* v4 or v5 wouldn't quite be correct. > > FWIW: I was thinking about this but that is not limited to OpenPGP. I > can use the same key material for an OpenPGP key, an X.509 key, and an > SSH key. This is actually sometimes useful if you have a single key on > a smartcard. Have you conducted a proper cross-protocol analysis of what data each key type is used to sign showing that this interaction doesn't lead to bad things happening? > > > Salam-Shalom, > > Werner > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sat Oct 3 18:50:21 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 3CF9F1B2E28 for ; Sat, 3 Oct 2015 18:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 6jjfaWnw3CH9 for ; Sat, 3 Oct 2015 18:50:19 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (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 987811B2E27 for ; Sat, 3 Oct 2015 18:50:18 -0700 (PDT) Received: by lbwr8 with SMTP id r8so42291005lbw.2 for ; Sat, 03 Oct 2015 18:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=t+dZ/pdsQyMqROV61yOwfGxF2iDAEZYD4vE6ZyleyF8=; b=M/ASVs+rt48ErLysTdjHqBc/sLVdaLr39zjwF/U6D4946ZqQCfmnyRg8jFWNIVd0JF baMdJr2To8f2UxNivaPc+3D+5iU1qF6y7J637tiy8gFNsGSrgyIrB3vv5+p9H1f4achD +SFuffGklu4Tv2Ou2Mrc2eL5OUUYTZgY0NtetjUtmgrVWSNCmkVeSexIXJGrmMbMy8d/ aFXE1D5RaAN1hKq7vBNLoouexXE25hUsdJ6BpoQBaG7IKhqxYnI49VL9ZSSpqolQIOs9 erheXcUHnFOGL8d11jzYUPuzltkepRCLKRSDf0vdnnbTzgDD6tG6NIw6Y6gWyu+VD63N eMYQ== MIME-Version: 1.0 X-Received: by 10.25.158.84 with SMTP id h81mr5862226lfe.58.1443923416655; Sat, 03 Oct 2015 18:50:16 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.2.163 with HTTP; Sat, 3 Oct 2015 18:50:16 -0700 (PDT) In-Reply-To: References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> Date: Sat, 3 Oct 2015 21:50:16 -0400 X-Google-Sender-Auth: WMtETjukgfWJ-tThzjJavX5__LU Message-ID: From: Phillip Hallam-Baker To: Watson Ladd Content-Type: multipart/alternative; boundary=001a1141053a55332005213d9eaa Archived-At: Cc: IETF OpenPGP , Daniel Kahn Gillmor Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Sun, 04 Oct 2015 01:50:20 -0000 --001a1141053a55332005213d9eaa Content-Type: text/plain; charset=UTF-8 On Thu, Oct 1, 2015 at 6:39 PM, Watson Ladd wrote: > On Wed, Sep 30, 2015 at 2:00 AM, Werner Koch wrote: > > On Tue, 29 Sep 2015 20:40, dkg@fifthhorseman.net said: > > > >> v4 key and wrap it in a v5 packet, thereby producing a "new key" that's > >> actually the "same key". So claiming that key material can only be used > >> as *either* v4 or v5 wouldn't quite be correct. > > > > FWIW: I was thinking about this but that is not limited to OpenPGP. I > > can use the same key material for an OpenPGP key, an X.509 key, and an > > SSH key. This is actually sometimes useful if you have a single key on > > a smartcard. > > Have you conducted a proper cross-protocol analysis of what data each > key type is used to sign showing that this interaction doesn't lead to > bad things happening? > Yes, hence the reason for my UDF design which salts the hash with the mime content type of the data being hashed. Thus one fingerprint format can be used for a S/MIME key or an OpenPGP key or an SSH key. --001a1141053a55332005213d9eaa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 1, 2015 at 6:39 PM, Watson Ladd <watsonbladd@gmail.com= > wrote:
O= n Wed, Sep 30, 2015 at 2:00 AM, Werner Koch <wk@gnupg.org> wrote:
> On Tue, 29 Sep 2015 20:40, dk= g@fifthhorseman.net said:
>
>> v4 key and wrap it in a v5 packet, thereby producing a "new k= ey" that's
>> actually the "same key".=C2=A0 So claiming that key mate= rial can only be used
>> as *either* v4 or v5 wouldn't quite be correct.
>
> FWIW: I was thinking about this but that is not limited to OpenPGP.=C2= =A0 I
> can use the same key material for an OpenPGP key, an X.509 key, and an=
> SSH key.=C2=A0 This is actually sometimes useful if you have a single = key on
> a smartcard.

Have you conducted a proper cross-protocol analysis of what data eac= h
key type is used to sign showing that this interaction doesn't lead to<= br> bad things happening?

Yes, hence the re= ason for my UDF design which salts the hash with the mime content type of t= he data being hashed. Thus one fingerprint format can be used for a S/MIME = key or an OpenPGP key or an SSH key.
=C2=A0
--001a1141053a55332005213d9eaa-- From nobody Sun Oct 4 10:28:18 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 A7C401B2AF5 for ; Sun, 4 Oct 2015 10:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 PrVL8zFHflGj for ; Sun, 4 Oct 2015 10:28:14 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 040A41A7D82 for ; Sun, 4 Oct 2015 10:28:14 -0700 (PDT) Received: by ioiz6 with SMTP id z6so164359511ioi.2 for ; Sun, 04 Oct 2015 10:28:13 -0700 (PDT) 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 :content-type; bh=fmBGKlZtuGHWN2jR3EL0CSE+y7qf2oVxh8g+6GpKRgM=; b=tP1i8Jx3HlZ8b7zlqNYiG/N9dKcPQuUu6BqJ0MMsQJoLy6iOaj6IkAAEV6su4ZIhxO S+rrjvexboQ8XCMAjeYB/QTwmDNW7/pkxaNdbV8taaKS7O1uvRPFh/UJPZoM7dpYL6hF n0k3D7/yQ/zGFZb/d06HqvYYVIlnJIOowVcuk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=fmBGKlZtuGHWN2jR3EL0CSE+y7qf2oVxh8g+6GpKRgM=; b=Ku/OqI7TCfVYdQCIEay75wUnMKSUdaVbDbVTs1cTjPuIDuuVea7tCAnnMZkBzwuSus P0qj6dTaXlon2U2bc7+VUbZVqfqsy9P0CEbKrw1kxGUBVb2nvL6aFgnyZaxav7yIITHM 6wzih2fvqi2RMBDMMpnR99dpu1IqzNyNRQHmu3445bAadrrna0obB2xgFSagMnxQJ66+ OkqkQgWQ2cu5xNsenew9LTKjjjZhLjK4x9nOOvDhQIRsxEh3qRvAyJ+ux24ee8j4L00B tNW2csQKsZ82oC+eI4pxl5SHKeurRlzzgU+W5uQZ4AGYNdZ/eL4xwCZqc3vPn5cL6VBK 37PQ== X-Gm-Message-State: ALoCoQlBCSqqmz0HrcJ+1JT/4mN2DZSZHhoixZiVdyY1jBxZ2B2fvYpz8t37qP0sjiTeXlm+QlPf X-Received: by 10.107.170.223 with SMTP id g92mr23231031ioj.79.1443979693366; Sun, 04 Oct 2015 10:28:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.95.195 with HTTP; Sun, 4 Oct 2015 10:27:53 -0700 (PDT) In-Reply-To: <87mvw4ctv5.fsf_-_@vigenere.g10code.de> References: <878u84zy4r.fsf@vigenere.g10code.de> <55FD7CF0.8030200@iang.org> <87io742kz7.fsf@latte.josefsson.org> <87mvw4ctv5.fsf_-_@vigenere.g10code.de> From: Tom Ritter Date: Sun, 4 Oct 2015 12:27:53 -0500 Message-ID: To: Simon Josefsson , ianG , IETF OpenPGP Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [openpgp] New fingerprint: which hash algo (was: to v5 or not to v5) 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: Sun, 04 Oct 2015 17:28:15 -0000 On 30 September 2015 at 01:18, Werner Koch wrote: > On Mon, 21 Sep 2015 11:13, simon@josefsson.org said: > >> Regarding which hash to use, SHA-256 is probably the simplest choice >> From a practicallity and consensus point of view. Are there any strong >> reasons to favor something else? I have a small preference to see the fingerprint algorithm match what we believe the most popular signature (hash) algorithm will be. I've been working with a number of embedded folks and code size can often be a big concern. More Algorithms, More Code. -tom From nobody Sun Oct 4 11:26:07 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 0022E1B346D for ; Sun, 4 Oct 2015 11:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 UYiaHX-BhOA0 for ; Sun, 4 Oct 2015 11:26:04 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D2E41B345C for ; Sun, 4 Oct 2015 11:26:04 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Zinyz-0002VT-R5 for ; Sun, 04 Oct 2015 20:26:01 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZinvC-0004wl-E9; Sun, 04 Oct 2015 20:22:06 +0200 From: Werner Koch To: Phillip Hallam-Baker References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Phillip Hallam-Baker , Watson Ladd , IETF OpenPGP , Daniel Kahn Gillmor Date: Sun, 04 Oct 2015 20:22:06 +0200 In-Reply-To: (Phillip Hallam-Baker's message of "Sat, 3 Oct 2015 21:50:16 -0400") Message-ID: <87y4fi5wa9.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: Watson Ladd , IETF OpenPGP , Daniel Kahn Gillmor Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Sun, 04 Oct 2015 18:26:06 -0000 On Sun, 4 Oct 2015 03:50, phill@hallambaker.com said: > Yes, hence the reason for my UDF design which salts the hash with the mime > content type of the data being hashed. Thus one fingerprint format can be > used for a S/MIME key or an OpenPGP key or an SSH key. See rfc-4880, 12.2 (Key IDs and fingerprints) Here are the fields of the hash material, with the example of a DSA key: a.1) 0x99 (1 octet) a.2) high-order length octet of (b)-(e) (1 octet) a.3) low-order length octet of (b)-(e) (1 octet) b) version number = 4 (1 octet); c) timestamp of key creation (4 octets); d) algorithm (1 octet): 17 = DSA (example); e) Algorithm-specific fields. Algorithm-Specific Fields for DSA keys (example): e.1) MPI of DSA prime p; e.2) MPI of DSA group order q (q is a prime divisor of p-1); e.3) MPI of DSA group generator g; e.4) MPI of DSA public-key value y (= g**x mod p where x is secret). also the MPI format is different from X.509 and from SSH. Thus we already "salt" the fingerprints with version numbers and a timestamp and get different fingerprints for these 3 protocols and most likely for all protocols even for the same key material. For a v5 key the fingerprint will also be different due to a.3b). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Sun Oct 4 20:44:06 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 960621A06FD for ; Sun, 4 Oct 2015 20:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 1texItxv06a5 for ; Sun, 4 Oct 2015 20:44:02 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0131.outbound.protection.outlook.com [65.55.169.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86A6F1A03AB for ; Sun, 4 Oct 2015 20:44:02 -0700 (PDT) Received: from BY1PR0501CA0037.namprd05.prod.outlook.com (10.162.139.47) by BN1PR05MB057.namprd05.prod.outlook.com (10.255.202.139) with Microsoft SMTP Server (TLS) id 15.1.286.20; Mon, 5 Oct 2015 03:44:00 +0000 Received: from BN1AFFO11FD008.protection.gbl (2a01:111:f400:7c10::105) by BY1PR0501CA0037.outlook.office365.com (2a01:111:e400:4821::47) with Microsoft SMTP Server (TLS) id 15.1.286.20 via Frontend Transport; Mon, 5 Oct 2015 03:44:00 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.18) by BN1AFFO11FD008.mail.protection.outlook.com (10.58.52.68) with Microsoft SMTP Server (TLS) id 15.1.286.14 via Frontend Transport; Mon, 5 Oct 2015 03:43:59 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 4 Oct 2015 20:43:58 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t953hvD36101; Sun, 4 Oct 2015 20:43:57 -0700 (PDT) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 011471145A; Sun, 4 Oct 2015 20:43:57 -0700 (PDT) To: Phillip Hallam-Baker , Watson Ladd , IETF OpenPGP , Daniel Kahn Gillmor In-Reply-To: <87y4fi5wa9.fsf@vigenere.g10code.de> References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <87y4fi5wa9.fsf@vigenere.g10code.de> Comments: In-reply-to: Werner Koch message dated "Sun, 04 Oct 2015 20:22:06 +0200." From: "Mark D. Baushke" Date: Sun, 4 Oct 2015 20:43:56 -0700 Message-ID: <74252.1444016636@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD008; 1:N/OISPQlLEIAKtNTodGExdgNXkbbijCFS7yCd9QXU6HkVETWgxc5+YH0b6Y1yrySShNxPvGRvh4iyRXIVNjn/PVwq3JI5SvxhZDHYAmS29+ud5boqb+3a9or6C1cDXcAAnpyYHNnhzH+c2APtf9bKFS6xcSRcW2f/DoIJ6nr3P9nM/4xwvr20ofE0r3RLP3/r8mRHCgMChER79eus4KYHomiDg+B3CFBitWMRz+IR7YYmKQLbhnhyxSRNPeU0BnHjuaFza+eLEnSEVY4q70tI0J5PDPN2w/jZNZjMxmsgSYUvnYb5oZk30nkfQ2X/hUowpQs9hOFPC2rIMafuRa15sZ6oAgI9XE34JKg9jTN2QUjSEwDw6zPD252vYqAxreS X-Forefront-Antispam-Report: CIP:66.129.239.18; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(199003)(189002)(5007970100001)(46102003)(6806005)(93886004)(11100500001)(5001860100001)(50986999)(107886002)(76176999)(189998001)(117636001)(81156007)(2950100001)(97736004)(5001830100001)(5003600100002)(92566002)(69596002)(53416004)(54356999)(77096005)(5001960100002)(19580405001)(5003940100001)(87936001)(77156002)(5001770100001)(62966003)(4001540100001)(48376002)(50466002)(68736005)(76506005)(106466001)(19580395003)(86362001)(47776003)(64706001)(105596002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB057; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB057; 2:ZSDImjiTBI3LvRMSJcPYUkGFsLqtAkv9yWn0McHk8uHRA76VQuxdId4TBXrXybHVU4NlAnh7mE02mRf6jARrTDzmOzafPkWRiEeEM2vETOUhRBkcEmMZva7CTJX+cgbfUwBVXgRkRs+8H+iB3T9Rad4XSsk4qsoJyWf4K68lQ60=; 3:cW4/VlNnsoWr+9qhJ6FWXs2vmeuiMMv6IZ3paRKZX0rF1UUocF9hUswwCWlfvWMSTpV+9murdAR12YeoDazCiNI7fVG3Po24LCPPqfHklQChBp2yah/wGlhOowAloy3DnOH5riL9cW1cHjY+QKeeWKNtwgirNauOIxbPqk3Xp6yNLUE5ZPECuMskObD10mMzD/a14ezEZKUEs4GCxxfLskU0SSl+2kiewLTpUUYudQk=; 25:ln83uO871ktL4wn81Cw/29bzpjXRW4vRaTnSEHVMHz+gw/m0fRb0A2/Sk0rxXCvKwKPqd9Emu1dElASpkZ2+HcXuDrcOT2dq/YzACu8e3rlZhf+rVrpxb6JbpV6tq53PLuB0sNjr13CAa4nk0E4xmzI3mgX97i+px7StywAsMWdv9w8ToXvfBfF2v7N+c/bMj4g7Y+ZQAsaOXqZVN8vVlE8GdeIf3yHCkd3x2E19xpXQdxPybQlXVLJ5jfCIjsaP X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB057; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB057; 20:aoblkFLYo98vRAsqAZDLaqGBq4jIrtbMKoDLkGPUdPykadfSHtungi+LBgBzKsLkhvJYo2aYMWDW9DGppsXJaSVdjFvT9axrtC27I571lG1CFmDv+QHEs0WOqNZzKdZFOuF08zGTfSz3zmNkZvtIBFxVLAesB6Ov+0gpvQPHSAywrrzGaFhx9B78EC729p5EbnVFVY4tHujW2+wbeXJxdzXik9Ek+oo3zplUJN4AEXo29VtvtVCVsLfAgPi062Jzi6CXS6q9Km4LjyTfgYfIUY6z4/T3FQW5nSEnuBAGXyE5wL9rhG14/N4q4d61sQ6wW0aKs/17vudLl6dUrigzuHJcRNsCdrO1DSv2Q+cDRkxjI22IJFBJiGIV7Lu00yKtrX6j1QS5gATYiza/RTYz7xpSPPpMhL/FZuzr7mbV3tMW2/5CsmApWalZEcNa5vnJRepFzMzG1stWDXLSDMworEKY2FaLaQuujWGxHaNli+OFLF/JdcNj+IIlQCiDteeH; 4:OrOKw7KXy9hMpuYP8onp14UcurFDCimTamFY/ja3aSLSBh1Zsw9Dq84kqWHeMqxppz7N+rLM87A+k7+Y7hWOqyD4ienWSS9ibofDmJpSb/8JjhKoU6jIZcUYsXR6YubjxOj+gqw3qh06Uk11VA+xeEanE8ozLCFdomHk1YBbY6HYulYcCiUSe498MPjS57THtbM9yLy4M3hpDzGwxMHMFqzvPAQpHuIDIgTHu19XUBOd0gvXBfgdTA/cUQ9N3hUi/Ry9/Xbmxd1QMFRbJD4l0e3y1FmstHOrYmux/48Dz0/hEj2iud31Dnl8+5NPiTVZCzleC/8anpEBgUGtgSiDfLJnEi/7at+Hc+5X12inyQ0= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:BN1PR05MB057; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB057; X-Forefront-PRVS: 07200C0526 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR05MB057; 23:XvMoYWjA9DUHyO7lru5zo/lRGYs7EAbZVJAPe+uQXb?= =?us-ascii?Q?c8U4+xq8PUxkYI3He7JOWx05Lj7ZROUKCl0UyLOUe23yKCAzFjLisSDnnjTE?= =?us-ascii?Q?P/Ge3rdFhx2JadII+p1KhteCrYB3OPT+giTSyNXxKzyaKuY+2wAx4MviAjKc?= =?us-ascii?Q?oMm3donMTb9mQvgcjZHHaOBelRoasdXmZYL+NCkfqFEneFCj3A1IEpLLw8hl?= =?us-ascii?Q?MQZ1BkvuZUyIoasn7SdWgzCS9+Wy+V+9RNykIYBYithb7qXvxPpF/m98WfZF?= =?us-ascii?Q?DQ7h1p6Ivs0/nB1H0AirG74/f4h+Vr+3SLJZfoOYvMD/Hk6XW5SNcDUeKIEY?= =?us-ascii?Q?7c73l2Q0PXvQvytlXNhEpfD7OrBvyNAqauJWyhPmZSVq2PWwjMSgFXfUMgA9?= =?us-ascii?Q?mUEe9oBkq9rlYNIIOMasciY4iXPY/hakQBgvVIIedJOAXC5wMeUxdzMnPJ5B?= =?us-ascii?Q?9CdRqtZ2yK+bE/Pvc3ik83IL9dcLVZvoa183y0vles9HW6fKyF84K9dRGYw/?= =?us-ascii?Q?FNRX6qSdDVzlz2htj5BfCicGbaoHvBgKCEIYhwvhD2eVy1bZbRzgIt31cMzJ?= =?us-ascii?Q?hzPfyJHYhhzS8Qu7PMrownbm1Tg3M4uwu/ANMFOw1ko5U/sKWSQXrtKfxYdD?= =?us-ascii?Q?AJnbhlVeX2DwwCw2oHwcoudbUIPj5B8LZ2Cp95SswQ421bz0gM0wqz3mMkJ+?= =?us-ascii?Q?YXQF6bpIyfjuy/TWD5/Ng9KiYN/6pKrfmqetZ58XaubWtBiNWc3bFelyC1md?= =?us-ascii?Q?5/MM9QF0/H4n8Qe1DCX3i1tgUkZbcMJjVp0PQdL31rOE0tzL9m0dOIgQGlPj?= =?us-ascii?Q?b2BZa9j5I23ebpJzE5frPnotnJNvY1jJ5OKES3iL6BdpVKclKE9BPPVStPJR?= =?us-ascii?Q?j0gAa9cylSk0cgnGZ9AZKppKL8EXFbUTRvcLNVqH+IWrmi/nftqZj2uJ/vin?= =?us-ascii?Q?wdoLd9etX96nVX883K7+VQXfCuLsiZCQLn0PLmwpKdCB9ILvo4n2tX/2ihwc?= =?us-ascii?Q?qMkm8oycwM7PY8/S2S9wtvzLF4WVSgg0eXAstAdU21miUzPwTzfL1gsATaKf?= =?us-ascii?Q?VABZ1t7mIYBk/hsrNUov9P0axt1WrXJ/ttT4sXsjdwngJ1DWGJZFVWxeY/2l?= =?us-ascii?Q?T6iio/IQFxnzvDiV90Rw7XgNWmeR1UhzcN0stU9RW5iYP3s7P2/2Uc0mI48e?= =?us-ascii?Q?ii3hZVC1yFbOEYA5JhAZb/iMnEce2Uzyf/?= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB057; 5:Wjq+tKLvxq9sdCFuMLEo97vGwcyB/2ELDw5CAJRSbtqRm5B/0TV2aygbpWFc7gSDawXexgV96Esslmhkgi5ShcwbHqtBumxxsPtsBFTGDqtkkMNZqsWBLUKTHLPNg/fDHQgDG1jj08ezXu+muJSumQ==; 24:c3/33S8snC14Fg3U7SbnLaaE0fzGMe2e3k0p1JPEKB09xw0nDWXHnpoeSPvko1ftchYG1uHJXYdpMCUK7dO+agCROoTGVv/eBgkpV2YOwHg=; 20:FAAByMyC794IsZ3Sor7HzISjtLhoff3IIsKqrqKaKH27FC2zmbuW0vnLPYRjQFmCNc/xvvUhXl/4MMM/es0TWg== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2015 03:43:59.9864 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB057 Archived-At: Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Mon, 05 Oct 2015 03:44:04 -0000 > On Sun, 4 Oct 2015 03:50, phill@hallambaker.com said: ... > See rfc-4880, 12.2 (Key IDs and fingerprints) ... > c) timestamp of key creation (4 octets); This reminds me. I suspect we want to move to be explicit that the timestamp is unsigned during RFC 4880bis, or we want to allocate more bits and make it a 64-bit integer (8 octets). The currnet POSIX-compliant epoch time_t starting at midnight January 1, 1970 using a signed 32-bit integer (4 octets) runs into trouble at 0x80000000 03:14:08 UTC on 19 January 2038 which might also be read as 20:45:52 UTC on 13 December 1901 (-2147483648). -- Mark From nobody Mon Oct 5 03:27:18 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 41FD51A1AE8 for ; Mon, 5 Oct 2015 03:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 237QeH10UWGh for ; Mon, 5 Oct 2015 03:27:14 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B011A1AE6 for ; Mon, 5 Oct 2015 03:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1444040834; x=1475576834; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UaIVofnXiLr4LnXmrboUQwPGjEy4NQMtdN818BMuimU=; b=OYHt4/S3zkmUzEyDLrZ/qS89RRuCiRqaf2ueusrm6N+6IcgEMQk4wne6 IBv8LnNlfIekljLKCZzPwXGTmCb4olR9HgJiNZ73BitjN5padGFyCXaxj XHShRlA+xF3GzvOv+BKd9lu3/nCJWkgA0+M2D+hSyj5A6L5fusHvaxvEa P7cTSpGJxEP0B29YL3vyGyJNEqud4ru3gx1eKBDEG9aDppNFbMXvov1mc 3vqwxYtXZq4GQdBS4jRmu+7oboZkC0Wv0X+2fdi768mwfGVblHls1XD3L KxXdTeXyZkyeSNpMz8ocyzrNRgZOhmDVYmOJFttsqmoDaxuDKASEe+hXb w==; X-IronPort-AV: E=Sophos;i="5.17,638,1437393600"; d="scan'208";a="46467965" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 05 Oct 2015 23:27:03 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Mon, 5 Oct 2015 23:27:02 +1300 From: Peter Gutmann To: Werner Koch , Phillip Hallam-Baker Thread-Topic: [openpgp] New fingerprint: to v5 or not to v5 Thread-Index: AQHQ8XkqGRFnZAPwNU68Rcs3/4z3Np5TD6qAgAGZmFyAAc3ZgIADWg0AgAHwMP2AAQuhlw== Date: Mon, 5 Oct 2015 10:27:02 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz> References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> , <87y4fi5wa9.fsf@vigenere.g10code.de> In-Reply-To: <87y4fi5wa9.fsf@vigenere.g10code.de> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Watson Ladd , IETF OpenPGP , Daniel Kahn Gillmor Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Mon, 05 Oct 2015 10:27:18 -0000 Werner Koch writes:=0A= =0A= >Thus we already "salt" the fingerprints with version numbers and a timesta= mp=0A= >and get different fingerprints for these 3 protocols and most likely for a= ll=0A= >protocols even for the same key material. For a v5 key the fingerprint wi= ll=0A= >also be different due to a.3b).=0A= =0A= ... which is a major pain because the value used to ID the key changes with= =0A= any tiny change in the metadata surrounding it, so you can no longer identi= fy=0A= the key that was used to sign something. The timestamp is the real killer,= =0A= since non-PGP key formats don't record this and there's no explicit storage= of=0A= the keyID (it's implicitly calculated from data that isn't available in non= -=0A= PGP storage), you can no longer track down which key did what. I've got=0A= around it by always recording a creation time of zero for keys (so you just= =0A= hash four bytes of zeroes), but this only works for keys created in my code= =0A= that knows about this convention.=0A= =0A= The whole PGP key format as it currently stands is rather a mess. There's = no=0A= single entry for a key but a connected series of packets of arbitrary numbe= r=0A= where you have to perform arbitrary amounts of lookahead to see where they= =0A= end, then a second pass to parse the packets, and then more iterative passe= s=0A= to resolve all the bits and pieces in the packets. Since the keyID is=0A= generated implicitly from the packets, you have to do this each time you=0A= search a keyring. There are all sorts of attributes, often only vaguely=0A= defined, that can be attached at any point where a signature can be found. = The=0A= descriptions contain gems like:=0A= =0A= This is a flag in a User ID's self-signature that states whether this Us= er=0A= ID is the main User ID for this key [...] If more than one User ID in a = key=0A= is marked as primary, the implementation may resolve the ambiguity in an= y=0A= way it sees fit, [...]=0A= =0A= I have no idea what would happen if you created entries like ones with=0A= multiple subkeys or conflicting attributes in different locations, but I'd= =0A= imagine the behaviour of implementations would be pretty much a coin-toss, = and=0A= the spec doesn't help. I've got around this in my code by assuming a=0A= canonical "one main key, one subkey, some userIDs", with anything outside t= his=0A= ignored. This leads to predictable, deterministic behaviour and (hopefully= ) a=0A= lack of surprises, like the one I'm currently dealing with where a particul= ar=0A= implementation wants to see a certain arrangement of packets and attributes= =0A= and I'm still not sure what they are.=0A= =0A= If the keyring format is redefined for the PGPng, I'd really like to see th= e=0A= format be made more usable, something like (for each entry):=0A= =0A= header (type + length )=0A= {=0A= ID information (explicitly stored, not implicitly generated);=0A= primary key;=0A= [ optional subkey ];=0A= user IDs;=0A= certifications (signatures);=0A= }=0A= =0A= To find a key:=0A= =0A= foreach entry=0A= {=0A= read length;=0A= check IDs for a match;=0A= if( match )=0A= break;=0A= skip length bytes;=0A= }=0A= =0A= With the IDs explicitly stored, you no longer need some complex hash-based= =0A= value to identify the key, you can use any probabilistically-unique value.= =0A= =0A= Peter.= From nobody Mon Oct 5 03:46:07 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 3EC0E1A9107 for ; Mon, 5 Oct 2015 03:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 8EZGM9oBa026 for ; Mon, 5 Oct 2015 03:46:04 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C89C1A8A81 for ; Mon, 5 Oct 2015 03:46:04 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Zj3HO-0001qW-Ce for ; Mon, 05 Oct 2015 12:46:02 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Zj3Ed-0007EM-UJ; Mon, 05 Oct 2015 12:43:11 +0200 From: Werner Koch To: "Mark D. Baushke" References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <87y4fi5wa9.fsf@vigenere.g10code.de> <74252.1444016636@eng-mail01.juniper.net> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: "Mark D. Baushke" , Phillip Hallam-Baker , Watson Ladd , IETF OpenPGP , Daniel Kahn Gillmor Date: Mon, 05 Oct 2015 12:43:11 +0200 In-Reply-To: <74252.1444016636@eng-mail01.juniper.net> (Mark D. Baushke's message of "Sun, 4 Oct 2015 20:43:56 -0700") Message-ID: <877fn161fk.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: Watson Ladd , Phillip Hallam-Baker , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Mon, 05 Oct 2015 10:46:06 -0000 On Mon, 5 Oct 2015 05:43, mdb@juniper.net said: > This reminds me. I suspect we want to move to be explicit that the > timestamp is unsigned during RFC 4880bis, or we want to allocate > more bits and make it a 64-bit integer (8 octets). I was thinking about this but: 3.1. Scalar Numbers Scalar numbers are unsigned and are always stored in big-endian format. Using n[k] to refer to the kth octet being interpreted, the value of a two-octet scalar is ((n[0] << 8) + n[1]). The value of a four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) + n[3]). Thus it is an implementation problem for 32 bit systems which still have not switched from to a 64 bit time_t or fixed their implementation to work with dates after 2038 (which is not a problem because only (time_t)(-1) has a special meaning). I doubt that we need to care about the year 2106 already in a v5 format. > The currnet POSIX-compliant epoch time_t starting at midnight January 1, > 1970 using a signed 32-bit integer (4 octets) runs into trouble at 0x80000000 POSIX 2001 says in Base Definitions, line 13001: - time_t and clock_t shall be integer or real-floating types. it is not specified whether signed or unsigned and thus both are allowed. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Oct 5 04:36:07 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 D0AEA1AC3B0 for ; Mon, 5 Oct 2015 04:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 seYOaKAwFUoS for ; Mon, 5 Oct 2015 04:36:05 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795301AC3B9 for ; Mon, 5 Oct 2015 04:36:04 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Zj43m-0002ii-F8 for ; Mon, 05 Oct 2015 13:36:02 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Zj415-0007Ks-8D; Mon, 05 Oct 2015 13:33:15 +0200 From: Werner Koch To: Peter Gutmann References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <87y4fi5wa9.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Peter Gutmann , Phillip Hallam-Baker , Watson Ladd , IETF OpenPGP , Daniel Kahn Gillmor Date: Mon, 05 Oct 2015 13:33:14 +0200 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Mon, 5 Oct 2015 10:27:02 +0000") Message-ID: <8737xp5z45.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: Watson Ladd , Phillip Hallam-Baker , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Mon, 05 Oct 2015 11:36:07 -0000 On Mon, 5 Oct 2015 12:27, pgut001@cs.auckland.ac.nz said: > ... which is a major pain because the value used to ID the key changes with > any tiny change in the metadata surrounding it, so you can no longer identify > the key that was used to sign something. The timestamp is the real killer, > since non-PGP key formats don't record this and there's no explicit storage of The only variable thing is the timestamp with the creation date. Everything else is fixed and depends only on the key material. I very well know the pain with the creation date which for example forces the OpenPGP card to have a creation date DO in addition to the fingerprint and in some other cases you need to guess/try the creation date to make a fingerprint form the raw key material. Is your request to leave the timestamp out of a v5 fingerprint computation? That would make some things easier but raises the issue that the owner of the key can change the creation date and only the then broken key signatures and the history of self-signatures would reflect this. > If the keyring format is redefined for the PGPng, I'd really like to see the That is out of scope for the current work. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Oct 5 04:44:46 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 556861AC3DF for ; Mon, 5 Oct 2015 04:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 qwaoi1cZamTU for ; Mon, 5 Oct 2015 04:44:43 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A33561AC3E1 for ; Mon, 5 Oct 2015 04:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1444045482; x=1475581482; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bXS32bCtHp7C7c7bBUy8vTl1OCknG5EAHXQcROVl0n8=; b=pAhR+ddK9wp5ePjkti/q+WBiH/Hl1t9aW7BzNpHExpHYUcYRnbNZKfQx i6inrJ7jcb19Pg0QuEZ8rnylXJmq3SGVqzkj4HDybX3Magcgc6E8m5ULo 6ZkZXGpb9cbGW8vBDjAOK8uZ/4fXIoA/hHYjvCqkoGicIZl3AjIYXrr+0 N4ZE29KSNJpgqfKWp2PpeW9U4yawMdlLb3sCMpIKOzahK+dMl2CdgH1U2 ox64kn9j4KSuNpgnhruGZZlYBqgDXM0a5PFBsIf190IUrzByQHXFb09xh a8NA8zBxDGoX/wTYSzQPP6EzrtJWDMRfAuCNZXzm5RicrlWe9VONLvvcZ A==; X-IronPort-AV: E=Sophos;i="5.17,638,1437393600"; d="scan'208";a="46481437" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 06 Oct 2015 00:44:40 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Tue, 6 Oct 2015 00:44:40 +1300 From: Peter Gutmann To: Werner Koch Thread-Topic: [openpgp] New fingerprint: to v5 or not to v5 Thread-Index: AQHQ/2GfGRFnZAPwNU68Rcs3/4z3Np5cx1Ip Date: Mon, 5 Oct 2015 11:44:39 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B279C6@uxcn10-5.UoA.auckland.ac.nz> References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <87y4fi5wa9.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz>, <8737xp5z45.fsf@vigenere.g10code.de> In-Reply-To: <8737xp5z45.fsf@vigenere.g10code.de> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Watson Ladd , Phillip Hallam-Baker , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Mon, 05 Oct 2015 11:44:45 -0000 Werner Koch writes:=0A= =0A= >Is your request to leave the timestamp out of a v5 fingerprint computation= ?=0A= =0A= Either leave it out or, much better, use an explicit ID stored with the key= =0A= rather than one that's implicitly calculated from various bits and pieces= =0A= surrounding the key. That's how PKCS #15 and (ugh) PKCS #12 do it, it make= s=0A= key lookup much less of a pain and avoids the current lost-key problem wher= e=0A= you can't match up a key to a signature even though it's present and=0A= available.=0A= =0A= >That is out of scope for the current work.=0A= =0A= I can't see anything in the charter that would exclude it, it says the work= =0A= items "include, but are not limited to ...", and specifically allows for wo= rk=0A= that won't unduly delay things and that has support from the WG.=0A= =0A= Peter.= From nobody Mon Oct 5 07:07: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 2E4CD1ACE13 for ; Mon, 5 Oct 2015 07:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 aHjwETHDpdFs for ; Mon, 5 Oct 2015 07:07:54 -0700 (PDT) Received: from mail.uni-sb.de (mail.uni-sb.de [134.96.252.33]) by ietfa.amsl.com (Postfix) with ESMTP id D944B1ACE10 for ; Mon, 5 Oct 2015 07:07:53 -0700 (PDT) Received: from mail.cs.uni-saarland.de (mail.cs.uni-saarland.de [134.96.254.200]) by uni-sb.de (8.14.5/2011051800) with ESMTP id t95E7rov003744; Mon, 5 Oct 2015 16:07:53 +0200 (CEST) Received: from mail-infsec.cs.uni-saarland.de (mail-infsec.cs.uni-saarland.de [134.96.225.250]) by mail.cs.uni-saarland.de (8.14.5/2015101000) with ESMTP id t95E7pEC004392; Mon, 5 Oct 2015 16:07:51 +0200 (CEST) Received: from [192.168.1.52] (static-213-115-182-170.sme.bredbandsbolaget.se [213.115.182.170]) by mail-infsec.cs.uni-saarland.de (Postfix) with ESMTPSA id ACCAA21382; Mon, 5 Oct 2015 16:07:51 +0200 (CEST) To: openpgp@ietf.org, cryptography@metzdowd.com, cfrg@mail.ietf.org From: Jonas Magazinius Message-ID: <56128436.40607@assured.se> Date: Mon, 5 Oct 2015 16:07:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020806050006010304030302" X-DCC-debian-Metrics: mail.cs.uni-saarland.de 1169; Body=3 Fuz1=6 Fuz2=6 Archived-At: Subject: [openpgp] OpenPGP SEIP downgrade attack 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: Mon, 05 Oct 2015 14:07:57 -0000 This is a multi-part message in MIME format. --------------020806050006010304030302 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi, I've recently been analysing the OpenPGP standard and have found that it is vulnerable to a chosen-ciphertext attack to downgrade an SEIP packet to a plain SE packet. Due to the properties of CFB mode and OpenPGP’s predictable message structure, it is possible to switch the SEIP tag to SE, strip the MDC (and signature), and align and manipulate the encrypted packet. The implications are, among others, that an encrypted and signed message can be stripped of its signature and modified arbitrarily, with certain restrictions, by an attacker without knowing the key. This attack also resurrects attacks from as early as 2000 [4,5]. Part of the reason SEIP and MDC was introduced ~15 years ago was to deal with exactly this problem. Looking back at the OpenPGP mailinglist arhive it seems that the correctness of the integrity protection has been questioned now and then over the years [1,2], but it's been maintained that it is secure against this kind of attack [3]. It also seems like thoughts along this line is not new [6], so question remains why it has not been dealt with before. Different implementations handle SE packets differently. GPG throws a warning [3] that the message could have been modified, but other implementations do not differentiate between SE and SEIP. A quick fix for this issue would be to throw an error for all SE packets, though I understand the legacy issues it would bring (as was also suggested [3]). A large part of the problem here is due to CFB mode, but it seems we're stuck with that. It would make sense to use a different mode, but again I understand the legacy issues. To try it out in practice and to see how hard it would be for someone else to come to the same conclusion, I created this challenge: https://0x.nu/ I thought it would be tough to crack, but to my great surprise it was solved in less than 12 hours. So far only one person has solved it though. I was going to submit a paper about the attack, but considering how quickly the challenge was cracked I realised the urgency to report this. The attack in more detail: To start out, some important properties of CFB mode. (Sorry for restating the obvious, it's just for completeness.) 1) A modification of the length of the ciphertext will cause the same effect on the plaintext. Addition of blocks to the ciphertext will extend the plaintext equally. Any number of bytes cut off the end of the ciphertext will cut the same number of bytes from the plaintext. 2) The decryption of a block depends only on the preceding block, regardless of where in the ciphertext it appears. Sequences of blocks can be cut, duplicated, or injected amidst two blocks. (When injecting the surrounding blocks will fail to decrypt correctly, but under the right circumstances that does not matter.) 3) If part of the plaintext is known, the corresponding part of the ciphertext can be modified to produce arbitrary text. It is important to note that none of these properties depend on the encryption key, which implies that knowing the key is not required to abuse them. Now, turning a SEIP packet into a SE packet, can be done in three steps: 1) Changing the tag. 2) Aligning the encrypted blocks to match the resynchronized structure of the SE packet. 3) Ensure correct parsing of the decrypted text into packets. The first step is obvious. To deal with the second step we can abuse property 1 and 2, and simply prepend two bytes to the encrypted string. Because of the resynchronization step in SE packet encryption, these two bytes will only affect decryption of the last two bytes of the IV. The rest of the blocks will now be aligned with the SE structure and decrypt correctly. Because the blocks have been shifted the decrypted text will however not parse correctly due to the now missplaced checkbytes. The last step is to make the decrypted text parse as a set of packets. To parse correctly, the first two bytes of the plaintext must match the header of a packet such that it allows the rest of the text to parse as the original packets. This can be achieved by abusing property 2 and 3. Either, if the first two bytes of plaintext of any block is known, then that block and the preceeding one can be repurposed to create such a packet, or if no plaintext is known it can be bruteforced (given a decryption oracle). Unfortunately OpenPGP packets are very predictable and there are a number of ways this can be done. In fact, if the message is signed it is pretty straight forward because of the predictable one pass signature packet. This is supposed to convey the idea of the attack, but not be a complete recipe on how to do it. If more info is needed on the specifics of the attack in order to fix it, then this can be provided. Best regards, Jonas Magazinius Assured AB, Sweden [1] Is there any published analysis of OpenPGP's MDC? https://www.ietf.org/mail-archive/web/openpgp/current/msg00969.html [2] security fixes (KDF, MDC->MAC)? https://www.ietf.org/mail-archive/web/openpgp/current/msg02841.html [3] Re: security fixes (KDF, MDC->MAC)? - http://www.ietf.org/mail-archive/web/openpgp/current/msg02838.html [4] A Chosen Ciphertext Attack against Several E-Mail Encryption Protocols - USENIX'00 [5] Implementation of Chosen-Ciphertext Attacks against PGP and GnuPG - ISC'02 [6] OpenPGP security analysis - https://www.ietf.org/mail-archive/web/cfrg/current/msg00059.html --------------020806050006010304030302 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi,

I've recently been analysing the OpenPGP standard and have found that it is vulnerable to a chosen-ciphertext attack to downgrade an SEIP packet to a plain SE packet. Due to the properties of CFB mode and OpenPGP’s predictable message structure, it is possible to switch the SEIP tag to SE, strip the MDC (and signature), and align and manipulate the encrypted packet. The implications are, among others, that an encrypted and signed message can be stripped of its signature and modified arbitrarily, with certain restrictions, by an attacker without knowing the key. This attack also resurrects attacks from as early as 2000 [4,5]. Part of the reason SEIP and MDC was introduced ~15 years ago was to deal with exactly this problem. Looking back at the OpenPGP mailinglist arhive it seems that the correctness of the integrity protection has been questioned now and then over the years [1,2], but it's been maintained that it is secure against this kind of attack [3]. It also seems like thoughts along this line is not new [6], so question remains why it has not been dealt with before.

Different implementations handle SE packets differently. GPG throws a warning [3] that the message could have been modified, but other implementations do not differentiate between SE and SEIP. A quick fix for this issue would be to throw an error for all SE packets, though I understand the legacy issues it would bring (as was also suggested [3]). A large part of the problem here is due to CFB mode, but it seems we're stuck with that. It would make sense to use a different mode, but again I understand the legacy issues.

To try it out in practice and to see how hard it would be for someone else to come to the same conclusion, I created this challenge: https://0x.nu/
I thought it would be tough to crack, but to my great surprise it was solved in less than 12 hours. So far only one person has solved it though. I was going to submit a paper about the attack, but considering how quickly the challenge was cracked I realised the urgency to report this.



The attack in more detail:

To start out, some important properties of CFB mode. (Sorry for restating the obvious, it's just for completeness.)
1) A modification of the length of the ciphertext will cause the same effect on the plaintext. Addition of blocks to the ciphertext will extend the plaintext equally. Any number of bytes cut off the end of the ciphertext will cut the same number of bytes from the plaintext.
2) The decryption of a block depends only on the preceding block, regardless of where in the ciphertext it appears. Sequences of blocks can be cut, duplicated, or injected amidst two blocks. (When injecting the surrounding blocks will fail to decrypt correctly, but under the right circumstances that does not matter.)
3) If part of the plaintext is known, the corresponding part of the ciphertext can be modified to produce arbitrary text.

It is important to note that none of these properties depend on the encryption key, which implies that knowing the key is not required to abuse them.

Now, turning a SEIP packet into a SE packet, can be done in three steps:
1) Changing the tag.
2) Aligning the encrypted blocks to match the resynchronized structure of the SE packet.
3) Ensure correct parsing of the decrypted text into packets.
The first step is obvious. To deal with the second step we can abuse property 1 and 2, and simply prepend two bytes to the encrypted string. Because of the resynchronization step in SE packet encryption, these two bytes will only affect decryption of the last two bytes of the IV. The rest of the blocks will now be aligned with the SE structure and decrypt correctly. Because the blocks have been shifted the decrypted text will however not parse correctly due to the now missplaced checkbytes.

The last step is to make the decrypted text parse as a set of packets. To parse correctly, the first two bytes of the plaintext must match the header of a packet such that it allows the rest of the text to parse as the original packets. This can be achieved by abusing property 2 and 3. Either, if the first two bytes of plaintext of any block is known, then that block and the preceeding one can be repurposed to create such a packet, or if no plaintext is known it can be bruteforced (given a decryption oracle). Unfortunately OpenPGP packets are very predictable and there are a number of ways this can be done. In fact, if the message is signed it is pretty straight forward because of the predictable one pass signature packet.

This is supposed to convey the idea of the attack, but not be a complete recipe on how to do it. If more info is needed on the specifics of the attack in order to fix it, then this can be provided.


Best regards,

Jonas Magazinius
Assured AB, Sweden


[1] Is there any published analysis of OpenPGP's MDC? https://www.ietf.org/mail-archive/web/openpgp/current/msg00969.html
[2] security fixes (KDF, MDC->MAC)? https://www.ietf.org/mail-archive/web/openpgp/current/msg02841.html
[3] Re: security fixes (KDF, MDC->MAC)? - http://www.ietf.org/mail-archive/web/openpgp/current/msg02838.html
[4] A Chosen Ciphertext Attack against Several E-Mail Encryption Protocols - USENIX'00
 [5] Implementation of Chosen-Ciphertext Attacks against PGP and GnuPG - ISC'02
[6] OpenPGP security analysis - https://www.ietf.org/mail-archive/web/cfrg/current/msg00059.html
--------------020806050006010304030302-- From nobody Mon Oct 5 07:10:06 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 2310A1ACE20 for ; Mon, 5 Oct 2015 07:10:05 -0700 (PDT) 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 bcfrGmaM1ilC for ; Mon, 5 Oct 2015 07:09:58 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (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 03E8F1ACE1B for ; Mon, 5 Oct 2015 07:09:57 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so116566413wic.1 for ; Mon, 05 Oct 2015 07:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PyXaEPB63cvHQAL9YqwgxoJu8/ZxA2uM9Pu/le0++5w=; b=Sf5eZMA3tAPCqdoKsuhnHFrhde/2vGt0RtKpkh/LRHiPOL09bSzjt/AYmHjJRZvd3+ BgR2H4WST4DimNWuklrAcXVwB6129a+CSlmwxKaaQYgeeSBj+MV0N3fridKm4bUGnpmZ GBehl0kP+tnurQEwm8zyZFJbvKpdpH3GaGR6guBRAN+vB8NVoKKGi6XAu9B1gLuPmFWV xQ1NYqRP7LweyTrOWfIL/qm+JTB1gCFWgNvkjkQlxUhgep8wll5/wsqVN2BuX9t2rbKh eYk5YnQ7hZuQl1wbDX9cGSb/OPsInuzMtsB/f3vcMG6ibqSVpsZ8fgczZkBGyYeoykqj C8yg== MIME-Version: 1.0 X-Received: by 10.180.186.10 with SMTP id fg10mr12203817wic.30.1444054196359; Mon, 05 Oct 2015 07:09:56 -0700 (PDT) Received: by 10.28.51.145 with HTTP; Mon, 5 Oct 2015 07:09:56 -0700 (PDT) In-Reply-To: <56128436.40607@assured.se> References: <56128436.40607@assured.se> Date: Mon, 5 Oct 2015 10:09:56 -0400 Message-ID: From: Watson Ladd To: Jonas Magazinius Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cfrg@mail.ietf.org, IETF OpenPGP , Cryptography Subject: Re: [openpgp] OpenPGP SEIP downgrade attack 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: Mon, 05 Oct 2015 14:10:05 -0000 On Mon, Oct 5, 2015 at 10:07 AM, Jonas Magazinius wrote: > Hi, > > I've recently been analysing the OpenPGP standard and have found that it = is > vulnerable to a chosen-ciphertext attack to downgrade an SEIP packet to a > plain SE packet. Due to the properties of CFB mode and OpenPGP=E2=80=99s = predictable > message structure, it is possible to switch the SEIP tag to SE, strip the > MDC (and signature), and align and manipulate the encrypted packet. The > implications are, among others, that an encrypted and signed message can = be > stripped of its signature and modified arbitrarily, with certain > restrictions, by an attacker without knowing the key. This attack also > resurrects attacks from as early as 2000 [4,5]. Part of the reason SEIP a= nd > MDC was introduced ~15 years ago was to deal with exactly this problem. > Looking back at the OpenPGP mailinglist arhive it seems that the correctn= ess > of the integrity protection has been questioned now and then over the yea= rs > [1,2], but it's been maintained that it is secure against this kind of > attack [3]. It also seems like thoughts along this line is not new [6], s= o > question remains why it has not been dealt with before. > > Different implementations handle SE packets differently. GPG throws a > warning [3] that the message could have been modified, but other > implementations do not differentiate between SE and SEIP. A quick fix for > this issue would be to throw an error for all SE packets, though I > understand the legacy issues it would bring (as was also suggested [3]). = A > large part of the problem here is due to CFB mode, but it seems we're stu= ck > with that. It would make sense to use a different mode, but again I > understand the legacy issues. > > To try it out in practice and to see how hard it would be for someone els= e > to come to the same conclusion, I created this challenge: https://0x.nu/ > I thought it would be tough to crack, but to my great surprise it was sol= ved > in less than 12 hours. So far only one person has solved it though. I was > going to submit a paper about the attack, but considering how quickly the > challenge was cracked I realised the urgency to report this. I don't think we need to fix this, so much as completely redesign the packet format to be correct. If the WG wants to go down this path, I can definitely do it, but we would need to junk a lot. > > > > The attack in more detail: > > To start out, some important properties of CFB mode. (Sorry for restating > the obvious, it's just for completeness.) > > 1) A modification of the length of the ciphertext will cause the same eff= ect > on the plaintext. Addition of blocks to the ciphertext will extend the > plaintext equally. Any number of bytes cut off the end of the ciphertext > will cut the same number of bytes from the plaintext. > > 2) The decryption of a block depends only on the preceding block, regardl= ess > of where in the ciphertext it appears. Sequences of blocks can be cut, > duplicated, or injected amidst two blocks. (When injecting the surroundin= g > blocks will fail to decrypt correctly, but under the right circumstances > that does not matter.) > > 3) If part of the plaintext is known, the corresponding part of the > ciphertext can be modified to produce arbitrary text. > > > It is important to note that none of these properties depend on the > encryption key, which implies that knowing the key is not required to abu= se > them. > > Now, turning a SEIP packet into a SE packet, can be done in three steps: > > 1) Changing the tag. > > 2) Aligning the encrypted blocks to match the resynchronized structure of > the SE packet. > > 3) Ensure correct parsing of the decrypted text into packets. > > The first step is obvious. To deal with the second step we can abuse > property 1 and 2, and simply prepend two bytes to the encrypted string. > Because of the resynchronization step in SE packet encryption, these two > bytes will only affect decryption of the last two bytes of the IV. The re= st > of the blocks will now be aligned with the SE structure and decrypt > correctly. Because the blocks have been shifted the decrypted text will > however not parse correctly due to the now missplaced checkbytes. > > The last step is to make the decrypted text parse as a set of packets. To > parse correctly, the first two bytes of the plaintext must match the head= er > of a packet such that it allows the rest of the text to parse as the > original packets. This can be achieved by abusing property 2 and 3. Eithe= r, > if the first two bytes of plaintext of any block is known, then that bloc= k > and the preceeding one can be repurposed to create such a packet, or if n= o > plaintext is known it can be bruteforced (given a decryption oracle). > Unfortunately OpenPGP packets are very predictable and there are a number= of > ways this can be done. In fact, if the message is signed it is pretty > straight forward because of the predictable one pass signature packet. > > This is supposed to convey the idea of the attack, but not be a complete > recipe on how to do it. If more info is needed on the specifics of the > attack in order to fix it, then this can be provided. > > > Best regards, > > Jonas Magazinius > Assured AB, Sweden > > > [1] Is there any published analysis of OpenPGP's MDC? > https://www.ietf.org/mail-archive/web/openpgp/current/msg00969.html > [2] security fixes (KDF, MDC->MAC)? > https://www.ietf.org/mail-archive/web/openpgp/current/msg02841.html > [3] Re: security fixes (KDF, MDC->MAC)? - > http://www.ietf.org/mail-archive/web/openpgp/current/msg02838.html > [4] A Chosen Ciphertext Attack against Several E-Mail Encryption Protocol= s - > USENIX'00 > [5] Implementation of Chosen-Ciphertext Attacks against PGP and GnuPG - > ISC'02 > [6] OpenPGP security analysis - > https://www.ietf.org/mail-archive/web/cfrg/current/msg00059.html > > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Mon Oct 5 10:40:02 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 6880D1B2A44 for ; Mon, 5 Oct 2015 10:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 6ZdO7P1Ksz5z for ; Mon, 5 Oct 2015 10:39:59 -0700 (PDT) Received: from tus1smtoutpex01.symantec.com (tus1smtoutpex01.symantec.com [216.10.195.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8824C1B2A22 for ; Mon, 5 Oct 2015 10:39:59 -0700 (PDT) X-AuditID: d80ac3f1-f79fd6d0000022fa-2a-5612b5eef18a Received: from tus1smtintpin01.ges.symantec.com (usdu-zone.relay.symantec.com [192.168.215.101]) by tus1smtoutpex01.symantec.com (Symantec Brightmail Gateway out) with SMTP id C6.87.08954.EE5B2165; Mon, 5 Oct 2015 18:39:58 +0100 (BST) Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by tus1smtintpin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1Zj9jy-0007Li-N9; Mon, 05 Oct 2015 17:39:58 +0000 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([155.64.220.150]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Mon, 5 Oct 2015 10:38:47 -0700 From: Neil Hunsperger To: Jonas Magazinius , "openpgp@ietf.org" , "cryptography@metzdowd.com" , "cfrg@mail.ietf.org" Date: Mon, 5 Oct 2015 10:39:33 -0700 Thread-Topic: [openpgp] OpenPGP SEIP downgrade attack Thread-Index: AdD/dznvn+dBJ+g3T5CSY/fL9b5l7QAFm09Q Message-ID: <14D026C7F297AD44AC82578DD818CDD047B949DAE1@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <56128436.40607@assured.se> In-Reply-To: <56128436.40607@assured.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RouteViaPGP: true X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsVyYMX1VN13W4XCDM72G1psPH6GxeJGzwtG i76lTYwWDf8esjuweGy6sZHFY8mSn0wezYvms3lM+9/LFsASxWWTkpqTWZZapG+XwJXxb18j W8E+torpP88wNzCuYOti5OSQEDCReNV6nx3CFpO4cG89UJyLQ0jgLaNE+6Uudjjnwee5jBDO SkaJCZOmMIO0sAG1r53exgRiiwgcZJR4fr8axGYRUJH43rAMqIaDQxio5uwJfogSU4mmZUfY IWwjibnnHrOC2LwCURJf3mwEGyMkoC6x+dYmsDingIZE36+9YKsYga77fmoNWA2zgLjErSfz mSCuFpBYsuc8M4QtKvHy8T9WiHpRiTvt6xlBTmAW0JRYv0sfolVRYkr3Q3aItYISJ2c+YYFo FZZo+/WafQKj+CwkG2YhdM9C0j0LSfcCRpZVjDIlpcWGxbkl+aUlBakVBoZ6xZW5icA4TNZL zs/dxAiMxRtchz/uYDy61/EQowAHoxIPb+Z6oTAh1sQyoMpDjBIczEoivA0dQCHelMTKqtSi /Pii0pzU4kOM0hwsSuK8wlmvQoUE0hNLUrNTUwtSi2CyTBycUg2Mk91jyop/6qYfvXdtufXL G+o3C6MuO6w+VdV+om+dmef26IevGS+4T8l2mXa2X+9R6JVihTvpVRO/5PyYzu6a8Y9BclPJ Co1Su4eih+pXR8yesf/wXGaDQ6cPeD9Z9e75VWn/UO0XP3bx3Ppx/s6L1cESG7kCDjXwX9H5 3qApZVDVJlgqdFx/oxJLcUaioRZzUXEiAPRDdTbBAgAA Archived-At: Subject: Re: [openpgp] OpenPGP SEIP downgrade attack 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: Mon, 05 Oct 2015 17:40:00 -0000 RnJvbTogb3BlbnBncCBbbWFpbHRvOm9wZW5wZ3AtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEpvbmFzIE1hZ2F6aW5pdXMNCj4gSSd2ZSByZWNlbnRseSBiZWVuIGFuYWx5c2luZyB0aGUg T3BlblBHUCBzdGFuZGFyZCBhbmQgaGF2ZSBmb3VuZCB0aGF0IGl0IGlzIHZ1bG5lcmFibGUgdG8g YSBjaG9zZW4tY2lwaGVydGV4dCBhdHRhY2sgdG8gZG93bmdyYWRlIGFuIFNFSVAgcGFja2V0IHRv IGEgcGxhaW4gU0UgcGFja2V0Lg0KDQo+IEkgd2FzIGdvaW5nIHRvIHN1Ym1pdCBhIHBhcGVyIGFi b3V0IHRoZSBhdHRhY2ssIGJ1dCBjb25zaWRlcmluZyBob3cgcXVpY2tseSB0aGUgY2hhbGxlbmdl IHdhcyBjcmFja2VkIEkgcmVhbGlzZWQgdGhlIHVyZ2VuY3kgdG8gcmVwb3J0IHRoaXMuDQoNCkFz c3VtaW5nIFNFIGFuZCBTRUlQIG5vdyBoYXZlIGVxdWl2YWxlbnQgc2VjdXJpdHksIGRvZXMgYW55 b25lIHN1c3BlY3QgYSByZWFsLXdvcmxkIGltcGFjdD8gSS5lLiBpcyB0aGVyZSBzb2Z0d2FyZSB0 aGF0IHRydXN0cyBlbmNyeXB0ZWQgdW5zaWduZWQgZGF0YSBtb3JlIHRoYW4gaXQgdHJ1c3RzIHVu ZW5jcnlwdGVkIHVuc2lnbmVkIGRhdGE/DQoNCi1OZWlsDQo= From nobody Mon Oct 5 11:16:08 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 14EC41B32A6 for ; Mon, 5 Oct 2015 11:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 yXyJhH776aOB for ; Mon, 5 Oct 2015 11:16:05 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EFAD1B328D for ; Mon, 5 Oct 2015 11:16:05 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZjAIs-0004fU-VX for ; Mon, 05 Oct 2015 20:16:03 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZjAGB-0008Jk-Qb; Mon, 05 Oct 2015 20:13:15 +0200 From: Werner Koch To: Jonas Magazinius References: <56128436.40607@assured.se> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Jonas Magazinius , openpgp@ietf.org, cryptography@metzdowd.com, cfrg@mail.ietf.org Date: Mon, 05 Oct 2015 20:13:15 +0200 In-Reply-To: <56128436.40607@assured.se> (Jonas Magazinius's message of "Mon, 5 Oct 2015 16:07:50 +0200") Message-ID: <87y4fh4210.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: cfrg@mail.ietf.org, openpgp@ietf.org, cryptography@metzdowd.com Subject: Re: [openpgp] OpenPGP SEIP downgrade attack 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: Mon, 05 Oct 2015 18:16:07 -0000 On Mon, 5 Oct 2015 16:07, jonas.magazinius@assured.se said: > predictable message structure, it is possible to switch the SEIP tag to > SE, strip the MDC (and signature), and align and manipulate the > protection has been questioned now and then over the years [1,2], but > it's been maintained that it is secure against this kind of attack [3]. Well, I assumed that this is the case (my "Yes") but in the next mail Trevor explained that this is not true. More important however is my remark that we need to get MDC deployed so that we can issue an error for non MDC packets instead of just a warning. AFAIK, there are still implementations not supporting MDC and a small number of folks loudly complaining when I removed PGP-2 support. > A large part of the problem here is due to CFB mode, but it seems we're > stuck with that. It would make sense to use a different mode, but again > I understand the legacy issues. One of the goals of 4880bis is: - A symmetric encryption mechanism that offers modern message integrity protection (AEAD) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Oct 5 14:27:01 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 E58381B5061 for ; Mon, 5 Oct 2015 14:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543] autolearn=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 OwPMIYmDq2h4 for ; Mon, 5 Oct 2015 14:26:59 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6FD21B505D for ; Mon, 5 Oct 2015 14:26:58 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by virulha.pair.com (Postfix) with ESMTPSA id 3C1316D75E; Mon, 5 Oct 2015 17:26:57 -0400 (EDT) To: openpgp@ietf.org References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <87y4fi5wa9.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz> <8737xp5z45.fsf@vigenere.g10code.de> From: ianG Message-ID: <56128637.6030504@iang.org> Date: Mon, 5 Oct 2015 10:16:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <8737xp5z45.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Mon, 05 Oct 2015 21:27:00 -0000 On 5/10/2015 07:33 am, Werner Koch wrote: > On Mon, 5 Oct 2015 12:27, pgut001@cs.auckland.ac.nz said: > Is your request to leave the timestamp out of a v5 fingerprint > computation? Makes sense to me. Or, as it is just a calculation, the 4 octets MUST be set to 0. > That would make some things easier but raises the issue that the owner > of the key can change the creation date and only the then broken key > signatures and the history of self-signatures would reflect this. I don't understand why that is an issue for the fingerprint? >> If the keyring format is redefined for the PGPng, I'd really like to see the > > That is out of scope for the current work. :) Maybe spun off into a separate draft? iang From nobody Mon Oct 5 14:27:11 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 BC6B41B5067 for ; Mon, 5 Oct 2015 14:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543] autolearn=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 q4hrqXhlhB5S for ; Mon, 5 Oct 2015 14:27:09 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 234E01B5066 for ; Mon, 5 Oct 2015 14:27:09 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by virulha.pair.com (Postfix) with ESMTPSA id 388806D75E; Mon, 5 Oct 2015 17:27:08 -0400 (EDT) To: openpgp@ietf.org References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <87y4fi5wa9.fsf@vigenere.g10code.de> <74252.1444016636@eng-mail01.juniper.net> From: ianG Message-ID: <561282D0.5000802@iang.org> Date: Mon, 5 Oct 2015 10:01:52 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <74252.1444016636@eng-mail01.juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Mon, 05 Oct 2015 21:27:09 -0000 On 4/10/2015 23:43 pm, Mark D. Baushke wrote: >> On Sun, 4 Oct 2015 03:50, phill@hallambaker.com said: > ... >> See rfc-4880, 12.2 (Key IDs and fingerprints) > ... >> c) timestamp of key creation (4 octets); > > This reminds me. I suspect we want to move to be explicit that the > timestamp is unsigned during RFC 4880bis, Agreed - redefined to be unsigned. It's timely (pun intended). iang From nobody Mon Oct 5 18:49:49 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 2A3301B3533 for ; Mon, 5 Oct 2015 18:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 K36KzcnwNxeO for ; Mon, 5 Oct 2015 18:49:43 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63DF31B3531 for ; Mon, 5 Oct 2015 18:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1444096183; x=1475632183; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=tbRtOOk4ngON0QHEycV5vFep2h+TsURNj9Vz9a3HGHA=; b=YpttZNUwaD5GOx3KD6Jno3loQVvYmPZykfZnZBDSSS1cO/zehaP0phas HJ8kCd0ZqAVb3oWpvgvO9GVG6CWFse4QXnaNvP3qB2Gr0OUWppufiWu1e sSMuMZY3JOMpHEL9E3g2/rPewq5PYe9U0UgU56NYaXG/kVC29ep3SUBbe irGVdYk3R8Z//bqSkkUJXPKO+idCM4XWX2axC3Z/WXld0ZYtWHbCe96Kq HnFLx9VllssKsLuC7znm9EQAABx87XX8AlYWxSB1xb0nfmrbWXN+QdlqS o3V8AIsfBrHaNOT2tBbu/aKsjJRYmcDY5VQevYs59PyHqfgf4YLo8H6Fc A==; X-IronPort-AV: E=Sophos;i="5.17,641,1437393600"; d="scan'208";a="46650546" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 06 Oct 2015 14:49:41 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Tue, 6 Oct 2015 14:49:41 +1300 From: Peter Gutmann To: Jonas Magazinius , "openpgp@ietf.org" , "cryptography@metzdowd.com" , "cfrg@mail.ietf.org" Thread-Topic: [openpgp] OpenPGP SEIP downgrade attack Thread-Index: AQHQ/3dAIgzGDRicekamqnyxIGnZTZ5dsvDI Date: Tue, 6 Oct 2015 01:49:40 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B28366@uxcn10-5.UoA.auckland.ac.nz> References: <56128436.40607@assured.se> In-Reply-To: <56128436.40607@assured.se> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] OpenPGP SEIP downgrade attack 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: Tue, 06 Oct 2015 01:49:48 -0000 Jonas Magazinius writes:=0A= =0A= >I've recently been analysing the OpenPGP standard and have found that it = =0A= >is vulnerable to a chosen-ciphertext attack to downgrade an SEIP packet = =0A= >to a plain SE packet. =0A= =0A= Nice work!=0A= =0A= >Part of the reason SEIP and MDC was introduced ~15 years ago was to deal = =0A= >with exactly this problem. =0A= =0A= It's always been a quick hack though. I didn't implement MDC for a long = =0A= time because I was waiting for it to be done properly (encrypt-then-MAC),= =0A= but eventually I decided that a hack was better than nothing at all. It's= =0A= really not hard to do properly, just take what CMS / S/MIME did and convert= =0A= the bit-bagging to PGP format [0]. Encrypting a non-keyed hash in CFB mode= =0A= of all things is just asking for trouble.=0A= =0A= >Different implementations handle SE packets differently.=0A= =0A= Is the SEIP -> SE rewrite completely transparent, or are there implementati= on=0A= quirks/peculiarities that make it work in some cases and not others? It'd= =0A= be interesting to have a sample of a SEIP message with its SE rewrite to lo= ok=0A= at.=0A= =0A= Peter.=0A= =0A= [0] It specifically protects against strip-the-MAC/rewrite-the-message =0A= attacks, but if you *can* find an attack I'd be interested in hearing = =0A= about it.= From nobody Mon Oct 5 18:52:03 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 0180E1B2D2C for ; Mon, 5 Oct 2015 18:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Os13J2PNFcge for ; Mon, 5 Oct 2015 18:52:01 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C37C1B2D18 for ; Mon, 5 Oct 2015 18:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1444096320; x=1475632320; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MnbcZ/39N76IhROQ+VgNwuj9F5rOy8aywcVBNklrSsI=; b=KLBwjoTlQsIfz7JwXoek39gTF5YD5Kh482mOXW/BWZz4SqC81g/h8V5P Udgpe31e5lBzNP+GH7af4nc+OHrtPi794XHoaaTXvEA054qP9cbtm/QIk 8Wb8eO9P8NFCNs2pklH2nNrUAN5lzxYJhmtD7BUHP5rQAUFdbDdDvvhxv RRuX12A/YKVex05/Eg5kBayF0Mt/anZScccFe+7ReoOy7RM0BRF4faC5y 7UMdr2KEld1y6pfyaJLX3E9gYUTdOn1UsgQ+iCuFpJACFGx3G1kF/Z9M+ 4s3tQuzAeyBXfBopREDZMmQ9/7w11kduZ1qZJOGDvKv5u0/0Kic6LaRrM Q==; X-IronPort-AV: E=Sophos;i="5.17,641,1437393600"; d="scan'208";a="46650910" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 06 Oct 2015 14:51:59 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Tue, 6 Oct 2015 14:51:58 +1300 From: Peter Gutmann To: Werner Koch , Jonas Magazinius Thread-Topic: [openpgp] OpenPGP SEIP downgrade attack Thread-Index: AQHQ/3dAIgzGDRicekamqnyxIGnZTZ5dNOhtgAB/Q6w= Date: Tue, 6 Oct 2015 01:51:58 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B28383@uxcn10-5.UoA.auckland.ac.nz> References: <56128436.40607@assured.se>,<87y4fh4210.fsf@vigenere.g10code.de> In-Reply-To: <87y4fh4210.fsf@vigenere.g10code.de> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "cfrg@mail.ietf.org" , "openpgp@ietf.org" , "cryptography@metzdowd.com" Subject: Re: [openpgp] OpenPGP SEIP downgrade attack 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: Tue, 06 Oct 2015 01:52:02 -0000 Werner Koch writes:=0A= =0A= >More important however is my remark that we need to get MDC deployed so = =0A= >that we can issue an error for non MDC packets instead of just a warning.= =0A= =0A= We don't need to get it deployed, we need to get it replaced by encrypt-=0A= then-MAC, with the whole handled in a manner where downgrade attacks aren't= =0A= possible.=0A= =0A= Peter.=0A= From nobody Mon Oct 5 19:20:11 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 092A51B359B for ; Mon, 5 Oct 2015 19:20:10 -0700 (PDT) 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, 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 KEC1PhZmbuC2 for ; Mon, 5 Oct 2015 19:20:08 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (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 4F4311B3596 for ; Mon, 5 Oct 2015 19:20:08 -0700 (PDT) Received: by ykdz138 with SMTP id z138so190083354ykd.2 for ; Mon, 05 Oct 2015 19:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=WgszJHpAH6opsdJracIuIUzV1XkTljfhgKmo0b2RQmI=; b=wd75hJjphpp1M2pqyAD+nfmwDKVL9z1nGUyk8tEBVJ8y3LHLYozZglYefLoVzjfnHC hyn+RQAd0k8TK7p9gtyqdhQGEBrhjbgs03J3Wd8w+0d6qLFq8n7rPfPBpXAAu5Tlk8o5 KNohF7k1h4Ku7S/QPhGGgQUdU1s1kh2KpdL7ZRhAqRpw7WJlc1N08KAzgWBAbwnDVAUl 9jsw05OX2zkAHHI98p7w41coDjc1Q/mnUecBHXYLIdPdpsq9UQ/0I9OobuyzFre+U+p8 eg4zzdQyZ35R1osEPW2dpeHBdVDLhHN7WzMpbj/SMpPVwahG4onMF5QW2K0kHkAjn+Pe kssQ== X-Received: by 10.129.49.149 with SMTP id x143mr27917364ywx.147.1444098007547; Mon, 05 Oct 2015 19:20:07 -0700 (PDT) MIME-Version: 1.0 References: <56128436.40607@assured.se> <87y4fh4210.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B28383@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B28383@uxcn10-5.UoA.auckland.ac.nz> From: David Leon Gil Date: Tue, 06 Oct 2015 02:19:58 +0000 Message-ID: To: Peter Gutmann , Werner Koch , Jonas Magazinius Content-Type: multipart/alternative; boundary=001a1140781ec2c68f052166446e Archived-At: Cc: "cfrg@mail.ietf.org" , "openpgp@ietf.org" , "cryptography@metzdowd.com" Subject: Re: [openpgp] OpenPGP SEIP downgrade attack 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: Tue, 06 Oct 2015 02:20:10 -0000 --001a1140781ec2c68f052166446e Content-Type: text/plain; charset=UTF-8 This is a very nice explanation of the downgrade attack. I suspect that its discovery predates your work: See https://github.com/google/end-to-end/issues/161 (scroll down a bit) for a bug where I note it. On Mon, Oct 5, 2015 at 6:52 PM Peter Gutmann wrote: > Werner Koch writes: > > >More important however is my remark that we need to get MDC deployed so > >that we can issue an error for non MDC packets instead of just a warning. > > We don't need to get it deployed, we need to get it replaced by encrypt- > then-MAC, with the whole handled in a manner where downgrade attacks aren't > possible. > > Peter. > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --001a1140781ec2c68f052166446e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is a very nice explanation of the downgrade attack. I suspect that its= discovery predates your work: See https://github.com/google/end-to-end/issues/161 (sc= roll down a bit) for a bug where I note it.

On Mon, Oct 5, 2015 at 6:52 PM Peter Gutmann <pgut001@cs.auckland.ac.nz> wr= ote:
Werner Koch <wk@gnupg.org> writes:

>More important however is my remark that we need to get MDC deployed so=
>that we can issue an error for non MDC packets instead of just a warnin= g.

We don't need to get it deployed, we need to get it replaced by encrypt= -
then-MAC, with the whole handled in a manner where downgrade attacks aren&#= 39;t
possible.

Peter.

_______________________________________________
openpgp mailing list
openpgp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/openpgp
--001a1140781ec2c68f052166446e-- From nobody Mon Oct 5 23:51:07 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 22E421B2E4F for ; Mon, 5 Oct 2015 23:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Pwp4QhcFhvA2 for ; Mon, 5 Oct 2015 23:51:05 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F9F1B2E50 for ; Mon, 5 Oct 2015 23:51:04 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZjM5W-0007U7-Vb for ; Tue, 06 Oct 2015 08:51:03 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZjM4a-0001f9-N1; Tue, 06 Oct 2015 08:50:04 +0200 From: Werner Koch To: ianG References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <87y4fi5wa9.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz> <8737xp5z45.fsf@vigenere.g10code.de> <56128637.6030504@iang.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: ianG , openpgp@ietf.org Date: Tue, 06 Oct 2015 08:50:04 +0200 In-Reply-To: <56128637.6030504@iang.org> (iang@iang.org's message of "Mon, 5 Oct 2015 10:16:23 -0400") Message-ID: <87oagc4hk3.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Tue, 06 Oct 2015 06:51:07 -0000 On Mon, 5 Oct 2015 16:16, iang@iang.org said: >> That would make some things easier but raises the issue that the owner >> of the key can change the creation date and only the then broken key >> signatures and the history of self-signatures would reflect this. > > I don't understand why that is an issue for the fingerprint? Because that changes the behaviour in the error cases. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Oct 6 00:01:07 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 AD8921A8AD6 for ; Tue, 6 Oct 2015 00:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 hM8AgA91_Oi7 for ; Tue, 6 Oct 2015 00:01:05 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8C1A1A8AD4 for ; Tue, 6 Oct 2015 00:01:05 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZjMFD-0007Xe-Ax for ; Tue, 06 Oct 2015 09:01:03 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZjMA7-0001gK-Ez; Tue, 06 Oct 2015 08:55:47 +0200 From: Werner Koch To: Peter Gutmann References: <56128436.40607@assured.se> <87y4fh4210.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B28383@uxcn10-5.UoA.auckland.ac.nz> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Peter Gutmann , Jonas Magazinius , "cfrg\@mail.ietf.org" , "openpgp\@ietf.org" , "cryptography\@metzdowd.com" Date: Tue, 06 Oct 2015 08:55:47 +0200 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B28383@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Tue, 6 Oct 2015 01:51:58 +0000") Message-ID: <87k2r04hak.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: "cfrg@mail.ietf.org" , Jonas Magazinius , "cryptography@metzdowd.com" , "openpgp@ietf.org" Subject: Re: [openpgp] OpenPGP SEIP downgrade attack 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: Tue, 06 Oct 2015 07:01:06 -0000 On Tue, 6 Oct 2015 03:51, pgut001@cs.auckland.ac.nz said: > We don't need to get it deployed, we need to get it replaced by encrypt- > then-MAC, with the whole handled in a manner where downgrade attacks aren't > possible. And wait another 15 years until it has been taken up by all implementations? What is wrong with the planned AE mode? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Oct 6 01:06:07 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 387BE1B3B46 for ; Tue, 6 Oct 2015 01:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 wa2FDTWUBTUN for ; Tue, 6 Oct 2015 01:06:04 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADD881B3B43 for ; Tue, 6 Oct 2015 01:06:04 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZjNG6-0000lF-R8 for ; Tue, 06 Oct 2015 10:06:02 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZjNBM-0001qA-LY; Tue, 06 Oct 2015 10:01:08 +0200 From: Werner Koch To: Peter Gutmann References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <87y4fi5wa9.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz> <8737xp5z45.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B279C6@uxcn10-5.UoA.auckland.ac.nz> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Peter Gutmann , Watson Ladd , Phillip Hallam-Baker , Daniel Kahn Gillmor , IETF OpenPGP Date: Tue, 06 Oct 2015 10:01:08 +0200 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B279C6@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Mon, 5 Oct 2015 11:44:39 +0000") Message-ID: <87fv1o4e9n.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: Watson Ladd , Phillip Hallam-Baker , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Tue, 06 Oct 2015 08:06:06 -0000 On Mon, 5 Oct 2015 13:44, pgut001@cs.auckland.ac.nz said: > Either leave it out or, much better, use an explicit ID stored with the key > rather than one that's implicitly calculated from various bits and pieces That explicit ID sounds pretty much like a issuer+serialno or one of the other X.509 methods to identify a key. It is not a fingerprint as we know it and it can't be used as a secure identification of the key. > surrounding the key. That's how PKCS #15 and (ugh) PKCS #12 do it, it makes > key lookup much less of a pain and avoids the current lost-key problem where > you can't match up a key to a signature even though it's present and Lost key? Do you mean missing Issuer subpacket (5.2.3.5) or one pointing two keys with duplicated long keyids? I have never seen the former and in any case I would consider this a corrupted message. To fix the latter we will certainly define the use of a fingerprint. > I can't see anything in the charter that would exclude it, it says the work > items "include, but are not limited to ...", and specifically allows for work > that won't unduly delay things and that has support from the WG. Changing the entire packet structure is not an easy thing and definitely would delay the listed goals. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Oct 6 02:03:53 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 1634D1A6F93 for ; Tue, 6 Oct 2015 02:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 1blNLT2UXh89 for ; Tue, 6 Oct 2015 02:03:50 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 62D551A6F86 for ; Tue, 6 Oct 2015 02:03:49 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t9693WJe032728 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 6 Oct 2015 11:03:33 +0200 Date: Tue, 6 Oct 2015 11:03:30 +0200 From: Simon Josefsson To: Tom Ritter Message-ID: <20151006110330.38b38ea4@latte.josefsson.org> In-Reply-To: References: <878u84zy4r.fsf@vigenere.g10code.de> <55FD7CF0.8030200@iang.org> <87io742kz7.fsf@latte.josefsson.org> <87mvw4ctv5.fsf_-_@vigenere.g10code.de> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/KTo922B.AG3JusNSwa7949H"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: IETF OpenPGP , ianG Subject: Re: [openpgp] New fingerprint: which hash algo (was: to v5 or not to v5) 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: Tue, 06 Oct 2015 09:03:52 -0000 --Sig_/KTo922B.AG3JusNSwa7949H Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable > On 30 September 2015 at 01:18, Werner Koch wrote: > > On Mon, 21 Sep 2015 11:13, simon@josefsson.org said: > > > >> Regarding which hash to use, SHA-256 is probably the simplest > >> choice From a practicallity and consensus point of view. Are > >> there any strong reasons to favor something else? >=20 > I have a small preference to see the fingerprint algorithm match what > we believe the most popular signature (hash) algorithm will be. I've > been working with a number of embedded folks and code size can often > be a big concern. More Algorithms, More Code. My perception is that the most popular signature hash algorithms right now are SHA-256 and SHA-512. While SHA-256 and SHA-512 have somewhat different characteristics on different platforms, I believe we are approaching the limit of where a lot of additional comparisons are worth the time and effort compared to just pick one of them. I'm fine with SHA-256 for the reasons that Werner presented. Does someone else want to promote another option? Can we get closure on this? /Simon --Sig_/KTo922B.AG3JusNSwa7949H Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWE45jAAoJEIYLf7sy+BGd0W4H/RBcJJ3OsRTbuxrvgt8L/4FK 9y18Uh5HcGs8o5IN2uJ03eq+bUf3pr7blIeHfFf5iSKXL4PH2WSYrqQ6R6r2xPjD YErcGJ/Xur3PmOoMaiPsD0ryQgWJ65q7GlNrKp8xuxCpYCczk+Bj0cVGV6AY20Y4 xUUykDTlIrz0Sa5gI09Wy0alHKMMPvfw9I2QrSKgi0l1D8PSqOAgqWviwmOmVaYY C7WN0zV+STrmGDBAceLmEk5bxxPZdPSbPSGY74zCiHmOeVtIAEu9EhJoidx2lPSl cqoGmFUy60Xs2E+IH2ri79OZIKGv6AZxSDDpaBsJy4qNXtslXVsn8V7nUqZoIzs= =4kIh -----END PGP SIGNATURE----- --Sig_/KTo922B.AG3JusNSwa7949H-- From nobody Wed Oct 7 06:51:14 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 3E7D21A90AA for ; Wed, 7 Oct 2015 06:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 cc10prXGptT6 for ; Wed, 7 Oct 2015 06:50:55 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E1D1A90B2 for ; Wed, 7 Oct 2015 06:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1444225855; x=1475761855; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aNGOv2eBa8UkksvxPC2PSL8e8ZxQhcH6Rg6V5syOou8=; b=DD8J3tYm+r1bUgq4mg9i4+wYhaIj02v2sfSHnrsMWkfpp3MgD29IJKs4 NWvKMPigwnRRu1NdaA76/rV3miE5hLAqqbtQBtoqy/x03KBUbFyi7W6xp Xvz7KNwKZYGkyHQspAhc5zqj0DU7eoGLpNQHujQYchLsFXChB/H5h6+tB TCOBQm7w0zPkHVvX1zkvkIgsr83EUaYl6hZYeNTK2LeY1SXdec3834FpE ZAEpbC7kcRqiSR66thymXTILPZo0I8VuTUuBGpAM5CFW93T4REpSIxp64 pB0r2w5f1N3v4b+1E5l9Bcz4rGCqmXLaM2XtpYQKBYzfljelZAFWcpAuf Q==; X-IronPort-AV: E=Sophos;i="5.17,649,1437393600"; d="scan'208";a="47102553" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 08 Oct 2015 02:50:52 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Thu, 8 Oct 2015 02:50:52 +1300 From: Peter Gutmann To: Werner Koch Thread-Topic: [openpgp] OpenPGP SEIP downgrade attack Thread-Index: AQHQ/3dAIgzGDRicekamqnyxIGnZTZ5eCp4tgAIEspQ= Date: Wed, 7 Oct 2015 13:50:52 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B2C5B4@uxcn10-5.UoA.auckland.ac.nz> References: <56128436.40607@assured.se> <87y4fh4210.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B28383@uxcn10-5.UoA.auckland.ac.nz>, <87k2r04hak.fsf@vigenere.g10code.de> In-Reply-To: <87k2r04hak.fsf@vigenere.g10code.de> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "cfrg@mail.ietf.org" , Jonas Magazinius , "cryptography@metzdowd.com" , "openpgp@ietf.org" Subject: Re: [openpgp] OpenPGP SEIP downgrade attack 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, 07 Oct 2015 13:50:59 -0000 Werner Koch writes:=0A= =0A= >And wait another 15 years until it has been taken up by all implementation= s?=0A= >What is wrong with the planned AE mode?=0A= =0A= Which has just as little support as a planned EtM mode? =0A= =0A= The reason why I prefer EtM is that it can be pretty trivially retrofitted = to=0A= existing crypto (just add a SHA-256 MAC somewhere) and is compatible with a= ny=0A= existing cipher, while whatever AEAD mechanism is chosen (I'm guessing AES-= =0A= GCM, which seems to be fashionable) is purely for AES, there's no Twofish o= r=0A= CAST or whatever AEAD mode defined.=0A= =0A= Peter.=0A= From nobody Wed Oct 7 07:03:28 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 A4F861A90AD for ; Wed, 7 Oct 2015 07:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 wN7LLFMbin_7 for ; Wed, 7 Oct 2015 07:03:06 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA101A9109 for ; Wed, 7 Oct 2015 07:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1444226561; x=1475762561; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yxzAMIJBXrElxDhOFiNfm6h7aFefMnX9aCcguYgYoR0=; b=1a3LAOPw1T8oZHdOnlK1aH9XM7v+mdLnLVZ7UnBdPsNsSyHCQT2VGoO6 p/RstwPMUS3m/OihgIHhZfdj5g9TG6tUq1qBkcSSV90jDYOkbNOj43LXp s7Pmb6xADLMul/7YnP/NoEPYbDzbHpzd5e4XB5UQButZrp3EkmBtPp8yF LlvcBvRtnkeocgSMErIXlhI0v7qlZ8CQofPOyhIZpC3HiiEOL5Btr61ia nZ9/0RPIDenp6LxaKfW+rxOoN8phHNbIaCu4Dv7hS+Yih5Qkw3d73WoC3 uPn64jO//tnLgBYfjEF9MIuPjSXnJUyiQukvdUbjaaXzeJMXMxk2fyXXl A==; X-IronPort-AV: E=Sophos;i="5.17,649,1437393600"; d="scan'208";a="47105360" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 08 Oct 2015 03:02:19 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Thu, 8 Oct 2015 03:02:18 +1300 From: Peter Gutmann To: Werner Koch Thread-Topic: [openpgp] New fingerprint: to v5 or not to v5 Thread-Index: AQHRAA0oGRFnZAPwNU68Rcs3/4z3Np5gESqI Date: Wed, 7 Oct 2015 14:02:17 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B2C5EE@uxcn10-5.UoA.auckland.ac.nz> References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <87y4fi5wa9.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz> <8737xp5z45.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B279C6@uxcn10-5.UoA.auckland.ac.nz>, <87fv1o4e9n.fsf@vigenere.g10code.de> In-Reply-To: <87fv1o4e9n.fsf@vigenere.g10code.de> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Watson Ladd , Phillip Hallam-Baker , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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, 07 Oct 2015 14:03:08 -0000 Werner Koch writes:=0A= =0A= >That explicit ID sounds pretty much like a issuer+serialno or one of the= =0A= >other X.509 methods to identify a key. It is not a fingerprint as we know= it=0A= >and it can't be used as a secure identification of the key.=0A= =0A= It works quite well as a unique identifier for a key. The problem here is= =0A= that PGP makes the same mistake that's made in things like credit cards and= =0A= SSNs, where you've got a magic value that's supposed to be both a unique=0A= identifier (public) and an authentication/authorisation value (private).=0A= =0A= X.509 handles this by having two distinct things, a unique identifier=0A= (subjectKeyIdentifier) to identify a key, and a fingerprint (hash of the ce= rt)=0A= to verify its integrity or whatever it is you want to do with it.=0A= =0A= PGP in contrast confuses the two, so you have a supposedly unique identifie= r=0A= that hashes in a mutable value (the time) but then doesn't hash in other=0A= important information like the user ID associated with the key. So it does= n't=0A= work very well either as an identifier or as an integrity-check value.=0A= =0A= The fix would be to have two distinct values, a unique identifier (64 or 12= 8=0A= bits of whatever) to uniquely identify a key, and then a fingerprint that= =0A= covers the key, subkey(s), user ID(s), attributes, and whatnot, to check th= at=0A= you've got what you were expecting to get.=0A= =0A= >Lost key? =0A= =0A= The key is present somewhere on the keyring but the date has changed, so yo= u=0A= can't locate it by key ID any more because the date hashed into the other b= its=0A= and pieces changes the key ID.=0A= =0A= Peter.= From nobody Wed Oct 7 12:36:10 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 5F5341B2F65 for ; Wed, 7 Oct 2015 12:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 9A5CDCQt_MRf for ; Wed, 7 Oct 2015 12:36:06 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D63A01B29A8 for ; Wed, 7 Oct 2015 12:36:05 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZjuVP-0000DB-NG for ; Wed, 07 Oct 2015 21:36:03 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZjuT0-0006jv-Ts; Wed, 07 Oct 2015 21:33:34 +0200 From: Werner Koch To: Peter Gutmann References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <87y4fi5wa9.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz> <8737xp5z45.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B279C6@uxcn10-5.UoA.auckland.ac.nz> <87fv1o4e9n.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2C5EE@uxcn10-5.UoA.auckland.ac.nz> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Peter Gutmann , Watson Ladd , Phillip Hallam-Baker , Daniel Kahn Gillmor , IETF OpenPGP Date: Wed, 07 Oct 2015 21:33:34 +0200 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B2C5EE@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Wed, 7 Oct 2015 14:02:17 +0000") Message-ID: <87wpuy1njl.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: Watson Ladd , Phillip Hallam-Baker , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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, 07 Oct 2015 19:36:08 -0000 On Wed, 7 Oct 2015 16:02, pgut001@cs.auckland.ac.nz said: > X.509 handles this by having two distinct things, a unique identifier > (subjectKeyIdentifier) to identify a key, and a fingerprint (hash of the cert) Which is not defined by any standard. > PGP in contrast confuses the two, so you have a supposedly unique identifier > that hashes in a mutable value (the time) but then doesn't hash in other > important information like the user ID associated with the key. So it doesn't As you surely know PGP can't add the user ID because the user id is attached to the key so that you can add or remove user ids. > The fix would be to have two distinct values, a unique identifier (64 or 128 > bits of whatever) to uniquely identify a key, and then a fingerprint that > covers the key, subkey(s), user ID(s), attributes, and whatnot, to check that > you've got what you were expecting to get. It will only take a few days until the first wags create multiple different keys with the same identifier to confuse software. Think of the collisions in 64 bit key ids which will sooner or later lead to problems in current OpenPGP. Let's call your proposed system UnDER.509. >>Lost key? > > The key is present somewhere on the keyring but the date has changed, so you > can't locate it by key ID any more because the date hashed into the other bits > and pieces changes the key ID. I call this corrupt data. The self-signature would not verify and thus the key is unusable. Time to remember where you stored the backup. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Oct 7 12:41:07 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 872B61B2F80 for ; Wed, 7 Oct 2015 12:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 QEuspMjxtlfH for ; Wed, 7 Oct 2015 12:41:05 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CB231AD2A9 for ; Wed, 7 Oct 2015 12:41:05 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZjuaF-0000GD-NL for ; Wed, 07 Oct 2015 21:41:03 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZjuX4-0006kt-CW; Wed, 07 Oct 2015 21:37:46 +0200 From: Werner Koch To: Peter Gutmann References: <56128436.40607@assured.se> <87y4fh4210.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B28383@uxcn10-5.UoA.auckland.ac.nz> <87k2r04hak.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2C5B4@uxcn10-5.UoA.auckland.ac.nz> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Peter Gutmann , "cfrg\@mail.ietf.org" , Jonas Magazinius , "cryptography\@metzdowd.com" , "openpgp\@ietf.org" Date: Wed, 07 Oct 2015 21:37:45 +0200 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B2C5B4@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Wed, 7 Oct 2015 13:50:52 +0000") Message-ID: <87si5m1ncm.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: "cfrg@mail.ietf.org" , Jonas Magazinius , "cryptography@metzdowd.com" , "openpgp@ietf.org" Subject: Re: [openpgp] OpenPGP SEIP downgrade attack 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, 07 Oct 2015 19:41:06 -0000 On Wed, 7 Oct 2015 15:50, pgut001@cs.auckland.ac.nz said: > The reason why I prefer EtM is that it can be pretty trivially retrofitted to > existing crypto (just add a SHA-256 MAC somewhere) and is compatible with any But raises the same problems as all data format changes. When taking up these trouble why got for a slow method whilst faster methods are available. > existing cipher, while whatever AEAD mechanism is chosen (I'm guessing AES- > GCM, which seems to be fashionable) is purely for AES, there's no Twofish or > CAST or whatever AEAD mode defined. OCB works with all 128 bit block length ciphers and is faster than GCM. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Oct 7 15:21:46 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 4B9051B2A09 for ; Wed, 7 Oct 2015 15:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 Cb3w_mmvzzZw for ; Wed, 7 Oct 2015 15:21:43 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id DBF691B2A05 for ; Wed, 7 Oct 2015 15:21:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 4E502844075E; Wed, 7 Oct 2015 15:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSUEObMXcWU2; Wed, 7 Oct 2015 15:21:33 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 15948844073E; Wed, 7 Oct 2015 15:21:33 -0700 (PDT) Received: from [10.119.74.214] ([64.120.47.67]) by keys.merrymeet.com (PGP Universal service); Wed, 07 Oct 2015 15:21:33 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 07 Oct 2015 15:21:33 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Jon Callas In-Reply-To: <87si5m1ncm.fsf@vigenere.g10code.de> Date: Wed, 7 Oct 2015 15:21:23 -0700 Message-Id: <14D252D1-28DC-4C37-9C07-2B8637A1AF89@callas.org> References: <56128436.40607@assured.se> <87y4fh4210.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B28383@uxcn10-5.UoA.auckland.ac.nz> <87k2r04hak.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2C5B4@uxcn10-5.UoA.auckland.ac.nz> <87si5m1ncm.fsf@vigenere.g10code.de> To: Werner Koch X-Mailer: Apple Mail (2.2104) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "cfrg@mail.ietf.org" , "openpgp@ietf.org" , "cryptography@metzdowd.com" , Jon Callas , Peter Gutmann , Jonas Magazinius Subject: Re: [openpgp] OpenPGP SEIP downgrade attack 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, 07 Oct 2015 22:21:45 -0000 > On Oct 7, 2015, at 12:37 PM, Werner Koch wrote: > OCB works with all 128 bit block length ciphers and is faster than = GCM. So does CCM, and CCM has no intellectual property issues, nor GCM's = brittleness. Jon From nobody Thu Oct 8 07:59:24 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 EDC6C1A21AA for ; Thu, 8 Oct 2015 07:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 YT9tTWQEX-4f for ; Thu, 8 Oct 2015 07:59:18 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6079D1A1AE3 for ; Thu, 8 Oct 2015 07:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1444316358; x=1475852358; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XyGQB8tZ1D+OMwTCHP6/v/42GDr8afh/FTMbU2UgYes=; b=xqKh8NO2fpxA/F/PbQT5eFPWvcWfeRh2qGOxX8G3zVlO575vTxvleLAa cTpbtPA3YHZIueDhbyiEDwBvynKrzHX97ITyq1IyYTuRjsftIM5g6pRql l3x4p6kovG/Eb+MyJ6HkKptChmE9TsnOVkz671RK3GfuR9+lzK8UMQiVY 9mfIApx/iWwptx9acHsc/4nvHQMz3ys1KJJiSWENVTpmSUgQaz75q9FKF J3nkVAH3b5gZtTcREw/9hzEQ/ibKq0V+6hrzxXVrdtAOY2F+o/FTqqeBa M3TgIKi1Bgr+Uqpq6V+s3VR1W+w/G1cVKHJ/fTqYhEwKZ+f/SALRoEhND Q==; X-IronPort-AV: E=Sophos;i="5.17,655,1437393600"; d="scan'208";a="47360665" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 09 Oct 2015 03:59:16 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Fri, 9 Oct 2015 03:59:16 +1300 From: Peter Gutmann To: Werner Koch Thread-Topic: [openpgp] OpenPGP SEIP downgrade attack Thread-Index: AQHQ/3dAIgzGDRicekamqnyxIGnZTZ5gcUt1gAFDQuw= Date: Thu, 8 Oct 2015 14:59:15 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B2D532@uxcn10-5.UoA.auckland.ac.nz> References: <56128436.40607@assured.se> <87y4fh4210.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B28383@uxcn10-5.UoA.auckland.ac.nz> <87k2r04hak.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2C5B4@uxcn10-5.UoA.auckland.ac.nz>, <87si5m1ncm.fsf@vigenere.g10code.de> In-Reply-To: <87si5m1ncm.fsf@vigenere.g10code.de> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "cfrg@mail.ietf.org" , Jonas Magazinius , "cryptography@metzdowd.com" , "openpgp@ietf.org" Subject: Re: [openpgp] OpenPGP SEIP downgrade attack 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: Thu, 08 Oct 2015 14:59:23 -0000 Werner Koch writes:=0A= =0A= >When taking up these trouble why got for a slow method whilst faster metho= ds=0A= >are available.=0A= =0A= AES-GCM is only fast on CPUs with dedicated hardware support for it (PCLMUL= QDQ=0A= on x86), it's actually quite slow in pure software (on x86 the slowdown is= =0A= about an order of magnitude). The figures are really all over the place=0A= depending on what system it's running on, so it's a bit hard to generalise = any=0A= statement about it.=0A= =0A= (It's also not clear whether someone encrypting a 10k email message with PG= P=0A= is going to notice it being processed at 100MB/s or 150MB/s).=0A= =0A= >OCB works with all 128 bit block length ciphers and is faster than GCM.=0A= =0A= It's also a lot more patented than GCM.=0A= =0A= (I actually really like OCB and don't like GCM much, but the patent situati= on=0A= makes it pretty problematic).=0A= =0A= Peter.=0A= From nobody Thu Oct 8 08:17:14 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 8EB401A6F8E for ; Thu, 8 Oct 2015 08:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_FILL_THIS_FORM_SHORT=0.01, 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 fQYTIuXw3szv for ; Thu, 8 Oct 2015 08:17:11 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB86F1A8AFE for ; Thu, 8 Oct 2015 08:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1444317413; x=1475853413; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kMBlks9YgNp5UOgXUVB2oNF6WZszauGD95NrlfNLaXk=; b=hAqtxq9CSkNg8OhYAOO+/K1cJj8+OSZX5meCKkhjHnTzzdnvr/ngGFAU AGRH7dWganqVmFilxCD88RyO6pLCm04GjOTb1mauBHcIAs5yt95BNd/wy eZC7cAs4F19AwM1Nvvb38apG5T1Atowg1v7iOFDLCHduAWOjwDQvF8i1M NH+L2G8C3T2WSFh93eDtKoqCnqYuvhLx7xQhggF8YspM6bxeBNfN/4ZLk TbVsuq5m8LLUtYxZoBT2v40SQLgKVNvtyId9G9+GFo+QmxUbeD6U9RGwC 7WNmTqIR97PZCeNx9maWILwv8r+DmG2sJwR1LdfX0gB+EEC2VtI+y9jMj g==; X-IronPort-AV: E=Sophos;i="5.17,655,1437393600"; d="scan'208";a="47361759" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe2.UoA.auckland.ac.nz) ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 09 Oct 2015 04:16:52 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Fri, 9 Oct 2015 04:16:52 +1300 From: Peter Gutmann To: Werner Koch Thread-Topic: [openpgp] New fingerprint: to v5 or not to v5 Thread-Index: AQHRATcNGRFnZAPwNU68Rcs3/4z3Np5hta52 Date: Thu, 8 Oct 2015 15:16:50 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B2D5B1@uxcn10-5.UoA.auckland.ac.nz> References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <87y4fi5wa9.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz> <8737xp5z45.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B279C6@uxcn10-5.UoA.auckland.ac.nz> <87fv1o4e9n.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2C5EE@uxcn10-5.UoA.auckland.ac.nz>, <87wpuy1njl.fsf@vigenere.g10code.de> In-Reply-To: <87wpuy1njl.fsf@vigenere.g10code.de> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Watson Ladd , Phillip Hallam-Baker , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Thu, 08 Oct 2015 15:17:12 -0000 Werner Koch writes:=0A= =0A= >Which is not defined by any standard.=0A= =0A= You don't need a standard to tell you that a SHA-1 hash of a certificate is= =0A= obtained by taking a certificate and hashing it with SHA-1. Pretty much=0A= everything has supported this for years, typically under the name of=0A= certificate fingerprint.=0A= =0A= >It will only take a few days until the first wags create multiple differen= t=0A= >keys with the same identifier to confuse software.=0A= =0A= X.509 has been using this mechanism for about twenty years without any=0A= problems. Sure, someone could do that, but what would they gain by it? Th= e=0A= same wags could create a key with a colliding email address attached to it,= =0A= and they've been able to do that for twenty years as well but the world has= n't=0A= ended because of it.=0A= =0A= >I call this corrupt data. The self-signature would not verify and thus th= e=0A= >key is unusable. Time to remember where you stored the backup.=0A= =0A= It's not corrupted, someone just updated their key info, the signatures on = the=0A= new key data are all valid. The fact that the exact same key that was used= =0A= earlier, with the exact same name/email address attached to it, now has a= =0A= totally different identifier associated with it, is a problem with how PGP= =0A= identifiers are handled. No data corruption has taken place.=0A= =0A= Peter.=0A= From nobody Thu Oct 8 08:46:09 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 D95831A908D for ; Thu, 8 Oct 2015 08:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_FILL_THIS_FORM_SHORT=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 ehCFfUHYbISu for ; Thu, 8 Oct 2015 08:46:06 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB8231A908C for ; Thu, 8 Oct 2015 08:46:05 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZkDOO-00085f-6G for ; Thu, 08 Oct 2015 17:46:04 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZkDKU-00010p-Ap; Thu, 08 Oct 2015 17:42:02 +0200 From: Werner Koch To: Peter Gutmann References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <87y4fi5wa9.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz> <8737xp5z45.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B279C6@uxcn10-5.UoA.auckland.ac.nz> <87fv1o4e9n.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2C5EE@uxcn10-5.UoA.auckland.ac.nz> <87wpuy1njl.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2D5B1@uxcn10-5.UoA.auckland.ac.nz> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Peter Gutmann , Watson Ladd , Phillip Hallam-Baker , Daniel Kahn Gillmor , IETF OpenPGP Date: Thu, 08 Oct 2015 17:42:01 +0200 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B2D5B1@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Thu, 8 Oct 2015 15:16:50 +0000") Message-ID: <87bnc91i5y.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: Watson Ladd , Phillip Hallam-Baker , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Thu, 08 Oct 2015 15:46:08 -0000 On Thu, 8 Oct 2015 17:16, pgut001@cs.auckland.ac.nz said: > X.509 has been using this mechanism for about twenty years without any > problems. Sure, someone could do that, but what would they gain by it? The YMMV: I have seen serial number re-use for different keys done by official CAs more than once. >>I call this corrupt data. The self-signature would not verify and thus the >>key is unusable. Time to remember where you stored the backup. > > It's not corrupted, someone just updated their key info, the signatures on the What do you mean by "key info". > new key data are all valid. The fact that the exact same key that was used > earlier, with the exact same name/email address attached to it, now has a > totally different identifier associated with it, is a problem with how PGP > identifiers are handled. No data corruption has taken place. You mean the binding signatures verify okay but the key is different? If that is the case you found a bug in the software. You can't change the creation date, the key material, the user id or the hashed signature subpackets without invalidating the corresponding self-signature. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Thu Oct 8 08:52:17 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 EE7F11A90A4 for ; Thu, 8 Oct 2015 08:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 MDb0skSGDcm8 for ; Thu, 8 Oct 2015 08:52:12 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5532F1A90AB for ; Thu, 8 Oct 2015 08:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1444319532; x=1475855532; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hUg8NKbkrYKRhWayLRgOnzM1kU/DYhbz/UwN7aEFomY=; b=uGqkV1NNELM1oe7p3mYPSvrQ4JtOTvOHzeTnYOmmXBu9VyGVwySd9vFx Q6aahUJNJaojDUSlooKoUadgMwEiDGq4m8I17nOV/3U6betPeuKWo4Hyh UX+mtyJNLW9aw9jFaDczheNLYy3QEo7Y4quDnycj2nHRF3oJsgMseFw/F 5RImE+LtRVrKeJVyCmFGBJRvnlosRpgrI/Oz5ZMweGkkePF31Hv4kQMzh dsdpgYRbDPrzBSHegVyqbpkwmzEfRUbpwb6NUkp0fGo8mvB7d6NzJsKvF FDcziZuV3A1UYJeNI1Dlljy11KBrlCkRcmpVfw91Wevo9WfONYP5WaFCc Q==; X-IronPort-AV: E=Sophos;i="5.17,655,1437393600"; d="scan'208";a="47363161" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 09 Oct 2015 04:52:10 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Fri, 9 Oct 2015 04:52:10 +1300 From: Peter Gutmann To: Werner Koch Thread-Topic: [openpgp] New fingerprint: to v5 or not to v5 Thread-Index: AQHRAd/fGRFnZAPwNU68Rcs3/4z3Np5hvsR8 Date: Thu, 8 Oct 2015 15:52:09 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B2D663@uxcn10-5.UoA.auckland.ac.nz> References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <87y4fi5wa9.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz> <8737xp5z45.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B279C6@uxcn10-5.UoA.auckland.ac.nz> <87fv1o4e9n.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2C5EE@uxcn10-5.UoA.auckland.ac.nz> <87wpuy1njl.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2D5B1@uxcn10-5.UoA.auckland.ac.nz>, <87bnc91i5y.fsf@vigenere.g10code.de> In-Reply-To: <87bnc91i5y.fsf@vigenere.g10code.de> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Watson Ladd , Phillip Hallam-Baker , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Thu, 08 Oct 2015 15:52:15 -0000 Werner Koch writes:=0A= =0A= >You mean the binding signatures verify okay but the key is different? If t= hat=0A= >is the case you found a bug in the software. You can't change the creatio= n=0A= >date, the key material, the user id or the hashed signature subpackets=0A= >without invalidating the corresponding self-signature.=0A= =0A= There's no bug in the software, someone took the key (that's the key data, = not=0A= a complete copy of the original keyring packets with their signatures) and= =0A= wrote it out to a new keyring with a new date. Same key, same userID,=0A= different date (because it was written at a different time than before), ne= w=0A= signatures covering everything. There are no bugs and no corruption, but t= he=0A= implicitly-calculated key ID has changed because the datestamp has changed.= =0A= =0A= Peter.=0A= From nobody Thu Oct 8 09:21:09 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 26C4E1A9103 for ; Thu, 8 Oct 2015 09:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 y08qua_uZDyr for ; Thu, 8 Oct 2015 09:21:06 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A362E1A90F9 for ; Thu, 8 Oct 2015 09:21:06 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZkDwG-0000Yh-SL for ; Thu, 08 Oct 2015 18:21:04 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZkDtZ-00018Q-5L; Thu, 08 Oct 2015 18:18:17 +0200 From: Werner Koch To: Peter Gutmann References: <56128436.40607@assured.se> <87y4fh4210.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B28383@uxcn10-5.UoA.auckland.ac.nz> <87k2r04hak.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2C5B4@uxcn10-5.UoA.auckland.ac.nz> <87si5m1ncm.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2D532@uxcn10-5.UoA.auckland.ac.nz> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Peter Gutmann , "cfrg\@mail.ietf.org" , Jonas Magazinius , "cryptography\@metzdowd.com" , "openpgp\@ietf.org" Date: Thu, 08 Oct 2015 18:18:17 +0200 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B2D532@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Thu, 8 Oct 2015 14:59:15 +0000") Message-ID: <877fmx1ghi.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: "cfrg@mail.ietf.org" , Jonas Magazinius , "cryptography@metzdowd.com" , "openpgp@ietf.org" Subject: Re: [openpgp] OpenPGP SEIP downgrade attack 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: Thu, 08 Oct 2015 16:21:08 -0000 On Thu, 8 Oct 2015 16:59, pgut001@cs.auckland.ac.nz said: > (It's also not clear whether someone encrypting a 10k email message with PGP > is going to notice it being processed at 100MB/s or 150MB/s). I heard of backups somewhat larger than that. For mail it is anyway not a problem - you sign and encrypt and you are done. Not even a need for an MDC. > (I actually really like OCB and don't like GCM much, but the patent situation > makes it pretty problematic). Well, for the majority of uses cases there is a gratis license grant from Phil Rogaway for his patents. Further daft-zauner-tls-aes-ocb-03.txt states: 6. Intellectual Propery Rights Issues Historically OCB Mode has seen difficulty with deployment and standardization because of pending patents and intellectual rights claims on OCB itself. In preparation of this document all interested parties have declared they will issue IPR statements exempting use of OCB Mode in TLS from these claims. Specifically - OCB Mode as described in this document for use in TLS - is based, and strongly influenced, by earlier work from Charanjit Jutla on [IAPM]. At IETF-93 this case was mentioned and it was suggested to ask for a similar licenses exception [1,2] if we consider to use OCB for OpenPGP. Salam-Shalom, Werner [1] https://datatracker.ietf.org/ipr/2647/ [1] https://datatracker.ietf.org/ipr/2640/ -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Thu Oct 8 09:24:13 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 A471E1A9104 for ; Thu, 8 Oct 2015 09:24:08 -0700 (PDT) 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, 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 1RAaJTpuWFsT for ; Thu, 8 Oct 2015 09:24:00 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::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 AB9051A9118 for ; Thu, 8 Oct 2015 09:23:54 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so36128660wic.1 for ; Thu, 08 Oct 2015 09:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=N/j0Mg6Xs/3oh1jZrU8pNvspZR6rnTSHVQXFxQZnHMQ=; b=bF6W5BN6UUYTQIRjt7VPtAtklOqiFiY9bn9fhCjrbba6yxHfhTEhqT4AGxVSZX+Yd9 /EC53HXO1d0QqAQeCXuYLJJ6tZprdmGfBR6sg6r13VG19Lv+GtczZFoX5ci3qsjjqfY7 fblO2AmUtXaUbR0hjcRnXkhf5mjt2TY/vbWZRkHfjrDzX23Tdv2u+NJnWUP1ekwzHszV NS/xRiaSPXmt9EjcYokPgEJhu3G3VEwIk5CBF+hQUf8QjRKHrd/AiPbSrqWbfwu5kAII +/sCzbtpfNZx7AD3OSZKxWEYZufUBOdc8LmUU5lhK9QIuMIWae6XMGN3NInPcv97/XeY qlEw== MIME-Version: 1.0 X-Received: by 10.194.175.232 with SMTP id cd8mr9724307wjc.45.1444321433094; Thu, 08 Oct 2015 09:23:53 -0700 (PDT) Received: by 10.28.51.145 with HTTP; Thu, 8 Oct 2015 09:23:52 -0700 (PDT) Received: by 10.28.51.145 with HTTP; Thu, 8 Oct 2015 09:23:52 -0700 (PDT) In-Reply-To: <877fmx1ghi.fsf@vigenere.g10code.de> References: <56128436.40607@assured.se> <87y4fh4210.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B28383@uxcn10-5.UoA.auckland.ac.nz> <87k2r04hak.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2C5B4@uxcn10-5.UoA.auckland.ac.nz> <87si5m1ncm.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2D532@uxcn10-5.UoA.auckland.ac.nz> <877fmx1ghi.fsf@vigenere.g10code.de> Date: Thu, 8 Oct 2015 12:23:52 -0400 Message-ID: From: Watson Ladd To: "cryptography@metzdowd.com" , "cfrg@mail.ietf.org" , "openpgp@ietf.org" , Peter Gutmann , Jonas Magazinius Content-Type: multipart/alternative; boundary=089e013d1020f60e3a05219a496c Archived-At: Subject: Re: [openpgp] OpenPGP SEIP downgrade attack 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: Thu, 08 Oct 2015 16:24:08 -0000 --089e013d1020f60e3a05219a496c Content-Type: text/plain; charset=UTF-8 On Oct 8, 2015 12:21 PM, "Werner Koch" wrote: > > On Thu, 8 Oct 2015 16:59, pgut001@cs.auckland.ac.nz said: > > > (It's also not clear whether someone encrypting a 10k email message with PGP > > is going to notice it being processed at 100MB/s or 150MB/s). > > I heard of backups somewhat larger than that. For mail it is anyway not a > problem - you sign and encrypt and you are done. Not even a need for an > MDC. Does this provide the right agreement semantics for both sender and recipient? It certainly doesn't solve the security issues with CFB mode. > > > (I actually really like OCB and don't like GCM much, but the patent situation > > makes it pretty problematic). > > Well, for the majority of uses cases there is a gratis license grant > from Phil Rogaway for his patents. > Further daft-zauner-tls-aes-ocb-03.txt states: > > 6. Intellectual Propery Rights Issues > > Historically OCB Mode has seen difficulty with deployment and > standardization because of pending patents and intellectual rights > claims on OCB itself. In preparation of this document all interested > parties have declared they will issue IPR statements exempting use of > OCB Mode in TLS from these claims. Specifically - OCB Mode as > described in this document for use in TLS - is based, and strongly > influenced, by earlier work from Charanjit Jutla on [IAPM]. > > At IETF-93 this case was mentioned and it was suggested to ask for a > similar licenses exception [1,2] if we consider to use OCB for OpenPGP. > > > Salam-Shalom, > > Werner > > > [1] https://datatracker.ietf.org/ipr/2647/ > [1] https://datatracker.ietf.org/ipr/2640/ > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp --089e013d1020f60e3a05219a496c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 8, 2015 12:21 PM, "Werner Koch" <wk@gnupg.org> wrote:
>
> On Thu,=C2=A0 8 Oct 2015 16:59, pgut001@cs.auckland.ac.nz said:
>
> > (It's also not clear whether someone encrypting a 10k email m= essage with PGP
> > is going to notice it being processed at 100MB/s or 150MB/s).
>
> I heard of backups somewhat larger than that.=C2=A0 For mail it is any= way not a
> problem - you sign and encrypt and you are done.=C2=A0 Not even a need= for an
> MDC.

Does this provide the right agreement semantics for both sen= der and recipient? It certainly doesn't solve the security issues with = CFB mode.

>
> > (I actually really like OCB and don't like GCM much, but the = patent situation
> > makes it pretty problematic).
>
> Well, for the majority of uses cases there is a gratis license grant > from Phil Rogaway for his patents.
> Further daft-zauner-tls-aes-ocb-03.txt states:
>
> =C2=A0 =C2=A06.=C2=A0 Intellectual Propery Rights Issues
>
> =C2=A0 =C2=A0Historically OCB Mode has seen difficulty with deployment= and
> =C2=A0 =C2=A0standardization because of pending patents and intellectu= al rights
> =C2=A0 =C2=A0claims on OCB itself.=C2=A0 In preparation of this docume= nt all interested
> =C2=A0 =C2=A0parties have declared they will issue IPR statements exem= pting use of
> =C2=A0 =C2=A0OCB Mode in TLS from these claims.=C2=A0 Specifically - O= CB Mode as
> =C2=A0 =C2=A0described in this document for use in TLS - is based, and= strongly
> =C2=A0 =C2=A0influenced, by earlier work from Charanjit Jutla on [IAPM= ].
>
> At IETF-93 this case was mentioned and it was suggested to ask for a > similar licenses exception [1,2] if we consider to use OCB for OpenPGP= .
>
>
> Salam-Shalom,
>
> =C2=A0 =C2=A0Werner
>
>
> [1] https://datatra= cker.ietf.org/ipr/2647/
> [1] https://datatra= cker.ietf.org/ipr/2640/
>
> --
> Die Gedanken sind frei.=C2=A0 Ausnahmen regelt ein Bundesgesetz.
>
> _______________________________________________
> openpgp mailing list
> openpgp@ietf.org
> https://www.= ietf.org/mailman/listinfo/openpgp

--089e013d1020f60e3a05219a496c-- From nobody Thu Oct 8 15:48:19 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 B19B41A1EF7 for ; Thu, 8 Oct 2015 15:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 QqCIwM2z07q9 for ; Thu, 8 Oct 2015 15:48:17 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7D61A1EF6 for ; Thu, 8 Oct 2015 15:48:17 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by virulha.pair.com (Postfix) with ESMTPSA id A73836D769; Thu, 8 Oct 2015 18:48:15 -0400 (EDT) To: openpgp@ietf.org References: <878u84zy4r.fsf@vigenere.g10code.de> <55FD7CF0.8030200@iang.org> <87io742kz7.fsf@latte.josefsson.org> <87mvw4ctv5.fsf_-_@vigenere.g10code.de> <20151006110330.38b38ea4@latte.josefsson.org> From: ianG Message-ID: <5616F2AE.5050106@iang.org> Date: Thu, 8 Oct 2015 23:48:14 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151006110330.38b38ea4@latte.josefsson.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] New fingerprint: which hash algo 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: Thu, 08 Oct 2015 22:48:18 -0000 On 6/10/2015 10:03 am, Simon Josefsson wrote: >> On 30 September 2015 at 01:18, Werner Koch wrote: >>> On Mon, 21 Sep 2015 11:13, simon@josefsson.org said: >>> >>>> Regarding which hash to use, SHA-256 is probably the simplest >>>> choice From a practicallity and consensus point of view. Are >>>> there any strong reasons to favor something else? >> >> I have a small preference to see the fingerprint algorithm match what >> we believe the most popular signature (hash) algorithm will be. I've >> been working with a number of embedded folks and code size can often >> be a big concern. More Algorithms, More Code. > > My perception is that the most popular signature hash algorithms right > now are SHA-256 and SHA-512. Err... A few minor quibbles here about the notions of cryptographic democracy: 1. Popularity? Why is that interesting? Surely we can do a bit better than democracy or fashion or votes on cat pictures? Engineering or planning, anyone? 2. The reason SHA-256 is the most popular these days is that, in the wake of the 2004 Shandong hashquake, we've made a stunning amount of progress in upgrading. We've almost decided against SHA1 in certificates. We're almost serious about it. And now that freestart collisions are chewing it down to its last 4 bits, we might actually ... do it. (Which is to say, popularity got us to a situation where *11* years after the shots were fired, and 15 years after the new version was delivered, we're still using lots and lots of SHA1. We want to improve that with 15 year old tech?) 3. It's certainly a stunning indictment on algorithmic agility that SHA1 is still an issue, which is another process by which popularity makes its objective mark. > While SHA-256 and SHA-512 have somewhat > different characteristics on different platforms, I believe we are > approaching the limit of where a lot of additional comparisons are > worth the time and effort compared to just pick one of them. I'm fine > with SHA-256 for the reasons that Werner presented. Does someone > else want to promote another option? Can we get closure on this? > > /Simon From nobody Fri Oct 9 07:38:30 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 AA0D41B3413 for ; Fri, 9 Oct 2015 07:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.592 X-Spam-Level: X-Spam-Status: No, score=-0.592 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=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 zeCrXTCgpcSD for ; Fri, 9 Oct 2015 07:38:28 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2.hushmail.com [65.39.178.134]) (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 728001B3411 for ; Fri, 9 Oct 2015 07:38:28 -0700 (PDT) Received: from smtp2.hushmail.com (localhost [127.0.0.1]) by smtp2.hushmail.com (Postfix) with SMTP id DE560A0281 for ; Fri, 9 Oct 2015 14:38:27 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.ai; h=date:to:subject:from; s=hush; bh=U7G6Srd3m+irObUte2hDaG8mxXMpEPt8Gz+uPU7qH20=; b=nGYlYLUATyuAthKG3RtpQvwIOxtU7dkAK+CgJEDvhFpenu/O/6zmWFcMZRd9HCWfVh0iO2dd/L++KPtyl0Riv+AJTM+O3EYfG6Z2psCXIxP1EXHIogLrhHxNeDQjbJV4BnoLqg4JmwpLTh4pf77eMMQZkeVZEgbqmnRKAvvsRo5ypMPL9exx9amUoSPUmFIu9u2E1UCKINKLp23mGryuwTH0gMxGz4rmQIznWr1HB/Xh5J3OiJ3ogT52T0E0OOLihE4ju7eu/IQyBb+e3PDUDFugWYKoj+JaM8bI7QVjFOYs0MmoXggWIeinlxk+m8nk7rIdXfp+1ordb2zExo1N7Q== Received: from smtp.hushmail.com (w9.hushmail.com [65.39.178.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp2.hushmail.com (Postfix) with ESMTPS for ; Fri, 9 Oct 2015 14:38:27 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id B928740186; Fri, 9 Oct 2015 14:38:27 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 09 Oct 2015 10:38:27 -0400 To: openpgp@ietf.org From: vedaal@nym.hush.com In-Reply-To: <5616F2AE.5050106@iang.org> References: <878u84zy4r.fsf@vigenere.g10code.de> <55FD7CF0.8030200@iang.org> <87io742kz7.fsf@latte.josefsson.org> <87mvw4ctv5.fsf_-_@vigenere.g10code.de> <20151006110330.38b38ea4@latte.josefsson.org> <5616F2AE.5050106@iang.org> Content-Type: multipart/alternative; boundary="=_e064e31235c839b794e2df61cfad57be" Message-Id: <20151009143827.B928740186@smtp.hushmail.com> Archived-At: Subject: Re: [openpgp] New fingerprint: which hash algo 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: Fri, 09 Oct 2015 14:38:29 -0000 --=_e064e31235c839b794e2df61cfad57be Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" On 10/8/2015 at 6:45 PM, "ianG" wrote: Engineering or planning, anyone? ..... (Which is to say, popularity got us to a situation where *11* years after the shots were fired, and 15 years after the new version was delivered, we're still using lots and lots of SHA1. We want to improve that with 15 year old tech?) ===== So if it's a new key version V5, may be it would be reasonable to go with a the new hash standard, SHA 3 (Keccak) http://www.nist.gov/manuscript-publication-search.cfm?pub_id=919061 vedaal --=_e064e31235c839b794e2df61cfad57be Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"

On 10/8/2015 a= t 6:45 PM, "ianG" <iang@iang.org> wrote:

Engineering or = planning, anyone?

.....

(Which is to say, popularity got us t= o a situation where *11* years
after the shots were fired, and 15 years= after the new version was
delivered, we're still using lots and lots o= f SHA1. We want to improve
that with 15 year old tech?)

=3D=3D= =3D=3D=3D

So if it's a new key version V5, may be it would be reason= able to go with a the new hash standard, SHA 3 (Keccak)

http:= //www.nist.gov/manuscript-publication-search.cfm?pub_id=3D919061

vedaal
 --=_e064e31235c839b794e2df61cfad57be-- From nobody Fri Oct 9 08:48:25 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 608971B44AB for ; Fri, 9 Oct 2015 08:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 z1CRwdzPe7MA for ; Fri, 9 Oct 2015 08:48:21 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 886561B449F for ; Fri, 9 Oct 2015 08:48:21 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id ADFBB205F2 for ; Fri, 9 Oct 2015 11:48:19 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute1.internal (MEProxy); Fri, 09 Oct 2015 11:48:19 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=humdai.net; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=i0CVzDyEXcbPypbhC2Y0C3MGj54=; b=EXrFeh EWu0JvZdw8I/M8L8GTdXXXqMImSSUbdVmDeLzx1J9VIGfbqmzXpUBOMxFeNgQodN HGtQ5/dtvIlNnLBMT3QhGXyNMG6Ed9ayV5Ak0dZebd6So0ChAYS/hPEMO60w4j9d yc0w3KKb9XA3ldN5N1+hmVvK1KxPYPsA6ciQA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=i0CVzDyEXcbPypb hC2Y0C3MGj54=; b=FqvznaH1gs/43eycnr5lyTDj/bjDvZIhpZUxn2bx7SJPFYz he0Zhj4GpkUHamq0IhpcDHWlE+G5uHlJk3ayVyonNEdahyYXqVlPnK8SLqBj7kZp h7k6KnmWuh2IK6vTL7kAyfITW4kltPM5f73QLdVW3iWOe1uy8vMfX/w+F58U= Received: by web2.nyi.internal (Postfix, from userid 99) id 7380B5401AA; Fri, 9 Oct 2015 11:48:19 -0400 (EDT) Message-Id: <1444405699.1451275.405969297.6A25C66E@webmail.messagingengine.com> X-Sasl-Enc: egecA1DC1tfte7GcAZBmFeMxWCNC2msEcOjv6p1nCpvJ 1444405699 From: Steve Pointer To: openpgp@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-3fc6701a Date: Fri, 09 Oct 2015 16:48:19 +0100 In-Reply-To: <20151009143827.B928740186@smtp.hushmail.com> References: <878u84zy4r.fsf@vigenere.g10code.de> <55FD7CF0.8030200@iang.org> <87io742kz7.fsf@latte.josefsson.org> <87mvw4ctv5.fsf_-_@vigenere.g10code.de> <20151006110330.38b38ea4@latte.josefsson.org> <5616F2AE.5050106@iang.org> <20151009143827.B928740186@smtp.hushmail.com> Archived-At: Subject: Re: [openpgp] New fingerprint: which hash algo 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: Fri, 09 Oct 2015 15:48:23 -0000 > So if it's a new key version V5, may be it would be reasonable to go with a the new hash standard, SHA 3 (Keccak) Surprised that nobody has mentioned Suite B: https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml Last updated a couple of months ago to advise: "Use SHA-384 to protect up to TOP SECRET." http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf -- Steve P From nobody Fri Oct 9 09:47:13 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 CC3501B479B for ; Fri, 9 Oct 2015 09:47:10 -0700 (PDT) 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 FpLMAyi6I3xi for ; Fri, 9 Oct 2015 09:47:09 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 895F21B479C for ; Fri, 9 Oct 2015 09:47:06 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so75038189wic.1 for ; Fri, 09 Oct 2015 09:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=wdH6lLi+FpGkwyI2BoIuzumLaBpbbw3C0KTIjLa9dzc=; b=ULK/ybNpH1vP30/9CBCobkoKTXqSTlJlraopAElOznPLFgn+TS+bX/9MiiLRSkWQDt UtZ5+dV7E+IHVZXLWQZ1SAZ9FL+at/Q9aUQfCUH29Gq6pYK9y4SIS6pHYoQ4I4MKw1y2 sAU3qGg3cKCQPAdRbyCDKUIP8jMVQB47eB1N4ds380L5ZyZn7ZOjiRbGsBC5xCKDWKbq JaMPU4G2bBnctw3j+sza0GS20JgT4iRXf/mZ0ToeslNlqg6T4bXrNgSypAzJcNhVNSH+ qewJrc4qAE2ICFHgssoI0dSsy08hZO5hGEaIVIP3DC56M8ryZLFNJv1O7hQTeZSvnJfo UnJg== X-Received: by 10.194.62.46 with SMTP id v14mr15222342wjr.112.1444409225009; Fri, 09 Oct 2015 09:47:05 -0700 (PDT) Received: from [131.175.121.117] (pc121-117.elet.polimi.it. [131.175.121.117]) by smtp.googlemail.com with ESMTPSA id jq10sm3042665wjc.40.2015.10.09.09.47.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2015 09:47:04 -0700 (PDT) From: Alessandro Barenghi X-Google-Original-From: Alessandro Barenghi To: openpgp@ietf.org References: <878u84zy4r.fsf@vigenere.g10code.de> <55FD7CF0.8030200@iang.org> <87io742kz7.fsf@latte.josefsson.org> <87mvw4ctv5.fsf_-_@vigenere.g10code.de> <20151006110330.38b38ea4@latte.josefsson.org> <5616F2AE.5050106@iang.org> X-Enigmail-Draft-Status: N1110 Message-ID: <5617EF87.6020300@polimi.it> Date: Fri, 9 Oct 2015 16:47:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5616F2AE.5050106@iang.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] New fingerprint: which hash algo 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: Fri, 09 Oct 2015 16:47:10 -0000 On 10/08/2015 10:48 PM, ianG wrote: > 2. The reason SHA-256 is the most popular these days is that, in the > wake of the 2004 Shandong hashquake, we've made a stunning amount of > progress in upgrading. We've almost decided against SHA1 in > certificates. We're almost serious about it. And now that freestart > collisions are chewing it down to its last 4 bits, Actually, they finished chewing https://sites.google.com/site/itstheshappening/ (still only a freestart collision, but full 80 rounds) > we might actually ... do it. Yep, and IMHO picking a hash function with a different inner structure from SHA-1, and designed to address the issue coming with it, such as SHA-3 may quite be a good idea. After all, ~89% of the signatures currently present on the sks keyserver network are made over a SHA-1 hash, and it may take a while to update them all. Cheers Alessandro From nobody Fri Oct 9 10:14:10 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 12CA11B48CC for ; Fri, 9 Oct 2015 10:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Y31RA8cSwrmS for ; Fri, 9 Oct 2015 10:14:07 -0700 (PDT) Received: from shards.monkeyblade.net (shards.monkeyblade.net [IPv6:2001:4f8:3:36:211:85ff:fe63:a549]) by ietfa.amsl.com (Postfix) with ESMTP id 8786C1B48C8 for ; Fri, 9 Oct 2015 10:14:07 -0700 (PDT) Received: from [10.10.142.30] (wsip-70-167-255-237.dc.dc.cox.net [70.167.255.237]) (Authenticated sender: rjh-sixdemonbag) by shards.monkeyblade.net (Postfix) with ESMTPSA id 3C22D58C293 for ; Fri, 9 Oct 2015 10:14:07 -0700 (PDT) To: openpgp@ietf.org References: <878u84zy4r.fsf@vigenere.g10code.de> <55FD7CF0.8030200@iang.org> <87io742kz7.fsf@latte.josefsson.org> <87mvw4ctv5.fsf_-_@vigenere.g10code.de> <20151006110330.38b38ea4@latte.josefsson.org> <5616F2AE.5050106@iang.org> <5617EF87.6020300@polimi.it> From: "Robert J. Hansen" X-Enigmail-Draft-Status: N1110 Message-ID: <5617F5DB.6020808@sixdemonbag.org> Date: Fri, 9 Oct 2015 13:14:03 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5617EF87.6020300@polimi.it> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Fri, 09 Oct 2015 10:14:07 -0700 (PDT) Archived-At: Subject: Re: [openpgp] New fingerprint: which hash algo 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: Fri, 09 Oct 2015 17:14:09 -0000 > Yep, and IMHO picking a hash function with a different inner structure > from SHA-1, and designed to address the issue coming with it, such as > SHA-3 may quite be a good idea. I feel like a churl for observing this, but the history of Merkle-Damgård hashes is really not very good. MD4, MD5, SHA-0, SHA-1, RIPEMD, and probably RIPEMD-160 and/or RIPEMD-128. Some of this is because these are popular hash functions and as a result have received the most cryptanalysis. But part of me wonders if now would not be an excellent time to introduce a non-Merkle-Damgård hash to OpenPGP, in the hopes that maybe it will fare better. From nobody Fri Oct 9 11:45:21 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 D6DD21B49FB for ; Fri, 9 Oct 2015 11:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 6ER742atnjtK for ; Fri, 9 Oct 2015 11:45:16 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id B5D671B49E9 for ; Fri, 9 Oct 2015 11:45:16 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 7BEEBF984; Fri, 9 Oct 2015 14:45:14 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 2FB74203E2; Fri, 9 Oct 2015 14:44:46 -0400 (EDT) From: Daniel Kahn Gillmor To: ianG , openpgp@ietf.org In-Reply-To: <56128637.6030504@iang.org> References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <87y4fi5wa9.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz> <8737xp5z45.fsf@vigenere.g10code.de> <56128637.6030504@iang.org> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Fri, 09 Oct 2015 14:44:46 -0400 Message-ID: <87wpuvx4o1.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Fri, 09 Oct 2015 18:45:19 -0000 On Mon 2015-10-05 10:16:23 -0400, ianG wrote: > On 5/10/2015 07:33 am, Werner Koch wrote: >> On Mon, 5 Oct 2015 12:27, pgut001@cs.auckland.ac.nz said: > >> Is your request to leave the timestamp out of a v5 fingerprint >> computation? > > > Makes sense to me. > > Or, as it is just a calculation, the 4 octets MUST be set to 0. I would agree that leaving the key creation time out of the fingerprint calculation makes it easier to associate the mathematical object of raw key material with an explicit key ID. For X.509, we do have certificate fingerprints, but they turn out to not be particularly useful. The main place where X.509 fingerprints have come in handy in protocols is in HPKP, where the subjectPublicKeyInfo material is what is fingerprinted, not the certificate itself. >> That would make some things easier but raises the issue that the owner >> of the key can change the creation date and only the then broken key >> signatures and the history of self-signatures would reflect this. if the fingerprint calculation doesn't include the key creation time, we would also need to decide whether key creation time should be included in the material digested for other OpenPGP certifications. in that case, i see three options: a) don't include any key creation time at all; signatures themselves have a creation time, which is sufficient. b) include key creation time in the material certified only for self-sigs (certifications issued by the key itself). Do not include any key creation time in the material certified by third-parties. c) Include creation time of the certified key in the material certified for all certifications -- first-party or third-party. I'm tempted by the simplicity of (a), to be honest. (b) sounds doable, but i don't know how useful it is to have assertions from the key of when the key was created, or what to do with situations where some self-sigs assert a different key creation time than others. Should we reject or ignore some of them? if so, which ones? (c) sounds like trouble -- you'll get self-signed assertions of key creation time that don't match third-party assertions of key creation time. What does that mean? how should it be represented to the user? I think this is the issue that Werner was hinting at. what are the downsides of (a)? What are the advantages of having a key creation time at all? Is it simply that it provides a universally-known temporal boundary when to accept signatures made by that key? --dkg From nobody Fri Oct 9 19:11:51 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 9F5831B52CD for ; Fri, 9 Oct 2015 19:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 uBXd0WgesQgB for ; Fri, 9 Oct 2015 19:11:47 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D8881B52C9 for ; Fri, 9 Oct 2015 19:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1444443108; x=1475979108; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6SrJ+OZ0jjOOFsBc57lNYpgohQhGxZ9e4WDXzDZIyI4=; b=d6UzVia4t6v1CW840/XJT8hQ5PkxZCFJTt3n5bS8WInl6z8J/AiGDifG QzR8nhiWTz6Udh0dk3aMOtr2mlNLELfihMrUTsIzX4k7EHka5nQRBskGg +WkeSaDR6Gl6hhjzGdxMbXXjaQpJE8vADx6bNBsWAXZciuh/PjU7iykVZ N4aXRpEMF/hpEY7hcUOQ/At4BWo4LGwH5CBXMTJ+Wdq4P5xTvIqdJMLe7 fGC3g0bkxBH7faESTeC9sG3/Q7mMy+N9JK5g7Q9FxNDMIVgW/10xC9pY9 NIovcQAG4EF4azXvH8h5BmQmP715r5/vbGq+SHTdiOzN9Zrt7RLjBo7Sk w==; X-IronPort-AV: E=Sophos;i="5.17,661,1437393600"; d="scan'208";a="47643049" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe3.UoA.auckland.ac.nz) ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 10 Oct 2015 15:11:44 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Sat, 10 Oct 2015 15:11:43 +1300 From: Peter Gutmann To: Daniel Kahn Gillmor , ianG , "openpgp@ietf.org" Thread-Topic: [openpgp] New fingerprint: to v5 or not to v5 Thread-Index: AQHQ/2GfGRFnZAPwNU68Rcs3/4z3Np5cGCKAgAaUTwCAAVZniA== Date: Sat, 10 Oct 2015 02:11:42 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B2EE19@uxcn10-5.UoA.auckland.ac.nz> References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <87y4fi5wa9.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz> <8737xp5z45.fsf@vigenere.g10code.de> <56128637.6030504@iang.org>,<87wpuvx4o1.fsf@alice.fifthhorseman.net> In-Reply-To: <87wpuvx4o1.fsf@alice.fifthhorseman.net> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Sat, 10 Oct 2015 02:11:49 -0000 Daniel Kahn Gillmor write:=0A= =0A= >For X.509, we do have certificate fingerprints, but they turn out to not b= e=0A= >particularly useful.=0A= =0A= Actually they're very useful if you're doing proper checking in your PKI (s= o=0A= not relying on commercial CAs or any of the X.500/X.509 folderol that doesn= 't=0A= work), you either fingerprint the cert(s) you expect to see (e.g. for secur= ing=0A= a web service for a mobile app) or the CA cert that you rely on to issue ce= rts=0A= you can rely on. You can also use them for cute things like self-certifying= =0A= URLs, the first part of the FQDN is a hash of the cert at that location.=0A= =0A= Peter.=0A= From nobody Sat Oct 10 03:35:54 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 0CE8B1A8788 for ; Sat, 10 Oct 2015 03:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.112 X-Spam-Level: X-Spam-Status: No, score=-0.112 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 duq7ZEpKkBok for ; Sat, 10 Oct 2015 03:35:51 -0700 (PDT) Received: from the.earth.li (the.earth.li [IPv6:2001:41c8:10:b1f:c0ff:ee:15:900d]) (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 8F8891A873B for ; Sat, 10 Oct 2015 03:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=earth.li; s=the; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date; bh=JfmNWoFFhqBvxfqqenOA2n6Nf2AampSfzQHraBFSGa8=; b=oZW9zSIHkBW6bYAjipBUwxsRaHoHf3UZ0J8xH0SfYJZ2H3NsvoPaiexOIODJWwzrpBns1MQ2A2mygv4mf+oTIfKf19Wu7eeAisx4iMV02ukBJib//sBseahZ6Tt2v500ud+brqSNFqPwAMo4HVrOwqdswAcE+Z4gkeh3w9o0J/PrUQ1Rjt7aCdIItg6+y/bV759WMxWc/CpMgqMj15h7Jw8bHWKdkmIsF30W6EEnjs/UbY2QOrRW0nBjoxaqqbz8vl+yP9Fq+xGaVAe1KPO+WflIXRZv9kkPXcVvFM0TeFuwqH1v7DBJDcmaeRBYJIjhf+bsYgBulp3dEQXvsndcVg==; Received: from noodles by the.earth.li with local (Exim 4.84) (envelope-from ) id 1ZkrVF-0000U4-D4 for openpgp@ietf.org; Sat, 10 Oct 2015 11:35:49 +0100 Date: Sat, 10 Oct 2015 11:35:49 +0100 From: Jonathan McDowell To: openpgp@ietf.org Message-ID: <20151010103549.GZ26454@earth.li> References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <87y4fi5wa9.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz> <8737xp5z45.fsf@vigenere.g10code.de> <56128637.6030504@iang.org> <87wpuvx4o1.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wpuvx4o1.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Sat, 10 Oct 2015 10:35:53 -0000 On Fri, Oct 09, 2015 at 02:44:46PM -0400, Daniel Kahn Gillmor wrote: > a) don't include any key creation time at all; signatures themselves > have a creation time, which is sufficient. > > b) include key creation time in the material certified only for > self-sigs (certifications issued by the key itself). Do not include > any key creation time in the material certified by third-parties. > > c) Include creation time of the certified key in the material certified > for all certifications -- first-party or third-party. > > I'm tempted by the simplicity of (a), to be honest. > > (b) sounds doable, but i don't know how useful it is to have assertions > from the key of when the key was created, or what to do with situations > where some self-sigs assert a different key creation time than others. > Should we reject or ignore some of them? if so, which ones? > > (c) sounds like trouble -- you'll get self-signed assertions of key > creation time that don't match third-party assertions of key creation > time. What does that mean? how should it be represented to the user? > I think this is the issue that Werner was hinting at. > > what are the downsides of (a)? What are the advantages of having a key > creation time at all? Is it simply that it provides a universally-known > temporal boundary when to accept signatures made by that key? I've certainly used key creation time as a separate piece of information to "most recent self-signature". The latter indicates how recently the key can be seen as still in use / maintained, but the former gives an idea of how long it's been around and can help when making a decision about which of multiple keys to use for an individual. I think having that in the self-sig would work ok (i.e. option b). In general is the most recent self-sig not the one that should be trusted, with perhaps a warning if any of the previous ones have a different creation time listed? J. -- Friends are God's apology for relations. From nobody Sun Oct 11 02:02:44 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 AB76A1A6F9F for ; Sun, 11 Oct 2015 02:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 HZCHz9lYfs4t for ; Sun, 11 Oct 2015 02:02:41 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 885E71A6F62 for ; Sun, 11 Oct 2015 02:02:40 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so17710856wic.1 for ; Sun, 11 Oct 2015 02:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=CS80X7I9PLbdL8FhNrjIZpRCvvBfFs1p3+pwmX5bquU=; b=aqfHeP7ifaeaN5B3XQAKIMbEuGNaaPFzMjJwlkocI70Qqj7w8/aKGZu//GsoXtMZeh oBlhUuMfuE1LKP0wAggE2BS8dyXgBE1lv+AV7dYHSCVt000dDjor1S52b2ZJTGf/0U7a Ci0K7Ag7jHGz+28vTZlFl+c5KV9Vjr2TruyzXFDlEZRKKKI8kvRVCnzY3LnZHw4OWFDg Jbtkunu1Jj8Fxc3GIvOY0S0fV92uZh4rmOp3ALIGEMNv7mni1NoCz/2m+Fb0nZ/EwNMi HQhQZiL+0vMTW4Pw9NfNyDcoUn5NtHhUf+1m3qa7jAU1bBr+Rln4EJ3ORdrgPORkpObI nOQw== MIME-Version: 1.0 X-Received: by 10.181.8.72 with SMTP id di8mr8588457wid.62.1444554158877; Sun, 11 Oct 2015 02:02:38 -0700 (PDT) Received: by 10.28.24.75 with HTTP; Sun, 11 Oct 2015 02:02:38 -0700 (PDT) In-Reply-To: <20151010103549.GZ26454@earth.li> References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <87y4fi5wa9.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz> <8737xp5z45.fsf@vigenere.g10code.de> <56128637.6030504@iang.org> <87wpuvx4o1.fsf@alice.fifthhorseman.net> <20151010103549.GZ26454@earth.li> Date: Sun, 11 Oct 2015 10:02:38 +0100 Message-ID: From: Nicholas Cole To: "openpgp@ietf.org" Content-Type: multipart/alternative; boundary=001a1134cdee7fb6180521d079c3 Archived-At: Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Sun, 11 Oct 2015 09:02:42 -0000 --001a1134cdee7fb6180521d079c3 Content-Type: text/plain; charset=UTF-8 On Saturday, 10 October 2015, Jonathan McDowell wrote: > On Fri, Oct 09, 2015 at 02:44:46PM -0400, Daniel Kahn Gillmor wrote: > > a) don't include any key creation time at all; signatures themselves > > have a creation time, which is sufficient. > > > > b) include key creation time in the material certified only for > > self-sigs (certifications issued by the key itself). Do not include > > any key creation time in the material certified by third-parties. > > > > c) Include creation time of the certified key in the material certified > > for all certifications -- first-party or third-party. > > > > I'm tempted by the simplicity of (a), to be honest. > > > > (b) sounds doable, but i don't know how useful it is to have assertions > > from the key of when the key was created, or what to do with situations > > where some self-sigs assert a different key creation time than others. > > Should we reject or ignore some of them? if so, which ones? > > > > (c) sounds like trouble -- you'll get self-signed assertions of key > > creation time that don't match third-party assertions of key creation > > time. What does that mean? how should it be represented to the user? > > I think this is the issue that Werner was hinting at. > > > > what are the downsides of (a)? What are the advantages of having a key > > creation time at all? Is it simply that it provides a universally-known > > temporal boundary when to accept signatures made by that key? > > I've certainly used key creation time as a separate piece of information > to "most recent self-signature". The latter indicates how recently the > key can be seen as still in use / maintained, but the former gives an > idea of how long it's been around and can help when making a decision > about which of multiple keys to use for an individual. I think having > that in the self-sig would work ok (i.e. option b). In general is the > most recent self-sig not the one that should be trusted, with perhaps a > warning if any of the previous ones have a different creation time > listed? > > For what it is worth, I think that a secure creation time is probably useful to some, and should be preserved if possible. If it can be included in the hashed material for the key (as it currently is) in a way that does not help people to forge keys, then I think it should be -- including it only as a piece of signed data is going to allow key owners to manipulate it. --001a1134cdee7fb6180521d079c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Saturday, 10 October 2015, Jonathan McDowell <noodles@earth.li> wrote:
On Fri, Oct 09, 2015 at 02:44:46PM -0400, Daniel Kahn Gillmor= wrote:
>=C2=A0 a) don't include any key creation time at all; signatures th= emselves
>=C2=A0 =C2=A0 =C2=A0have a creation time, which is sufficient.
>
>=C2=A0 b) include key creation time in the material certified only for<= br> >=C2=A0 =C2=A0 =C2=A0self-sigs (certifications issued by the key itself)= .=C2=A0 Do not include
>=C2=A0 =C2=A0 =C2=A0any key creation time in the material certified by = third-parties.
>
>=C2=A0 c) Include creation time of the certified key in the material ce= rtified
>=C2=A0 =C2=A0 =C2=A0for all certifications -- first-party or third-part= y.
>
> I'm tempted by the simplicity of (a), to be honest.
>
> (b) sounds doable, but i don't know how useful it is to have asser= tions
> from the key of when the key was created, or what to do with situation= s
> where some self-sigs assert a different key creation time than others.=
> Should we reject or ignore some of them?=C2=A0 if so, which ones?
>
> (c) sounds like trouble -- you'll get self-signed assertions of ke= y
> creation time that don't match third-party assertions of key creat= ion
> time.=C2=A0 What does that mean?=C2=A0 how should it be represented to= the user?
> I think this is the issue that Werner was hinting at.
>
> what are the downsides of (a)?=C2=A0 What are the advantages of having= a key
> creation time at all?=C2=A0 Is it simply that it provides a universall= y-known
> temporal boundary when to accept signatures made by that key?

I've certainly used key creation time as a separate piece of informatio= n
to "most recent self-signature". The latter indicates how recentl= y the
key can be seen as still in use / maintained, but the former gives an
idea of how long it's been around and can help when making a decision about which of multiple keys to use for an individual. I think having
that in the self-sig would work ok (i.e. option b). In general is the
most recent self-sig not the one that should be trusted, with perhaps a
warning if any of the previous ones have a different creation time
listed?



For what it is worth, I think that a s= ecure creation time is probably useful to some, and should be preserved if = possible. If it can be included in the hashed material for the key (as it c= urrently is)=C2=A0in a way that does not help people to forge keys, then I = think it should be -- including it only as a piece of signed data is going = to allow key owners to manipulate it.=C2=A0


= =C2=A0
--001a1134cdee7fb6180521d079c3-- From nobody Mon Oct 12 05:06:41 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 A878A1AD06D for ; Mon, 12 Oct 2015 05:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 eExf0oc3WkrT for ; Mon, 12 Oct 2015 05:06:38 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5D71ACEFA for ; Mon, 12 Oct 2015 05:06:38 -0700 (PDT) Received: from localhost (D57DC892.static.ziggozakelijk.nl [213.125.200.146]) by mail.mugenguild.com (Postfix) with ESMTPSA id 63C675FDA4 for ; Mon, 12 Oct 2015 14:06:35 +0200 (CEST) References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <87y4fi5wa9.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz> <8737xp5z45.fsf@vigenere.g10code.de> <56128637.6030504@iang.org> <87wpuvx4o1.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4B2EE19@uxcn10-5.UoA.auckland.ac.nz> From: Vincent Breitmoser To: "openpgp\@ietf.org" Cc: In-reply-to: <9A043F3CF02CD34C8E74AC1594475C73F4B2EE19@uxcn10-5.UoA.auckland.ac.nz> Date: Mon, 12 Oct 2015 14:06:27 +0200 Message-ID: <87d1wkjnp8.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Mon, 12 Oct 2015 12:06:40 -0000 The creation date in the fingerprint is used for two purposes I can think of: Firstly, it is commonly used by users to pick a key when a keyserver search returns more than one result, which is made possible without processing the full key by integrity protecting the creation date in the fingerprint. It is questionable whether this behavior should be encouraged, but if there is no attacker this is often a reasonable guess. If there is an attacker, you are doomed no matter what you do with an unauthenticated key. Secondly, implementations use it as a boundary for signature validity. I don't think this behavior is actually specified, so this is mostly just guesswork in the trust model? Including the key material as the only dynamic part of the fingerprint is the most basic decision. So the question becomes, do we have a good reason to include anything more? For the creation date in particular, are the above two properties desirable and worth it? Just for brainstorming, the other extreme would be allowing arbitrary properties (e.g. signature subpackets) to be included in the fingerprint, allowing an implementation to have properties which can never change throughout the lifetime of a key, and which cannot be suppressed by an attacker unlike irrecovable signature packets. - V From nobody Mon Oct 12 05:46:16 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 A73F01B2A44 for ; Mon, 12 Oct 2015 05:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 9eXNdgsbgWWi for ; Mon, 12 Oct 2015 05:46:12 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (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 3EC541AD0A5 for ; Mon, 12 Oct 2015 05:46:12 -0700 (PDT) Received: by wicge5 with SMTP id ge5so16109184wic.0 for ; Mon, 12 Oct 2015 05:46:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=NC7GM4wrsVMgdtR3XI/snQhudBnZ5B7Iuu5TkZK4wK8=; b=hrFyNzfHrh9vDj7wjaFgB9jven9BcnAIDH4COvk32Zp3zq8Qi7CHjt9QyW3CWh/JD3 JPa0YMT7VQpunZoTz7JCARz1oT7BeWKVUySVVnUxB9nSY+g4OrZFV61+KA7UfiNggSUm rrYojuBJtp4aybDp6W4O+uComcefzV9COCkdeDnM1MXs15oijiaBr17Q75TkyREx4kDA sgxAgpDAZbdksLm44EvD7Msa4vttiy4KyWDtoCG7Eht0P1geO8HS/JWTOsgJfjdTNUri HmwfNypvI5J4osHsgZo7TxZKdYqEUdLSn3p6iBhxaKBNQUQ2jtadESbFOLZ/yN6869Q4 ehNA== X-Gm-Message-State: ALoCoQnlkgHg0eNDraNtB7flQTv+3IeF3Z/DSiInSO1xVEifgB1PFU7o8pH/16gm0ZTX4odyOYT9 X-Received: by 10.180.8.68 with SMTP id p4mr14685531wia.16.1444653970848; Mon, 12 Oct 2015 05:46:10 -0700 (PDT) Received: from [192.168.120.120] (dhcp142.cs.elte.hu. [157.181.227.142]) by smtp.googlemail.com with ESMTPSA id az6sm10761114wib.12.2015.10.12.05.46.09 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Oct 2015 05:46:09 -0700 (PDT) To: openpgp@ietf.org References: <878u84zy4r.fsf@vigenere.g10code.de> <55FD7CF0.8030200@iang.org> <87io742kz7.fsf@latte.josefsson.org> <87mvw4ctv5.fsf_-_@vigenere.g10code.de> <20151006110330.38b38ea4@latte.josefsson.org> <5616F2AE.5050106@iang.org> From: "Daniel A. Nagy" Message-ID: <561BAB91.8040104@epointsystem.org> Date: Mon, 12 Oct 2015 14:46:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5616F2AE.5050106@iang.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] New fingerprint: which hash algo 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: Mon, 12 Oct 2015 12:46:15 -0000 Hello, Now that SHA1 is on the brink of being broken, I believe that all Merkle–Damgård hashes should be avoided in new designs. Keccak (SHA-3) is just better in so many ways. Daniel On 2015-10-09 00:48, ianG wrote: > On 6/10/2015 10:03 am, Simon Josefsson wrote: >>> On 30 September 2015 at 01:18, Werner Koch wrote: >>>> On Mon, 21 Sep 2015 11:13, simon@josefsson.org said: >>>> >>>>> Regarding which hash to use, SHA-256 is probably the simplest >>>>> choice From a practicallity and consensus point of view. Are >>>>> there any strong reasons to favor something else? >>> >>> I have a small preference to see the fingerprint algorithm match what >>> we believe the most popular signature (hash) algorithm will be. I've >>> been working with a number of embedded folks and code size can often >>> be a big concern. More Algorithms, More Code. >> >> My perception is that the most popular signature hash algorithms right >> now are SHA-256 and SHA-512. > > Err... A few minor quibbles here about the notions of cryptographic > democracy: > > > 1. Popularity? Why is that interesting? Surely we can do a bit better > than democracy or fashion or votes on cat pictures? > > Engineering or planning, anyone? > > 2. The reason SHA-256 is the most popular these days is that, in the > wake of the 2004 Shandong hashquake, we've made a stunning amount of > progress in upgrading. We've almost decided against SHA1 in > certificates. We're almost serious about it. And now that freestart > collisions are chewing it down to its last 4 bits, we might actually ... > do it. > > (Which is to say, popularity got us to a situation where *11* years > after the shots were fired, and 15 years after the new version was > delivered, we're still using lots and lots of SHA1. We want to improve > that with 15 year old tech?) > > 3. It's certainly a stunning indictment on algorithmic agility that > SHA1 is still an issue, which is another process by which popularity > makes its objective mark. > > >> While SHA-256 and SHA-512 have somewhat >> different characteristics on different platforms, I believe we are >> approaching the limit of where a lot of additional comparisons are >> worth the time and effort compared to just pick one of them. I'm fine >> with SHA-256 for the reasons that Werner presented. Does someone >> else want to promote another option? Can we get closure on this? >> >> /Simon > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Mon Oct 12 07:11:11 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 4DB241B32DF for ; Mon, 12 Oct 2015 07:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 gU5YLmrHB7w1 for ; Mon, 12 Oct 2015 07:11:08 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FA581B32DD for ; Mon, 12 Oct 2015 07:11:08 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Zldog-0000qX-2m for ; Mon, 12 Oct 2015 16:11:06 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Zldlg-0006Go-6r; Mon, 12 Oct 2015 16:08:00 +0200 From: Werner Koch To: Vincent Breitmoser References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <87y4fi5wa9.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz> <8737xp5z45.fsf@vigenere.g10code.de> <56128637.6030504@iang.org> <87wpuvx4o1.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4B2EE19@uxcn10-5.UoA.auckland.ac.nz> <87d1wkjnp8.fsf@littlepip.fritz.box> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Vincent Breitmoser , "openpgp\@ietf.org" , Jon Callas Date: Mon, 12 Oct 2015 16:07:59 +0200 In-Reply-To: <87d1wkjnp8.fsf@littlepip.fritz.box> (Vincent Breitmoser's message of "Mon, 12 Oct 2015 14:06:27 +0200") Message-ID: <87egh0w56o.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: "openpgp@ietf.org" , Jon Callas Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Mon, 12 Oct 2015 14:11:10 -0000 On Mon, 12 Oct 2015 14:06, look@my.amazin.horse said: > The creation date in the fingerprint is used for two purposes I can > think of: and this one: Thirdly, to figure out a suitable subkey for encryption. For this case I see no security problem to put the creation date into a key-binding signature. IT needs quite some code chnages though. > Including the key material as the only dynamic part of the fingerprint > is the most basic decision. So the question becomes, do we have a good > reason to include anything more? For the creation date in particular, I don't think so. v3 keys didn't include the timestamp in the fingerprint but had other problems. Maybe this was just an over-cautiousness from the PGP-5 architects. Jon: Do you remember? Assuming we leave the timestamp out of the fingerprint but still sign it with the self- and key-binding signatures, how does it change the attack model: For a key without any third party key-signatures, the holder of the key can change the creation date arbitrarily while keeping the same fingerprint. The immediate problem will be that keyservers and other code may choke on the timestamp conflict because they may assume two keys with the same fingerprint are identical. Even today keys may not be identical because there are different ways to encode the packet length. I doubt that this is or should be a problem which cannot be fixed while adding v5 format. The holder of the key can change the expiration time of the key by adjusting the creation timestamp. He is also able to do this today by issuing a new self-signature. If the key has a third party key-signature any change of the creation time can be detected. If key-signatures are part of the trust model such a change will be detected. I conclude that leaving out the timestamp from the fingerprint computation is only a problem for "self-signed" keys where the trust model is based solely on the fingerprint, and relies on the creation date. Not something I would worry about. > Just for brainstorming, the other extreme would be allowing arbitrary > properties (e.g. signature subpackets) to be included in the > fingerprint, allowing an implementation to have properties which can We had a similar discussion already related to a fixed expiration time. Although this hard-wired expiration time was not considered to be part of the fingerprint, no valid use-case for this irrevocable signature attribute was shown. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Oct 12 07:46:10 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 CA1661B340E for ; Mon, 12 Oct 2015 07:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 cNP8KDsKeuox for ; Mon, 12 Oct 2015 07:46:09 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D656E1B33B0 for ; Mon, 12 Oct 2015 07:46:08 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZleMZ-0001nL-0m for ; Mon, 12 Oct 2015 16:46:07 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZleID-0006Ml-6e; Mon, 12 Oct 2015 16:41:37 +0200 From: Werner Koch To: Peter Gutmann References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <87y4fi5wa9.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz> <8737xp5z45.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B279C6@uxcn10-5.UoA.auckland.ac.nz> <87fv1o4e9n.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2C5EE@uxcn10-5.UoA.auckland.ac.nz> <87wpuy1njl.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2D5B1@uxcn10-5.UoA.auckland.ac.nz> <87bnc91i5y.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2D663@uxcn10-5.UoA.auckland.ac.nz> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Peter Gutmann , Watson Ladd , Phillip Hallam-Baker , Daniel Kahn Gillmor , IETF OpenPGP Date: Mon, 12 Oct 2015 16:41:37 +0200 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B2D663@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Thu, 8 Oct 2015 15:52:09 +0000") Message-ID: <871td0w3mm.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: Watson Ladd , Phillip Hallam-Baker , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Mon, 12 Oct 2015 14:46:09 -0000 On Thu, 8 Oct 2015 17:52, pgut001@cs.auckland.ac.nz said: > There's no bug in the software, someone took the key (that's the key data, not > a complete copy of the original keyring packets with their signatures) and > wrote it out to a new keyring with a new date. Same key, same userID, Which is a freature in my book. People have done this for X.509 keys a lot (although I heard that Mozilla now complains about using a new X.509 certificate with key material known from another certificate). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Oct 12 21:19:33 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 228281B373D for ; Mon, 12 Oct 2015 21:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 sZZ5jYxSQpFG for ; Mon, 12 Oct 2015 21:19:29 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 493B61B32C3 for ; Mon, 12 Oct 2015 21:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1444709969; x=1476245969; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=A+m6eb7MyUKg29c01k3+MfQ4Vu6v0oQnmJ9GsC0xwJc=; b=hIBrH0UWWsj0ouSmgrW1dMUg1sgD3wUMis5E9zyrtYDPGrOY/EXQPQys p6zD7PV6wLM4xF42nlZEz9UCDkqmeT9mncBaLZWwykus+PRwkrMBnfhWo XoHSPMjvMCX5pPYZOK/k9km3wCntNootbrQA/jfOXBwzP+g2EvNUb/bQ3 mno4Xq94jbziuSEkMVRLe7ATvvxXdESubeDt3QhZhRWL3ZklClVmhTLvW ehuQv4HcnhAFhmPdRqlQl1eY/4g9QOPKHDi3pu0+1nnctt0h/KFmvcOzM MHI1JkbmhbtGitKgb4FAHMWnM2uTkzuZ46qmSaIZ8EljNZKolwQmY+Ixt A==; X-IronPort-AV: E=Sophos;i="5.17,676,1437393600"; d="scan'208";a="48199875" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe2.UoA.auckland.ac.nz) ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 13 Oct 2015 17:19:27 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Tue, 13 Oct 2015 17:19:27 +1300 From: Peter Gutmann To: Werner Koch Thread-Topic: [openpgp] New fingerprint: to v5 or not to v5 Thread-Index: AQHRAd/fGRFnZAPwNU68Rcs3/4z3Np5hvsR8gAY2+kiAAOMQSA== Date: Tue, 13 Oct 2015 04:19:26 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B33D20@uxcn10-5.UoA.auckland.ac.nz> References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <87y4fi5wa9.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz> <8737xp5z45.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B279C6@uxcn10-5.UoA.auckland.ac.nz> <87fv1o4e9n.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2C5EE@uxcn10-5.UoA.auckland.ac.nz> <87wpuy1njl.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2D5B1@uxcn10-5.UoA.auckland.ac.nz> <87bnc91i5y.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2D663@uxcn10-5.UoA.auckland.ac.nz>, <871td0w3mm.fsf@vigenere.g10code.de> In-Reply-To: <871td0w3mm.fsf@vigenere.g10code.de> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Watson Ladd , Phillip Hallam-Baker , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Tue, 13 Oct 2015 04:19:33 -0000 Werner Koch writes:=0A= =0A= >People have done this for X.509 keys a lot (although I heard that Mozilla = now=0A= >complains about using a new X.509 certificate with key material known from= =0A= >another certificate).=0A= =0A= The practice is unfortunately far too common in the X.509 world, where the= =0A= same key is re-certified year in, year out. The end result is a worst-of-= =0A= both-worlds system where you're forced to pay a CA every year to make the= =0A= browser warnings go away, but don't get the benefit of changing your key to= =0A= limit the damage due to a compromise. It's more PKI security theatre I=0A= guess...=0A= =0A= Peter.=0A= From nobody Tue Oct 13 03:59:32 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 B69161A924A for ; Tue, 13 Oct 2015 03:59:31 -0700 (PDT) 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 AKagOKXOiWfB for ; Tue, 13 Oct 2015 03:59:30 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::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 2FF321A9248 for ; Tue, 13 Oct 2015 03:59:30 -0700 (PDT) Received: by wicge5 with SMTP id ge5so52132227wic.0 for ; Tue, 13 Oct 2015 03:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=meiCEjVLN4IUqU0KAhEmqIM/I1ylGkM0RXZDDYpgC8Q=; b=XFyqUmGiN/FZzj4GKYvbTl/sspPOBDuMso1JQXgCkijdvHN790gFPo0nBVgoRfPqnP i7kMTe8xsh3sGlZd/EiNFza9jNX+vnovgcwZ448f3BQH+ZFhvaL40n3Tbak1q7Hkf/i0 0YUg9GTWpl8jgdgJ0vRZMbFFKkTnCaMXfhy64g+pd9fZaeAaAAQ9KrKDtJfl1Pb+4Db6 vynUqsw3hI4U9vFYy6BAhmPQXutRkVsYsc22uXZA5TWAVmJeeH9Z5+bgygsrblRdvO5m kcj0/zOPQtjHRjXHxuneS6/pTtUg2OxmqSiJ/aM2vhOpUvruLgdYPjxcfy96TmAvOmPv jepA== MIME-Version: 1.0 X-Received: by 10.180.88.164 with SMTP id bh4mr19178821wib.18.1444733968722; Tue, 13 Oct 2015 03:59:28 -0700 (PDT) Received: by 10.28.51.145 with HTTP; Tue, 13 Oct 2015 03:59:28 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B33D20@uxcn10-5.UoA.auckland.ac.nz> References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <87y4fi5wa9.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz> <8737xp5z45.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B279C6@uxcn10-5.UoA.auckland.ac.nz> <87fv1o4e9n.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2C5EE@uxcn10-5.UoA.auckland.ac.nz> <87wpuy1njl.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2D5B1@uxcn10-5.UoA.auckland.ac.nz> <87bnc91i5y.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2D663@uxcn10-5.UoA.auckland.ac.nz> <871td0w3mm.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B33D20@uxcn10-5.UoA.auckland.ac.nz> Date: Tue, 13 Oct 2015 06:59:28 -0400 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Werner Koch , Phillip Hallam-Baker , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Tue, 13 Oct 2015 10:59:31 -0000 On Tue, Oct 13, 2015 at 12:19 AM, Peter Gutmann wrote: > Werner Koch writes: > >>People have done this for X.509 keys a lot (although I heard that Mozilla now >>complains about using a new X.509 certificate with key material known from >>another certificate). > > The practice is unfortunately far too common in the X.509 world, where the > same key is re-certified year in, year out. The end result is a worst-of- > both-worlds system where you're forced to pay a CA every year to make the > browser warnings go away, but don't get the benefit of changing your key to > limit the damage due to a compromise. It's more PKI security theatre I > guess... X509 keys are authentication keys. You cannot go back and authenticate things that failed after compromise. > > Peter. -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Oct 13 04:36:13 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 696CA1ACD16 for ; Tue, 13 Oct 2015 04:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Y2beFRiPyy2u for ; Tue, 13 Oct 2015 04:36:09 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 984341AC41B for ; Tue, 13 Oct 2015 04:36:09 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZlxsF-0002vA-2G for ; Tue, 13 Oct 2015 13:36:07 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Zlxpb-0001IL-CG; Tue, 13 Oct 2015 13:33:23 +0200 From: Werner Koch To: Watson Ladd References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <87y4fi5wa9.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz> <8737xp5z45.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B279C6@uxcn10-5.UoA.auckland.ac.nz> <87fv1o4e9n.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2C5EE@uxcn10-5.UoA.auckland.ac.nz> <87wpuy1njl.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2D5B1@uxcn10-5.UoA.auckland.ac.nz> <87bnc91i5y.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B2D663@uxcn10-5.UoA.auckland.ac.nz> <871td0w3mm.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73F4B33D20@uxcn10-5.UoA.auckland.ac.nz> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Watson Ladd , Peter Gutmann , Phillip Hallam-Baker , Daniel Kahn Gillmor , IETF OpenPGP Date: Tue, 13 Oct 2015 13:33:23 +0200 In-Reply-To: (Watson Ladd's message of "Tue, 13 Oct 2015 06:59:28 -0400") Message-ID: <87a8rnuhoc.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: IETF OpenPGP , Phillip Hallam-Baker , Daniel Kahn Gillmor , Peter Gutmann Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 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: Tue, 13 Oct 2015 11:36:11 -0000 On Tue, 13 Oct 2015 12:59, watsonbladd@gmail.com said: > X509 keys are authentication keys. You cannot go back and authenticate Of course they are also used for encryption. That is specified by the key-usage (which commonly allows signing and encryption with the same key). Recall that X.509 keys are not only used for TLS but also for CMS. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Sun Oct 18 07:20:13 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 0ADC51A88F3 for ; Sun, 18 Oct 2015 07:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 3rZYW4rdkZCv for ; Sun, 18 Oct 2015 07:20:08 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (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 88ADA1A88ED for ; Sun, 18 Oct 2015 07:20:08 -0700 (PDT) Received: by wijp11 with SMTP id p11so66601203wij.0 for ; Sun, 18 Oct 2015 07:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=from:to:subject:message-id:date:user-agent:mime-version :content-type; bh=LXUPrX3xY08jlNhhY2WKl/5EpZ159n+BLlk89aetzjo=; b=Ay5iUmroPE0EXHKX2sdfr2vYU4gT1iELooyJTjhkoc3EbcE4laKHsaZE32WuTs+xEq 2ktEdI+ZxH+JStOgFlzsjftByJw2WbcCocDiGjHEk16q8tJzvwtPIDr8MGDbY0ApbSgf /dPx6Cn/hU/uVS3Ow4jdqnMrbaj3pb45e5OyxTehkGBQS3J14Er29cpyWXJZzvp4+dO1 8g9G28vDypnDGcsH7Rvit2S3oPI/vQoIcXs1zKx60haz50fkwHOpqn0oefFd8XpR8Dym 864mT/XrivzQzttoX1WZGLzDs7wf3TqgprdOvAtjSm1mkCVKpDNOQ+YahrHFPzykHI0u rTdA== X-Received: by 10.195.11.40 with SMTP id ef8mr28144512wjd.103.1445178007071; Sun, 18 Oct 2015 07:20:07 -0700 (PDT) Received: from [192.168.188.46] (x4db106c5.dyn.telefonica.de. [77.177.6.197]) by smtp.googlemail.com with ESMTPSA id jj8sm11128569wid.2.2015.10.18.07.20.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Oct 2015 07:20:06 -0700 (PDT) From: Nils Durner X-Enigmail-Draft-Status: N1110 To: "openpgp@ietf.org" Message-ID: <5623AA95.4060903@googlemail.com> Date: Sun, 18 Oct 2015 16:20:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------000008040907080307050501" Archived-At: Subject: [openpgp] [PATCH] RFC4880bis: Argon2i 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: Sun, 18 Oct 2015 14:20:11 -0000 This is a multi-part message in MIME format. --------------000008040907080307050501 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, attached is a patch against RFC 4880bis in git://git.gnupg.org/gnupg-doc.git to include Argon2i as an S2K method. Notes: * I have made room for 256-bit nonces. The Argon2 paper[0] recommends 16 byte nonces for password hashing with a maximum length of 2^32-1. My reason for this is to make the nonce size equal to the AES-256 key size so that we enjoy full key strength without relying on the password to contribute any entropy at all. * What do others think about the RECOMMENDATION of a parallelism degree of 1? Are use-cases known where hosts are unable to do multi-threading (well)? * Argon2 is not final yet, as far as I understand. The reference to it in template.xml should be checked/updated once it is. o Is Cryptolux.org considered a stable location to link to? * Private keys now MUST be protected using a salted S2K scheme Looking at http://wiki.gnupg.org/rfc4880bis, HKDF should be removed from the S2K candidates. From the HKDF paper[1]: > typical PBKDFs [...] use [...] salt [...] and (ii) the slowing down of > the KDF operation [...] This makes PBKDFs very different than the > general-purpose KDFs studied here. In particular, while passwords can > be modeled as a source of keying material, this source has too little > entropy to meaningfully apply our extractor approach So it cannot be used directly and the changes required to make it a suitable PBKDF would replicate the work done for the Password Hashing Competition[2] which selected Argon2 as the basis for its winner[3]. Regards, Nils [0] https://www.cryptolux.org/images/0/0d/Argon2.pdf [1] https://password-hashing.net/ [2] https://groups.google.com/forum/#!topic/crypto-competitions/3QNdmwBS9= 8o --------------000008040907080307050501 Content-Type: text/x-patch; name="rfc4880bis-argon2.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="rfc4880bis-argon2.diff" diff --git a/misc/id/rfc4880bis/middle.mkd b/misc/id/rfc4880bis/middle.mk= d index 80c0a61..97c506a 100644 --- a/misc/id/rfc4880bis/middle.mkd +++ b/misc/id/rfc4880bis/middle.mkd @@ -256,6 +256,7 @@ reserved values: 1 Salted S2K 2 Reserved value 3 Iterated and Salted S2K + 4 Argon2i 100 to 110 Private/Experimental S2K =20 These are described in the following Sections. @@ -340,11 +341,50 @@ even though that is greater than the octet count. = After the hashing is done, the data is unloaded from the hash context(s) as with the other S2K algorithms. =20 +#### {3.7.1.4} Argon2i + +This employs the password derivation scheme Argon2, which is memory-hard= +and resilient against side-channel and trade-off attacks. + + Octet 0: 0x04 + Octets 1-33: 32-octet salt + Octet 34: one-octet parallelism value + Octets 35-39: 4-octet memory size value + Octets 40-44: 4-octet iteration count + +The salt value corresponds to the nonce parameter of Argon2. The +parallelism value determines how many computational chains (threads) can= +be run. A parallelism degree of 1 is RECOMMENDED. The memory size value +is the number of kilobytes of memory to be used when deriving the +password. This value MUST at least be 8 * parallelism degree. The +iteration account specifies the number of passes over memory. To protect= +against trade-off attacks, 3 iterations are RECOMMENDED. + +Other secondary inputs to Argon2 are not used: secret key K and +associated data X MUST be passed with 0-octet length to Argon2. +The tag length parameter to Argon2 that describes the length of the +derived symmetric key MUST be equal to the key size of the symmetric +cipher to be used. The version parameter v MUST be set to 0x10, the +type parameter y to 1, thus specifying that the Argon2i variant is to be= +used. + +##### {3.7.1.4.1} NON-NORMATIVE NOTES +Implementations can improve memory bandwidth usage by choosing larger +parallelism degrees than 1. The number of memory blocks to be used in +Argon2 is internally rounded down to the nearest multiple of +4 * parallelism degree. The iteration count can be used to tune running +time independently of the memory size. + ### {3.7.2} String-to-Key Usage =20 -Implementations SHOULD use salted or iterated-and-salted S2K -specifiers, as simple S2K specifiers are more vulnerable to dictionary -attacks. +Implementations MUST generate S2K specifiers that include salts +(either type 2, 3 or 4), as simple S2K specifiers are more vulnerable to= +dictionary attacks. Use of Argon2i is RECOMMENDED as it offers +protection against massive-parallel and side-channel attacks. When +reading S2K specifiers that do not include salts, implementations SHOULD= +issue a warning about potentially insecure methods being used. When +reading S2K specifiers other than Argon2i, implementations SHOULD issue +a warning about outdated methods being used. =20 #### {3.7.2.1} Secret-Key Encryption =20 @@ -1646,9 +1686,9 @@ following Symmetrically Encrypted Data packet, foll= owed by the session key octets themselves. =20 Note: because an all-zero IV is used for this decryption, the S2K -specifier MUST use a salt value, either a Salted S2K or an -Iterated-Salted S2K. The salt value will ensure that the decryption -key is not repeated even if the passphrase is reused. +specifier MUST use a salt value, either S2K types 1, 3 or 4. +The salt value will ensure that the decryption key is not repeated even +if the passphrase is reused. =20 ## {5.4} One-Pass Signature Packets (Tag 4) =20 @@ -4120,8 +4160,7 @@ SHOULD be rejected. MDC MUST be used when a symmetric encryption key is protected by ECDH. None of the ECC methods described in this document are allowed with deprecated V3 keys. A compliant application MUST only - use iterated and salted S2K to protect private keys, as defined in - Section 3.7.1.3{FIXME}, "Iterated and Salted S2K". + use S2K schemes that make use of salts to protect private keys. =20 Side channel attacks are a concern when a compliant application's use of the OpenPGP format can be modeled by a decryption or signing diff --git a/misc/id/rfc4880bis/template.xml b/misc/id/rfc4880bis/templat= e.xml index 82cfd27..a2a86a0 100644 --- a/misc/id/rfc4880bis/template.xml +++ b/misc/id/rfc4880bis/template.xml @@ -94,6 +94,16 @@ + + + Argon2: the memory-hard function for password hashing and= other applications + + + + + + =20 --------------000008040907080307050501-- From nobody Mon Oct 19 09:52:30 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 CEDC51A89A0 for ; Mon, 19 Oct 2015 09:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aTPD_6KhOn6r for ; Mon, 19 Oct 2015 09:52:27 -0700 (PDT) Received: from master.debian.org (master.debian.org [IPv6:2001:41b8:202:deb:216:36ff:fe40:4001]) (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 CCBA31A8A8D for ; Mon, 19 Oct 2015 09:52:24 -0700 (PDT) Received: from guillem by master.debian.org with local (Exim 4.84) (envelope-from ) id 1ZoDfa-0003s2-PO for openpgp@ietf.org; Mon, 19 Oct 2015 16:52:22 +0000 Date: Mon, 19 Oct 2015 18:52:13 +0200 From: Guillem Jover To: openpgp@ietf.org Message-ID: <20151019165213.GA15609@gaara.hadrons.org> References: <20150918162458.GA14374@gaara.hadrons.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150918162458.GA14374@gaara.hadrons.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [openpgp] OpenPGP Armor Message specification 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: Mon, 19 Oct 2015 16:52:30 -0000 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hi! On Fri, 2015-09-18 at 18:24:58 +0200, Guillem Jover wrote: > As I mentioned to Werner and Daniel at DebConf 15, I think the > specification of the OpenPGP Armor Messages has some unclear parts, > which I think were part of the reason for several security issues > in multiple projects due to mismatched parsing of Armor Header Lines. > > > > > > > > Here are some things that would be good to clarify in RFC4880: > > * In §6.2 there's no explicit definition of what ASCII characters are > to be considered whitespace (contrast that with §7.1). In this case > GnuPG considers whitespace to be «SPACE 0x20, HT 0x09 and CR 0x0D» > and now most tools in Debian do too. I don't know if that matches > with PGP for example. > > * In §7, mention that this is a specific instance of §6.2? > > * In §7, probably clarify that by «empty» in: > «- Exactly one empty line not included into the message digest,» > it means «blank» as in §6.2: > «- A blank (zero-length, or containing only whitespace) line» Ok, how about something along the lines of the attached patch against RFC4880bis? Although maybe it would be better to define "whitespace" just once instead of inlining it in several places. Thanks, Guillem --Dxnq1zWXvFF0Q93v Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0001-Clarify-ASCII-Armoring-and-Cleartext-formats.patch" Content-Transfer-Encoding: quoted-printable =46rom 159e601ec1e05d78d51a1e8af30e10260617848a Mon Sep 17 00:00:00 2001 =46rom: Guillem Jover Date: Mon, 19 Oct 2015 16:33:32 +0200 Subject: [PATCH] Clarify ASCII Armoring and Cleartext formats Describe explicitly what ASCII characters are considered whitespace. Use "blank" instead of "empty" when referring to a blank line that can be either zero-length or contain only whitespace, and describe what it means. Mention that Section 7 follows the same format and restrictions of Section 6.2. Add that trailing whitespace at the end of any line is removed for both signature generation and verification. --- misc/id/rfc4880bis/middle.mkd | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/misc/id/rfc4880bis/middle.mkd b/misc/id/rfc4880bis/middle.mkd index 80c0a61..1c919aa 100644 --- a/misc/id/rfc4880bis/middle.mkd +++ b/misc/id/rfc4880bis/middle.mkd @@ -2403,7 +2403,7 @@ Concatenating the following data creates ASCII Armor: =20 * Armor Headers =20 - * A blank (zero-length, or containing only whitespace) line + * A blank line =20 * The ASCII-Armored data =20 @@ -2450,7 +2450,8 @@ Note that all these Armor Header Lines are to consist= of a complete line. That is to say, there is always a line ending preceding the starting five dashes, and following the ending five dashes. The header lines, therefore, MUST start at the beginning of a line, and MUST NOT -have text other than whitespace following them on the same line. These +have text other than whitespace -- space (0x20), tab (0x09) or carriage +return (0x0d) -- following them on the same line. These line endings are considered a part of the Armor Header Line for the purposes of determining the content they delimit. This is particularly important when computing a cleartext signature (see below). @@ -2517,6 +2518,9 @@ Currently defined Armor Header Keys are as follows: cares to; an implementation MAY ignore it and assume all text is UTF-8. =20 +The blank line can either be zero-length or contain only whitespace, +that is spaces (0x20), tabs (0x09) or carriage returns (0x0d). + The Armor Tail Line is composed in the same manner as the Armor Header Line, except the string "BEGIN" is replaced by the string "END". =20 @@ -2639,7 +2643,9 @@ would have no leading whitespace. It is desirable to be able to sign a textual octet stream without ASCII armoring the stream itself, so the signed text is still readable without special software. In order to bind a signature to such a -cleartext, this framework is used. (Note that this framework is not +cleartext, this framework is used, which follows the the same basic +format and restrictions as the ASCII armoring described above in +"Forming ASCII Armor" (Section 6.2). (Note that this framework is not intended to be reversible. RFC 3156 [](#RFC3156) defines another way to sign cleartext messages for environments that support MIME.) =20 @@ -2650,7 +2656,7 @@ The cleartext signed message consists of: =20 - One or more "Hash" Armor Headers, =20 - - Exactly one empty line not included into the message digest, + - Exactly one blank line not included into the message digest, =20 - The dash-escaped cleartext that is included into the message digest, @@ -2695,9 +2701,9 @@ When reversing dash-escaping, an implementation MUST = strip the string "- " if it occurs at the beginning of a line, and SHOULD warn on "-" and any character other than a space at the beginning of a line. =20 -Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at -the end of any line is removed when the cleartext signature is -generated. +Also, any trailing whitespace -- spaces (0x20), tabs (0x09) or +carriage returns (0x0d) -- at the end of any line is removed when +the cleartext signature is generated and verified. =20 # {8} Regular Expressions =20 --=20 2.6.1.204.gc021fdf --Dxnq1zWXvFF0Q93v-- From nobody Fri Oct 23 11:01:03 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 AE8741A1BA2 for ; Fri, 23 Oct 2015 11:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 MUgzx9jHzEIn for ; Fri, 23 Oct 2015 11:00:59 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 B06E21A1B8E for ; Fri, 23 Oct 2015 11:00:58 -0700 (PDT) Received: by lffv3 with SMTP id v3so92108034lff.0 for ; Fri, 23 Oct 2015 11:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=kV57Y2EmbftryWUbzg/XgeHajsm8hnqawy76cloafd4=; b=QOMx3+w99/VptcQgGua/4iDrlUYIFSACAzAZFVMX0uDa1nS6YvcJZy6ty6s4QaQ31q uMCheXWKrdsZbT8ZLz5XYuCujBlYIJ2LfxQYPR+Jj/UrPdgaluJ6PDOXrAtFwxJj6SAe U+x3brsWBGfB0N81lPb1UJfE8Q8o7m/vLwAiFxvGkmdIgREpl3rnPmWdPc+ehYsojUxE nXdS69YN55onbOtiFhEN3onGecwp1WQIovGtfMsZaE97xUwWTj+fmEI6S0Ufr9KCqKz1 3wLb/E8LB6IfprcIoDu76qaaKqPNJb/n35UiJgkBXEYaiIiDDu8hqnSm+7vkgNN65D3/ 04PA== MIME-Version: 1.0 X-Received: by 10.25.21.83 with SMTP id l80mr8034702lfi.79.1445623256846; Fri, 23 Oct 2015 11:00:56 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.213.75 with HTTP; Fri, 23 Oct 2015 11:00:56 -0700 (PDT) In-Reply-To: <561BAB91.8040104@epointsystem.org> References: <878u84zy4r.fsf@vigenere.g10code.de> <55FD7CF0.8030200@iang.org> <87io742kz7.fsf@latte.josefsson.org> <87mvw4ctv5.fsf_-_@vigenere.g10code.de> <20151006110330.38b38ea4@latte.josefsson.org> <5616F2AE.5050106@iang.org> <561BAB91.8040104@epointsystem.org> Date: Fri, 23 Oct 2015 14:00:56 -0400 X-Google-Sender-Auth: DUizgwSavkvqG8O0srvPXmwA3LA Message-ID: From: Phillip Hallam-Baker To: "Daniel A. Nagy" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] New fingerprint: which hash algo 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: Fri, 23 Oct 2015 18:01:00 -0000 On Mon, Oct 12, 2015 at 8:46 AM, Daniel A. Nagy wrote: > Hello, > > Now that SHA1 is on the brink of being broken, I believe that all > Merkle=E2=80=93Damg=C3=A5rd hashes should be avoided in new designs. Kecc= ak (SHA-3) > is just better in so many ways. > > Daniel The consensus among folk who followed the SHA-3 competition more closely that I did was that they came to understand a lot more about SHA-2 and were much more confident about it as a result. The strong consensus is that every application requiring a digest should require either SHA-2 or SHA-3 and strongly recommend BOTH. SHA-3 is a newer construction and has been chosen so that it is highly unlikely that a single attack would defeat both. But it is not considered 'more secure'. It is different but that only gives you an advantage if you use both so that you can make use of the diversity. We stopped using MD5 very quickly. Most people had dropped it before the attack was widely known. That was possible because SSL 2.0 had required the use of MD5 and SHA-1 to construct the MAC. So the transition was painless. It took the platform providers much longer to support SHA2 and when they did they refused to support any mechanism that would make it easy to manage the transition. Due to the way OpenPGP works, it is not possible to have a recommended algorithm for fingerprints. Every client has to be able to process any recommended algorithm, so recommended means 'mandatory to accept'. But there should definitely be two algorithms to choose from. That is why I use the first octet in UDF to serve as an algorithm flag. It is precisely so that we can adapt if the need should arise. We can argue as to whether we need 8 bits or could survive with 5 or even one. But if you want to do the job properly you need to have an identifier. The other part of UDF is constructed so that it is possible to use the same support infrastructure for both OpenPGP fingerprints and SSH fingerprints without any risk of unfortunate interactions. From nobody Fri Oct 23 13:16:57 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 80F921A8A62 for ; Fri, 23 Oct 2015 13:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 LArliOFWcfJC for ; Fri, 23 Oct 2015 13:16:42 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 87C8A1A8A55 for ; Fri, 23 Oct 2015 13:16:42 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 0C0A7F984; Fri, 23 Oct 2015 16:16:38 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id C6FC71FF82; Fri, 23 Oct 2015 16:16:10 -0400 (EDT) From: Daniel Kahn Gillmor To: Phillip Hallam-Baker , "Daniel A. Nagy" In-Reply-To: References: <878u84zy4r.fsf@vigenere.g10code.de> <55FD7CF0.8030200@iang.org> <87io742kz7.fsf@latte.josefsson.org> <87mvw4ctv5.fsf_-_@vigenere.g10code.de> <20151006110330.38b38ea4@latte.josefsson.org> <5616F2AE.5050106@iang.org> <561BAB91.8040104@epointsystem.org> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Fri, 23 Oct 2015 16:16:10 -0400 Message-ID: <87twph8ho5.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] New fingerprint: which hash algo 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: Fri, 23 Oct 2015 20:16:49 -0000 On Fri 2015-10-23 14:00:56 -0400, Phillip Hallam-Baker wrote: > Due to the way OpenPGP works, it is not possible to have a recommended > algorithm for fingerprints. Every client has to be able to process any > recommended algorithm, so recommended means 'mandatory to accept'. But > there should definitely be two algorithms to choose from. In earlier discussions, i think people have made pretty convincing arguments that "two algorithms to choose from" is not a useful arrangement for OpenPGP fingerprints. In particular, fingerprints are used in verification contexts where the user has a bit of paper and sees something on the screen and is asked a question "do these things match?" If there are two algorithms to choose from, there are potentially two fingerprints to choose from, and this process becomes more complicated. the tool now has to either (a) first, ask the user which form of fingerprint is on the bit of paper before displaying the fingerprint (making fingerprint comparison a multi-roundtrip operation), or (b) present both and hope the user knows to ignore one or the other (similarly to how web browser certificate dialogs look, and we know how well that works). Either of these outcomes make this particular use case -- which already has bad usability -- worse. Arguably, we shouldn't encourage this use case at all, and should replace it with something like "type in the expected fingerprint and we'll tell you if it matches". If we make that decision, the argument for multiple fingerprint algorithms might be OK. But while i use this workflow myself, i think most users would find it too burdensome. Reading high-entropy hexadecimal (or base64 or whatever) is bad enough. typing it in is even worse. --dkg From nobody Fri Oct 23 13:43: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 AE2571A907D for ; Fri, 23 Oct 2015 13:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 It1ojBeRGA5V for ; Fri, 23 Oct 2015 13:43:46 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3271A1A906F for ; Fri, 23 Oct 2015 13:43:46 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by virulha.pair.com (Postfix) with ESMTPSA id B8F046D753; Fri, 23 Oct 2015 16:43:44 -0400 (EDT) To: openpgp@ietf.org References: <878u84zy4r.fsf@vigenere.g10code.de> <55FD7CF0.8030200@iang.org> <87io742kz7.fsf@latte.josefsson.org> <87mvw4ctv5.fsf_-_@vigenere.g10code.de> <20151006110330.38b38ea4@latte.josefsson.org> <5616F2AE.5050106@iang.org> <561BAB91.8040104@epointsystem.org> <87twph8ho5.fsf@alice.fifthhorseman.net> From: ianG Message-ID: <562A9BFF.90708@iang.org> Date: Fri, 23 Oct 2015 21:43:43 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <87twph8ho5.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] New fingerprint: which hash algo 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: Fri, 23 Oct 2015 20:43:47 -0000 On 23/10/2015 21:16 pm, Daniel Kahn Gillmor wrote: > On Fri 2015-10-23 14:00:56 -0400, Phillip Hallam-Baker wrote: >> Due to the way OpenPGP works, it is not possible to have a recommended >> algorithm for fingerprints. Every client has to be able to process any >> recommended algorithm, so recommended means 'mandatory to accept'. But >> there should definitely be two algorithms to choose from. > > In earlier discussions, i think people have made pretty convincing > arguments that "two algorithms to choose from" is not a useful > arrangement for OpenPGP fingerprints. Yes, giving users "choice" in cryptographic algorithms is a bad idea in general. > In particular, fingerprints are used in verification contexts where the > user has a bit of paper and sees something on the screen and is asked a > question "do these things match?" > > If there are two algorithms to choose from, there are potentially two > fingerprints to choose from, and this process becomes more complicated. > the tool now has to either (a) first, ask the user which form of > fingerprint is on the bit of paper before displaying the fingerprint > (making fingerprint comparison a multi-roundtrip operation), or > (b) present both and hope the user knows to ignore one or the other > (similarly to how web browser certificate dialogs look, and we know how > well that works). > > Either of these outcomes make this particular use case -- which already > has bad usability -- worse. > > Arguably, we shouldn't encourage this use case at all, and should > replace it with something like "type in the expected fingerprint and > we'll tell you if it matches". If we make that decision, the argument > for multiple fingerprint algorithms might be OK. But while i use this > workflow myself, i think most users would find it too burdensome. > Reading high-entropy hexadecimal (or base64 or whatever) is bad enough. > typing it in is even worse. IFF it is decided that there are two incompatible fingerprint schemes then they should be made unconfusable. One way to do this is to use PHB's leading byte or nibble indicator. Another way to do this would be to split the lengths such that one set of lengths is valid in one MD, and another is valid in another MD. SO e.g., anything 8, 12, 16, 20 bytes long is SHA2 and 10,14,18,22 are reserved for SHA3, etc. (Just for explanatory purposes. PHB also has his 5-byte method which I quite like.) iang ps; just to re-iterate my view on multiple algorithms, I've yet to see a compelling argument, being one that is actually founded rather than circulated or based on claims of caution. From nobody Mon Oct 26 09:02:38 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 ABCAC1B4574 for ; Mon, 26 Oct 2015 09:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 heG_JcCijkUt for ; Mon, 26 Oct 2015 09:02:35 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 3684E1B2FF0 for ; Mon, 26 Oct 2015 09:02:35 -0700 (PDT) Received: by lffz202 with SMTP id z202so154660873lff.3 for ; Mon, 26 Oct 2015 09:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=xes95k7KlDl2358Z++ymPt6GNT/40bpAJ08UEdQ9nrE=; b=VhhKnc5WadRfElCmhHTdI+s4tAOlkiC+ugY6ttfmgohTWW2iNbVRD4EtW/bfDPr1f+ /iHRl58TM5sA/RRtbKp29US0KpsxoEQuMYxDqdLsDRyjnb1fXEO/c3oolTjzCWMIcKT+ Qh86pgjlb+ofFrMQ8zSyDirouVKF9s80S4tXnckwUnkTzpfqhEEH9aZCqSX8dFE7hYcN wSef/U/1tmVRDjzpjj0pwEc+N7935Odbtoqe430PPypKoXjRJPZbZPljnybHE2IC38bs 1hAZ2VrRC5ODjTcrUJ7TAMkALATEl4nMBwXfRfALMILpHqiVPBBEzlvz+OlS1XOCBa9R eraw== MIME-Version: 1.0 X-Received: by 10.112.168.194 with SMTP id zy2mr18312924lbb.79.1445875353454; Mon, 26 Oct 2015 09:02:33 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.213.75 with HTTP; Mon, 26 Oct 2015 09:02:33 -0700 (PDT) In-Reply-To: <87twph8ho5.fsf@alice.fifthhorseman.net> References: <878u84zy4r.fsf@vigenere.g10code.de> <55FD7CF0.8030200@iang.org> <87io742kz7.fsf@latte.josefsson.org> <87mvw4ctv5.fsf_-_@vigenere.g10code.de> <20151006110330.38b38ea4@latte.josefsson.org> <5616F2AE.5050106@iang.org> <561BAB91.8040104@epointsystem.org> <87twph8ho5.fsf@alice.fifthhorseman.net> Date: Mon, 26 Oct 2015 12:02:33 -0400 X-Google-Sender-Auth: 1zBS2L3vuvzoRqy9wJXZXigo1xo Message-ID: From: Phillip Hallam-Baker To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP , "Daniel A. Nagy" Subject: Re: [openpgp] New fingerprint: which hash algo 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: Mon, 26 Oct 2015 16:02:36 -0000 On Fri, Oct 23, 2015 at 4:16 PM, Daniel Kahn Gillmor wrote: > On Fri 2015-10-23 14:00:56 -0400, Phillip Hallam-Baker wrote: >> Due to the way OpenPGP works, it is not possible to have a recommended >> algorithm for fingerprints. Every client has to be able to process any >> recommended algorithm, so recommended means 'mandatory to accept'. But >> there should definitely be two algorithms to choose from. > > In earlier discussions, i think people have made pretty convincing > arguments that "two algorithms to choose from" is not a useful > arrangement for OpenPGP fingerprints. As I pointed out, it isn't really a choice. Every client has to be able to verify any fingerprint that can be generated. > In particular, fingerprints are used in verification contexts where the > user has a bit of paper and sees something on the screen and is asked a > question "do these things match?" Again, I did point out that issue. If you have more than one digest algorithm, each has to result in a unique presentation. Hence the need for tagging. > If there are two algorithms to choose from, there are potentially two > fingerprints to choose from, and this process becomes more complicated. > the tool now has to either (a) first, ask the user which form of > fingerprint is on the bit of paper before displaying the fingerprint > (making fingerprint comparison a multi-roundtrip operation), or > (b) present both and hope the user knows to ignore one or the other > (similarly to how web browser certificate dialogs look, and we know how > well that works). Only if either you do it wrong or decide on one algorithm and pick the wrong one. That is the same problem that comes up with attacks involving presenting a SSH key to OpenPGP or vice versa. > Either of these outcomes make this particular use case -- which already > has bad usability -- worse. > > Arguably, we shouldn't encourage this use case at all, and should > replace it with something like "type in the expected fingerprint and > we'll tell you if it matches". If we make that decision, the argument > for multiple fingerprint algorithms might be OK. But while i use this > workflow myself, i think most users would find it too burdensome. > Reading high-entropy hexadecimal (or base64 or whatever) is bad enough. > typing it in is even worse. I don't think that is right either. I would prefer to make comparison a lot easier by going for visual comparisons. Base32 is a lowest common denominator approach. I would like to have an alphabet of 2^16 words and 2^16 images as well. From nobody Fri Oct 30 03:01:06 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 333771B2A37 for ; Fri, 30 Oct 2015 03:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.542 X-Spam-Level: * X-Spam-Status: No, score=1.542 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DATE_IN_PAST_06_12=1.543] autolearn=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 fC02QTC88O4N for ; Fri, 30 Oct 2015 03:01:01 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 80A831B2A45 for ; Fri, 30 Oct 2015 03:01:01 -0700 (PDT) Received: from fifthhorseman.net (y125068.ppp.asahi-net.or.jp [118.243.125.68]) by che.mayfirst.org (Postfix) with ESMTPSA id 96570F98C; Fri, 30 Oct 2015 06:00:52 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id A456E20161; Thu, 29 Oct 2015 19:11:48 -0400 (EDT) From: Daniel Kahn Gillmor To: cfrg@irtf.org, openpgp@ietf.org User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Fri, 30 Oct 2015 08:11:48 +0900 Message-ID: <87twp91d8r.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [openpgp] streamable AEAD construct for stored data? 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: Fri, 30 Oct 2015 10:01:04 -0000 Hi CFRG folks-- We're looking into fixing the OpenPGP symmetrically-encrypted data formats for RFC4880bis. The structures are used for mail messages but also for large file encryption. It's clear that the OpenPGP CFB mode isn't designed to modern symmetric encryption standards, so we're hoping to introduce a better approach. We need, among other things to address integrity protection in a more meaningful way than the current OpenPGP MDC (modification detection code), which is basically a SHA-1 hash of the cleartext. This was never much better than a band-aid. And as discussed in the recent "OpenPGP SEIP downgrade attack" thread, an "integrity-protected" packet with an MDC can be stripped down to produce a syntactically-valid packet without integrity protection. But one of our constraints is the OpenPGP use case that streams decrypted data, like this: pgp --decrypt Ideally such a scheme would take an AEAD and produce something very > like an AEAD in that it takes a key, nonce and additional data, but > can safely work in a streaming fashion. I don't think it need be very > complex: take 64 bits of the nonce from the underlying AEAD as the > chunk number, always start with chunk number zero and feed the > additional data into chunk zero with a zero byte prefix. Prefix each > chunk ciphertext with a 16 bit length and set the MSB to indicate the > last chunk and authenticate that indication by setting the additional > data to a single, 1 byte. The major worry might be that for many > underlying AEADs, taking 64 bits of the nonce for the chunk counter > leaves one with very little (or none!) left. Two examples of projects that take something like this approach are miniLock and Tahoe-LAFS: https://github.com/kaepora/miniLock https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/specifications/file-encoding.rst I'm unaware of any formalization of this approach, though. Does anyone know of one? If OpenPGP were to adopt AGL's construct, are there specific risks to be aware of? This approach still has two notable problems i can see, which may or may not be addressable (but if they are, i'd love to hear it): a) it doesn't deal with truncation -- the initially-streamed data has already been streamed by the time a truncation is discovered. (there may be no way to fix this; it seems kind of like a fact of nature, and if so, systems should only do streaming decryption if they're capable of coping with truncation) b) it doesn't seem to compose as well with asymmetric signatures as one might like: a signature over the whole material can't itself be verified until one full pass through the data; and a signature over just the symmetric key would prove nothing, since anyone getting the symmetric key could forge an arbitrary valid, decryptable stream. Is there an intermediate approach that would combine an asymmetric signature with a chunkable authenticated encryption such that a decryptor could stream one pass and be certain of its origin (at least up until truncation, if (a) can't be resolved)? Thoughts, pointers, or suggestions would be much appreciated. --dkg From nobody Fri Oct 30 05:30:51 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 3D2641B2B10 for ; Fri, 30 Oct 2015 05:30:50 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=unavailable 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 NAubsKYQAK_6 for ; Fri, 30 Oct 2015 05:30:47 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 B7A521B2B08 for ; Fri, 30 Oct 2015 05:30:46 -0700 (PDT) Received: by wicfx6 with SMTP id fx6so9546674wic.1 for ; Fri, 30 Oct 2015 05:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5dnSDYYfhPEJqMVug9Qcrxstj9vm97kmrba0GxlixO8=; b=GU1D2mWmDwFjJz32mQ8nwljavV9ZliJpLx9D4afVsH1/UABfC99XLdQ1o68uuZy+z/ i080LCRm+RV+uMmpr8ZVsLpXABhbq4yHWGLdybtStnUe5Azl4Gp0K9QyINpBuG9iKWS3 Xp/SL64VG7sx77mcSmT8eLalFlNdF+Yk5F3vqtSrKajInmnTEe/K1IHZtOyzHRGHxhs8 ggIqd4u7GrjDT7Ifz+UBD94SFS69bywu+A4SnWrxTF9No2XCgli5zZH4wXzwng2Vh4if Sr9Okt4XWQlgEmWli57uP08IyVRU5QZIgOD/Fx2imMMlloFhN6A1W0i80opcyG6D2o/j /dRg== MIME-Version: 1.0 X-Received: by 10.194.203.101 with SMTP id kp5mr8031876wjc.64.1446208245250; Fri, 30 Oct 2015 05:30:45 -0700 (PDT) Received: by 10.28.101.212 with HTTP; Fri, 30 Oct 2015 05:30:44 -0700 (PDT) Received: by 10.28.101.212 with HTTP; Fri, 30 Oct 2015 05:30:44 -0700 (PDT) In-Reply-To: References: <87twp91d8r.fsf@alice.fifthhorseman.net> Date: Fri, 30 Oct 2015 08:30:44 -0400 Message-ID: From: Watson Ladd To: Natanael Content-Type: multipart/alternative; boundary=047d7b622670babff30523519828 Archived-At: Cc: IETF OpenPGP , cfrg@irtf.org, Daniel Kahn Gillmor Subject: Re: [openpgp] [Cfrg] streamable AEAD construct for stored data? 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: Fri, 30 Oct 2015 12:30:50 -0000 --047d7b622670babff30523519828 Content-Type: text/plain; charset=UTF-8 On Oct 30, 2015 8:25 AM, "Natanael" wrote: > > > Den 30 okt 2015 11:01 skrev "Daniel Kahn Gillmor" : > > > > Hi CFRG folks-- > > > > We're looking into fixing the OpenPGP symmetrically-encrypted data > > formats for RFC4880bis. The structures are used for mail messages but > > also for large file encryption. It's clear that the OpenPGP CFB mode > > isn't designed to modern symmetric encryption standards, so we're hoping > > to introduce a better approach. > > > > We need, among other things to address integrity protection in a more > > meaningful way than the current OpenPGP MDC (modification detection > > code), which is basically a SHA-1 hash of the cleartext. This was never > > much better than a band-aid. And as discussed in the recent "OpenPGP > > SEIP downgrade attack" thread, an "integrity-protected" packet with an > > MDC can be stripped down to produce a syntactically-valid packet without > > integrity protection. > > > > But one of our constraints is the OpenPGP use case that streams > > decrypted data, like this: > > [...] > > > This approach still has two notable problems i can see, which may or may > > not be addressable (but if they are, i'd love to hear it): > > > > a) it doesn't deal with truncation -- the initially-streamed data has > > already been streamed by the time a truncation is discovered. > > (there may be no way to fix this; it seems kind of like a fact of > > nature, and if so, systems should only do streaming decryption if > > they're capable of coping with truncation) > > Does it help to define the ciphertext length and check that first, before decrypting? Doesn't help if the file isn't local and the connection is broken, but then at least your software should detect that and halt of necessary. > > > b) it doesn't seem to compose as well with asymmetric signatures as one > > might like: a signature over the whole material can't itself be > > verified until one full pass through the data; and a signature over > > just the symmetric key would prove nothing, since anyone getting the > > symmetric key could forge an arbitrary valid, decryptable stream. > > Is there an intermediate approach that would combine an asymmetric > > signature with a chunkable authenticated encryption such that a > > decryptor could stream one pass and be certain of its origin (at > > least up until truncation, if (a) can't be resolved)? > > > > Thoughts, pointers, or suggestions would be much appreciated. Use authenticated encryption so no signatures are required. Detached signature verification is used for large public messages already: no streaming needed. > > To solve B what you need to do is something like signing a list of ciphertext hashes/authentication tags. The idea below demands conditions beyond MAC security. > > One thought I've had before (my idea is to use it for FDE*) is to for example use HMAC over segments (including counters) or to extract AEAD tags (prefixed with counters to preserve order) and create a Merkle tree hash of those lists when creating the message, to then sign that Merkle tree, such that when you decrypt and recreate the tags for comparison you can confirm that nothing has been modified (with the level of assurance that the tags can provide). Or you skip the standard AEAD and MAC constructs and use a signed Merkle tree hash of the ciphertext itself as your own custom MAC. > > One benefit of using a hash-tree like algorithm with a signature is the reduction of storage overhead and memory usage, and that you retain the ability to independently verify each segment. Ideally you would use a hash-tree like algorithm which also can be generated efficiently in a single pass over even large ciphertexts with reasonable memory usage (does anybody know of one?). > > Not that I've also read the referenced Tahoe-LAFS link, it looks like they're doing something very close to what I described above, but slightly different: > They use AES-CTR over the whole file with a unique key, one plain hash over the entire ciphertext, one Merkle tree hash over the ciphertext blocks and one Merkle tree hash over the erasure coded shares of the blocks, if I'm reading it correctly, with all three hashes stored in plaintext with the shares and then hashed together (also including the length of the file). They also have some sort of hash chain, but the graphics don't load and I can't figure out how exactly it is applied, beyond potentially having to do with confirming the order of blocks. Instead of using HMAC they use double SHA256 in a particular format. > > Minus the erasure coding** and with an added signature of the file hashes/header, that's almost exactly what I imagined, I'm just worried about the risk of the performance penalty limiting adoption. If the performance of this method is considered acceptable or can be improved to an acceptable level, I definitely support using it. > > * A bit off topic here, but for FDE I imagine changing the encryption key every write-session using a KDF and session counter, keeping an authenticated encrypted list of which segments uses which session write keys. This way you prevent partial ciphertext reversal and prevent detection of when ciphertext segments repeat over time (re-zeroized or restored files). You can also arbitrarily re-encrypt random segments to obscure your real write patterns (and reduce the list size occasionally by purging unused keys after re-encrypting the last segments using them). > > ** In Tahoe-LAFS, erasure coding of blocks is used to allow you to split files across storage nodes with minimal risk of data loss. That's not applicable here, as it can be applied independently when considered necessary. > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --047d7b622670babff30523519828 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 30, 2015 8:25 AM, "Natanael" <natanael.l@gmail.com> wrote:
>
>
> Den 30 okt 2015 11:01 skrev "Daniel Kahn Gillmor" <dkg@fifthhorseman.net>:
> >
> > Hi CFRG folks--
> >
> > We're looking into fixing the OpenPGP symmetrically-encrypted= data
> > formats for RFC4880bis.=C2=A0 The structures are used for mail me= ssages but
> > also for large file encryption.=C2=A0 It's clear that the Ope= nPGP CFB mode
> > isn't designed to modern symmetric encryption standards, so w= e're hoping
> > to introduce a better approach.
> >
> > We need, among other things to address integrity protection in a = more
> > meaningful way than the current OpenPGP MDC (modification detecti= on
> > code), which is basically a SHA-1 hash of the cleartext.=C2=A0 Th= is was never
> > much better than a band-aid.=C2=A0 And as discussed in the recent= "OpenPGP
> > SEIP downgrade attack" thread, an "integrity-protected&= quot; packet with an
> > MDC can be stripped down to produce a syntactically-valid packet = without
> > integrity protection.
> >
> > But one of our constraints is the OpenPGP use case that streams > > decrypted data, like this:
>
> [...]
>
> > This approach still has two notable problems i can see, which may= or may
> > not be addressable (but if they are, i'd love to hear it): > >
> > =C2=A0a) it doesn't deal with truncation -- the initially-str= eamed data has
> > =C2=A0 =C2=A0 already been streamed by the time a truncation is d= iscovered.
> > =C2=A0 =C2=A0 (there may be no way to fix this; it seems kind of = like a fact of
> > =C2=A0 =C2=A0 nature, and if so, systems should only do streaming= decryption if
> > =C2=A0 =C2=A0 they're capable of coping with truncation)
>
> Does it help to define the ciphertext length and check that first, bef= ore decrypting? Doesn't help if the file isn't local and the connec= tion is broken, but then at least your software should detect that and halt= of necessary.
>
> > =C2=A0b) it doesn't seem to compose as well with asymmetric s= ignatures as one
> > =C2=A0 =C2=A0 might like: a signature over the whole material can= 't itself be
> > =C2=A0 =C2=A0 verified until one full pass through the data; and = a signature over
> > =C2=A0 =C2=A0 just the symmetric key would prove nothing, since a= nyone getting the
> > =C2=A0 =C2=A0 symmetric key could forge an arbitrary valid, decry= ptable stream.
> > =C2=A0 =C2=A0 Is there an intermediate approach that would combin= e an asymmetric
> > =C2=A0 =C2=A0 signature with a chunkable authenticated encryption= such that a
> > =C2=A0 =C2=A0 decryptor could stream one pass and be certain of i= ts origin (at
> > =C2=A0 =C2=A0 least up until truncation, if (a) can't be reso= lved)?
> >
> > Thoughts, pointers, or suggestions would be much appreciated.

Use authenticated encryption so no signatures are required. = Detached signature verification is used for large public messages already: = no streaming needed.
>
> To solve B what you need to do is something like signing a list of cip= hertext hashes/authentication tags.

The idea below demands conditions beyond MAC security.

>
> One thought I've had before (my idea is to use it for FDE*) is to = for example use HMAC over segments (including counters) or to extract AEAD = tags (prefixed with counters to preserve order) and create a Merkle tree ha= sh of those lists when creating the message, to then sign that Merkle tree,= such that when you decrypt and recreate the tags for comparison you can co= nfirm that nothing has been modified (with the level of assurance that the = tags can provide). Or you skip the standard AEAD and MAC constructs and use= a signed Merkle tree hash of the ciphertext itself as your own custom MAC.=
>
> One benefit of using a hash-tree like algorithm with a signature is th= e reduction of storage overhead and memory usage, and that you retain the a= bility to independently verify each segment. Ideally you would use a hash-t= ree like algorithm which also can be generated efficiently in a single pass= over even large ciphertexts with reasonable memory usage (does anybody kno= w of one?).
>
> Not that I've also read the referenced Tahoe-LAFS link, it looks l= ike they're doing something very close to what I described above, but s= lightly different:
> They use AES-CTR over the whole file with a unique key, one plain hash= over the entire ciphertext, one Merkle tree hash over the ciphertext block= s and one Merkle tree hash over the erasure coded shares of the blocks, if = I'm reading it correctly, with all three hashes stored in plaintext wit= h the shares and then hashed together (also including the length of the fil= e). They also have some sort of hash chain, but the graphics don't load= and I can't figure out how exactly it is applied, beyond potentially h= aving to do with confirming the order of blocks. Instead of using HMAC they= use double SHA256 in a particular format.
>
> Minus the erasure coding** and with an added signature of the file has= hes/header, that's almost exactly what I imagined, I'm just worried= about the risk of the performance penalty limiting adoption. If the perfor= mance of this method is considered acceptable or can be improved to an acce= ptable level, I definitely support using it.
>
> * A bit off topic here, but for FDE I imagine changing the encryption = key every write-session using a KDF and session counter, keeping an authent= icated encrypted list of which segments uses which session write keys. This= way you prevent partial ciphertext reversal and prevent detection of when = ciphertext segments repeat over time (re-zeroized or restored files). You c= an also arbitrarily re-encrypt random segments to obscure your real write p= atterns (and reduce the list size occasionally by purging unused keys after= re-encrypting the last segments using them).
>
> ** In Tahoe-LAFS, erasure coding of blocks is used to allow you to spl= it files across storage nodes with minimal risk of data loss. That's no= t applicable here, as it can be applied independently when considered neces= sary.
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irt= f.org/mailman/listinfo/cfrg
>

--047d7b622670babff30523519828-- From nobody Fri Oct 30 07:11:37 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 F3FE61A1A3D for ; Fri, 30 Oct 2015 07:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable 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 xtcdQaEHAhry for ; Fri, 30 Oct 2015 07:11:32 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 57BCB1A1A1C for ; Fri, 30 Oct 2015 07:11:32 -0700 (PDT) Received: from fifthhorseman.net (y125068.ppp.asahi-net.or.jp [118.243.125.68]) by che.mayfirst.org (Postfix) with ESMTPSA id 9710BF984; Fri, 30 Oct 2015 10:11:24 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 377CA1FFD3; Fri, 30 Oct 2015 23:11:23 +0900 (JST) From: Daniel Kahn Gillmor To: Watson Ladd , Natanael In-Reply-To: References: <87twp91d8r.fsf@alice.fifthhorseman.net> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Fri, 30 Oct 2015 23:11:23 +0900 Message-ID: <878u6ktpis.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP , cfrg@irtf.org Subject: Re: [openpgp] [Cfrg] streamable AEAD construct for stored data? 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: Fri, 30 Oct 2015 14:11:35 -0000 On Fri 2015-10-30 21:30:44 +0900, Watson Ladd wrote: >> > b) it doesn't seem to compose as well with asymmetric signatures as one >> > might like: a signature over the whole material can't itself be >> > verified until one full pass through the data; and a signature over >> > just the symmetric key would prove nothing, since anyone getting the >> > symmetric key could forge an arbitrary valid, decryptable stream. >> > Is there an intermediate approach that would combine an asymmetric >> > signature with a chunkable authenticated encryption such that a >> > decryptor could stream one pass and be certain of its origin (at >> > least up until truncation, if (a) can't be resolved)? >> > >> > Thoughts, pointers, or suggestions would be much appreciated. > > Use authenticated encryption so no signatures are required. Detached > signature verification is used for large public messages already: no > streaming needed. OK, i am worried that i might have sidetracked the dicsussion with this side-note here. We don't have a solution for (b) above today, and as Watson notes, there are use patterns that suggest people might be OK with doing two-pass signature verification before processing large files. So i'd like to ask folks to put this side-note aside, please, and try to re-focus on the main original question: > AGL describes this problem here: > > https://www.imperialviolet.org/2014/06/27/streamingencryption.html > > and he roughly outlines a generic construction of a composable/chunkable > approach using AEAD: > >> Ideally such a scheme would take an AEAD and produce something very >> like an AEAD in that it takes a key, nonce and additional data, but >> can safely work in a streaming fashion. I don't think it need be very >> complex: take 64 bits of the nonce from the underlying AEAD as the >> chunk number, always start with chunk number zero and feed the >> additional data into chunk zero with a zero byte prefix. Prefix each >> chunk ciphertext with a 16 bit length and set the MSB to indicate the >> last chunk and authenticate that indication by setting the additional >> data to a single, 1 byte. The major worry might be that for many >> underlying AEADs, taking 64 bits of the nonce for the chunk counter >> leaves one with very little (or none!) left. > > Two examples of projects that take something like this approach are > miniLock and Tahoe-LAFS: > > https://github.com/kaepora/miniLock > https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/specifications/file-encoding.rst > > I'm unaware of any formalization of this approach, though. Does anyone > know of one? If OpenPGP were to adopt AGL's construct, are there > specific risks to be aware of? --dkg From nobody Fri Oct 30 07:46:51 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 57B6E1A6F6E for ; Fri, 30 Oct 2015 07:46:50 -0700 (PDT) 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=unavailable 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 73IFS79Ru5ZY for ; Fri, 30 Oct 2015 07:46:48 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 9313C1A6F63 for ; Fri, 30 Oct 2015 07:46:47 -0700 (PDT) Received: by wicll6 with SMTP id ll6so12220380wic.1 for ; Fri, 30 Oct 2015 07:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qsuhNHjCSvw7Qjsl2282demS53vTT3h/Get7FFvZEEc=; b=yfocB8SfZnd/Dvu6T/a6ffNmTC0mrigrCBS0yc7Vz6ivuNQ5EXHZ/fXlRkK0xPX2Yr +HsJcXeQ1hZY7RPqDMMqnLp3KR8Oulq3CapZk0JABiYli8ZCTOPjqUKr/p/gNkFY+0Qm EXQw9DF1CIhSkfVmAoPhWN1FPvDG7giF1X1Q5K0oA6qGkuaZoVevtep5SR+oxAKyF0z5 1+FoL7LiXATtvyiKW6u1vr8ANg/t8YXFhY0MtfECk6+Z3kFmrlf9GDuC2R7r+JhB0i+O Wb26ClTdR47A9o5Kcp5ELWyX7jMEYsL38bBR3B9AGhedgKDrqUH6Pid3hzhc3Ke708Jm 4l9Q== MIME-Version: 1.0 X-Received: by 10.194.58.142 with SMTP id r14mr10594976wjq.37.1446216406087; Fri, 30 Oct 2015 07:46:46 -0700 (PDT) Received: by 10.28.101.212 with HTTP; Fri, 30 Oct 2015 07:46:46 -0700 (PDT) In-Reply-To: <878u6ktpis.fsf@alice.fifthhorseman.net> References: <87twp91d8r.fsf@alice.fifthhorseman.net> <878u6ktpis.fsf@alice.fifthhorseman.net> Date: Fri, 30 Oct 2015 10:46:46 -0400 Message-ID: From: Watson Ladd To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP , "cfrg@irtf.org" , Natanael Subject: Re: [openpgp] [Cfrg] streamable AEAD construct for stored data? 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: Fri, 30 Oct 2015 14:46:50 -0000 On Fri, Oct 30, 2015 at 10:11 AM, Daniel Kahn Gillmor wrote: > On Fri 2015-10-30 21:30:44 +0900, Watson Ladd wrote: >>> > b) it doesn't seem to compose as well with asymmetric signatures as one >>> > might like: a signature over the whole material can't itself be >>> > verified until one full pass through the data; and a signature over >>> > just the symmetric key would prove nothing, since anyone getting the >>> > symmetric key could forge an arbitrary valid, decryptable stream. >>> > Is there an intermediate approach that would combine an asymmetric >>> > signature with a chunkable authenticated encryption such that a >>> > decryptor could stream one pass and be certain of its origin (at >>> > least up until truncation, if (a) can't be resolved)? >>> > >>> > Thoughts, pointers, or suggestions would be much appreciated. >> >> Use authenticated encryption so no signatures are required. Detached >> signature verification is used for large public messages already: no >> streaming needed. > > OK, i am worried that i might have sidetracked the dicsussion with this > side-note here. We don't have a solution for (b) above today, and as > Watson notes, there are use patterns that suggest people might be OK > with doing two-pass signature verification before processing large > files. > > So i'd like to ask folks to put this side-note aside, please, and try to > re-focus on the main original question: > >> AGL describes this problem here: >> >> https://www.imperialviolet.org/2014/06/27/streamingencryption.html >> >> and he roughly outlines a generic construction of a composable/chunkable >> approach using AEAD: >> >>> Ideally such a scheme would take an AEAD and produce something very >>> like an AEAD in that it takes a key, nonce and additional data, but >>> can safely work in a streaming fashion. I don't think it need be very >>> complex: take 64 bits of the nonce from the underlying AEAD as the >>> chunk number, always start with chunk number zero and feed the >>> additional data into chunk zero with a zero byte prefix. Prefix each >>> chunk ciphertext with a 16 bit length and set the MSB to indicate the >>> last chunk and authenticate that indication by setting the additional >>> data to a single, 1 byte. The major worry might be that for many >>> underlying AEADs, taking 64 bits of the nonce for the chunk counter >>> leaves one with very little (or none!) left. >> >> Two examples of projects that take something like this approach are >> miniLock and Tahoe-LAFS: >> >> https://github.com/kaepora/miniLock >> https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/specifications/file-encoding.rst >> >> I'm unaware of any formalization of this approach, though. Does anyone >> know of one? If OpenPGP were to adopt AGL's construct, are there >> specific risks to be aware of? In AES-GCM the nonce is 96 bits. (Yes, I know it admits any length nonces, but there is a weakness due to Iwata-Ohashi-Minematsu for any length not 96 bits). Reserving 64 bits for the chunk counter leaves 32 bits. Each chunk can be a maximum of 2^12 or so blocks, due to the absence of a beyond-birthday bound security result. (Maybe there is one, I don't know it, and I suspect there isn't for confidentiality). ChaCha20 supports more blocks in each chunk, due to PRF, not PRP. Therefore we can get by with fewer chunks and a larger nonce, thus enabling random selection of the nonces even after reserving chunk counters. Of course chunk sizes are limited by the desire to minimize working memory more than the associated counters, so this might not be possible. Of course there is a way to finesse the entire issue: use hashing to turn a longer nonce into a (key, nonce) pair ala XSalsa20. Sadly the utility of such designs wasn't appreciated by people involved in the choice of ChaCha20+Poly1305, instead of XSalsa20+Poly1305. > > --dkg -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Fri Oct 30 08:47:47 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 5BABE1B2D11 for ; Fri, 30 Oct 2015 08:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 ihe2Siiz6P7Y for ; Fri, 30 Oct 2015 08:47:45 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2.hushmail.com [65.39.178.134]) (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 546811B2D0F for ; Fri, 30 Oct 2015 08:47:45 -0700 (PDT) Received: from smtp2.hushmail.com (localhost [127.0.0.1]) by smtp2.hushmail.com (Postfix) with SMTP id B1AD8A046F for ; Fri, 30 Oct 2015 15:47:44 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.ai; h=date:to:subject:from; s=hush; bh=JMWT1EEM6oGE+SyUSPGohEhkuH5n5FgC+IVr+UPbNLI=; b=hPj6g5K4Gw9fKyGz/5xVHeFSnc8VkyNkCKs42KYHHToi2oyWmI7i7NszxN6IgRuT7rIPrY2pOskKLcvMHm54w3lZQ4Fw1ruvV4RHX6NlErBS9MTETQ8qvsQgypI/4BHWqvH6PlZjIbLX5Vm1z11/8FNGB0dJDQ4BaybGQaIfwjsFoBYTprEhDNNTEK4riyHv6iMtkvBI5rQBl1tZQxAGexRNO+vEVRly6EWp2LAJHEYoW+bbCSqp3Ow+5/DB/sEUxqp6oLM6Zn4j+AwG0pIi3d88CrKAypDvGQ4LudHH0HsEUu5LKuDYLbp6NPTbJEkluB9x6PR0S+FDLN83mYgEbQ== Received: from smtp.hushmail.com (w2.hushmail.com [65.39.178.46]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp2.hushmail.com (Postfix) with ESMTPS; Fri, 30 Oct 2015 15:47:44 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 7248CE0394; Fri, 30 Oct 2015 15:47:44 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 30 Oct 2015 11:47:44 -0400 To: "Daniel Kahn Gillmor" , openpgp@ietf.org From: vedaal@nym.hush.com In-Reply-To: <87twp91d8r.fsf@alice.fifthhorseman.net> Content-Type: multipart/alternative; boundary="=_a6e8dc87affd6e3fd49f4c3c46ee19eb" Message-Id: <20151030154744.7248CE0394@smtp.hushmail.com> Archived-At: Subject: Re: [openpgp] streamable AEAD construct for stored data? 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: Fri, 30 Oct 2015 15:47:46 -0000 --=_a6e8dc87affd6e3fd49f4c3c46ee19eb Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Is there an intermediate approach that would combine an asymmetric signature with a chunkable authenticated encryption such that a decryptor could stream one pass and be certain of its origin (at least up until truncation, if (a) can't be resolved)? ===== Maybe sign the encrypted data. i.e. an armored signed PGP message, where the plaintext is the already encrypted armored text. vedaal --=_a6e8dc87affd6e3fd49f4c3c46ee19eb Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"

Is there an intermediate = approach that would combine an asymmetric
signature with a chunkable= authenticated encryption such that a
decryptor could stream one pas= s and be certain of its origin (at
least up until truncation, if (a)= can't be resolved)?

=3D=3D=3D=3D=3D

Maybe sign the encrypted= data.
i.e. 
an armored signed PGP message, where the plaintext= is the already encrypted armored text.


vedaal
<= /span> --=_a6e8dc87affd6e3fd49f4c3c46ee19eb-- From nobody Sat Oct 31 01:50:55 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 1DE981B2CCA for ; Sat, 31 Oct 2015 01:50:54 -0700 (PDT) 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, 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 pODxfjWMbk_b for ; Sat, 31 Oct 2015 01:50:52 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 EE86B1B2CC8 for ; Sat, 31 Oct 2015 01:50:51 -0700 (PDT) Received: by lfbn126 with SMTP id n126so44254846lfb.2 for ; Sat, 31 Oct 2015 01:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=if9dYy9tcA/+X9o+pEkwdPrX0ASqMA+OjTD38g8khG8=; b=jO+wqpzrKKYg4bv3wRGP/yguo9RYQB/tjdxg0iv0054+PcRQL9YOc5dJM348j+UZjl ddTROpm8n3ihMovJOyHTr9E0pppoJV8BQ5+Wk+wX6mRB3oaBThWNXKlFSUZ6gV3+5/6c MBWFyeO4+nvioQQRbyL0/REfIP/hTJE1e+N4jFOFz7kTo4DLs2hzsFu4350lr9o4naJQ Y9ojUwSA8skOnNvAuWHT96Z/dgpfUHbbSlDaWrIKQ+PPqR7/TqF3BJrvCRnpTKfRNG3N LJMQCev9LwRLf/7KPy7Sf90xSlnOCBQFGY/Vwl+jqKTa4KGAfuqRkYdfLgqFr4rwNyso fbiQ== MIME-Version: 1.0 X-Received: by 10.25.23.69 with SMTP id n66mr3993721lfi.52.1446281450125; Sat, 31 Oct 2015 01:50:50 -0700 (PDT) Received: by 10.112.184.77 with HTTP; Sat, 31 Oct 2015 01:50:50 -0700 (PDT) Date: Sat, 31 Oct 2015 09:50:50 +0100 Message-ID: From: Bryan Ford To: openpgp@ietf.org Content-Type: multipart/alternative; boundary=001a1140560c14826e052362a435 Archived-At: Cc: Linus Gasser Subject: [openpgp] Modernizing the OpenPGP Format draft 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: Sat, 31 Oct 2015 08:50:54 -0000 --001a1140560c14826e052362a435 Content-Type: text/plain; charset=UTF-8 Hi folks, At the last IETF meeting I had promised to draft some preliminary text on improving/modernizing the OpenPGP encrypted message format, in particular to support AEAD ciphers and improve the integrity-check. I wrote up and submitted a (very preliminary) Internet-Draft on this topic shortly before the I-D cutoff deadline, but because of an insane sequence of other duties keeping me occupied for the past couple weeks, I managed to forget to announce it properly on the E-mail list. So here it is at any rate: Title: Modernizing the OpenPGP Message Format URL: https://datatracker.ietf.org/doc/draft-ford-openpgp-format/ Abstract: This draft proposes and solicits discussion on methods of modernizing OpenPGP's encrypted message format to support more state-of-the-art authenticated encryption schemes, and optionally to protect format metadata as well as data via metadata encryption and judicious padding. It covers two topics, the first being the AEAD evolution, the second being a somewhat more ambitious idea to provide better metadata protection and anonymization properties at the "outer-wrapper" level; see the draft for (some more, still sketchy) details. I noticed an earlier E-mail on this list polling for interest in an in-person openpgp meeting at IETF94, but didn't see any response, so I assumed there wouldn't be one - but now on catching up I notice that there's indeed an openpgp session scheduled after all, which is great. If a few minutes can be squeezed in for me to present/discuss this draft, that would be wonderful (and sorry for the late request due to my confusion about whether there would be an openpgp session at all). Thanks Bryan --001a1140560c14826e052362a435 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi folks,

At the last IETF meeting I ha= d promised to draft some preliminary text on improving/modernizing the Open= PGP encrypted message format, in particular to support AEAD ciphers and imp= rove the integrity-check.=C2=A0 I wrote up and submitted a (very preliminar= y) Internet-Draft on this topic shortly before the I-D cutoff deadline, but= because of an insane sequence of other duties keeping me occupied for the = past couple weeks, I managed to forget to announce it properly on the E-mai= l list.=C2=A0 So here it is at any rate:

Title: Modernizing the Op= enPGP Message Format
URL: https://datatracker.ietf.org/doc/draft-ford-openp= gp-format/
Abstract:
=C2=A0 =C2=A0This draft proposes and solicit= s discussion on methods of modernizing
=C2=A0 =C2=A0OpenPGP's encryp= ted message format to support more state-of-the-art
=C2=A0 =C2=A0authent= icated encryption schemes, and optionally to protect format
=C2=A0 =C2= =A0metadata as well as data via metadata encryption and judicious
=C2=A0= =C2=A0padding.

It covers two topics, the first being th= e AEAD evolution, the second being a somewhat more ambitious idea to provid= e better metadata protection and anonymization properties at the "oute= r-wrapper" level; see the draft for (some more, still sketchy) details= .

I noticed an earlier E-mail on this list polling= for interest in an in-person openpgp meeting at IETF94, but didn't see= any response, so I assumed there wouldn't be one - but now on catching= up I notice that there's indeed an openpgp session scheduled after all= , which is great.=C2=A0 If a few minutes can be squeezed in for me to prese= nt/discuss this draft, that would be wonderful (and sorry for the late requ= est due to my confusion about whether there would be an openpgp session at = all).

Thanks
Bryan

<= /div> --001a1140560c14826e052362a435-- From nobody Sat Oct 31 17:48:09 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 BED2F1B4A1E for ; Sat, 31 Oct 2015 17:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 E-D-Rc0o7wME for ; Sat, 31 Oct 2015 17:48:05 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (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 296631B4A1B for ; Sat, 31 Oct 2015 17:48:05 -0700 (PDT) Received: by igbdj2 with SMTP id dj2so33544490igb.1 for ; Sat, 31 Oct 2015 17:48:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastauthority_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=d2OyG09I3CvzDZlK36LqKUSKbr6VVMjpuxy55DN0TSE=; b=qkZfExblD8DJPVIS6hwc5HII9X7haQMTb5nqUj8udGgg4DLVGtSQGCkL9RgazOyrte SETAd8IiGA8jKNAFAJ+dWXsA8rH9a+OMrKLzq/vpKaXKMY20FUG2bMVI+dpo3d/o/ZCA v749uNdto3Sf51bM9ZSzyQIIyd2xbk34r21aSHhQc5DiYmG0G7cdNg6f4oCC7WlnU8dh cuFql2oZgOpczvnUowKD02eMo93fdsMkC3XP1OwSaQA8VoGgYbXcfpzKBCqEBPJONfk0 u/SZNMR6EI5WcwzOxl4+iFnPGRae63vIkT+Ow0+oLLGIZgifmh14GQ4rcsTZKOSpXdkT vSlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=d2OyG09I3CvzDZlK36LqKUSKbr6VVMjpuxy55DN0TSE=; b=YFhmTVdswsnWXFzDpLOF5oCwm1szVg6HQ1JmQNN/+VHFSJR2TyXOs+LFn2RO1k7qLJ ZU7O8QjXRk7yIhTJqJA8Kky8X6W09CYFCV8w0w5yYcv6/n415WW+1S3WgVwedWtHjc51 16IR5fcm/nobbcV3SRii+tr0DNQ5RL9bpy5yUwZa/E00OT2s2jJW7/TR5ubjUdWYiC3K PCjRNbcHP/MWXgGIXu7jGMxIvquunlD88z2TlEczf9sCNycZVxavWPOQHCouUTGalgvD JpLou146mUnzuQtymMpUGQlpHBfyM2QG0BY3v2Y0Zw8NlrZHie+Md0Fp90IkRMU785U6 Gw0w== X-Gm-Message-State: ALoCoQnSTWnrYB/pzKRRYmR22zNqNwP3fUL1+MQnThNaO5XgcaEypltw757sQ0LlqwMS3IsVRaTj MIME-Version: 1.0 X-Received: by 10.50.29.101 with SMTP id j5mr4954180igh.70.1446338884242; Sat, 31 Oct 2015 17:48:04 -0700 (PDT) Received: by 10.107.129.161 with HTTP; Sat, 31 Oct 2015 17:48:04 -0700 (PDT) In-Reply-To: <87twp91d8r.fsf@alice.fifthhorseman.net> References: <87twp91d8r.fsf@alice.fifthhorseman.net> Date: Sun, 1 Nov 2015 00:48:04 +0000 Message-ID: From: Zooko Wilcox-OHearn To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: openpgp@ietf.org, "cfrg@irtf.org" Subject: Re: [openpgp] [Cfrg] streamable AEAD construct for stored data? 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: Sun, 01 Nov 2015 00:48:06 -0000 Hi folks: I'm one of the designers of Tahoe-LAFS. First of all, I'd like to agree that this is an important issue =E2=80=94 w= e do need a data integrity protocol with which a reader can verify a subset of the data. This is especially useful for heads =E2=80=94 leading bytes =E2=80=94 of the data, so that when someone executes a command like this: curl http://foo.info/x.tar.pgp | gpg --decrypt | tar x the "gpg" process can operate with limited RAM/storage and can also be sure that any data it passes to the tar process is authentic, before it passes that data to the tar process. In addition, some techniques can also allow authenticated reads of arbitrary spans of the data. The Merkle Tree approach, such as is used in Tahoe-LAFS, allows this. Therefore if you're reading a file from Tahoe-LAFS then if you do something like "fseek(filehandle, 1000000000, 0); fread(buf, 1, 1000000, filehandle);" then you'll get the one million bytes of data which begins one billion bytes into the file, but you'll get the assurance from Tahoe-LAFS that those one million bytes are cryptographically authenticated. Second, I'd like to emphasize something that dkg pointed out in the first post =E2=80=94 that even if we do this correctly at this layer, then there is still a risk of truncation attacks. For example, imagine that someone runs: curl http://foo.info/x.sh.pgp | gpg --decrypt | sh Even if gpg can ensure cryptographic integrity of every byte before it passes that byte to sh, this is vulnerable to potentially damaging attacks by interrupting the flow of ciphertext to gpg. This is a problem that can't be solved by the gpg process in this example. It has to be solved by the next process in the chain =E2=80=94 tar in the firs= t example or sh in the second. But let's remember that it is a real problem. > b) it doesn't seem to compose as well with asymmetric signatures as one > might like: a signature over the whole material can't itself be > verified until one full pass through the data; and a signature over > just the symmetric key would prove nothing, since anyone getting the > symmetric key could forge an arbitrary valid, decryptable stream. > Is there an intermediate approach that would combine an asymmetric > signature with a chunkable authenticated encryption such that a > decryptor could stream one pass and be certain of its origin (at > least up until truncation, if (a) can't be resolved)? This is a big deal, and an under-appreciated one. A lot of modern cryptography was developed in the model of a bilateral and synchronous connection between two parties. In that model, this isn't a problem. You have a shared secret, and anything that you receive that *you* didn't send you can assume that the other party sent. (So you have to prevent replay and reflection attacks, but if you've done so, then this isn't a problem.) But in a more asynchronous/persistent model, and in a model with more than two parties, then you can't rely on that and you need something else. The way we do this in Tahoe-LAFS (like Taylor Campbell explained in this thread), is that the writer generates a Merkle Tree over the data and transmits, along with each block, the Merkle Branch needed to authenticate that block. Now the reason we do it that way in Tahoe-LAFS is that we want to bind all the bytes of (one version of) the file together. If a reader reads the first million bytes of a file, and then reads the second million bytes of the file, you don't want an attacker to have the option of supplying the first million from one version of the file and the next million from a different version of the file, without the reader realizing this, even if both versions of the file were, at some point, signed by the legitimate writer. So using the Merkle Tree provides a convenient way to: * bundle all the bytes of the file into a single crypto value (the Merkle Tree root) which we can then use as a "stand-in" for the complete contents of a single version of the file, for authentication purposes * suffer low worst-case overhead for a read of an arbitrary span of data (i.e., if you're reading a random span out of the middle of a file, not just reading from the beginning) But, we made that decision back before we were willing to rely on ECC, so our public key digital signatures were big old 2048-bit RSA sigs. Now that we would be willing to rely on svelte Ed25519 sigs, we might consider including a pkdigsig with each block instead of a Merkle Branch with each block. It would require careful engineering about the identification and versioning of the file, either way. Regards, Zooko