From nobody Sun Nov 1 07:52: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 2F9071A89A8 for ; Fri, 30 Oct 2015 05:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 eEgJl2alelxD for ; Fri, 30 Oct 2015 05:25:05 -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 5377D1A898B for ; Fri, 30 Oct 2015 05:25:05 -0700 (PDT) Received: by wijp11 with SMTP id p11so9901749wij.0 for ; Fri, 30 Oct 2015 05:25:04 -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=RveZKYEv5CKPecK/6xC9HzTAJYDUp/2vHFt0vTvpURA=; b=Bysr6hPEoIwFDQEQQJzjn2fTxCINyTEJiqdhmICmJ+tDBx7dLPracE1/XctdR/uYMe iutafD9cXctgHQ0KPi/n7m7CiQeNpxXGpeOOlSkUKxic8sUHkhlpXGP+MgFVUk3EGDPw esjJRFDMlG8d7r+nIZP0abcPCfOkgfoV7Rq5MgY87mRwt8TrwYZOXZZZtYYqKcvV352i qGlJwDtJvhQVxWJw36rlRmxUktU5D/nZgfgS6dbciLqrxFnxTCxTgSZGqmhM74IBafmT 0AzXK6RpCbpvbgIfXImfRNK0+FxpaUApj1bGQNAEcjxoSi9ltgCKhr9uyAvRQYvzSlxv 32fA== MIME-Version: 1.0 X-Received: by 10.194.89.166 with SMTP id bp6mr9008067wjb.96.1446207903905; Fri, 30 Oct 2015 05:25:03 -0700 (PDT) Received: by 10.194.175.33 with HTTP; Fri, 30 Oct 2015 05:25:03 -0700 (PDT) Received: by 10.194.175.33 with HTTP; Fri, 30 Oct 2015 05:25:03 -0700 (PDT) In-Reply-To: <87twp91d8r.fsf@alice.fifthhorseman.net> References: <87twp91d8r.fsf@alice.fifthhorseman.net> Date: Fri, 30 Oct 2015 13:25:03 +0100 Message-ID: From: Natanael To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=089e011604526245e2052351848d Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 07:51:58 -0800 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: Fri, 30 Oct 2015 12:25:08 -0000 --089e011604526245e2052351848d Content-Type: text/plain; charset=UTF-8 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. To solve B what you need to do is something like signing a list of ciphertext hashes/authentication tags. 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. --089e011604526245e2052351848d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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 message= s but
> also for large file encryption.=C2=A0 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<= br> > meaningful way than the current OpenPGP MDC (modification detection > code), which is basically a SHA-1 hash of the cleartext.=C2=A0 This wa= s never
> much better than a band-aid.=C2=A0 And as discussed in the recent &quo= t;OpenPGP
> SEIP downgrade attack" thread, an "integrity-protected"= packet with an
> MDC can be stripped down to produce a syntactically-valid packet witho= ut
> 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-streamed= data has
> =C2=A0 =C2=A0 already been streamed by the time a truncation is discov= ered.
> =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 decr= yption if
> =C2=A0 =C2=A0 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 tha= t and halt of necessary.

> =C2=A0b) it doesn't seem to compose as well with as= ymmetric signatures 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 sig= nature over
> =C2=A0 =C2=A0 just the symmetric key would prove nothing, since anyone= getting the
> =C2=A0 =C2=A0 symmetric key could forge an arbitrary valid, decryptabl= e stream.
> =C2=A0 =C2=A0 Is there an intermediate approach that would combine 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 its or= igin (at
> =C2=A0 =C2=A0 least up until truncation, if (a) can't be resolved)= ?
>
> Thoughts, pointers, or suggestions would be much appreciated.

To solve B what you need to do is something like signing a l= ist of ciphertext hashes/authentication tags.

One thought I've had before (my idea is to use it for FD= E*) is to for example use HMAC over segments (including counters) or to ext= ract AEAD tags (prefixed with counters to preserve order) and create a Merk= le tree hash of those lists when creating the message, to then sign that Me= rkle 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 construc= ts and use a signed Merkle tree hash of the ciphertext itself as your own c= ustom MAC.

One benefit of using a hash-tree like algorithm with a signa= ture is the reduction of storage overhead and memory usage, and that you re= tain the ability to independently verify each segment. Ideally you would us= e a hash-tree like algorithm which also can be generated efficiently in a s= ingle pass over even large ciphertexts with reasonable memory usage (does a= nybody 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 ab= ove, 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). T= hey 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 th= e file hashes/header, that's almost exactly what I imagined, I'm ju= st 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 e= ncryption 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 detectio= n of when ciphertext segments repeat over time (re-zeroized or restored fil= es). You can also arbitrarily re-encrypt random segments to obscure your re= al 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. Tha= t's not applicable here, as it can be applied independently when consid= ered necessary.

--089e011604526245e2052351848d-- From nobody Sun Nov 1 07:52: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 85E381B2C40 for ; Fri, 30 Oct 2015 06:18:16 -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 Q8ZVqCz7wgJO for ; Fri, 30 Oct 2015 06:18:15 -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 8690C1B2C39 for ; Fri, 30 Oct 2015 06:18:14 -0700 (PDT) Received: by wicfv8 with SMTP id fv8so10607731wic.0 for ; Fri, 30 Oct 2015 06:18:13 -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=8bxE7WQenuJqupi5pxYa3SXHYq+Hiu3Yr52Bbn/C2VY=; b=o28Md3cNX36AUzPDBejHXY0hKdXb4JLZ6Wo90Tcuceku8PLyDjKVIt62DmnJljGqEb LmmO9yup4t8dapFVLvrhl32lQtQTC9X+KzLX/NmJtSMeZnmy3AVJV2qiBZ71DNg3lbge tcHCcs8RO0+cV3Fe5vqiTKIaii5jjtUXZd60DBO0XiBLxZL/VwvSHQe9gS0XsUC31YSW HSrEpbkzeUpy18tRE3yy86/ZL8+Q7VBlSPqezF9Pg0XEUHPZUZoXziYwbV1w57UwZl5z yCV/01ESMC5iT9qHafUvqC8s9Y4zt2xuCJaGlmP5NZpcbi/Mac8Axoe/qyTNo61d4tPL 6XUQ== MIME-Version: 1.0 X-Received: by 10.194.187.41 with SMTP id fp9mr9651844wjc.14.1446211093158; Fri, 30 Oct 2015 06:18:13 -0700 (PDT) Received: by 10.194.175.33 with HTTP; Fri, 30 Oct 2015 06:18:12 -0700 (PDT) Received: by 10.194.175.33 with HTTP; Fri, 30 Oct 2015 06:18:12 -0700 (PDT) In-Reply-To: References: <87twp91d8r.fsf@alice.fifthhorseman.net> Date: Fri, 30 Oct 2015 14:18:12 +0100 Message-ID: From: Natanael To: Watson Ladd Content-Type: multipart/alternative; boundary=047d7bb03a6e7a611305235242c4 Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 07:51:58 -0800 Cc: openpgp@ietf.org, 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 13:18:16 -0000 --047d7bb03a6e7a611305235242c4 Content-Type: text/plain; charset=UTF-8 Den 30 okt 2015 13:30 skrev "Watson Ladd" : > On Oct 30, 2015 8:25 AM, "Natanael" wrote: >> [...] > Use authenticated encryption so no signatures are required. Detached signature verification is used for large public messages already: no streaming needed. I'm not sure if we read the requirements differently. He asked for immutable signed files, as in that an AEAD authentication key is insufficient because the other recipients all have the same key and can substitute the ciphertext. There's an explicit requirement that the capabilities of the sender and (potentially multiple) receivers are different. Yes, the signature would fail if combining standard AEAD with a full ciphertext signature and one receiver modified the ciphertext, but see the reasoning for why it is necessary again - by the time the failure is detected, the software that's performing the streaming decryption and processing may already have taken some undesired action, or might fail to cancel a future undesired action (by not deleting the resulting plaintext). Preemptively preventing mistakes done by the client software. It isn't just AEAD, it is seekable streaming AEAD with per-block verification of immutability. Allowing you to look up any block individually and confirm *that block* hasn't been modified by anybody but the original sender. Imagine for example an encrypted video or a large archive of files being sent to multiple receivers. With AES-GCM and a signature at the end, you either decrypt and verify everything before viewing or you decrypt just one part and accept that another one of the receivers may have tampered with your copy of the video/files (if it for example is stored on a NAS). Or worse, the software parsing the plaintext might have an exploitable bug, which may then already have been exploited when the signature verification fails, so that even if the decryption software rolls back everything it did then you now have malware on your system anyway. The other option is of course the sender creating multiple ciphertexts with separate keys for every recipient. Very much not ideal for large files. > > 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. Feel free to explain what conditions those are. I'll happily admit I'm just a cryptography novice, I'm willing to learn why this might be flawed or insufficient. --047d7bb03a6e7a611305235242c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Den 30 okt 2015 13:30 skrev "Watson Ladd" <watsonbladd@gmail.com>:
>=C2=A0 On Oct 30, 2015 8:25 AM, "Natanael" <natanael.l@gmail.com> wrote:
>> [...]
> Use authenticated encryption so no signatures are required. Detached s= ignature verification is used for large public messages already: no streami= ng needed.

I'm not sure if we read the requirements differently. He= asked for immutable signed files, as in that an AEAD authentication key is= insufficient because the other recipients all have the same key and can su= bstitute the ciphertext. There's an explicit requirement that the capab= ilities of the sender and (potentially multiple) receivers are different. <= /p>

Yes, the signature would fail if combining standard AEAD wit= h a full ciphertext signature and one receiver modified the ciphertext, but= see the reasoning for why it is necessary again - by the time the failure = is detected, the software that's performing the streaming decryption an= d processing may already have taken some undesired action, or might fail to= cancel a future undesired action (by not deleting the resulting plaintext)= . Preemptively preventing mistakes done by the client software.

It isn't just AEAD, it is seekable streaming AEAD with p= er-block verification of immutability. Allowing you to look up any block in= dividually and confirm *that block* hasn't been modified by anybody but= the original sender.

Imagine for example an encrypted video or a large archive of= files being sent to multiple receivers. With AES-GCM and a signature at th= e end, you either decrypt and verify everything before viewing or you decry= pt just one part and accept that another one of the receivers may have tamp= ered with your copy of the video/files (if it for example is stored on a NA= S).

Or worse, the software parsing the plaintext might have an e= xploitable bug, which may then already have been exploited when the signatu= re verification fails, so that even if the decryption software rolls back e= verything it did then you now have malware on your system anyway.

The other option is of course the sender creating multiple c= iphertexts with separate keys for every recipient. Very much not ideal for = large files.

> > To solve B what you need to do is something like s= igning a list of ciphertext hashes/authentication tags.
>
> The idea below demands conditions beyond MAC security.

Feel free to explain what conditions those are. I'll hap= pily admit I'm just a cryptography novice, I'm willing to learn why= this might be flawed or insufficient.

--047d7bb03a6e7a611305235242c4-- From nobody Sun Nov 1 07:52:04 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 B01FB1B302C for ; Fri, 30 Oct 2015 11:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 QsJdtiDIuI9I for ; Fri, 30 Oct 2015 11:32:31 -0700 (PDT) Received: from jupiter.mumble.net (jupiter.mumble.net [74.50.56.165]) by ietfa.amsl.com (Postfix) with ESMTP id 523111B3023 for ; Fri, 30 Oct 2015 11:32:31 -0700 (PDT) Received: by jupiter.mumble.net (Postfix, from userid 1014) id 35630603F0; Fri, 30 Oct 2015 18:32:23 +0000 (UTC) From: Taylor R Campbell To: Daniel Kahn Gillmor In-reply-to: <87twp91d8r.fsf@alice.fifthhorseman.net> (dkg@fifthhorseman.net) Date: Fri, 30 Oct 2015 18:32:30 +0000 Sender: Taylor R Campbell User-Agent: IMAIL/1.21; Edwin/3.116; MIT-Scheme/9.1.99 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20151030183223.35630603F0@jupiter.mumble.net> Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 07:51:55 -0800 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: Fri, 30 Oct 2015 18:32:37 -0000 Date: Fri, 30 Oct 2015 08:11:48 +0900 From: Daniel Kahn Gillmor 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)? If only the receiving end needs streaming -- that is, if the sender can process an entire message before the receiver receives any of it -- then you can relatively easily address this, as Tahoe-LAFS does, given a session key k: (sender) 1. Break the data up into bounded-size chunks. 2. (Symmetrically encrypt the chunks with k if you want.) 3. Compute a Merkle tree under a PRF keyed by k of the chunks. 4. Sign the root of the Merkle tree. 5. Store the signed root, and each chunk alongside its path down the Merkle tree. This requires only O(log n) working memory to compute the Merkle tree -- it takes a single pass over the whole input. (receiver) 1. Verify the root of the Merkle tree. 2. When receiving a chunk and a path, verify the path from the root. 3. (Decrypt the chunk with k if you want.) For public signatures, you can fix k = 0 and hope nobody finds collisions in PRF_0, or randomize k and hope nobody finds target-collision attacks on PRF (which is unlikely -- even MD5(k, m) is probably still OK for that, as far as I know). For authenticated encrypted messages, you can derive it from a DH shared secret, or do standard public-key-encrypted key wrap, &c. From nobody Sun Nov 1 07:52: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 C9EDD1B30D2 for ; Fri, 30 Oct 2015 11:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 Cl9TIlAXMGIG for ; Fri, 30 Oct 2015 11:48:06 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003: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 7EBAB1B30D1 for ; Fri, 30 Oct 2015 11:48:02 -0700 (PDT) Received: by oiad129 with SMTP id d129so64593055oia.0 for ; Fri, 30 Oct 2015 11:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital_net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Zkqh4v+uLnsUeESbRQFeyvoFdD8c++44GkfyRRKsoaI=; b=tCl/8XT5VE9A9gKteLMw78VHY3NshbhuglO/8tOC1m2vwS6cJcoxUbttI/fK3T638v 2yYKbr5MtJOGq9tXZ0KSLMVvQsFrFRfDYES94EEQSgGM0BQziW7ojRvhnPzaBpR4xPl9 qKzLSO3F6su5YXtl/LEAWh7z8USw0xf27Ys9WWYjxEbHhyxHP5/lUaRni09z+U55SQBY 0gIVP37WxFZX17sVQ1GQ0RZbiD4owtrHjMVwP2lUrGfTbPAI4h9XUXD+Wx5g+CPmulDJ +s50++n/RwujlVq7KsnezkcFivehV2fmTpZ0EpQTTvK1vIacN/wDe+MpkYTIUocvcPRc 0XmQ== 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:cc:content-type; bh=Zkqh4v+uLnsUeESbRQFeyvoFdD8c++44GkfyRRKsoaI=; b=IKCELtSz6PZpO+/oIdQoxAdxeEU8iy9r2e6kebVyR4bkXt1vVtlZJojvagb1Ff7TpC KECaH7PA/S/1am/MuuzZYavryOxEV6RLbUMYqFfxlfcVBtRM6YsyOsGdTU7X3kVGM5zz OSUEUoPGEJWvGRKRbjMNK8Edde3qhdi3r+tPARMdJk0jsToitWZtY6xv9flvm1Q3GKjn VmjLp0xf7bYbXjwLGQgZBroJg2y3HArVptmVCXFzRNjPbz7kOVWDF5rJnpwO0C4gq0rl 2kdAO5J0PA+uNMF2I0Gtd4HyUShTH+WGEG8Q0jNqhxTPoMWOUJJMv+1iJVwngHnjDo1v vAdA== X-Gm-Message-State: ALoCoQkrnswS9v0R5xqvbqpSyxPfDv1GeBV/3YWK1GMk7a5w5i5yAof+bMaf7zYVnucKqKqoDUkS X-Received: by 10.202.53.136 with SMTP id c130mr6651942oia.116.1446230881711; Fri, 30 Oct 2015 11:48:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.205.216 with HTTP; Fri, 30 Oct 2015 11:47:42 -0700 (PDT) In-Reply-To: <20151030183223.35630603F0@jupiter.mumble.net> References: <87twp91d8r.fsf@alice.fifthhorseman.net> <20151030183223.35630603F0@jupiter.mumble.net> From: Andy Lutomirski Date: Fri, 30 Oct 2015 11:47:42 -0700 Message-ID: To: Taylor R Campbell Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 07:51:57 -0800 Cc: openpgp@ietf.org, "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 18:48:08 -0000 On Fri, Oct 30, 2015 at 11:32 AM, Taylor R Campbell wrote: > This requires only O(log n) working memory to compute the Merkle tree > -- it takes a single pass over the whole input. > ...which reminds me: As far as I know, everyone thinks they know how to do a Merkle tree for things like this, but there doesn't seem to be a credible standard, and there are at least two modern examples of doing it wrong: Amazon's Glacier hash and (unless it changed) Bittorrent's new Merkle tree. Should CFRG consider standardizing a transport format for hash tree verifiers (or proofs or whatever they're called) and for a large blob that can be used to efficiently generate the proofs (essentially some kind of serialized tree)? The Sakura construction could be a good starting point. If I were designing such a standard, I would be extremely hesitant to start with SHA256 or similar because of the lack of personalization, whereas Sakura (and maybe BLAKE2) doesn't have this problem. Sadly, Sakura doesn't seem to be officially blessed yet. --Andy From nobody Sun Nov 1 07:52: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 901501B3C0F for ; Fri, 30 Oct 2015 14:28:12 -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 RllALZFXOob7 for ; Fri, 30 Oct 2015 14:28:11 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (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 4C0CA1B3C11 for ; Fri, 30 Oct 2015 14:28:11 -0700 (PDT) Received: by qgbb65 with SMTP id b65so72351339qgb.2 for ; Fri, 30 Oct 2015 14:28:10 -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=ps+fl4S1jeembv2aEmBSPyrIZopmr8DRsssThVkO8hY=; b=mbuTEe4oFOZ4mvRqbUnraXFYDKOnoO7O43jMGzCU2sdKtr3oAI3tT6QS7UmGJWf1iR 3DVZVfUaIfb5xxTvbVPqQWPTteNjAY1Tf5OGK0DofGT/mrGUIgOVS1/aEotWnTzqAGGm tHrZ9IGIGHnrG5LC+iDsqLOSqYavhurmJ74qgDXEO3dBsGaw5lItOKbIHNnHV+Gq9ZOW Ks/tWgRVW26KxGoecOYWIL6IuZwBk+kVL5RTxF/LiuZtWNrCW9CDx196E1uSseyF0Gyt peL+ZrssUYNWGQOavyX914EjnLyHGUl+vVTmZu4L10gdQehuH+r5n/lUpMGYH9cvD0T4 eUKg== MIME-Version: 1.0 X-Received: by 10.141.28.76 with SMTP id f73mr13816200qhe.17.1446240490517; Fri, 30 Oct 2015 14:28:10 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.140.81.241 with HTTP; Fri, 30 Oct 2015 14:28:10 -0700 (PDT) In-Reply-To: References: <87twp91d8r.fsf@alice.fifthhorseman.net> <20151030183223.35630603F0@jupiter.mumble.net> Date: Fri, 30 Oct 2015 14:28:10 -0700 X-Google-Sender-Auth: G6DSooAVMdMUW3awnx9XhGJ5Ntk Message-ID: From: Adam Langley To: Andy Lutomirski Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 07:51:58 -0800 Cc: openpgp@ietf.org, "cfrg@irtf.org" , Taylor R Campbell 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 21:28:12 -0000 On Fri, Oct 30, 2015 at 11:47 AM, Andy Lutomirski wrote: > As far as I know, everyone thinks they know how to do a Merkle tree > for things like this, but there doesn't seem to be a credible > standard, and there are at least two modern examples of doing it > wrong: Amazon's Glacier hash and (unless it changed) Bittorrent's new > Merkle tree. Do you have references for either of these two issues? I wasn't aware of them. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Sun Nov 1 07:52: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 667CD1ACF18 for ; Fri, 30 Oct 2015 15:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.121 X-Spam-Level: X-Spam-Status: No, score=0.121 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-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 Rhz0hHhqUiFs for ; Fri, 30 Oct 2015 15:09:40 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 4E25D1ACF0A for ; Fri, 30 Oct 2015 15:09:40 -0700 (PDT) Received: by oiad129 with SMTP id d129so67346992oia.0 for ; Fri, 30 Oct 2015 15:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital_net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IvAb7Irk6rQZK/5bD0oTQC5nKWvaoE0uDzRRR92Shfs=; b=KtXGase/LCN/wMvs5VoqMVNP2ItSOlGoHtZc0BkPbg1a7MxiLutYLt2Ro2PAdjB1AD gbYaxF8mfmJOqtuxtXlTe1XRZHd7hlVwPxzcFYcDbi3tfT/mXHeN7yhb9wmzHS/fYIzp 3I9FvIVM4Deua0iJgCZFpD68I+WKXwqCIzr8KkQkm6A1ESWfAucz6sbYX1XxYHz5zua8 uCZE2qdvlDwabiSBVCDRT4zO9VR8b/g6Wn3TI7P62LnCYyuhaeZ2X25bgU0NbSl6ytnY FjmVOEt9m1Gmcz+iVozrlvn+XqnL7baAXs1Jpb3BkmNTWe6NRdrPOGvgalBGX/FPl1MN Xs1w== 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:cc:content-type; bh=IvAb7Irk6rQZK/5bD0oTQC5nKWvaoE0uDzRRR92Shfs=; b=Y5XArhzq9a+Kr5YWHWy1XSblaNhZquyg1xpdtFZCfVZBdbUpWMQehXKh/oQtaFSYr/ wl6XDEgzBBRYPa5VI7NID5xi3yARexeFzC0nA6eIcE24RokUe/6jeFFr8X3jUCuXZCI/ xpC0WOR8uOlQbQlOAILKCPMnB9ObV+EuueG7xp+5/zzgowgGLAoHptQmpl4p9hZZjOFS Hah4ImtsFZhZMhOrUNrrwZd6nu7qXkTSSME+5BbV3dkQXZ8agdzS3YN9LNGfxDSL67n+ iuZQnegK3D9EFuAVejq1Skv6OIgvn1dOrIy/WOfQJ1iSgh2aezFnEzCZz6E8JnJgKCNi sRwQ== X-Gm-Message-State: ALoCoQlSS+2IrbxyBwgdTst7B5mF0yFvOAUBpbfXoXnOODazk9TzVfA4F7CE99N/OMVnfePhtSXI X-Received: by 10.202.184.130 with SMTP id i124mr6611321oif.122.1446242979565; Fri, 30 Oct 2015 15:09:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.205.216 with HTTP; Fri, 30 Oct 2015 15:09:19 -0700 (PDT) In-Reply-To: References: <87twp91d8r.fsf@alice.fifthhorseman.net> <20151030183223.35630603F0@jupiter.mumble.net> From: Andy Lutomirski Date: Fri, 30 Oct 2015 15:09:19 -0700 Message-ID: To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 07:51:57 -0800 Cc: openpgp@ietf.org, "cfrg@irtf.org" , Taylor R Campbell 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 22:09:41 -0000 On Fri, Oct 30, 2015 at 2:28 PM, Adam Langley wrote: > On Fri, Oct 30, 2015 at 11:47 AM, Andy Lutomirski wrote: >> As far as I know, everyone thinks they know how to do a Merkle tree >> for things like this, but there doesn't seem to be a credible >> standard, and there are at least two modern examples of doing it >> wrong: Amazon's Glacier hash and (unless it changed) Bittorrent's new >> Merkle tree. > > Do you have references for either of these two issues? I wasn't aware of them. > No, but here goes: Amazon does this: http://docs.aws.amazon.com/amazonglacier/latest/dev/checksum-calculations.html Take 1MB chunks (and a possible short trailing chunk). Hash them with SHA256. Then, as long as you have more than one hash in your array, hash pairs of hashes together and just keep the extra odd one at the end, if any. This reduces the number of hashes from n to ceil(n/2). When you have exactly one hash left, you're done. This is vulnerable to a trivial second-preimage attack. Fortunately, it seems to be okay if you also store the length of the data along with the hash value. I don't know what Bittorrent is actually doing, but I found this thing: http://www.bittorrent.org/beps/bep_0030.html It seems similarly broken. --Andy From nobody Sun Nov 1 07:52: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 B56621A2182 for ; Sat, 31 Oct 2015 02:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 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, MIME_8BIT_HEADER=0.3, 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 c5pxCUTut_ya for ; Sat, 31 Oct 2015 02:20:53 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (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 9312C1A212A for ; Sat, 31 Oct 2015 02:20:53 -0700 (PDT) Received: by pacfv9 with SMTP id fv9so101057000pac.3 for ; Sat, 31 Oct 2015 02:20:53 -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=DEr72vcBgTxDVytE/ejqomrO8ot9jHxhyD9MunCoM9Y=; b=tBrBtGLpowU+y0nsZZlByuLpXZv5MQAiF2C3CcbpgsOrukGUmKW8AmhWiqA/TDOGsL oFkMiYLWcO1AnSbfvoDRP585zHet9MRf/4CEKu+cuoimf1vT+SiJlRomTjCCTMKMjD4d 4hpdrXV7LnfaavdTdchJaPPfcwZ1HtoAaMbAjhSji9uaacoyIhbG9R0a4SGVk8QrH76a xtQPzW4pIH95OLyXghfCUUQZtPJD2bkm8VoS9ITxtxzi2v70Iv7ELydllJp715MB2D0s U2KJXN0IuBtrUB7nwjyNALP3RfxmFeXVrQxFHoaPq8/usm36QfyWhPjR0tUJcGGPxOD+ fbeA== MIME-Version: 1.0 X-Received: by 10.66.124.135 with SMTP id mi7mr14249569pab.86.1446283253279; Sat, 31 Oct 2015 02:20:53 -0700 (PDT) Sender: bjorn.edstrom@gmail.com Received: by 10.66.156.132 with HTTP; Sat, 31 Oct 2015 02:20:53 -0700 (PDT) In-Reply-To: <87twp91d8r.fsf@alice.fifthhorseman.net> References: <87twp91d8r.fsf@alice.fifthhorseman.net> Date: Sat, 31 Oct 2015 10:20:53 +0100 X-Google-Sender-Auth: JOiG9IHvAaC4-B5oy9zVHVOI_1w Message-ID: From: =?UTF-8?B?QmrDtnJuIEVkc3Ryw7Zt?= To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 07:51:56 -0800 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: Sat, 31 Oct 2015 09:20:54 -0000 On Fri, Oct 30, 2015 at 12:11 AM, Daniel Kahn Gillmor wrote: > But one of our constraints is the OpenPGP use case that streams > decrypted data, like this: > > pgp --decrypt > It's unlikely that this use case will go away. Is that constraint really set in stone? PGP is a complicated system to use and understand for most people and the more an implementation can do to prevent potential dangers the better. I think it could be worthwhile of the spec to have security guidelines for implementers to make dangerous invocations more difficult. To use your example, consider the following further examples: pgp --decrypt --file backup.pgp | tar x The above is fine. Run two passes over the file, one for integrity, one for output. pgp --decrypt < small-backup.pgp | tar x The above is fine. The file is small and it fits into some predefined buffer in memory before reaching EOF. Similar to the above: check before outputting anything. pgp --decrypt < backup.pgp | tar x The above is *not* fine, and the user should have to go through hoops to make it work (for example some kind of --unsafe option, or big warning pop up box in a GUI application). In general I think the OpenPGP spec should have more guidelines for implementors since it's very easy for the user to screw up if the user is not familiar with intricate details of the system. This is to a greater extent than other specs, that mostly concern specialists anyway. Removing the constraint above, and living in the normal world where you do 1 pass integrity before decrypting, you can use much more boring and standard cryptographic constructs, which I personally would prefer in this case. Cheers Bj=C3=B6rn From nobody Sun Nov 1 07:52:12 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 C0B331B5050 for ; Sat, 31 Oct 2015 19:10:52 -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, 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 FiQCUUISjAHG for ; Sat, 31 Oct 2015 19:10:44 -0700 (PDT) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9C71B504B for ; Sat, 31 Oct 2015 19:10:43 -0700 (PDT) Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-05v.sys.comcast.net with comcast id c2A81r0075E3ZMc012Ajci; Sun, 01 Nov 2015 02:10:43 +0000 Received: from [192.168.1.2] ([73.170.34.26]) by resomta-po-18v.sys.comcast.net with comcast id c2Ah1r00B0ZpzqZ012Ahv4; Sun, 01 Nov 2015 02:10:43 +0000 Message-ID: <563574A1.2070209@brainhub.org> Date: Sat, 31 Oct 2015 19:10:41 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Watson Ladd References: <87twp91d8r.fsf@alice.fifthhorseman.net> <878u6ktpis.fsf@alice.fifthhorseman.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020802080502020801030206" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1446343843; bh=GXkySd0rhp1EN8Zj/JV34UdlR04y9KHEtNENpTclsjA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=AZl2qBhYr3WiYh7YSue5zAYgLaDiMCKe3FMuaHUtJ3u1yHC787v5jAfqlk52BJ+Qj LiG3i6fdjJ5+nJLhGubnrgbk9wntF1PTqaTQ8ZtQa/X2D8LX8Y9R2gWj+bCKwUQqo+ 0OR0pad9Hw+4GgLOJMA98sMg2F56wXWBSjrYViN8ABeSJJJobRB+OeCh8y83YEI6ps 2VX4aP0V5SMOICwKV93Xz0S/2gp1JfHkDDAT2OhKwSbkPbTAY+JRZpOzGG1Id5mDza 7iQwkfRMxqKhXaAz3ZI1Gz3ZEM1kRcRfXklQEJccocP123M2n1V3VlfMAX3gk6ELU3 hbFO6OwTiIZHA== Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 07:51:57 -0800 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: Sun, 01 Nov 2015 02:10:52 -0000 This is a multi-part message in MIME format. --------------020802080502020801030206 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 10/30/2015 07:46 AM, Watson Ladd wrote: > 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). Such a generic claim about "absence of a beyond-birthday bound security", is unfortunately not true for AES-GCM. David Mcgrew pointed out his eprint paper, which I will distill here into a practical attack on the current TLS 1.3 privacy feature. The feature in question intends to hide the size of the TLS record (https://tools.ietf.org/html/draft-ietf-tls-tls13-10#section-5.2.3) The feature is broken in the very use case the feature was intended to defend against: - passive monitoring, including analysis of previously recorded traffic - the size of the protected (real) plaintext is revealed, and not just the the fact that the padding was used. The only challenge in this attack is the need to accumulate on the order of 2^64 16 byte blocks for a probability 1/2 statements, but this will be less, accordingly, for lower probability, and actually we will see that this even less due to the design of the feature. However this storage requirement is a common property of birthday boundary attacks. To remind, the TLS 1.3 padding pads the plaintext record at the end with Z=0^128 blocks. The key property that enables the attack is that encryption of Z will produce a block that is unique so far for the given stream. Let's see in details how this is exploited. - accumulate all 16-byte ciphertext blocks in the TLS session, building the table T with all seen 16-byte C_i. - Once the table has near 2^64 unique entries, we are setup to break the padding - For a new TLS record, iterating from the last_index-x 16-byte block: If the block is unique, this is likely C_j = AES-GCM(Z). Iterating up, we stop when we have a collision with an entry in T. On collision, we know that C_j wasn't an encrypted Z. Note that the property of multiple Z at the end amplifies this attack (not discussed further here). This means that we will need much less than 2^64 blocks for 1/2 probability. ( x here is to adjust for the fact that the very last block won't be Z due to fixed metadata. This shouldn't be a problem in practice. ) ( One possible fix is to use random/pseudorandom data instead of Z. Another is to limit the number of records sent, currently 2^64, which is too high in this attack). ( It's true, however, that AES-GCM seems to go farther than AES-CBC or AES-CFB in its defense against outright decryption of plaintext. ) --------------020802080502020801030206 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 10/30/2015 07:46 AM, Watson Ladd wrote:
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).

Such a generic claim about "absence of a beyond-birthday bound security", is unfortunately not true for AES-GCM.

David Mcgrew pointed out his eprint paper, which I will distill here into a practical attack on the current TLS 1.3 privacy feature. The feature in question intends to hide the size of the TLS record (https://tools.ietf.org/html/draft-ietf-tls-tls13-10#section-5.2.3)

The feature is broken in the very use case the feature was intended to defend against:
- passive monitoring, including analysis of previously recorded traffic
- the size of the protected (real) plaintext is revealed, and not just the the fact that the padding was used.

The only challenge in this attack is the need to accumulate on the order of 2^64 16 byte blocks for a probability 1/2 statements, but this will be less, accordingly, for lower probability, and actually we will see that this even less due to the design of the feature. However this storage requirement is a common property of birthday boundary attacks.

To remind, the TLS 1.3 padding pads the plaintext record at the end with Z=0^128 blocks.

The key property that enables the attack is that encryption of Z will produce a block that is unique so far for the given stream.

Let's see in details how this is exploited.

- accumulate all 16-byte ciphertext blocks in the TLS session, building the table T with all seen 16-byte C_i.
- Once the table has near 2^64 unique entries, we are setup to break the padding
- For a new TLS record, iterating from the last_index-x 16-byte block: If the block is unique, this is likely C_j = AES-GCM(Z). Iterating up, we stop when we have a collision with an entry in T. On collision, we know that C_j wasn't an encrypted Z.

Note that the property of multiple Z at the end amplifies this attack (not discussed further here). This means that we will need much less than 2^64 blocks for 1/2 probability.

( x here is to adjust for the fact that the very last block won't be Z due to fixed metadata. This shouldn't be a problem in practice. )

( One possible fix is to use random/pseudorandom data instead of Z. Another is to limit the number of records sent, currently 2^64, which is too high in this attack).

( It's true, however,  that AES-GCM seems to go farther than AES-CBC or AES-CFB in its defense against outright decryption of plaintext. )
--------------020802080502020801030206-- From nico@enigmail.net Mon Nov 2 11:13:56 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 74D781B2A8D for ; Mon, 2 Nov 2015 11:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 fl3ziz1JdAyX for ; Mon, 2 Nov 2015 11:13:54 -0800 (PST) Received: from mailout07.t-online.de (mailout07.t-online.de [194.25.134.83]) (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 F41DB1B2A8A for ; Mon, 2 Nov 2015 11:13:53 -0800 (PST) Received: from fwd15.aul.t-online.de (fwd15.aul.t-online.de [172.20.27.63]) by mailout07.t-online.de (Postfix) with SMTP id B29892EDB64; Mon, 2 Nov 2015 20:13:50 +0100 (CET) Received: from [10.0.253.2] (Tt0D+YZ-whlDxt2GMAszn8pkG+xipq+hrTURCy58h5YTe9qA4pAlV0kZM42p0pzgpu@[46.189.67.11]) by fwd15.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1ZtKYA-0XfOFs0; Mon, 2 Nov 2015 20:13:50 +0100 To: gnugp-devel@gnupg.org, openpgp@ietf.org From: "nico@enigmail.net" X-Enigmail-Draft-Status: N1110 Message-ID: <5637B5E4.9050107@enigmail.net> Date: Mon, 2 Nov 2015 20:13:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ID: Tt0D+YZ-whlDxt2GMAszn8pkG+xipq+hrTURCy58h5YTe9qA4pAlV0kZM42p0pzgpu X-TOI-MSGID: 6321ec3f-51a8-40a2-8b31-b4727f9f6409 Archived-At: X-Mailman-Approved-At: Mon, 02 Nov 2015 13:21:59 -0800 Subject: [openpgp] 2nd OpenPGP Summit on Dec 5/6 in Zurich X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: nico@enigmail.net List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 19:17:21 -0000 Hi all, in April 2015 we had a first OpenPGP summit. It was a meeting where the technical experts of projects and tools dealing with OpenPGP with a focus on email encryption met getting to know each other personally and discuss several issues. For details, see e.g. - https://www.gnupg.org/blog/20150426-openpgp-summit.html - https://www.mailpile.is/blog/2015-04-20_OpenPGP_Email_Summit.html I am happy now to announce a second OpenPGP Meeting on Dec 5 and 6 in Zurich (Switzerland). Due to limited space I asked how to deal with such a meeting to find the right mixture of "not too many people" and being open to the public: > https://lists.gnupg.org/pipermail/gnupg-users/2015-August/054096.html As a consequence of the public and private feedback we first invited those who joined the first meeting and/or were important projects in the area of email clients dealing with email encryption using OpenPGP (yes, we probably missed some important guys/projects). Now is the time for a public invitation to avoid that we miss important people and to provide enough transparency not to look suspicious. Thus, if you are working in the area of - TECHNICAL DETAILS - for SENDING ENCRYPTED EMAILS - with OPEN PGP - in a project or product feel free to join us. Note however, that due to capacity reasons we don't want to have more than 2 guys from each project and we can accept requests only until we have reached the limits. Thus, you should be more than just "only interested" in the stuff and/or the guys to join this meeting. (Werner Koch from GnuPG told me that he is planing to have a public OpenPGP or GnuPGP conference in spring 2016). This all has the goal of still being able to be productive with a high signal/noise ratio. If you want to attend, please SEND AN INFORMAL EMAIL to: nico@enigmail.net Ideally with some description of your role in tis area. Note that this is still neither a well-organized conference nor a commercial meeting. The only goal I have is to give the different people and projects working in this area an opportunity to meet and build some kind of community to become more effective. It's simple the reaction of that far too many people told me "we should meet with all the other people/projects one day". I organize the date and some rooms and will manage a bit the two days that we stay productive. And it is not meant as competition to other places to meet, discuss, and standardize. Just an opportunity, where the people/projects of the first summit agreed that this helps a lot. Looking forward to meet you and all the best Nico -- Nicolai M. Josuttis www.josuttis.de mailto:nico@enigmail.net PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5 From nobody Mon Nov 2 14:05: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 E0B171A888F for ; Mon, 2 Nov 2015 14:05:56 -0800 (PST) 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 497DjGHtQmxv for ; Mon, 2 Nov 2015 14:05:55 -0800 (PST) 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 132211A8894 for ; Mon, 2 Nov 2015 14:05:55 -0800 (PST) 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 784796D73D; Mon, 2 Nov 2015 17:05:53 -0500 (EST) To: openpgp@ietf.org References: From: ianG Message-ID: <5637DE40.4080109@iang.org> Date: Mon, 2 Nov 2015 22:05:52 +0000 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: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [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: Mon, 02 Nov 2015 22:05:57 -0000 Excellent start! On 31/10/2015 08:50 am, Bryan Ford wrote: > 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. I object to the use of the word "identity" in the text. Wrong layer. I'd suggest either integrity or authentication? I like the absolute separation of the the AEAD Protected Data packet - makes it easier to squash all the old stuff. "additional data" == 0. I'm fine with that. nonce as 0 for non-reuse - disagree. I would strongly prefer the nonce to always be there and always be randomly generated by requirement, because we can't trust the rest of the software. Multiple, redundant protections are great when they are free. Which they are in this case. Nonce to be always present, big and random, and the secret key should not be re-used. 2.2 looks great! Never heard of MonkeyDunkey but happy to endorse it sight unseen ;-) > 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. 2.3 also good, I'm very keen on that. The "bucket expansion" scheme is likely to signal which tool was used, unless we can convince other packages to do that (pretty unlikely). iang From nobody Mon Nov 2 15:25: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 4F3101A9057 for ; Mon, 2 Nov 2015 15:25:14 -0800 (PST) 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 qkuEtWV746Bb for ; Mon, 2 Nov 2015 15:25:13 -0800 (PST) Received: from outmail149112.authsmtp.co.uk (outmail149112.authsmtp.co.uk [62.13.149.112]) by ietfa.amsl.com (Postfix) with ESMTP id 9C17C1A904E for ; Mon, 2 Nov 2015 15:25:12 -0800 (PST) Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247]) by punt22.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tA2NPABN096064; Mon, 2 Nov 2015 23:25:10 GMT Received: from muck ([50.58.157.74]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tA2NP37h027617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 2 Nov 2015 23:25:07 GMT Date: Mon, 2 Nov 2015 18:25:02 -0500 From: Peter Todd To: Andy Lutomirski Message-ID: <20151102232502.GA20756@muck> References: <87twp91d8r.fsf@alice.fifthhorseman.net> <20151030183223.35630603F0@jupiter.mumble.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline In-Reply-To: X-Server-Quench: f4c3b15a-81b8-11e5-bcde-0015176ca198 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR bwdMdgAUFloCAgsB AmMbWVdeUlh7WWs7 bgpPaA1DY09JQQJu T01BRU1TWkEZA2Jh BRlGUht1cQRBNn91 Z0dnECZfD0codEMs X0ZVR2UbZGY1bX1N AxQNagNUcQZLeRkW O1F2XD1vNG8XDSUg EgkrMCgEdQZ0Jj5a d0kWMUgfSEMCFDox DzkvNBlnFkoDXDkp Mhc6YlAbBg4KLkIo PFdpVVsEOkh6 X-Authentic-SMTP: 61633532353630.1038:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 50.58.157.74/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. Archived-At: Cc: Adam Langley , openpgp@ietf.org, "cfrg@irtf.org" , Taylor R Campbell 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: Mon, 02 Nov 2015 23:25:14 -0000 --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 30, 2015 at 03:09:19PM -0700, Andy Lutomirski wrote: > No, but here goes: >=20 > Amazon does this: >=20 > http://docs.aws.amazon.com/amazonglacier/latest/dev/checksum-calculations= =2Ehtml >=20 > Take 1MB chunks (and a possible short trailing chunk). Hash them with > SHA256. Then, as long as you have more than one hash in your array, > hash pairs of hashes together and just keep the extra odd one at the > end, if any. This reduces the number of hashes from n to ceil(n/2). > When you have exactly one hash left, you're done. >=20 > This is vulnerable to a trivial second-preimage attack. Fortunately, > it seems to be okay if you also store the length of the data along > with the hash value. Mind explaining in a bit more detail what exactly you think this attack is? Bitcoin did have an attack on a similar implementation, but with the critical difference that in Bitcoin rather than moving the odd block up to the "next level" it was duplicated: https://github.com/bitcoin/bitcoin/blob/d22701118413b876579c020ea90ecf7a0d5= 671cb/src/primitives/block.cpp#L17 --=20 'peter'[:-1]@petertodd.org 00000000000000001082036bc5c78a25a50b85744159b260e5136771a5611715 --T4sUOijqQbZv57TR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJWN/DLXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAxMDgyMDM2YmM1Yzc4YTI1YTUwYjg1NzQ0MTU5YjI2MGU1 MTM2NzcxYTU2MTE3MTUvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udwKtgf+JZJ3g82nts+NOXidpQdOw7H5 NdTI0pMQyP+987nkGDIdtWc1mAReDQtHLo+BOi1NkPqBRtgaf9nzUHxL4G5JnFG/ JY+iWZPpAnux5EPyz3YYzotfJpwDcLXUzVMCxrLZ5Afbqq15iQw4zel0Q6dRO7An JZehInaHVBrxkKXdktGQB8PJDbjP6W43hjh5L05CIuEtLraGWA1Ych2Sizszs7np u14K+84hsS7siLSfu/EShM7RClR0NS3qFBnABvgwovEUS1aLAnpB9yjA96e0z2W5 R7vm2MTs1DFE9cI6n3L5bBw0zzVu+sQW2w3z6Ds4htyd3nxUc1TS0tsx8MAsFw== =JKkM -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- From nobody Mon Nov 2 15:30:34 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 CC9D51A9069 for ; Mon, 2 Nov 2015 15:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IovE3Vh6WM-T for ; Mon, 2 Nov 2015 15:30:32 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (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 743981A906D for ; Mon, 2 Nov 2015 15:30:31 -0800 (PST) Received: by padec8 with SMTP id ec8so53115979pad.1 for ; Mon, 02 Nov 2015 15:30:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=D9GLTTGRO1Db8dTGII+IRSCK2mj5HjHcC1nGMsYWGPk=; b=KyeTi3EVyLsBndUXRPrXtkSSR1VYUSStQAHYtlnKJP1KUFvnj3vNrtL3n7+WP/JmJu GnNYJkmM64FMEDBd49mjsc4epqVAWFRFxp4UJmnsIfCRKyNbn5Yl1HCJRGZ15wV+zjK7 hi/X/n1T6GYEFtEr/WnrhQ4d4/cklfM7inHbuU5TWMm+24xOn7CU6PlQ/x85iV19nvuv Nrr6fiCdBDPeoswR24HHyghVkdfSUMxmujFyoD60Xwuhq7ijL/OBwigweI9BoH7Lo734 GGJl1XdaAetJ3nOzmWdKv52LoW84XTHGoNHZGa/fvq2IQ7cUL/m3QfwyiB0RH7s1Ycc/ 100g== X-Received: by 10.68.88.165 with SMTP id bh5mr30378886pbb.160.1446507031172; Mon, 02 Nov 2015 15:30:31 -0800 (PST) Received: from t20010c4000003032c957b0a9225a62d2.v6.meeting.ietf94.jp (t20010c4000003032c957b0a9225a62d2.v6.meeting.ietf94.jp. [2001:c40:0:3032:c957:b0a9:225a:62d2]) by smtp.gmail.com with ESMTPSA id tt7sm26093991pab.45.2015.11.02.15.30.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Nov 2015 15:30:30 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_749C7FA0-B5FB-4A86-B363-E0E0FC4282F9"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Bryan Ford In-Reply-To: <5637DE40.4080109@iang.org> Date: Tue, 3 Nov 2015 08:30:26 +0900 Message-Id: <64F3E0AF-DAAE-4EBD-8568-8C387A297001@gmail.com> References: <5637DE40.4080109@iang.org> To: ianG X-Mailer: Apple Mail (2.2104) Archived-At: Cc: openpgp@ietf.org Subject: Re: [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: Mon, 02 Nov 2015 23:30:34 -0000 --Apple-Mail=_749C7FA0-B5FB-4A86-B363-E0E0FC4282F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Ian for the great feedback. Indeed, I think in all the places the draft says =E2=80=98identity = protection=E2=80=99 it should say =E2=80=98integrity protection=E2=80=99, = sorry about the confusion. That was just me mixing up i-words as I was = deliriously hammering out text half an hour before the I-D submission = deadline. ;) > On Nov 3, 2015, at 7:05 AM, ianG wrote: > nonce as 0 for non-reuse - disagree. I would strongly prefer the = nonce to always be there and always be randomly generated by = requirement, because we can't trust the rest of the software. Multiple, = redundant protections are great when they are free. Which they are in = this case. Nonce to be always present, big and random, and the secret = key should not be re-used. That=E2=80=99s completely reasonable, and I=E2=80=99d be fine with that = in the interest of caution and bug-resilience. >> 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. >=20 >=20 > 2.3 also good, I'm very keen on that. The "bucket expansion" scheme is = likely to signal which tool was used, unless we can convince other = packages to do that (pretty unlikely). Great. My hope is that if we were to specify the = padding/bucket-expansion mechanism in a separate document in an = application-neutral way and with the relevant theory spelled out, we = might eventually be able to convince other applications to use or = migrate to such a scheme too. But that would be a long-term goal, and = whether or not it happens it would have to start somewhere, and to me = OpenPGP seems like a reasonable place for it to start. ;) By the way, I have a draft-of-a-draft of a document with more details on = the metadata protection and padding schemes I have in mind; it obviously = didn=E2=80=99t make the I-D deadline and still has major holes but I=E2=80= =99m happy to share it informally with anyone interested. Cheers Bryan --Apple-Mail=_749C7FA0-B5FB-4A86-B363-E0E0FC4282F9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTExMDIyMzMwMjdaMCMGCSqGSIb3DQEJBDEWBBQ/v6mfFfvb03Mcd3sorjO7O8QWkTCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAowkjYpcEmurp7Fv5U4SBsENZGitmoGUWAZY5l+UJqNRymSqMkvlrPmZQtiB6IdMZ h33sJXTHPaT6rdCW3wPUOo1iL3Zo3NEwEbSQ4bByeMn/EynFhbTuWOJQ3YPTn3b2mFovMZ7Oat8r UNam/zBa9U4c38vHJ2CIkYG2HFO321kIremf0vNuScBQqHhm11VOzcda+m8s1kdo5b9mxTW2Llhz kXxfQpYbnz4vWHtoBZFqtF1HPBh1v826QFMNx1BsuwDxJ+PBjjMqsb46THHMVbOF7aTkXldWRu/D rHTNUawIY/ouJfECxVVlREjdJaMWp1RR5sfxf0I8QW/69GLb7wAAAAAAAA== --Apple-Mail=_749C7FA0-B5FB-4A86-B363-E0E0FC4282F9-- From nobody Mon Nov 2 15:40: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 0B5601A90BE for ; Mon, 2 Nov 2015 15:40:32 -0800 (PST) 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 ejsF1EBsJMBb for ; Mon, 2 Nov 2015 15:40:30 -0800 (PST) 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 C856C1A90BA for ; Mon, 2 Nov 2015 15:40:30 -0800 (PST) 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 03ACB6D764; Mon, 2 Nov 2015 18:40:28 -0500 (EST) To: openpgp@ietf.org References: <5637DE40.4080109@iang.org> <64F3E0AF-DAAE-4EBD-8568-8C387A297001@gmail.com> From: ianG Message-ID: <5637F46B.2010200@iang.org> Date: Mon, 2 Nov 2015 23:40:27 +0000 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: <64F3E0AF-DAAE-4EBD-8568-8C387A297001@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [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: Mon, 02 Nov 2015 23:40:32 -0000 On 2/11/2015 23:30 pm, Bryan Ford wrote: >> 2.3 also good, I'm very keen on that. The "bucket expansion" scheme is likely to signal which tool was used, unless we can convince other packages to do that (pretty unlikely). > > Great. My hope is that if we were to specify the padding/bucket-expansion mechanism in a separate document in an application-neutral way and with the relevant theory spelled out, we might eventually be able to convince other applications to use or migrate to such a scheme too. But that would be a long-term goal, and whether or not it happens it would have to start somewhere, and to me OpenPGP seems like a reasonable place for it to start. ;) Right that's what I was thinking - write a separate draft listing an algorithm to determine next padded length to aim for. I'd actually suggest slightly table driven: 512 1024 1500 (ethernet or the old UDP packet length) 4096 16k 64k (jumbo packet) ... iang From nobody Mon Nov 2 15:45: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 3AF5F1A90A0 for ; Mon, 2 Nov 2015 15:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 T9GeLsheZcwa for ; Mon, 2 Nov 2015 15:45:03 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 8E1611A90BA for ; Mon, 2 Nov 2015 15:45:03 -0800 (PST) Received: by oiao187 with SMTP id o187so52573oia.3 for ; Mon, 02 Nov 2015 15:45:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital_net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CqPnaG585VFUOioRG/itVRBPn82f4YrSVXbLKCttRk0=; b=q7b8n34/SWnBocLtJG+jWwJpWSVaLsVbtGuvRedze267SbJJq097Y5Mui7VCwe9u4V F/b78DxN9iWzh+gHFNHCU4wKA5tlH+fEpmsCmWvmH8o/A5378YzyGwl3QG7uyjJLdVOF mkAhZDtzH9EzZOmb+mrQxgx7NKyF/FfQdedGDtja/dMYfD9OGNSQu+bJ8VXSxipPYgww sRZT7WJGWs8/QKUTuNlQouaAPFwgWfy2zqCmVJef3KZGZAmXJVs1vy4tsNvLktgCtkBT p0dAvPdKASEfQXTAlrzufXpgPSm6mxE5pDR15Bsc00BJTIp5Xrt9FSAheFwGf1WdEGM/ bT3g== 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:cc:content-type; bh=CqPnaG585VFUOioRG/itVRBPn82f4YrSVXbLKCttRk0=; b=AGoepnALPvUKp9YKFrsAnPz6LMwyYN9B+VeZMC5bkYOiEuNYMEeNJEGe5IAiniiebl d9b4aIkjgxeWYMp0I4utd/t+NV2efGlrfNlYu2MgMJuc1ga0EqqeXiM95m8WlRtBb1DQ quyHTlW3ERRVC2Df4APpHD50AuRFZlyhMY7S46oViNKDaG788RfCMjlURTAGdJFtMb8e vtKF9e7NraRXVerj4z1LerjtVeYCn7fWtdfQl73Afk6zO0km4YGPwHxXY1NPIPBUrjIF zINQyDgrtSJn7dmlBdG5QQtDhijrpQo+QMtsfNVIRt3J9uMMQ/4i1N4VCm5OzGA6P2y6 dWDA== X-Gm-Message-State: ALoCoQmL1XL/xwh43HuCdAMwPo8Cmewrn73C1hvVGhRsnr7UwsBSMA7w5op7yRNDo5RNQ85nWuEG X-Received: by 10.202.53.136 with SMTP id c130mr15717210oia.116.1446507902963; Mon, 02 Nov 2015 15:45:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.205.216 with HTTP; Mon, 2 Nov 2015 15:44:43 -0800 (PST) In-Reply-To: <20151102232502.GA20756@muck> References: <87twp91d8r.fsf@alice.fifthhorseman.net> <20151030183223.35630603F0@jupiter.mumble.net> <20151102232502.GA20756@muck> From: Andy Lutomirski Date: Mon, 2 Nov 2015 15:44:43 -0800 Message-ID: To: Peter Todd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Adam Langley , openpgp@ietf.org, "cfrg@irtf.org" , Taylor R Campbell 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: Mon, 02 Nov 2015 23:45:05 -0000 On Mon, Nov 2, 2015 at 3:25 PM, Peter Todd wrote: > On Fri, Oct 30, 2015 at 03:09:19PM -0700, Andy Lutomirski wrote: >> No, but here goes: >> >> Amazon does this: >> >> http://docs.aws.amazon.com/amazonglacier/latest/dev/checksum-calculations.html >> >> Take 1MB chunks (and a possible short trailing chunk). Hash them with >> SHA256. Then, as long as you have more than one hash in your array, >> hash pairs of hashes together and just keep the extra odd one at the >> end, if any. This reduces the number of hashes from n to ceil(n/2). >> When you have exactly one hash left, you're done. >> >> This is vulnerable to a trivial second-preimage attack. Fortunately, >> it seems to be okay if you also store the length of the data along >> with the hash value. > > Mind explaining in a bit more detail what exactly you think this attack > is? Bitcoin did have an attack on a similar implementation, but with the > critical difference that in Bitcoin rather than moving the odd block up > to the "next level" it was duplicated: > In the simple case, take any long input that's a power of two blocks long. Calculate its Amazon-style hash tree root value. While calculating it, remember the top two non-root internal node hash values. Concatenate them and compute the Amazon-style hash tree root for *that*. You'll get exactly the same hash tree root. This violates both the collision resistance and second-preimage resistance properties of hash functions, so the Amazon hash tree construction is not a cryptographically secure hash function. This attack isn't just theoretical. It means that, for any given big file you archive in Glacier, there exists an incorrect and easy to construct file that could be substituted and would pass a hash equality check. That's not okay. --Andy From nobody Mon Nov 2 16:13: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 417A11A9238 for ; Mon, 2 Nov 2015 16:12:52 -0800 (PST) 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 l68AX2Eqet-m for ; Mon, 2 Nov 2015 16:12:49 -0800 (PST) Received: from outmail148095.authsmtp.com (outmail148095.authsmtp.com [62.13.148.95]) by ietfa.amsl.com (Postfix) with ESMTP id 4643C1A923D for ; Mon, 2 Nov 2015 16:12:49 -0800 (PST) Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt23.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tA30Cls9034221; Tue, 3 Nov 2015 00:12:47 GMT Received: from muck ([50.58.157.74]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tA30CeOk071600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 3 Nov 2015 00:12:44 GMT Date: Mon, 2 Nov 2015 19:12:40 -0500 From: Peter Todd To: Andy Lutomirski Message-ID: <20151103001239.GA1313@muck> References: <87twp91d8r.fsf@alice.fifthhorseman.net> <20151030183223.35630603F0@jupiter.mumble.net> <20151102232502.GA20756@muck> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: X-Server-Quench: 9c0c5960-81bf-11e5-829e-00151795d556 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR bwdMdgEUFloCAgsB AmMbW1ReUV97XWU7 bgpPaA1DY09JQQJu T01BRU1TWkEZAhxy U2FFUh5zcQVGNn93 Y0BnEHkIXBd/fEB9 X0ZVRzsbZGY1bX0X UkkNagNUcQZLeRZA PlV6Uj1vNG8XDSUg EgkrMCgEdQZ0Jj5a d0kWMUgfSEMCFDox DzkvNBlnFkoDXDkp Mhc6YlAbBg4KLkIo PFdpVVsEOkh6 X-Authentic-SMTP: 61633532353630.1037:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 50.58.157.74/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. Archived-At: Cc: Adam Langley , openpgp@ietf.org, "cfrg@irtf.org" , Taylor R Campbell 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: Tue, 03 Nov 2015 00:12:52 -0000 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 02, 2015 at 03:44:43PM -0800, Andy Lutomirski wrote: > > Mind explaining in a bit more detail what exactly you think this attack > > is? Bitcoin did have an attack on a similar implementation, but with the > > critical difference that in Bitcoin rather than moving the odd block up > > to the "next level" it was duplicated: > > >=20 > In the simple case, take any long input that's a power of two blocks > long. Calculate its Amazon-style hash tree root value. While > calculating it, remember the top two non-root internal node hash > values. Concatenate them and compute the Amazon-style hash tree root > for *that*. You'll get exactly the same hash tree root. >=20 > This violates both the collision resistance and second-preimage > resistance properties of hash functions, so the Amazon hash tree > construction is not a cryptographically secure hash function. >=20 > This attack isn't just theoretical. It means that, for any given big > file you archive in Glacier, there exists an incorrect and easy to > construct file that could be substituted and would pass a hash > equality check. That's not okay. Ah, that's a different attack than what I was thinking of. You could also fix this attack by simply using tagged hashing to make the computation of inner nodes and leaf nodes be guaranteed to be different. If so, concatenating the two leaf nodes' digests and computing the Amazon-style hash tree root value would result in a different digest. --=20 'peter'[:-1]@petertodd.org 000000000000000003ee8302880a8e3d7a1e76be81c561cee33a44767680472e --0F1p//8PRICkK4MW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJWN/v0XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwM2VlODMwMjg4MGE4ZTNkN2ExZTc2YmU4MWM1NjFjZWUz M2E0NDc2NzY4MDQ3MmUvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udx5sAf+MpcrAgPAIS4diWjTIJQR5nGY 4Hz84OkXKGGF0rNoJyKS6KVXZnmMcuqug+DBETRZhci9A4MT2mdqoCw0sCDcB//D LSiFpyU3Hvlgl8RKPTp9xISpNVs2ct6Ck6jyjD5R4xlepzL46z4lV7xMfVR40a6b 928VWtko8Fja3PfMiN90zWC1wiTJc8yBenKmDUycGd1KJOc8klNjI4aCHwA53JzB Iuos91nyFbv67m74hA+nEH3a+zBUaDwq9uXVEV+7VxPj/CPkJkbJ66CsRqWgOuUw 1GsthMgEb0Jhiz4swQnMeBSi5k+c4wUQRYPeukpgrSEu/q+wVH7XpIplnYYB3w== =PG4b -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW-- From nobody Mon Nov 2 16:15:45 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 AF7531A92AF for ; Mon, 2 Nov 2015 16:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 Sj-SkJQhDywn for ; Mon, 2 Nov 2015 16:15:40 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::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 998001A9245 for ; Mon, 2 Nov 2015 16:15:40 -0800 (PST) Received: by oiao187 with SMTP id o187so378011oia.3 for ; Mon, 02 Nov 2015 16:15:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital_net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/X47oRfSSuY1gvtx5kAoo8Ro4c/qjRjusOcbKSIlJaI=; b=BqmKcgPmH0GV/cC/VjKGTnFVUMPcTWG2En954xdZAPB7EOVZ6EMyjyPZyksTIYuIAI n5qhSUk8NgODz/ajEH73nSxGJwTtUfMe6QfTH/D9u5e798EKJ72doTbZZsDQXmVekgWq MvlJHR7TbVFjZOoppCJhPUJ4uVPV6BkwkBTOh88hjsnXORiRtZoAC2RYHugDyc1mYUmo 40EkbfmEUzn8q1g8GznxhGkvx63lcl4ztjnQSoJLID6vskDeL8708N+dYWGTkPB9dXBG TFeW1gNGtdYYCuu6zR9KZ9q1vdOs/Axljqj7tebBPJr9inKStBMdj35UT7Ly/TxpU2jq RUfA== 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:cc:content-type; bh=/X47oRfSSuY1gvtx5kAoo8Ro4c/qjRjusOcbKSIlJaI=; b=P/t39tJ09Y+hfFiGg7fE/uY5CA05G6MgCv8Q4BD5QiJIvKm19cPwtkhYkuTAPwKZGQ sRa6aq/x86WZCjEV6PPT9wUbTKW44c0TGuEk4N9E3Xd6wiIbz5VmI7bnpiMBtMQXkXTR ahIWu3Bais1/eyiSGxyBzRvERIIJB0J/xjbQrJ+EP0JNfQc4LJQBGLeui5t++hkyUNaQ 93TwZTvx5FJ8OEROSzeMa4z1Yn/bpzf2/qfMW2Sz9LGiCo12/vn6OXh3RuLE3JvPrOn3 IH9e8+3ZdODMe2zr1FBHn5c4hz66jQeDl7Ayhlgmrh3qmK7y++PK0CZvqvxlsRQIoZN5 az3g== X-Gm-Message-State: ALoCoQmZIlZpt1CEvGTuXhpSPeQtHnGAuhVqgm95xlx16eZjKDFcDbEmZv/TSE4mRhJv0FUBcdSs X-Received: by 10.202.204.67 with SMTP id c64mr15940225oig.93.1446509740023; Mon, 02 Nov 2015 16:15:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.205.216 with HTTP; Mon, 2 Nov 2015 16:15:20 -0800 (PST) In-Reply-To: <20151103001239.GA1313@muck> References: <87twp91d8r.fsf@alice.fifthhorseman.net> <20151030183223.35630603F0@jupiter.mumble.net> <20151102232502.GA20756@muck> <20151103001239.GA1313@muck> From: Andy Lutomirski Date: Mon, 2 Nov 2015 16:15:20 -0800 Message-ID: To: Peter Todd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Adam Langley , openpgp@ietf.org, "cfrg@irtf.org" , Taylor R Campbell 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: Tue, 03 Nov 2015 00:15:41 -0000 On Mon, Nov 2, 2015 at 4:12 PM, Peter Todd wrote: > On Mon, Nov 02, 2015 at 03:44:43PM -0800, Andy Lutomirski wrote: >> > Mind explaining in a bit more detail what exactly you think this attack >> > is? Bitcoin did have an attack on a similar implementation, but with the >> > critical difference that in Bitcoin rather than moving the odd block up >> > to the "next level" it was duplicated: >> > >> >> In the simple case, take any long input that's a power of two blocks >> long. Calculate its Amazon-style hash tree root value. While >> calculating it, remember the top two non-root internal node hash >> values. Concatenate them and compute the Amazon-style hash tree root >> for *that*. You'll get exactly the same hash tree root. >> >> This violates both the collision resistance and second-preimage >> resistance properties of hash functions, so the Amazon hash tree >> construction is not a cryptographically secure hash function. >> >> This attack isn't just theoretical. It means that, for any given big >> file you archive in Glacier, there exists an incorrect and easy to >> construct file that could be substituted and would pass a hash >> equality check. That's not okay. > > Ah, that's a different attack than what I was thinking of. You could > also fix this attack by simply using tagged hashing to make the > computation of inner nodes and leaf nodes be guaranteed to be different. > If so, concatenating the two leaf nodes' digests and computing the > Amazon-style hash tree root value would result in a different digest. > Indeed. My point is just that hash trees are useful and that they're apparently easy enough to screw up that major commercial users have screwed them up. Sakura is interesting because it allows lots of flexibility while retaining a security proof. For applications that require or even demand reduced flexibility, other options would work fine as well. --Andy From nobody Mon Nov 2 16:43:45 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 52C311AC3E5; Mon, 2 Nov 2015 16:43:44 -0800 (PST) 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 iGTCw4aqiQ9Q; Mon, 2 Nov 2015 16:43:42 -0800 (PST) Received: from outmail149077.authsmtp.com (outmail149077.authsmtp.com [62.13.149.77]) by ietfa.amsl.com (Postfix) with ESMTP id 961BA1AC3E3; Mon, 2 Nov 2015 16:43:41 -0800 (PST) Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247]) by punt21.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tA30hccV094672; Tue, 3 Nov 2015 00:43:38 GMT Received: from muck ([50.58.157.74]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tA30hVms012349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 3 Nov 2015 00:43:34 GMT Date: Mon, 2 Nov 2015 19:43:31 -0500 From: Peter Todd To: Andy Lutomirski Message-ID: <20151103004331.GA20311@muck> References: <87twp91d8r.fsf@alice.fifthhorseman.net> <20151030183223.35630603F0@jupiter.mumble.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline In-Reply-To: X-Server-Quench: ea968870-81c3-11e5-bcde-0015176ca198 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR bwdMdgEUFloCAgsB AmMbW1ReVF57WmY7 bgpPaA1DY09JQQJu T01BRU1TWkEZAhxZ YENdUhhwdAFPNn94 Zk9iECUKVUJyfUF9 X0ZVRm4bZGY1bX1N AxQNagNUcQZLeRkW O1F2XD1vNG8XDSUg EgkrMCgEdQZ0Jj5a d0kWMUgfSEMCFDox DzkvNBlnFkoDXDkp Mhc6YlAbBg4KLkIo PFdpVVsEOkh6 X-Authentic-SMTP: 61633532353630.1038:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 50.58.157.74/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. Archived-At: Cc: openpgp@ietf.org, "cfrg@irtf.org" , Daniel Kahn Gillmor , Taylor R Campbell 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: Tue, 03 Nov 2015 00:43:44 -0000 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 30, 2015 at 11:47:42AM -0700, Andy Lutomirski wrote: > On Fri, Oct 30, 2015 at 11:32 AM, Taylor R Campbell > wrote: > > This requires only O(log n) working memory to compute the Merkle tree > > -- it takes a single pass over the whole input. > > > ...which reminds me: >=20 > As far as I know, everyone thinks they know how to do a Merkle tree > for things like this, but there doesn't seem to be a credible > standard, and there are at least two modern examples of doing it > wrong: Amazon's Glacier hash and (unless it changed) Bittorrent's new > Merkle tree. >=20 > Should CFRG consider standardizing a transport format for hash tree > verifiers (or proofs or whatever they're called) and for a large blob > that can be used to efficiently generate the proofs (essentially some > kind of serialized tree)? The Sakura construction could be a good > starting point. If I were designing such a standard, I would be > extremely hesitant to start with SHA256 or similar because of the lack > of personalization, whereas Sakura (and maybe BLAKE2) doesn't have > this problem. >=20 > Sadly, Sakura doesn't seem to be officially blessed yet. I wasn't aware of Sakura previously; it does seem very complex which I'm sure is holding it back. I had a need for a merkle tree over a list of items with the ability to efficiency prove the (relative) position of items committed to in the tree, as well as strict determinism. (for every message there is only one valid digest) I came up a fairly simple scheme that I'm calling merkle-mountain-ranges: https://github.com/proofchains/python-proofmarshal/blob/master/proofmarshal= /mmr.py While I didn't write the above with hashing byte strings in mind, by specifying a block size it could be easily modified to do so. (though be careful you don't lose the determinism!) --=20 'peter'[:-1]@petertodd.org 00000000000000000de6dfa01305b9163ad2efd9f72c77c23ebddf62afc18b00 --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJWOAMwXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwZGU2ZGZhMDEzMDViOTE2M2FkMmVmZDlmNzJjNzdjMjNl YmRkZjYyYWZjMThiMDAvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udyWjwf7BN07puagH+rScQMx7UEa7rs/ R0GaqwROErQsSwv9OPZT+rOdzNNA7Gob2IpfZl6MLNqfSpjcGYR6S2k0c/wtsZ+b X8yCAl0poPFx70PjhhQUDc4Fn1Ws74nELPfIPWPsxEztKiPMoUq/KnffH++ckBpL cD7Hs16bYhx9JG6VG/qUaPYUQ5qZdBhh4L5Xozir1kkLpyh/HlC50VY5r85+9spY 7PJoQOiq2FmDPT0mhpMX6OMutmMPQ3oHhDI7QG1vrg5Q97y+KW4ZXnnKpm29ppOD tXcsTGb9/8U6dHLmg1AoZiXuw4hHODfJpO19jVb/bht9UytfIW0cNQLJj6qJUw== =+wvd -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- From nobody Mon Nov 2 17:20: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 640D71ACD95 for ; Mon, 2 Nov 2015 17:20:38 -0800 (PST) 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 nn9oDofnqA2u for ; Mon, 2 Nov 2015 17:20:37 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4E61ACD88 for ; Mon, 2 Nov 2015 17:20:35 -0800 (PST) Received: from fifthhorseman.net (dhcp-36-99.meeting.ietf94.jp [133.93.36.99]) by che.mayfirst.org (Postfix) with ESMTPSA id 56CF2F984; Mon, 2 Nov 2015 20:20:32 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 1792F20103; Tue, 3 Nov 2015 10:20:26 +0900 (JST) From: Daniel Kahn Gillmor To: Nils Durner , "openpgp\@ietf.org" In-Reply-To: <5623AA95.4060903@googlemail.com> References: <5623AA95.4060903@googlemail.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 03 Nov 2015 10:20:26 +0900 Message-ID: <874mh3q3ol.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [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: Tue, 03 Nov 2015 01:20:38 -0000 Hi Nils-- On Sun 2015-10-18 23:20:05 +0900, Nils Durner wrote: > attached is a patch against RFC 4880bis in > git://git.gnupg.org/gnupg-doc.git to include Argon2i as an S2K method. Thanks for this patch! Since Argon2 is the winner of the password-hashing competition [0], and Argon2i is the variant of Argon2 that is intended for password-based key derivation, this seems like a good candidate. If we introduce this as a normative dependency for OpenPGP, though, we might also want to have an IETF RFC for Argon2. Do you know of anyone working on such a draft? I don't see anythng posted at the datatracker: https://datatracker.ietf.org/doc/search/?name=argon&activedrafts=on&rfcs=on If anyone else knows of efforts to document argon2, or wants to advance such a draft, i'd be happy to hear about it. --dkg [0] https://password-hashing.net/ From nobody Mon Nov 2 18:48: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 DFF831B2BDB for ; Mon, 2 Nov 2015 18:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 ffjk-rYlRRjq for ; Mon, 2 Nov 2015 18:48:10 -0800 (PST) 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 1BE091B2BD5 for ; Mon, 2 Nov 2015 18:48:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1446518890; x=1478054890; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ec0ebct7xs8ndDw55QnZo7kTKUOSHljb5YTkO9RhSrg=; b=Il2kqArUjEKTBgdF5QgMFXjvrPygvyUk4vZgL2cfyqNylu6Pvbv7xXw1 bKVGcdXlgHpzWUkNMs0tgrhDAWOlvBybp02rgCc+SGwkt+LkCva7k9SFN DPjUkiqp3E6GRUtpNfufT5Dl5dMToHivgyeBr63ttRlVDFzmqI6hwAUlF lKkO8GCGu5eTPNoqhD0hQEHNET5RkBkXqaJhWUnel8maxJPZgvbciLsHE dK6CwXO8GwrMBM5c5q5jUlwrdfQ9Sl+Z3VZFkNhYYQbqmsyWf+FCN31J9 VKPjA4VNUjXQSuDJVyekw6NdddBKq7+YLV0ogz9re1WYqoQHmBfI9QeB1 g==; X-IronPort-AV: E=Sophos;i="5.20,237,1444647600"; d="scan'208";a="52195994" 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; 03 Nov 2015 15:48:08 +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, 3 Nov 2015 15:48:08 +1300 From: Peter Gutmann To: Daniel Kahn Gillmor , Nils Durner , "openpgp@ietf.org" Thread-Topic: [openpgp] [PATCH] RFC4880bis: Argon2i Thread-Index: AQHRFdXlijSW/3f4FU2z5WUCh4oiMp6Jl+Zg Date: Tue, 3 Nov 2015 02:48:07 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B5168F@uxcn10-5.UoA.auckland.ac.nz> References: <5623AA95.4060903@googlemail.com>, <874mh3q3ol.fsf@alice.fifthhorseman.net> In-Reply-To: <874mh3q3ol.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] [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: Tue, 03 Nov 2015 02:48:14 -0000 Daniel Kahn Gillmor writes:=0A= =0A= >If we introduce this as a normative dependency for OpenPGP, though, we mig= ht=0A= >also want to have an IETF RFC for Argon2. Do you know of anyone working o= n=0A= >such a draft?=0A= =0A= Uh, yeah, started it, got distracted by other work, I'll take this as a hin= t=0A= to finish it :-). I was going to post it here first in any case to get=0A= feedback, since it's more a proposal that needs comment on how people would= =0A= prefer certain things to be done.=0A= =0A= Peter.=0A= From nobody Mon Nov 2 19:52:22 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 C1A021B2C70 for ; Mon, 2 Nov 2015 19:52:20 -0800 (PST) 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 vN_SrxQNo33A for ; Mon, 2 Nov 2015 19:52:19 -0800 (PST) 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 98F891ACE1F for ; Mon, 2 Nov 2015 19:52:19 -0800 (PST) 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 C15286D724; Mon, 2 Nov 2015 22:52:17 -0500 (EST) To: openpgp@ietf.org References: <5623AA95.4060903@googlemail.com> <874mh3q3ol.fsf@alice.fifthhorseman.net> From: ianG Message-ID: <56382F70.5000501@iang.org> Date: Tue, 3 Nov 2015 03:52:16 +0000 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: <874mh3q3ol.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [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: Tue, 03 Nov 2015 03:52:20 -0000 On 3/11/2015 01:20 am, Daniel Kahn Gillmor wrote: > If we introduce this as a normative dependency for OpenPGP, I agree with all the rest, but can we also deprecate some old stuff as well? Can we construct a plan e.g., that no existing S2K be used with new keys and the new form not be used with old keys? Or *something* to avoid the monotonically increasing algorithmic bloat that seems so trendy. iang From nobody Mon Nov 2 19:55:31 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 0D0DE1B2C85 for ; Mon, 2 Nov 2015 19:55:30 -0800 (PST) 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 6btqRfIG1yzN for ; Mon, 2 Nov 2015 19:55:28 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id A23F31A900A for ; Mon, 2 Nov 2015 19:55:28 -0800 (PST) Received: from fifthhorseman.net (dhcp-36-99.meeting.ietf94.jp [133.93.36.99]) by che.mayfirst.org (Postfix) with ESMTPSA id 1FAFFF984; Mon, 2 Nov 2015 22:55:14 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 393BE1FFEF; Tue, 3 Nov 2015 12:55:04 +0900 (JST) From: Daniel Kahn Gillmor To: Peter Gutmann , Nils Durner , "openpgp\@ietf.org" In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B5168F@uxcn10-5.UoA.auckland.ac.nz> References: <5623AA95.4060903@googlemail.com> <874mh3q3ol.fsf@alice.fifthhorseman.net> <9A043F3CF02CD34C8E74AC1594475C73F4B5168F@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 03 Nov 2015 12:55:04 +0900 Message-ID: <87io5johyf.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [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: Tue, 03 Nov 2015 03:55:30 -0000 On Tue 2015-11-03 11:48:07 +0900, Peter Gutmann wrote: > Daniel Kahn Gillmor writes: > >>If we introduce this as a normative dependency for OpenPGP, though, we might >>also want to have an IETF RFC for Argon2. Do you know of anyone working on >>such a draft? > > Uh, yeah, started it, got distracted by other work, I'll take this as a hint > to finish it :-). Please do, thank you! > I was going to post it here first in any case to get feedback, since > it's more a proposal that needs comment on how people would prefer > certain things to be done. I'm happy to have it posted here for review. If it's a description of the algorithm on its own, we can also point the CFRG at it. --dkg From nobody Mon Nov 2 20:44: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 505771B2DB5 for ; Mon, 2 Nov 2015 20:44:06 -0800 (PST) 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 jnDwqvqtAtlX for ; Mon, 2 Nov 2015 20:44:05 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id E76DB1B2DB4 for ; Mon, 2 Nov 2015 20:44:04 -0800 (PST) Received: from fifthhorseman.net (dhcp-36-99.meeting.ietf94.jp [133.93.36.99]) by che.mayfirst.org (Postfix) with ESMTPSA id B8844F984; Mon, 2 Nov 2015 23:44:02 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 948111FEB8; Tue, 3 Nov 2015 13:43:59 +0900 (JST) From: Daniel Kahn Gillmor To: ianG , openpgp@ietf.org In-Reply-To: <56382F70.5000501@iang.org> References: <5623AA95.4060903@googlemail.com> <874mh3q3ol.fsf@alice.fifthhorseman.net> <56382F70.5000501@iang.org> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 03 Nov 2015 13:43:59 +0900 Message-ID: <878u6fofow.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [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: Tue, 03 Nov 2015 04:44:06 -0000 On Tue 2015-11-03 12:52:16 +0900, ianG wrote: > On 3/11/2015 01:20 am, Daniel Kahn Gillmor wrote: >> If we introduce this as a normative dependency for OpenPGP, > > I agree with all the rest, but can we also deprecate some old stuff as well? Ian's proposed change actually does deprecate some old stuff. Maybe it doesn't go far enough, though. > Can we construct a plan e.g., that no existing S2K be used with new keys > and the new form not be used with old keys? > > Or *something* to avoid the monotonically increasing algorithmic bloat > that seems so trendy. Yes, we'll be talking about algorithm deprecation at the meeting later today. --dkg From nobody Mon Nov 2 22:00: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 893201B29C0 for ; Mon, 2 Nov 2015 22:00:48 -0800 (PST) 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 rjOoORRYWqLB for ; Mon, 2 Nov 2015 22:00:47 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id BFA7C1ACE2C for ; Mon, 2 Nov 2015 22:00:46 -0800 (PST) Received: from fifthhorseman.net (dhcp-36-99.meeting.ietf94.jp [133.93.36.99]) by che.mayfirst.org (Postfix) with ESMTPSA id 05B0BF984 for ; Tue, 3 Nov 2015 01:00:43 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 026A11FFEF; Tue, 3 Nov 2015 15:00:37 +0900 (JST) From: Daniel Kahn Gillmor To: IETF OpenPGP User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 03 Nov 2015 15:00:37 +0900 Message-ID: <87ziyvmxkq.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [openpgp] Upcoming meeting 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, 03 Nov 2015 06:00:48 -0000 Hi all-- The IETF 94 OpenPGP WG session is coming up in a couple hours (at 17:10 JST, 08:10 UTC). Meeting overview slides can be found here: https://www.ietf.org/proceedings/94/slides/slides-94-openpgp-1.pdf If you're not in Yokohama, please participate remotely via one of the following channels: MeetEcho: http://www.meetecho.com/ietf94/openpgp listen: http://ietf94streaming.dnsalias.net/ietf/ietf945.m3u --dkg From nobody Mon Nov 2 22:45:50 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 EB2BA1B2E8F for ; Mon, 2 Nov 2015 22:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2M6Ndv1L5zK for ; Mon, 2 Nov 2015 22:45:47 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (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 8C4AA1B2E66 for ; Mon, 2 Nov 2015 22:45:47 -0800 (PST) Received: by wicll6 with SMTP id ll6so5114720wic.1 for ; Mon, 02 Nov 2015 22:45:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=UZpLS0nkyvU6upCJQUkp3x/fdMatXzW8aG5b1Lw8mSg=; b=B1p6sjjEXZbEFHmTQ97c11OMMCXHDroXW6avy0h8vxO/dj1KUwnTgphHYhah41QP6g 8GFoztWg/aEVfZcorgOzanAUdk1itYp89XZ7Xq4PIVhvMs03E4odrtlaPpVIpJ0+tutI D8t5pMczbogX+EvFGS6V1SuCFMJWM2NrcFwaHf7vR8llOxoiK8eVr63aNZ2bMjESMQm4 XKleO8Z+ldIECrF0VSNnRB8bdaRGWE/LFuDfI+jKpQT2Uki7Wfuq3sEd3hfye+nSHYkN 6namDZ9wlcbpe2EyJt/URrpbTw8gcvwwXHAll7fuZQjdGfah1p4Bv2ta0j/TlonDa4Lu gmBQ== X-Received: by 10.194.59.137 with SMTP id z9mr27649024wjq.28.1446533146132; Mon, 02 Nov 2015 22:45:46 -0800 (PST) Received: from [192.168.188.46] (x4db00818.dyn.telefonica.de. [77.176.8.24]) by smtp.googlemail.com with ESMTPSA id 197sm21805713wmx.23.2015.11.02.22.45.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 22:45:45 -0800 (PST) To: "openpgp@ietf.org" References: <5623AA95.4060903@googlemail.com> <874mh3q3ol.fsf@alice.fifthhorseman.net> From: Nils Durner Message-ID: <56385818.2000606@googlemail.com> Date: Tue, 3 Nov 2015 07:45:44 +0100 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: <874mh3q3ol.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Archived-At: Cc: Simon Josefsson Subject: Re: [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: Tue, 03 Nov 2015 06:45:49 -0000 Hi Daniel, > If we introduce this as a normative dependency for OpenPGP, though, we > might also want to have an IETF RFC for Argon2. Do you know of anyone > working on such a draft? Simon Josefsson has expressed interest in helping with that. @Simon: are you working on this? Regards, Nils From nobody Mon Nov 2 22:54: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 A25751B2ED9 for ; Mon, 2 Nov 2015 22:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bh0ODmM9KpfQ for ; Mon, 2 Nov 2015 22:54:51 -0800 (PST) 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 2F4AB1B2ED8 for ; Mon, 2 Nov 2015 22:54:51 -0800 (PST) Received: by wicfx6 with SMTP id fx6so63217778wic.1 for ; Mon, 02 Nov 2015 22:54:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=Mto9TQLzf4dysZUhDJO8n+Phf7eFf4SIH1gue8N28N4=; b=EnTkF6Rb58u/YCSBVrS+rTPUwkOWiVWaWhOQHf1ClWQxthZp+jU2pARobmakyXJJf7 50mJ0vRjDpobJUyuHy445XxA3jUWbLC1+tWfaHHwoXouVOTsyrAJSz9vYKhcLOhPSXi5 nXut6+mIO/3V/TE0Ct6kluM85rpn3LWcNGyjkS0aEpbilq2hpYJbP991/TooIa8adrNd e82tphZ2yZwonvvHnFGrhDzeWHMPLGO6KHCYs1PvSiswF7VUklNMAHrKARRSVQWKpo+5 OyDU/4ImuFGnqHa2vgjA+frGZ2+7cD6AG5RFqwdjzNO8E4zXY/DphuiRi/kF5zpI43At rBXg== X-Received: by 10.195.18.6 with SMTP id gi6mr26854207wjd.47.1446533689803; Mon, 02 Nov 2015 22:54:49 -0800 (PST) Received: from [192.168.188.46] (x4db00818.dyn.telefonica.de. [77.176.8.24]) by smtp.googlemail.com with ESMTPSA id w73sm21853395wme.12.2015.11.02.22.54.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 22:54:49 -0800 (PST) To: openpgp@ietf.org References: <5623AA95.4060903@googlemail.com> <874mh3q3ol.fsf@alice.fifthhorseman.net> <56382F70.5000501@iang.org> From: Nils Durner X-Enigmail-Draft-Status: N1110 Message-ID: <56385A38.6000707@googlemail.com> Date: Tue, 3 Nov 2015 07:54:48 +0100 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: <56382F70.5000501@iang.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [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: Tue, 03 Nov 2015 06:54:52 -0000 Hi Ian, > I agree with all the rest, but can we also deprecate some old stuff as > well? > > Can we construct a plan e.g., that no existing S2K be used with new > keys and the new form not be used with old keys? I have made salt-based methods mandatory in my patch: > +Implementations MUST generate S2K specifiers that include salts > +(either type 2, 3 or 4), as simple S2K specifiers are more vulnerable = to (type 2 should actually be "type 1") > +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 SHOU= LD > +issue a warning about potentially insecure methods being used. When > +reading S2K specifiers other than Argon2i, implementations SHOULD issu= e > +a warning about outdated methods being used. We can of course raise the bar by excluding types 1 & 3 entirely. Regards, Nils From nobody Tue Nov 3 00:23: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 5784D1B2F65 for ; Tue, 3 Nov 2015 00:23:40 -0800 (PST) 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 8tDOJHxFZXhJ for ; Tue, 3 Nov 2015 00:23:38 -0800 (PST) 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 16A451B2F69 for ; Tue, 3 Nov 2015 00:23:37 -0800 (PST) Received: from latte.josefsson.org ([IPv6:2001:9b0:104:42::a86]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tA38KCAi000512 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 3 Nov 2015 09:20:13 +0100 Date: Tue, 3 Nov 2015 09:20:06 +0100 From: Simon Josefsson To: Nils Durner Message-ID: <20151103092006.3cd3e900@latte.josefsson.org> In-Reply-To: <56385818.2000606@googlemail.com> References: <5623AA95.4060903@googlemail.com> <874mh3q3ol.fsf@alice.fifthhorseman.net> <56385818.2000606@googlemail.com> 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_/pYpBfexuHkS08CNC6naXq3k"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [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: Tue, 03 Nov 2015 08:23:40 -0000 --Sig_/pYpBfexuHkS08CNC6naXq3k Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Den Tue, 3 Nov 2015 07:45:44 +0100 skrev Re: [openpgp] [PATCH] RFC4880bis: Argon2i: > Hi Daniel, >=20 > > If we introduce this as a normative dependency for OpenPGP, though, > > we might also want to have an IETF RFC for Argon2. Do you know of > > anyone working on such a draft? >=20 > Simon Josefsson has expressed interest in helping with that. > @Simon: are you working on this? I started on an Argon2 draft but after talking to the Argon2 team we decided to wait until Argon2 was finalized. I suppose now is a good time to resume that work. I'll put something up on gitlab.com so people can review and help. If anyone wants to help, please let me know and we'll coordinate something. /Simon --Sig_/pYpBfexuHkS08CNC6naXq3k Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWOG42AAoJEIYLf7sy+BGdlY4H/R7pPX2NxwCiSnfA78m+OD+6 cG/s+NN5kndMui4MG5XaAc/nWtahXu3ybrgR6ApL0CbalK4FARmBGm9CSy+is2/L hjcRBB3jumuva6tRn74yHUDhv09IbXZlTN11Z6UE2nw9w9n6y2VdnCGzon+2moQH Ue/XgVzXaLg5MmFdbNb79aYL1AKWZMF9iML5yAfX8P/PglxSYHk+Zfk7vOXIBOpW juVXgyH+MyWaQc1VNP+SdBEMsb9RN5BtV9oYdE/yeDYtu5HSgjWPhhsjHCeUzALH LO2L6k3cFYg8bH9WRGa4nE6ln+9DnrGuMtRVfofrdH6bYPuyC0FNEWkHdvcngVk= =P+Nr -----END PGP SIGNATURE----- --Sig_/pYpBfexuHkS08CNC6naXq3k-- From nobody Tue Nov 3 01:47: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 A130F1B3143 for ; Tue, 3 Nov 2015 01:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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] 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 Rqb8G5LHXVlc for ; Tue, 3 Nov 2015 01:47:35 -0800 (PST) Received: from mail-lf0-x242.google.com (mail-lf0-x242.google.com [IPv6:2a00:1450:4010:c07::242]) (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 E234D1B3115 for ; Tue, 3 Nov 2015 01:47:34 -0800 (PST) Received: by lffz202 with SMTP id z202so1176239lff.3 for ; Tue, 03 Nov 2015 01:47:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NtlLbtFXEcCoI+XEOmHnXI+l9CwG8mJgIRvhA28aBk8=; b=MsJb6eUj+m+gnrkZCdn6AXhy2BfYeAzEG7NfNuhDJ8ye0fQVeCloSae1H/lgYXhxZb h3pH+TyEaz3rKsjJa3/rnr+PrBcQvN8MCB4cBjOw4YvEUFQIDINKcs30wqLIGprwXLxA 6WfbozWwazynYl5+GBFBpH6+9NzcbsB1GS/TM= 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:cc:content-type; bh=NtlLbtFXEcCoI+XEOmHnXI+l9CwG8mJgIRvhA28aBk8=; b=iHHZZnU96wMnN4N2CmHc3neqsLlMEN7LYY2jOcDyJ5g5JsQSwpyA4/O33ZQprdrGeb dpnPBkyzc6GBjWnDhII36kUQ45yCai3IZV4uHj2CBDimxonp5+XN1NpLQA0S3t6FOuWL 5wIj5IikPi+HvOmrnGZHLfWsL0aWkqhWPQ29trG0i1H3oEo1uzBtuXZr49Fu632C5eql CncDTkBrXD5fuLSXbUjFrFlr2OXizSGYjWQho0FShDhYpaKtQM1XEFkj0auD7HJatrS4 v0sO0SoQhcApDDz1ma0vM39dEQqeJcFohZnm4vacT7IsFrH3KbqgGFDwgh8tTylzhnL3 GWFg== X-Gm-Message-State: ALoCoQnNHDG68sXoUkqSmD8/Z1Y4T0wLXcdgCzfR41esymMGiFpKdLPq1dy8/tMrtCmJJQwSS7fU X-Received: by 10.25.20.24 with SMTP id k24mr8263301lfi.117.1446544052556; Tue, 03 Nov 2015 01:47:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.141.77 with HTTP; Tue, 3 Nov 2015 01:47:12 -0800 (PST) In-Reply-To: <20151103092006.3cd3e900@latte.josefsson.org> References: <5623AA95.4060903@googlemail.com> <874mh3q3ol.fsf@alice.fifthhorseman.net> <56385818.2000606@googlemail.com> <20151103092006.3cd3e900@latte.josefsson.org> From: Joseph Lorenzo Hall Date: Tue, 3 Nov 2015 18:47:12 +0900 Message-ID: To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Nils Durner , alex.biryukov@uni.lu, "openpgp@ietf.org" , khovratovich@gmail.com, dumitru-daniel.dinu@uni.lu Subject: Re: [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: Tue, 03 Nov 2015 09:47:36 -0000 At IETF94 one question that came up in trying to move quickly to support Argon2 is the potential IPR that might be in Argon2. The code available now [1] is CC0 which, AFAICT, doesn't have any patent grant or implication for patents, etc., meaning the authors could still claim something, precluding it from use without a waiver (or whatever, IANAL) I'll CC the Argon2 authors (on the Argon2 spec [2]) here and see if we can clarify any potential IPR and whether that might affect using it in the future in OpenPGP. best, Joe [1]: https://github.com/p-h-c/phc-winner-argon2 [2]: https://password-hashing.net/argon2-specs.pdf On Tue, Nov 3, 2015 at 5:20 PM, Simon Josefsson wrote: > Den Tue, 3 Nov 2015 07:45:44 +0100 > skrev Re: [openpgp] [PATCH] RFC4880bis: Argon2i: > >> Hi Daniel, >> >> > If we introduce this as a normative dependency for OpenPGP, though, >> > we might also want to have an IETF RFC for Argon2. Do you know of >> > anyone working on such a draft? >> >> Simon Josefsson has expressed interest in helping with that. >> @Simon: are you working on this? > > I started on an Argon2 draft but after talking to the Argon2 team we > decided to wait until Argon2 was finalized. I suppose now is a good > time to resume that work. I'll put something up on gitlab.com so > people can review and help. If anyone wants to help, please let me > know and we'll coordinate something. > > /Simon > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 joe@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 From nobody Tue Nov 3 02:02:34 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 7B65B1B3148 for ; Tue, 3 Nov 2015 02:02:33 -0800 (PST) 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_DE=0.35, SPF_HELO_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 LamXkUxLym4d for ; Tue, 3 Nov 2015 02:02:32 -0800 (PST) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0351B313B for ; Tue, 3 Nov 2015 02:02:31 -0800 (PST) Received: from p5ddfa7da.dip0.t-ipconnect.de ([93.223.167.218] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZtYQ7-0001iR-Sr for openpgp@ietf.org; Tue, 03 Nov 2015 10:02:28 +0000 Received: from grit.huenfield.org ([192.168.20.253]) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZtYQ6-000051-GQ for openpgp@ietf.org; Tue, 03 Nov 2015 11:02:27 +0100 Received: from ip6-localhost.huenfield.org ([::1] helo=grit.huenfield.org.walfield.org) by grit.huenfield.org with esmtp (Exim 4.84) (envelope-from ) id 1ZtYQ5-00017V-Jj for openpgp@ietf.org; Tue, 03 Nov 2015 11:02:25 +0100 Date: Tue, 03 Nov 2015 11:02:25 +0100 Message-ID: <87io5j764u.wl-neal@walfield.org> From: "Neal H. Walfield" To: IETF OpenPGP User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 192.168.20.253 X-SA-Exim-Mail-From: neal@walfield.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 17:06:47 +0000) X-SA-Exim-Scanned: Yes (on mail.huenfield.org) Archived-At: Subject: [openpgp] Reducing the meta-data leak 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, 03 Nov 2015 10:02:33 -0000 Hi, At the IETF 94 OpenPGP WG session, Bryan, if I recall correctly, suggested that we should try and hide more meta-data. For instance, instead of listing the recipients, someone decrypting a message would try each of their available secret keys in turn. Werner pointed out that these probes are a pain for people who use a passphrase protected key and I mentioned that it is a pain for people who use a smartcard, in paritcular, those who use more than one smartcard. What about using a bloom filter for encoding the recipients? This, of course, doesn't eliminate the meta-data leak and it can lead to false positives (= gratuitious passphrase prompts / smartcard prompts), but it should reduce the metadata leak a fair amount, I think. Thoughts? Thanks, :) Neal From nobody Tue Nov 3 03:06: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 419781ACE00 for ; Tue, 3 Nov 2015 03:06:23 -0800 (PST) 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 U4wYz9OCHVHn for ; Tue, 3 Nov 2015 03:06:21 -0800 (PST) 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 B65821B31F8 for ; Tue, 3 Nov 2015 03:06:20 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZtZPu-0007HK-Mm for ; Tue, 03 Nov 2015 12:06:18 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZtZM9-0005It-7V; Tue, 03 Nov 2015 12:02:25 +0100 From: Werner Koch To: Nils Durner References: <5623AA95.4060903@googlemail.com> 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: Nils Durner , "openpgp\@ietf.org" Date: Tue, 03 Nov 2015 12:02:25 +0100 In-Reply-To: <5623AA95.4060903@googlemail.com> (Nils Durner's message of "Sun, 18 Oct 2015 16:20:05 +0200") Message-ID: <87k2pzwdku.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] [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: Tue, 03 Nov 2015 11:06:23 -0000 On Sun, 18 Oct 2015 16:20, ndurner@googlemail.com said: > +Implementations MUST generate S2K specifiers that include salts > +(either type 2, 3 or 4), as simple S2K specifiers are more vulnerable to Type 2 is not defined but reserved, you probably meant type 1. I also assume you allow type 1 (Salted S2K) to allow the use of an entire random passphrase, right? The salt then acts as IV for the SESK. Should we explain this use of type 1? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Nov 3 03:56:50 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 28F651B328F for ; Tue, 3 Nov 2015 03:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 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, HTML_MESSAGE=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 TOgWIB4BKnkq for ; Tue, 3 Nov 2015 03:56:46 -0800 (PST) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 A42A31B327C for ; Tue, 3 Nov 2015 03:56:45 -0800 (PST) Received: by lfbf136 with SMTP id f136so14845560lfb.0 for ; Tue, 03 Nov 2015 03:56:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HrPUTOFtLrb7yoHM8Lfj0gVu7Iw9bkEka7OBw+0f+rA=; b=AzU2KU8uGgHzKyGo/HOkreFAYU1Q5tACUyXWh7KS5Jb56sj7daSUCbU2Yl0XGpThgr +UghYL+hIAIx2n28ena7HIFS9jnP4mnbBnORndbJe+YPmikD3jYKLFBT9liF4sQfAih+ HPQ0Nrq1Hj05E7IiCSDeZWI4lhz4iAVBMt9+Q= 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; bh=HrPUTOFtLrb7yoHM8Lfj0gVu7Iw9bkEka7OBw+0f+rA=; b=NJRxT+o+BC01V2ofcKeBEkv3A43s36Gghx8TCHHDb/05LaGuOHBfHbEE+xqWwzRXjl FZmxXP5sEEvVeuCe7AqfpdPvVeaX2XjedaD2BUOh2w+udkm0sByhkvdGt8QoAUqNf0U6 Koysrqpn8/hfThN19eoMNd1K/jET5Duf9MJRtVV+abE3n6JdrJ91lf3X5yeBBS9oZKhj DAxdeBPDWGX9Nk5A853yP3aPwe1Scl+VOXgGN9EMiLUYu5k0T5BnFZ4N9Sa9212wZOcz 3tvaJTe28DpwIftWYlIR19GAS1NhAY1/Fm3qaT5pO20GSlZTAoguokWxn1aD3D1othCR VYKA== X-Gm-Message-State: ALoCoQlyu8ne+NudJGVrHS7dUctgGwKEQzHc8Ky9plaqVJ1/arOc5OAgpHZdkgE+JOmV/flm8uiq MIME-Version: 1.0 X-Received: by 10.25.208.84 with SMTP id h81mr3011222lfg.22.1446551803513; Tue, 03 Nov 2015 03:56:43 -0800 (PST) Received: by 10.25.141.77 with HTTP; Tue, 3 Nov 2015 03:56:43 -0800 (PST) In-Reply-To: References: <5623AA95.4060903@googlemail.com> <874mh3q3ol.fsf@alice.fifthhorseman.net> <56385818.2000606@googlemail.com> <20151103092006.3cd3e900@latte.josefsson.org> Date: Tue, 3 Nov 2015 20:56:43 +0900 Message-ID: From: Joseph Lorenzo Hall To: Alex Biryukov Content-Type: multipart/alternative; boundary=001a11411fba65eaec0523a196d3 Archived-At: Cc: Simon Josefsson , "openpgp@ietf.org" , Dmitry Khovratovich , Nils Durner , Daniel Dinu , Kathleen Moriarty , Stephen Farrell Subject: Re: [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: Tue, 03 Nov 2015 11:56:48 -0000 --001a11411fba65eaec0523a196d3 Content-Type: text/plain; charset=UTF-8 Congratulations btw on winning the competition! Kathleen and Stephen can confirm, but I believe you don't have to do anything in terms of adding any language in this case (no patent issued/sought, patent pending, etc.). When/if the document is adopted by the working group, the chair will request any disclosures. On Tuesday, November 3, 2015, Alex Biryukov wrote: > Hi all, > > We were not intending to patent it, so we can add a sentence about it. > Suggestions of lawyer-happy phrases are welcome. > > Alex > > On Tue, Nov 3, 2015 at 10:47 AM, Joseph Lorenzo Hall > wrote: > >> At IETF94 one question that came up in trying to move quickly to >> support Argon2 is the potential IPR that might be in Argon2. The code >> available now [1] is CC0 which, AFAICT, doesn't have any patent grant >> or implication for patents, etc., meaning the authors could still >> claim something, precluding it from use without a waiver (or whatever, >> IANAL) >> >> I'll CC the Argon2 authors (on the Argon2 spec [2]) here and see if we >> can clarify any potential IPR and whether that might affect using it >> in the future in OpenPGP. >> >> best, Joe >> >> [1]: https://github.com/p-h-c/phc-winner-argon2 >> [2]: https://password-hashing.net/argon2-specs.pdf >> >> On Tue, Nov 3, 2015 at 5:20 PM, Simon Josefsson > > wrote: >> > Den Tue, 3 Nov 2015 07:45:44 +0100 >> > skrev Re: [openpgp] [PATCH] RFC4880bis: Argon2i: >> > >> >> Hi Daniel, >> >> >> >> > If we introduce this as a normative dependency for OpenPGP, though, >> >> > we might also want to have an IETF RFC for Argon2. Do you know of >> >> > anyone working on such a draft? >> >> >> >> Simon Josefsson has expressed interest in helping with that. >> >> @Simon: are you working on this? >> > >> > I started on an Argon2 draft but after talking to the Argon2 team we >> > decided to wait until Argon2 was finalized. I suppose now is a good >> > time to resume that work. I'll put something up on gitlab.com so >> > people can review and help. If anyone wants to help, please let me >> > know and we'll coordinate something. >> > >> > /Simon >> > >> > _______________________________________________ >> > openpgp mailing list >> > openpgp@ietf.org >> > https://www.ietf.org/mailman/listinfo/openpgp >> > >> >> >> >> -- >> Joseph Lorenzo Hall >> Chief Technologist >> Center for Democracy & Technology >> 1634 I ST NW STE 1100 >> Washington DC 20006-4011 >> (p) 202-407-8825 >> (f) 202-637-0968 >> joe@cdt.org >> PGP: https://josephhall.org/gpg-key >> fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 >> > > > > -- > --------------------------------- > Prof. Dr. Alex Biryukov, > FSTC/CSC, University of Luxembourg, > 6, rue Richard Coudenhove-Kalergi, > L-1359 Luxembourg-Kirchberg > LUXEMBOURG > Tel: +352 46 66 44 6793 > Fax: +352 46 66 44 5500 > -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 joe@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 --001a11411fba65eaec0523a196d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Congratulations btw on winning the competition!

Kathleen= and Stephen can confirm, but I believe you don't have to do anything i= n terms of adding any language=C2=A0in this case (no patent issued/sought, = patent pending, etc.). When/if the document is=C2=A0adopted by the working = group, the chair will request any disclosures.



O= n Tuesday, November 3, 2015, Alex Biryukov <alex.biryukov@uni.lu> wrote:
Hi all,

We were not intending to patent= it, so we can add a sentence about it. Suggestions of lawyer-happy phrases= are welcome.

Alex

On Tue, Nov 3, 2015 at 10:47 AM, Joseph Lorenzo Hal= l <joe@cdt.org> wrote:
At IETF94 one question that came up in tryi= ng to move quickly to
support Argon2 is the potential IPR that might be in Argon2. The code
available now [1] is CC0 which, AFAICT, doesn't have any patent grant or implication for patents, etc., meaning the authors could still
claim something, precluding it from use without a waiver (or whatever,
IANAL)

I'll CC the Argon2 authors (on the Argon2 spec [2]) here and see if we<= br> can clarify any potential IPR and whether that might affect using it
in the future in OpenPGP.

best, Joe

[1]: https://github.com/p-h-c/phc-winner-argon2
[2]: https://password-hashing.net/argon2-specs.pdf<= br>
On Tue, Nov 3, 2015 at 5:20 PM, Simon Josefsson <= simon@josefsson.org> wrote:
> Den Tue, 3 Nov 2015 07:45:44 +0100
> skrev Re: [openpgp] [PATCH] RFC4880bis: Argon2i:
>
>> Hi Daniel,
>>
>> > If we introduce this as a normative dependency for OpenPGP, t= hough,
>> > we might also want to have an IETF RFC for Argon2.=C2=A0 Do y= ou know of
>> > anyone working on such a draft?
>>
>> Simon Josefsson has expressed interest in helping with that.
>> @Simon: are you working on this?
>
> I started on an Argon2 draft but after talking to the Argon2 team we > decided to wait until Argon2 was finalized.=C2=A0 I suppose now is a g= ood
> time to resume that work.=C2=A0 I'll put something up on gitlab.com = so
> people can review and help.=C2=A0 If anyone wants to help, please let = me
> know and we'll coordinate something.
>
> /Simon
>
> _______________________________________________
> openpgp mailing list
> openpgp@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp<= br> >



--
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 2= 02-407-8825
(f) 2= 02-637-0968
joe@cdt.org
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10=C2=A0 1607 5F86 6987 40A9 A871



--
---------------------------------
Prof. Dr. Alex Biryu= kov,
FSTC/CSC, University of Luxembourg,
6, rue Richard Coudenhove-Ka= lergi,
L-1359 Luxembourg-Kirchberg
LUXEMBOURG
Tel:=C2=A0 +352 46 6= 6 44 6793
Fax: +352 46 66 44 5500


--
Joseph Lorenz= o Hall
Chief Technologist
Center for Democracy & Te= chnology
1634 I ST NW STE 1100
Washington DC 20006-4011= =C2=A0
(p) 202-407-8825
(f) 202-637-0968
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 =C2= =A01607 5F86 6987 40A9 A871



--001a11411fba65eaec0523a196d3-- From nobody Tue Nov 3 04:18: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 279611B32C8 for ; Tue, 3 Nov 2015 04:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 tp4JB3X3-PbE for ; Tue, 3 Nov 2015 04:18:02 -0800 (PST) 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 9C7811B32A5 for ; Tue, 3 Nov 2015 04:18:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1446553081; x=1478089081; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=axgOcRjNK1E5/Fcssd6kVKv9zV2m71ll4BQ1IlrrRYE=; b=mQqTCw5GQudmRW+yyQgEYyKii50AyTAsqVCgV5v6/LEcJA8dLRn3oBqd rR9WP6Py2ZkW+WffdtgNdzS651K0ZTuwx15j8ZqudHB5a8SEf3vPSdg+f VF0aT+d8kgb/qWucE2vOwCYyCG3AOrUkt1gP1j7ghBx8cafnRnA/jFQwz AloGkz/IlHPANCGhlu5C6RUFjuDRA2M1QYueiNdKz2W3otZ3HzHksAMvN sw1gVlmA15CEbQmoGqJDlPaKAjMe9JJwY0JMHn7jJwsfXluMhM23v0nPS uIXgVwxa1YVshaeY9RCjciD81ESYoe/B8QM5yvexDh6vdLkIrFMZmHG5s w==; X-IronPort-AV: E=Sophos;i="5.20,238,1444647600"; d="scan'208";a="52263271" 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; 04 Nov 2015 01:17:59 +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; Wed, 4 Nov 2015 01:17:59 +1300 From: Peter Gutmann To: Nils Durner , "openpgp@ietf.org" Thread-Topic: [openpgp] [PATCH] RFC4880bis: Argon2i Thread-Index: AQHRFdXlijSW/3f4FU2z5WUCh4oiMp6I0HUAgAAzAACAATMkiw== Date: Tue, 3 Nov 2015 12:17:58 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B51C09@uxcn10-5.UoA.auckland.ac.nz> References: <5623AA95.4060903@googlemail.com> <874mh3q3ol.fsf@alice.fifthhorseman.net> <56382F70.5000501@iang.org>,<56385A38.6000707@googlemail.com> In-Reply-To: <56385A38.6000707@googlemail.com> 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] [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: Tue, 03 Nov 2015 12:18:06 -0000 Nils Durner writes:=0A= =0A= >We can of course raise the bar by excluding types 1 & 3 entirely.=0A= =0A= 1 and 3? I assume you mean 0 and 1, with 2 being unused anyway. There sho= uld=0A= really only be a 3, a straight hash or salted hash is barely better than ju= st=0A= using the password directly.=0A= =0A= (They also seem to be virtually unused in practice, some time ago I=0A= inadvertently disabled use of 0 and 1 in my code and, after zero complaints= =0A= over this, made the change permanent).=0A= =0A= Peter.= From nobody Tue Nov 3 04:19: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 39B261B32C7 for ; Tue, 3 Nov 2015 04:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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, 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 ASdBkhcQnu0i for ; Tue, 3 Nov 2015 04:19:13 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 9AF441B32C6 for ; Tue, 3 Nov 2015 04:19:13 -0800 (PST) Received: by qkcl124 with SMTP id l124so5278656qkc.3 for ; Tue, 03 Nov 2015 04:19:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wYNi81g+ZfeDXyjP8b+gWmzuzBaZK1htTUebMdHp7Ek=; b=0XeJUaBsAcUeMVFpX3Ulq7fsnUoqL1blGC0gVf8Puj99I0fguAInXx5fa4ItIzSyZA qm+NYPgU1Zd2O6BnbnGPuXyVlX9t6MrEmHP7sOL4pJr7cpnLusx3nX/7R5fy9LGABLdd fhh/utdIevdDZqJKJzTXnXiN+UkO8PDQyaBGk= 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; bh=wYNi81g+ZfeDXyjP8b+gWmzuzBaZK1htTUebMdHp7Ek=; b=jDnLynZlcoHRR8fNIfR03YwtcthZkBTiKCQCTSZ5J++W3wR8fYgnWlny0JeTxgSTF2 UMNdK3L2axWvhWH25CLXlHq2KhANsi9rkjD8OHW2BeubT3PFLt39OoKPjr9ARUTYKK3N 5nka0FuXuKkw/+f2H04m0czFojU0f1HXRFYAmSWq9XXG3VcSyUa5kUkWNAKQVwPXJXW3 NTcN4vCZzvzEX8Ywn4f6VtL444tV0M6vIZhsjZc+GaSlk3NCZFBA+zn8H7KLaKa9Txln cmnG+/TiBqxdy5C5KtjDDfAlP9IPFzs+R8Q59jCk/vXEijy9HwlWxUgDCcVhxa5FZW9P fBfA== X-Gm-Message-State: ALoCoQlcvkwacBQb7/djBCKLSouVFcRy8F+BKmfquYKZ7qGaOrUCOh0KiWds7o5ocmhRDVImX0QT MIME-Version: 1.0 X-Received: by 10.55.203.20 with SMTP id d20mr21443695qkj.57.1446553152727; Tue, 03 Nov 2015 04:19:12 -0800 (PST) Received: by 10.140.94.117 with HTTP; Tue, 3 Nov 2015 04:19:12 -0800 (PST) In-Reply-To: <87io5j764u.wl-neal@walfield.org> References: <87io5j764u.wl-neal@walfield.org> Date: Tue, 3 Nov 2015 06:19:12 -0600 Message-ID: From: Tom Ritter To: "Neal H. Walfield" Content-Type: multipart/alternative; boundary=001a11411122d141290523a1e647 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Reducing the meta-data leak 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, 03 Nov 2015 12:19:15 -0000 --001a11411122d141290523a1e647 Content-Type: text/plain; charset=UTF-8 On Tuesday, 3 November 2015, Neal H. Walfield wrote: > Hi, > > At the IETF 94 OpenPGP WG session, Bryan, if I recall correctly, > suggested that we should try and hide more meta-data. For instance, > instead of listing the recipients, someone decrypting a message would > try each of their available secret keys in turn. Werner pointed out > that these probes are a pain for people who use a passphrase protected > key and I mentioned that it is a pain for people who use a smartcard, > in paritcular, those who use more than one smartcard. > > What about using a bloom filter for encoding the recipients? This, of > course, doesn't eliminate the meta-data leak and it can lead to false > positives (= gratuitious passphrase prompts / smartcard prompts), but > it should reduce the metadata leak a fair amount, I think. Thoughts? > > I'm skeptical that we could come up with a set of parameters such that this provides any real protection. On the loosest end, you would need to make it ambiguous enough such that if you tried 'all' the OpenPGP keys you would get too many false positives for it to be useful. On the tightest end, you would need to make it ambiguous enough that even if you *had* the list of the most common conversation partners of a user it would _still_ have too many false positives to be useful. And even then, the bloom filter is chosen once and set in stone in the spec for all users and use cases? It would clearly not fit some of the situations we expect OpenPGP to be used in. And I tend to lean towards more complex protocol options, but even I think user-configurable bloom filters in every OpenPGP message is going too far... -tom --001a11411122d141290523a1e647 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, 3 November 2015, Neal H. Walfield <neal@walfield.org> wrote:
Hi,

At the IETF 94 OpenPGP WG session, Bryan, if I recall correctly,
suggested that we should try and hide more meta-data.=C2=A0 For instance, instead of listing the recipients, someone decrypting a message would
try each of their available secret keys in turn.=C2=A0 Werner pointed out that these probes are a pain for people who use a passphrase protected
key and I mentioned that it is a pain for people who use a smartcard,
in paritcular, those who use more than one smartcard.

What about using a bloom filter for encoding the recipients?=C2=A0 This, of=
course, doesn't eliminate the meta-data leak and it can lead to false positives (=3D gratuitious passphrase prompts / smartcard prompts), but
it should reduce the metadata leak a fair amount, I think.=C2=A0 Thoughts?<= br>

I'm skeptical that we could com= e up with a set of parameters such that this provides any real protection.= =C2=A0 On the loosest end, you would need to make it ambiguous enough such = that if you tried 'all' the OpenPGP keys you would get too many fal= se positives for it to be useful. On the tightest end, you would need to ma= ke it ambiguous enough that even if you *had* the list of the most common c= onversation partners of a user it would _still_ have too many false positiv= es to be useful.=C2=A0

And even then, the bloom fi= lter is chosen once and set in stone in the spec for all users and use case= s? It would clearly not fit some of the situations we expect OpenPGP to be = used in.=C2=A0 And I tend to lean towards more complex protocol options, bu= t even I think user-configurable bloom filters in every OpenPGP message is = going too far...=C2=A0

-tom=C2=A0
--001a11411122d141290523a1e647-- From nobody Tue Nov 3 06:26: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 9CB821A03A5 for ; Tue, 3 Nov 2015 06:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2] 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 1ymIOIH-aSfT for ; Tue, 3 Nov 2015 06:26:22 -0800 (PST) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC2AA1A0367 for ; Tue, 3 Nov 2015 06:26:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 168B3E2039; Tue, 3 Nov 2015 09:26:19 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 27490-07; Tue, 3 Nov 2015 09:26:15 -0500 (EST) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 155B4E2038; Tue, 3 Nov 2015 09:26:15 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1446560775; bh=mlK9FXO/KWpn8L7ngIqHSCxXZMiOJup5LN2UzjF0Au0=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=DEatDZo0pgAi9KkVpUttGTjzU5n4zaGoS1+FkIUjryCeUt4xDutPup0Yd1WxtJbWz 0VJk8tKgYcln+vhqsZ+FmL8BfzqCjtg7e83/Af4X2uc1VnztKJW7fWQIo3uwV/M/HN iXg1PCdd0ew/HrifI2BuxFhbeNqFzSqstHn97m0c= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id tA3EQDYK017134; Tue, 3 Nov 2015 09:26:13 -0500 From: Derek Atkins To: nico@enigmail.net References: <5637B5E4.9050107@enigmail.net> Date: Tue, 03 Nov 2015 09:26:13 -0500 In-Reply-To: <5637B5E4.9050107@enigmail.net> (nico@enigmail.net's message of "Mon, 2 Nov 2015 20:13:40 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: openpgp@ietf.org, gnugp-devel@gnupg.org Subject: Re: [openpgp] 2nd OpenPGP Summit on Dec 5/6 in Zurich 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, 03 Nov 2015 14:26:24 -0000 Hi Nico, Just to be clear, this is an "OpenPGP in EMAIL" Summit, not a general OpenPGP Summit? I'm asking this because my company is working with OpenPGP but not in an email framework. Indeed, we're only using OpenPGP Key/Signature Formats and not any of the OpenPGP messaging systems. But it sounds like this use-case input isn't desired for this Summit? -derek "nico@enigmail.net" writes: > Hi all, > > in April 2015 we had a first OpenPGP summit. > It was a meeting where the technical experts of projects and tools > dealing with OpenPGP with a focus on email encryption met > getting to know each other personally and discuss several issues. > For details, see e.g. > - https://www.gnupg.org/blog/20150426-openpgp-summit.html > - https://www.mailpile.is/blog/2015-04-20_OpenPGP_Email_Summit.html > > I am happy now to announce a second OpenPGP Meeting on Dec 5 and 6 in > Zurich (Switzerland). > > Due to limited space I asked how to deal with such a meeting > to find the right mixture of "not too many people" and > being open to the public: >> https://lists.gnupg.org/pipermail/gnupg-users/2015-August/054096.html > > As a consequence of the public and private feedback we first invited > those who joined the first meeting and/or were important projects in the > area of email clients dealing with email encryption using OpenPGP > (yes, we probably missed some important guys/projects). > > Now is the time for a public invitation to avoid that we miss important > people and to provide enough transparency not to look suspicious. > > Thus, if you are working in the area of > - TECHNICAL DETAILS > - for SENDING ENCRYPTED EMAILS > - with OPEN PGP > - in a project or product > feel free to join us. > Note however, that due to capacity reasons we don't want to have more > than 2 guys from each project and we can accept requests only > until we have reached the limits. > > Thus, you should be more than just "only interested" > in the stuff and/or the guys to join this meeting. > (Werner Koch from GnuPG told me that he is planing to have a > public OpenPGP or GnuPGP conference in spring 2016). > > This all has the goal of still being able to be productive > with a high signal/noise ratio. > > If you want to attend, please > SEND AN INFORMAL EMAIL to: > nico@enigmail.net > Ideally with some description of your role in tis area. > > Note that this is still neither a well-organized conference > nor a commercial meeting. > The only goal I have is to give the different people > and projects working in this area an opportunity to meet and build > some kind of community to become more effective. > It's simple the reaction of that far too many people told me > "we should meet with all the other people/projects one day". > I organize the date and some rooms and will manage a bit the > two days that we stay productive. > And it is not meant as competition to other places to > meet, discuss, and standardize. Just an opportunity, where > the people/projects of the first summit agreed that this helps a lot. > > Looking forward to meet you and > all the best > Nico -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Nov 3 06:30: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 7B77B1A1A03 for ; Tue, 3 Nov 2015 06:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 37r4d-PHEZV7 for ; Tue, 3 Nov 2015 06:30:56 -0800 (PST) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 469EB1A1A00 for ; Tue, 3 Nov 2015 06:30:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id D2C77E203F; Tue, 3 Nov 2015 09:30:54 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 27490-09; Tue, 3 Nov 2015 09:30:50 -0500 (EST) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 7A65EE203A; Tue, 3 Nov 2015 09:30:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1446561049; bh=+20dMlIBEnARfR4MNXDxJAv/xdGcB9FmYQvsRS1YVnc=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=kfUIuVI5vovpfUIw6LVUJSrfTS5wEger4CEVpE+h77YRgm42qAWpUKF2ebFHkYKkq H8XGl09anUyKrl4FDyj30Yc6LkDRQIso2ctoxhTtdE1ZZ8XvPkxvx9wPM4DOHVjE5L rxmbyKbPlGbfXLlzPh4i+90TSF0Qqoq908dZrBz0= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id tA3EUmXu017369; Tue, 3 Nov 2015 09:30:48 -0500 From: Derek Atkins To: "Neal H. Walfield" References: <87io5j764u.wl-neal@walfield.org> Date: Tue, 03 Nov 2015 09:30:48 -0500 In-Reply-To: <87io5j764u.wl-neal@walfield.org> (Neal H. Walfield's message of "Tue, 03 Nov 2015 11:02:25 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Reducing the meta-data leak 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, 03 Nov 2015 14:30:57 -0000 "Neal H. Walfield" writes: > Hi, > > At the IETF 94 OpenPGP WG session, Bryan, if I recall correctly, > suggested that we should try and hide more meta-data. For instance, > instead of listing the recipients, someone decrypting a message would > try each of their available secret keys in turn. Werner pointed out > that these probes are a pain for people who use a passphrase protected > key and I mentioned that it is a pain for people who use a smartcard, > in paritcular, those who use more than one smartcard. > > What about using a bloom filter for encoding the recipients? This, of > course, doesn't eliminate the meta-data leak and it can lead to false > positives (= gratuitious passphrase prompts / smartcard prompts), but > it should reduce the metadata leak a fair amount, I think. Thoughts? There was an extension at one point where you use the string 0x00...00 for the keyID and that forced you to test all your secret keys. There are certainly times where that is warranted; there are other times where it is not. I wasn't at the meeting (in person or virtually) so I'm not sure I completely understand what the use-case is where the above solution doesn't work? > Thanks, > > :) Neal -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Nov 3 06:37: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 41E251A070E for ; Tue, 3 Nov 2015 06:37:19 -0800 (PST) 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_DE=0.35, SPF_HELO_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 4Ez_QDQe1W_w for ; Tue, 3 Nov 2015 06:37:13 -0800 (PST) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB481A1A2F for ; Tue, 3 Nov 2015 06:37:13 -0800 (PST) Received: from p5ddfa7da.dip0.t-ipconnect.de ([93.223.167.218] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1Ztchx-0003VJ-93; Tue, 03 Nov 2015 14:37:09 +0000 Received: from grit.huenfield.org ([192.168.20.253]) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Ztchv-0000ML-HO; Tue, 03 Nov 2015 15:37:09 +0100 Received: from ip6-localhost.huenfield.org ([::1] helo=grit.huenfield.org.walfield.org) by grit.huenfield.org with esmtp (Exim 4.84) (envelope-from ) id 1Ztchu-0003iY-C0; Tue, 03 Nov 2015 15:37:06 +0100 Date: Tue, 03 Nov 2015 15:37:06 +0100 Message-ID: <87h9l36tf1.wl-neal@walfield.org> From: "Neal H. Walfield" To: Derek Atkins In-Reply-To: References: <87io5j764u.wl-neal@walfield.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 192.168.20.253 X-SA-Exim-Mail-From: neal@walfield.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 17:06:47 +0000) X-SA-Exim-Scanned: Yes (on mail.huenfield.org) Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Reducing the meta-data leak 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, 03 Nov 2015 14:37:19 -0000 At Tue, 03 Nov 2015 09:30:48 -0500, Derek Atkins wrote: > "Neal H. Walfield" writes: > > At the IETF 94 OpenPGP WG session, Bryan, if I recall correctly, > > suggested that we should try and hide more meta-data. For instance, > > instead of listing the recipients, someone decrypting a message would > > try each of their available secret keys in turn. Werner pointed out > > that these probes are a pain for people who use a passphrase protected > > key and I mentioned that it is a pain for people who use a smartcard, > > in paritcular, those who use more than one smartcard. > > > > What about using a bloom filter for encoding the recipients? This, of > > course, doesn't eliminate the meta-data leak and it can lead to false > > positives (= gratuitious passphrase prompts / smartcard prompts), but > > it should reduce the metadata leak a fair amount, I think. Thoughts? > > There was an extension at one point where you use the string 0x00...00 > for the keyID and that forced you to test all your secret keys. There > are certainly times where that is warranted; there are other times where > it is not. > > I wasn't at the meeting (in person or virtually) so I'm not sure I > completely understand what the use-case is where the above solution > doesn't work? Bryan Ford proposed getting rid of all unencrypted meta-data. In particular, he wanted to get rid of the recipients / number of recipients. There are some practical difficulties with this approach, which I mentioned above. My proposal is a blue sky idea to avoid having to try to decrypt a message with every secret key while (hopefully) making it more difficult to get at the list of recipients. Neal From nobody Tue Nov 3 13:06: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 83D811A01A2 for ; Tue, 3 Nov 2015 13:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-v1l-Vf0EZ8 for ; Tue, 3 Nov 2015 13:06:12 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (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 F1AA61A871B for ; Tue, 3 Nov 2015 13:06:11 -0800 (PST) Received: by wicfx6 with SMTP id fx6so77532796wic.1 for ; Tue, 03 Nov 2015 13:06:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=KHc33mYeaR4aZVKXeZSctTTyYdLpgWozi881Me1EPyA=; b=asrG05WDCCnkRADby/ZAI2OaOw8TX2bVwt+/MIEGsb8Z9jGnILtPd04ekEwyKBWiLP 0QBtgwLLIECoxBYQiUGvQIixHsmgSnuWtkY+9VTet6j4Z3s3QVejKLyc/1h+WnT2YGFW Zwki+IMQku14auEOwUCFU+dC/qPRdc/9cKryEx6vDiNxECLChp/ZQdRtghj9ZajMhKEQ w+Dq8LaIc7dio9zLvHHMLArR/VeRAoz182KB9CwaARLoPz2XD45ac6KaT73aQCie+te3 Hb5h2Abo4ESLp8SsUSWqzDRW/aSW2slFAXeDKV0VlpBoMac1ejHEzbsjJciPa1tUT3Cs N7FA== X-Received: by 10.194.175.226 with SMTP id cd2mr36068836wjc.30.1446584770322; Tue, 03 Nov 2015 13:06:10 -0800 (PST) Received: from [192.168.188.46] (x4db00818.dyn.telefonica.de. [77.176.8.24]) by smtp.googlemail.com with ESMTPSA id n17sm25210828wmg.17.2015.11.03.13.06.09 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2015 13:06:09 -0800 (PST) To: "openpgp@ietf.org" References: <5623AA95.4060903@googlemail.com> <87k2pzwdku.fsf@vigenere.g10code.de> From: Nils Durner Message-ID: <563921C1.7020800@googlemail.com> Date: Tue, 3 Nov 2015 22:06:09 +0100 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: <87k2pzwdku.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [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: Tue, 03 Nov 2015 21:06:13 -0000 Hi Werner, >> +Implementations MUST generate S2K specifiers that include salts >> +(either type 2, 3 or 4), as simple S2K specifiers are more vulnerable to > Type 2 is not defined but reserved, you probably meant type 1. Right. Fixed in https://gitlab.com/ndurner/rfc4880bis-s2k/blob/master/misc/id/rfc4880bis/middle.mkd > I also assume you allow type 1 (Salted S2K) to allow the use of an > entire random passphrase, right? The salt then acts as IV for the SESK. > Should we explain this use of type 1? Absolutely. What do you think about: > diff --git a/misc/id/rfc4880bis/middle.mkd b/misc/id/rfc4880bis/middle.mkd > index 2ab0100..6987f6e 100644 > --- a/misc/id/rfc4880bis/middle.mkd > +++ b/misc/id/rfc4880bis/middle.mkd > @@ -379,7 +379,9 @@ time independently of the memory size. > > Implementations MUST generate S2K specifiers that include salts > (either type 1, 3 or 4), as simple S2K specifiers are more vulnerable to > -dictionary attacks. Use of Argon2i is RECOMMENDED as it offers > +dictionary attacks. Type 1 MAY only be generated if the string is > +entirely random and the salt is used as an IV. > +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 ? Regards, Nils From nobody Tue Nov 3 13:19:22 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 373721A90DD for ; Tue, 3 Nov 2015 13:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vw7-xd1XWM4Q for ; Tue, 3 Nov 2015 13:19:19 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 5A44F1A89F9 for ; Tue, 3 Nov 2015 13:19:19 -0800 (PST) Received: by wmll128 with SMTP id l128so98375787wml.0 for ; Tue, 03 Nov 2015 13:19:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=subject:references:from:cc:to:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=lrESSCU6NW5Ydu2rXyq+E//0uHBBbgL1jKcuaxAiOcM=; b=M5C07Wtie+KXDJEEPHT01mBv5lvvOXGJrbOzOfULJ6OhlHny+lEGmqtXVZ5VhicGPz X0YHBCylY3pR8f/ne4+iVt8L0ljX6cMjFUuV4PqCsCFHAKpMD+d2gpWFP0Dds66oijvF 40cOEi9a2L8Q89NPMZjnChR6dfidUWi8pHVEahsd+yBuJzYSYbL5vGXm3JVfKLA/CVuP XoGtNcM9Dm88yJyB1JGnvkzEvJA0kDW9AfmMlRpdYAFvqhUKhFZBeU0UOnraE0bSWbZV CipAWxMd78rFlgra54qkxOTBUekjEeVmzpLMoF2FeZ066ktjlGfMhVnzFqgH1CQWt1Yt oOoA== X-Received: by 10.28.22.203 with SMTP id 194mr20140493wmw.45.1446585557833; Tue, 03 Nov 2015 13:19:17 -0800 (PST) Received: from [192.168.188.46] (x4db00818.dyn.telefonica.de. [77.176.8.24]) by smtp.googlemail.com with ESMTPSA id l131sm25263819wmd.14.2015.11.03.13.19.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2015 13:19:17 -0800 (PST) References: <5623AA95.4060903@googlemail.com> <874mh3q3ol.fsf@alice.fifthhorseman.net> <56382F70.5000501@iang.org> <56385A38.6000707@googlemail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B51C09@uxcn10-5.UoA.auckland.ac.nz> From: Nils Durner X-Enigmail-Draft-Status: N1110 To: Peter Gutmann Message-ID: <563924D5.6020407@googlemail.com> Date: Tue, 3 Nov 2015 22:19:17 +0100 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: <9A043F3CF02CD34C8E74AC1594475C73F4B51C09@uxcn10-5.UoA.auckland.ac.nz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [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: Tue, 03 Nov 2015 21:19:21 -0000 Hi Peter, >> We can of course raise the bar by excluding types 1 & 3 entirely. > 1 and 3? I assume you mean 0 and 1, with 2 being unused anyway. I meant 0, 1, 3 - thus only allowing to generate (the new Argon2i-based) 4. Sorry for the confusion. > There should > really only be a 3, a straight hash or salted hash is barely better tha= n just > using the password directly. That is certainly one of the safest options for actual passwords, but gets in the way of symmetric keys (cheaply) being used as passphrases. Are you content with rather limiting the permitted use case for type 1 (and not allowing type 0) as per my previous mail in response to Werner (and pushed to https://gitlab.com/ndurner/rfc4880bis-s2k/blob/master/misc/id/rfc4880bis/= middle.mkd)? Regards, Nils From nobody Tue Nov 3 14:13: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 296631B30E6 for ; Tue, 3 Nov 2015 01:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 fQ4gGt6585ey for ; Tue, 3 Nov 2015 01:41:33 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 513651B30D9 for ; Tue, 3 Nov 2015 01:41:33 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B9C9B42456E; Tue, 3 Nov 2015 09:41:32 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 985B2424519; Tue, 3 Nov 2015 09:41:32 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1446543692; bh=80mxdngARRYsOiKPQqiMGFfKok32KEGI8lMdjKmQ5VQ=; l=3406; h=From:To:CC:Date:From; b=qRrEatt1cFDOFso3q7ttIeHtpUsEVR8nQwtUbYup6RQGCfHgQAIUQv0OCRRy2HWv3 cBwDQZ4tEDRaow3iLxyNhiFR9qEbnv1viY5sXrzzBFoDFym3WYFy/bTM7r09kD4Cy9 PKrqsVDjIojxhCDGan4PwwAs0wAIZRQ1OzTphe4c= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 8C3152039; Tue, 3 Nov 2015 09:41:32 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 3 Nov 2015 01:41:32 -0800 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Tue, 3 Nov 2015 04:41:32 -0500 From: "Salz, Rich" To: Daniel Kahn Gillmor , "ietf@cdl.asgaard.org" Thread-Topic: DRAFT minutes for OpenPGP at IETF 94 Thread-Index: AdEWDje/Y0w41e42QS+efNAoYRs2AA== Date: Tue, 3 Nov 2015 09:41:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.237.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 03 Nov 2015 14:13:12 -0800 Cc: "Salz, Rich" , "openpgp@ietf.org" Subject: [openpgp] DRAFT minutes for OpenPGP at IETF 94 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, 03 Nov 2015 09:41:35 -0000 WG: Open Specification for Pretty Good Privacy (openpgp= ) Meeting: IETF 93, Yokohama Location: Pacifico Yokohama Rooms 411/412 Date: 3 November 2015 Time: 17:10-18:40 JST Chairs: Daniel Kahn Gillmor Christopher LILJENSTOLPE Minutes: Rich Salz - Agenda Bashing, Blue Sheets, etc (10 min) No changes. - Call for an editor for 4880bis Werner Koch volunteer (GPG lead developer) Plan is to use git, markdown Poll: email vs gitlab, evenly split; will take to the list. Timing? Not yet considered; -00 and -01 that incorporate errata and ECC wit= hin a week or two. Maybe a year? Sense of the room? No consensus. Need to complete before CEASAR completes, will update if necessary. =20 - SEIPD -> SED attack : followup? Magazinius pointed out you can convert symmetrically-encrypted integrity-pr= otected data (SEIPD) to symmetrically-encrypted data (SED) without decrypti= ng. How to deprecate SED? We can say MUST NOT generate, but what about dec= rypting old stored SED data? Bryan: do we know of any ciphers that were on= ly ever used with SEIPD? Will follow-up on the mailing list. - General issue of deprecration for stored data? Possibilities (? Marks po= ssibly-controversial) MD5; SHA1?; RIPE-MD IDEA; 3DES?; CAST5?; Blowfish? Twofish? DSA? Size limits on RSA? NIST ECC? ElGamal? What does deprecation mean? Perhaps just encryption? Also decrypt if the c= ontent is known/believed to be not old Is signature verification different? There are several usability issues around this; we need to be careful. Consensus is not to create new content with deprecated algorithms. Perhaps address general issue of "what to do with old stuff"? And maybe ans= wer is "lose it" Stephen Farrell: Suggest reframe question as "everything deprecated unless = shown that need to generate ones using old mechanism" Discussion of how appropriate to put UI items in a protocol/data-format spe= c. Strong consensus to start with everything removed, and then add the ones we= want. - Fingerprint conclusion One format, or multiple Choice of digest? Truncation allowed? What is digested (creation, expiration times)? Distinguish v5 from v4? UI/UX guidance for implementers? Hum on formats; sorry I glitched on the text and the hum results. *Please u= pdate this* Please come to list with concrete suggestions; no opinions on roomt. Havin= g a concrete strawman proposal would be useful to get conclusions. - Symmetric crypto (Bryan Ford), draft-ford-openpgp-format See slides in = the proceedings. Consensus to use a new packet type for AEAD-protected FYI: Rogaway agrees to waive OCB patent for PGP (perhaps might not be suffi= cient) Lots of information exposed by plaintext metadata Magic number -- this is an openpgp file, so its suspicious Cipher -- is it worth trying to crack (e.g., is it rc4 :) Passphrase: worth trying a password cracker Recipient key-id's: where to point the rubber hose? # of recipients: aha, it's *that* group of dissidents? Should we aim to protect it all (at cost of "trial" encryptions)? Consider some padding mechanisms. - S2K (key derivation) - from https://password-hashing.net/ use Argon2i (constant time) Proposal by dkg: ask for early allocation; Stephen says wait for Simon's = draft to appear to shake out any possible IPR issues. - Registry policies To be mentioned on list From nobody Tue Nov 3 14:14:27 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05F91B2B00 for ; Tue, 3 Nov 2015 14:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJhQmikAbIOX for ; Tue, 3 Nov 2015 14:14:24 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 4EC631B2B03 for ; Tue, 3 Nov 2015 14:14:17 -0800 (PST) Received: by wmec75 with SMTP id c75so98502544wme.1 for ; Tue, 03 Nov 2015 14:14:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=from:subject:to:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=W6EkCGgiHPQ4uIxM5CaObyCoIZU1qNmZOOfeoeqDV0U=; b=i4WEkJj9qil96mYzgzzM43yC9d0ectxoW2KtkAg1Tcoj2T9pry3DurRzzCJvugQ+jY qTFlWgMrkF9qDvRJdNJ39O316/bH73R6fhoLLne8QVuYzwlVSyjTi9BjmOnzS5BmyT62 j7Hms5EVqF4JblYKN1OWVl4ndUyMQ0cZjJqwyXCUeRrWUgxcRSrF8/TxsREugVMp62Av gNc3e6qVaqAL9jqwvwsHY2tIW1GNY5uaaZO6WI6nlUOFz4gus3/vVbfjEPd9C4mrsGSk 61VWaWOpe0uHiowSS/kWVJpBdBjOUV7/Yx6XkBBKzl7VZ1DqlJEvPzdl4dl806RWX2Lf kbjQ== X-Received: by 10.28.55.144 with SMTP id e138mr20928754wma.69.1446588855910; Tue, 03 Nov 2015 14:14:15 -0800 (PST) Received: from [192.168.188.46] (x4db00818.dyn.telefonica.de. [77.176.8.24]) by smtp.googlemail.com with ESMTPSA id 20sm25448227wmh.8.2015.11.03.14.14.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2015 14:14:15 -0800 (PST) From: Nils Durner X-Enigmail-Draft-Status: N1110 To: "openpgp@ietf.org" Message-ID: <563931B6.9050107@googlemail.com> Date: Tue, 3 Nov 2015 23:14:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [openpgp] Regulation of algo deprecation 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, 03 Nov 2015 22:14:25 -0000 Hi, I would like to elaborate on why I feel that algorithm deprecation should also be guided by regulations. For Germany, the algorithm catalog for Electronic Signatures[0] issued by the Federal Network Agency, dictates that > SHA-1 and RIPEMD-160, respectively, are suitable only for verification > of qualified certificates until the end of 2015. I feel that implementations should help users use crypto correctly - and incorrect use also includes use of methods deemed insufficient by law, IMO. IANAL, but repudiability based on algorithm choice should be prevented against. Concrete example: a particular mail sent by Alice is not considered legally binding because Bob failed to realize that the algorithms used by Alice had already expired by regulation at the time she sent the mail. In order not to burden implementers with such considerations, I feel we should reflects this in the RFC already - perhaps as RECOMMENDATIONs so that implementations may still provide a --force parameter for anyone who exactly knows what they are doing or just don't follow the legal canon (if there is one, I think this would need some further research). Responding to Werner's concern that, following this line of thought, only Brainpool curves could be used: I don't see why. The 2014 version of aforementioned catalog[0], as well as the 2015 draft (dated 28.10.2014), merely recommend Brainpool, but don't require it. For the US, NIST naturally recommends NIST curves[2], but I don't see a restriction to just P-384 there either. At any rate, I would just make it RECOMMENDATIONs, not MUSTs - except for cases like MD5 where there is general consensus for other, actually technical, reasons. What do others think? Regards, Nils [0] https://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/Sachgebiete/QES/= Veroeffentlichungen/Algorithmen/2014Algorithmenkatalog.pdf [1] https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml From nobody Tue Nov 3 16:00: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 C6F831B3646 for ; Tue, 3 Nov 2015 16:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_52=0.6] 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 CjJqMCsMmMPf for ; Tue, 3 Nov 2015 16:00:16 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (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 BBF6D1B3645 for ; Tue, 3 Nov 2015 16:00:15 -0800 (PST) Received: by wijp11 with SMTP id p11so82178281wij.0 for ; Tue, 03 Nov 2015 16:00:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=UKCBqv0JGKdYFHy2bECcTvDju/qnsS3XIVU0TInj/dE=; b=Vhrt2FH+bVJwL9Q2ujDzhRAzRAmIy2Me4LWsJO09EdWt7ZcRpBvuctB+FGnN98+f4x UDae77VYgOW6l/UMrC4+SlBCB7x/Zp1OdN8u7kgu2HPsOyNhu3WzH7xl3sC3hk9d9a1M wvADgzt3yXrZ2KkYkxU6+/vgxvjhjmtuyRQ7E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=UKCBqv0JGKdYFHy2bECcTvDju/qnsS3XIVU0TInj/dE=; b=fHYxC0m79+BSjlAt+iNXQnomQw4JqJR1sMoCm/21FJdLj4GEvY4tDS5mVMA40MhHtc Hbag5iMlSI/nNW8SDuMV2Hbd+KsY8PN1JORz3aFlT6qTwxTwBrkEFfRgjotCqtkbpQAL Gfs1OKK546zStf/uyLbIRtaogjPn4z5LJnBtkfZLxhHGudir8ms09oWfB5QdlSABkJtm 7A9+Xd7eh+pPSf4gDqww7xAKMn+efbq/T6alpZK14ECRKuFLqNqDVOLb2wpn9ysADkov 4tt2UvYWWW617PwVkSbU3/YPFaVUZVu4vx5reMwY0vmTJYoYB/A10lzHsnrUJ1Dnl7mF PqqQ== X-Gm-Message-State: ALoCoQkgDku3oYwlYNR2esCfNdajA8bmDjknTcmPUiIC0lYNglVz93cmNbFuw4tNg4vJ98RJPSoy X-Received: by 10.194.58.84 with SMTP id o20mr38091180wjq.73.1446595214348; Tue, 03 Nov 2015 16:00:14 -0800 (PST) Received: from [10.0.0.112] (chello080108049181.14.11.vie.surfer.at. [80.108.49.181]) by smtp.gmail.com with ESMTPSA id ee5sm30018495wjd.17.2015.11.03.16.00.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Nov 2015 16:00:13 -0800 (PST) Message-ID: <56394A8A.5070904@azet.org> Date: Wed, 04 Nov 2015 01:00:10 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Nils Durner References: <563931B6.9050107@googlemail.com> In-Reply-To: <563931B6.9050107@googlemail.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig3534421EC3CBF1288A06038A" Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] Regulation of algo deprecation 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, 04 Nov 2015 00:00:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3534421EC3CBF1288A06038A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Sorry due to time constraints I wasn't able to remotely participate in the OpenPGP session. I've read the minutes, not sure if I got everything from that though. So my impression is that GnuPG / OpenPGP current support far to many possible algorithm choices. We should really limit that. For novice users it's not easy to get this right and there're only a few places on the internet that provide a solid default config (e.g. riseup - though I've modified their settings for personal use). The real problem with PGP is that not a lot of people use it and adding tons of curves or algorithms doesn't seem the right way to go. Maybe this has already been discussed previously and I didn't notice - if so, I'd be happy for a pointer to the relevant thread. CFRG recently recommended Curve25519 (or whatever nomenclature is currently en vouge), so why bother with Brainpool at all? Aaron --------------enig3534421EC3CBF1288A06038A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWOUqLAAoJEOTbZJL9ubXV42YQAJ+U5DR6NWwtsBd0kMXflW3h M4RWSpW/OFf4PAa1x1vKmXaCjQ7dobTt9cTD+r+x8LONDQQplFc8nXLnVUggEnui 8fbKlo9DEEWez18E+qso6WyFA1YsGd7HxLM4XCWUfoWfUlLIl1e0WlLHtzMMNXlS toufDiCYzlI/1YPFR/JbOleRupxsKGtD+WlrfISVTK735nsK9I1/xsE0e85afnsE +TLMZklo4zDbzQQGc6tSC9cfpS36QiBxSDjC2vS9IACWtYx4RH3/EnW2pfY76iYZ GBp59U/2g8wKV6Urt1RAsslmCSTRmG/2MGxUi7D/8RDSXM89Ezavhe1GveteMEaX Wa4cP/t8Ngv8MLvvYnIgVMtnR39VnFHmjc84fzZ7rhU8nxt3G3LqHY9uixicX2td NNJ9D1o3Q2uWoznIrmLSEOBTDs+WPwe8L0YqJ2weKRS8JAZBxF4a8de/rWjdAcTI xbrfyrJAo5MgJIkjkzwcBUtH4x08su3z/Zl2pSgieX8CmPjKo48LX6u5kwB9FT1i 9s0ctARCik+RgSytQetnyTagCw2dvth4ESSB7XE0iBNHwapwdq+ucEFcRM3rOOge ya3D3MlpI1G8Ngz/POh3q8V5+d8oDhbm/O4rKCB608DAwoi/ZjyrSlRMaCpIFxJV rl8yxUOeGPoJtHt85226 =jmq9 -----END PGP SIGNATURE----- --------------enig3534421EC3CBF1288A06038A-- From nobody Tue Nov 3 16:33:59 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 7B2731A0121 for ; Tue, 3 Nov 2015 16:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 AfO14oPji_2v for ; Tue, 3 Nov 2015 16:33:54 -0800 (PST) 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 DCAC91A0007 for ; Tue, 3 Nov 2015 16:33:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1446597234; x=1478133234; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ypq/kJtFCqiTZ9As7HUgbzZCXHDHuPj7Kobl6HwtdtA=; b=wdihLD6/BMzdshILb2XIFpI3tihgNfT9qE5VhR38DZRkxNEHQJ7eOmyf CWwWSkpU4bQy/wILrfsBgXXtB53XKMU/oh8VIhF7Pr80UnOn6q27bBkSp DlO7Gyqo9evF1sAY3VhSsVgUm3ba0UC0tBLfdwK6qx5snH9JsBpT+AXEF xYmz62DTkQlf7zWYiMumB5LB1xt538InoO0T0xOXDalxaavy7HXJweoE7 5TlpgpDzrSvM1N/KlgAXxGvBUYqG2iuy4ewbO1SOLESCdgbBx1GP7CSp/ OKNyGLWqlX+6EmcgbaAqvp1a8ldoW8nZD2LpS8N/mIAWGdXiTOh3fThfT Q==; X-IronPort-AV: E=Sophos;i="5.20,240,1444647600"; d="scan'208";a="52382790" 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; 04 Nov 2015 13:33:52 +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; Wed, 4 Nov 2015 13:33:51 +1300 From: Peter Gutmann To: Nils Durner Thread-Topic: [openpgp] [PATCH] RFC4880bis: Argon2i Thread-Index: AQHRFdXlijSW/3f4FU2z5WUCh4oiMp6I0HUAgAAzAACAATMki///vmSAgAEQNPo= Date: Wed, 4 Nov 2015 00:33:51 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B52B3E@uxcn10-5.UoA.auckland.ac.nz> References: <5623AA95.4060903@googlemail.com> <874mh3q3ol.fsf@alice.fifthhorseman.net> <56382F70.5000501@iang.org> <56385A38.6000707@googlemail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B51C09@uxcn10-5.UoA.auckland.ac.nz>, <563924D5.6020407@googlemail.com> In-Reply-To: <563924D5.6020407@googlemail.com> 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: "openpgp@ietf.org" Subject: Re: [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: Wed, 04 Nov 2015 00:33:58 -0000 Nils Durner writes:=0A= =0A= >That is certainly one of the safest options for actual passwords, but gets= in=0A= >the way of symmetric keys (cheaply) being used as passphrases.=0A= =0A= Hmm, yeah, but if you've already got a raw symmetric key (which won't need = any=0A= extra processing) I'd lean towards having it identified as such rather than= =0A= overloading a password-processing mechanism for it. In other words make th= e=0A= use for symmetric key transport explicit rather than relying on the=0A= implementer to somehow know that S2K type X is meant to be used for symkey= =0A= transport.=0A= =0A= So perhaps have type 4 =3D Argon2, type 5 =3D symmetric key transport, with= a=0A= safety note added to say that it's meant for randomly-generated symmetric k= eys=0A= that are already, in effect, in the post-S2K state.=0A= =0A= Peter.=0A= From nobody Tue Nov 3 16:49: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 60D1F1A6F53 for ; Tue, 3 Nov 2015 16:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_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 e-PtpGLbSJhw for ; Tue, 3 Nov 2015 16:49:06 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31A8E1A6F42 for ; Tue, 3 Nov 2015 16:49:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 19D79BE39; Wed, 4 Nov 2015 00:49:04 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aarLbghrhYOE; Wed, 4 Nov 2015 00:49:01 +0000 (GMT) Received: from [133.93.24.87] (unknown [133.93.24.87]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B2247BDF9; Wed, 4 Nov 2015 00:48:57 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1446598140; bh=5meHswPzGP/Lj4LEjZu/kwU4AAMcT72Jaz7mjFds9P0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=eR/ZnHG3g4GoOjkZNfCEmCoH5+a4undH3UQGZ/9pT6sXQXbCq9USwMxw+WxLGqeIc 0MO72EZubnM52mAOIXANwjoi88aTEDz6wvozaiIZqigDdbF9QpmkZP2Lm5sIbyYP+A 8/E3ZgqEnowaUijNCFb5Fo1ye57nNHMBB5KJxDUE= To: Joseph Lorenzo Hall , Alex Biryukov References: <5623AA95.4060903@googlemail.com> <874mh3q3ol.fsf@alice.fifthhorseman.net> <56385818.2000606@googlemail.com> <20151103092006.3cd3e900@latte.josefsson.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Enigmail-Draft-Status: N1110 Message-ID: <563955F4.9030607@cs.tcd.ie> Date: Wed, 4 Nov 2015 00:48:52 +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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Simon Josefsson , "openpgp@ietf.org" , Dmitry Khovratovich , Nils Durner , Daniel Dinu , Kathleen Moriarty Subject: Re: [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: Wed, 04 Nov 2015 00:49:09 -0000 Hiya, One way to handle this might be to add the winners as co-authors on the Internet-draft. In that case, the draft boilerplate text says that you're following the IETF IPR rules and hence would have filed an IPR declaration if one was needed. And if none is needed, we'd be done. I'm sure we can figure other options but the above would be easiest from the IETF point of view. Cheers, S. On 03/11/15 11:56, Joseph Lorenzo Hall wrote: > Congratulations btw on winning the competition! > > Kathleen and Stephen can confirm, but I believe you don't have to do > anything in terms of adding any language in this case (no patent > issued/sought, patent pending, etc.). When/if the document is adopted by > the working group, the chair will request any disclosures. > > > > On Tuesday, November 3, 2015, Alex Biryukov wrote: > >> Hi all, >> >> We were not intending to patent it, so we can add a sentence about it. >> Suggestions of lawyer-happy phrases are welcome. >> >> Alex >> >> On Tue, Nov 3, 2015 at 10:47 AM, Joseph Lorenzo Hall > > wrote: >> >>> At IETF94 one question that came up in trying to move quickly to >>> support Argon2 is the potential IPR that might be in Argon2. The code >>> available now [1] is CC0 which, AFAICT, doesn't have any patent grant >>> or implication for patents, etc., meaning the authors could still >>> claim something, precluding it from use without a waiver (or whatever, >>> IANAL) >>> >>> I'll CC the Argon2 authors (on the Argon2 spec [2]) here and see if we >>> can clarify any potential IPR and whether that might affect using it >>> in the future in OpenPGP. >>> >>> best, Joe >>> >>> [1]: https://github.com/p-h-c/phc-winner-argon2 >>> [2]: https://password-hashing.net/argon2-specs.pdf >>> >>> On Tue, Nov 3, 2015 at 5:20 PM, Simon Josefsson >> > wrote: >>>> Den Tue, 3 Nov 2015 07:45:44 +0100 >>>> skrev Re: [openpgp] [PATCH] RFC4880bis: Argon2i: >>>> >>>>> Hi Daniel, >>>>> >>>>>> If we introduce this as a normative dependency for OpenPGP, though, >>>>>> we might also want to have an IETF RFC for Argon2. Do you know of >>>>>> anyone working on such a draft? >>>>> >>>>> Simon Josefsson has expressed interest in helping with that. >>>>> @Simon: are you working on this? >>>> >>>> I started on an Argon2 draft but after talking to the Argon2 team we >>>> decided to wait until Argon2 was finalized. I suppose now is a good >>>> time to resume that work. I'll put something up on gitlab.com so >>>> people can review and help. If anyone wants to help, please let me >>>> know and we'll coordinate something. >>>> >>>> /Simon >>>> >>>> _______________________________________________ >>>> openpgp mailing list >>>> openpgp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/openpgp >>>> >>> >>> >>> >>> -- >>> Joseph Lorenzo Hall >>> Chief Technologist >>> Center for Democracy & Technology >>> 1634 I ST NW STE 1100 >>> Washington DC 20006-4011 >>> (p) 202-407-8825 >>> (f) 202-637-0968 >>> joe@cdt.org >>> PGP: https://josephhall.org/gpg-key >>> fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 >>> >> >> >> >> -- >> --------------------------------- >> Prof. Dr. Alex Biryukov, >> FSTC/CSC, University of Luxembourg, >> 6, rue Richard Coudenhove-Kalergi, >> L-1359 Luxembourg-Kirchberg >> LUXEMBOURG >> Tel: +352 46 66 44 6793 >> Fax: +352 46 66 44 5500 >> > > From nobody Tue Nov 3 17:01:34 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 3880E1A879D for ; Tue, 3 Nov 2015 17:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_12=0.6, SPF_FAIL=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 ib3sIRq9wbNd for ; Tue, 3 Nov 2015 17:01:29 -0800 (PST) Received: from castro.crustytoothpaste.net (sandals-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:79::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E8E1A878B for ; Tue, 3 Nov 2015 17:01:27 -0800 (PST) Received: from vauxhall.crustytoothpaste.net (unknown [IPv6:2001:470:1f05:79:f2de:f1ff:feb8:36fd]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by castro.crustytoothpaste.net (Postfix) with ESMTPSA id 23D7228094 for ; Wed, 4 Nov 2015 01:01:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=crustytoothpaste.net; s=default; t=1446598886; bh=QjQgQMTGgmuEPrOJ+Rxv/bMFK18nMwkEOeGAp+XntS0=; h=Date:From:To:Subject:References:In-Reply-To:From; b=HVX8dBnweJkU6zmdSHTJu8MUI8k0OQ6LTfh89b4Wo4hJVNwst9x4H5TT4fDMXEyE0 ao48FnqthTur/iFdCMzeFiyvfWyhHFkbUamYCvGBB32uiHhlb0eGLVYXO3JVl7r0Dv XPHUtXse0JIDlt3b/Gip+duBLvnSSiPEg9e5jOCzZFv1y/C6dzPTX9OmKL+sjYq9Sq bfoB1TWhp2LzSfbUX5m2rl0SQBceSrRfNDioQX9tOH3oxeVmdW6LlkSWGxQvzt031m cArlaVgk2zWrJHiUOPsL8193OzATr44Ob0vkY02bZkqYI6p/wzUYdeJzcaOezq55hL y0HQF4IlZ5FgrH2cMVU8pZ9hn40YkM2uIQkcNlRb9ITO0vdGsKjXQ4hpPFkd14u5EL YbBVOlDOJV/S69AcYHKErqZlnS7P44d4ShVvy7gBTHc2kgY16JuDgAW3miqq7on2nA Jex3ZwqI7zuLYnjVsV4wMdXjvP97BmT4wLEo6z2ldRbQKQvOFLn Date: Wed, 4 Nov 2015 01:01:22 +0000 From: "brian m. carlson" To: openpgp@ietf.org Message-ID: <20151104010122.GA3896@vauxhall.crustytoothpaste.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: X-Machine: Running on vauxhall using GNU/Linux on x86_64 (Linux kernel 4.2.0-1-amd64) User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [openpgp] DRAFT minutes for OpenPGP at IETF 94 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, 04 Nov 2015 01:01:32 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 03, 2015 at 09:41:31AM +0000, Salz, Rich wrote: > - Symmetric crypto (Bryan Ford), draft-ford-openpgp-format See slides i= n the proceedings. > Consensus to use a new packet type for AEAD-protected > FYI: Rogaway agrees to waive OCB patent for PGP (perhaps might not be suf= ficient) A note on using patented algorithms: Some organizations, such as Debian, require that parts of software be able to be extracted and otherwise used under the terms of the license. Even if the OCB patent is waived for OpenPGP, that would not be sufficient to allow parts of an OpenPGP implementation that use OCB to be used in non-OpenPGP software. That might prevent such OpenPGP implementations from entering the main Debian archive. Other organizations may have similar restrictions. This is just something to consider when discussing the use of patented algorithms. --=20 brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.9 (GNU/Linux) iQIcBAEBCgAGBQJWOVjhAAoJEL9TXYEfUvaLdIkQAJHusHJ32gk6sO5d2Nd/auBh m5BVQxM1OlI8aFcHD5UHq9n9t+dj46oGAN1eAT+AlPXX8HU2Vlf5jDyGfl5zrdkv 6s0Jv69RP4VL481on9VSKFfFk3eYakG5VvkIKFEZYdKP4A0M5M1HHgr0dvYeebg6 b4Sj2P15VQaWiGfwBywZdaKK9/xy9ZOzxFdUZs5q4ECx/wfTnwiUkR6aiI5qFG8W ZJj4KSB2hySiE7TDq7URGYgQwBJ0z+4EvNHffS1WlGko6kcJTAbLSIaBPxduU51S MiTjxzEmPEkuLf1UUVqkUONcPASg6m/KAISY7ZEsy+1oJbV2zMgpxrFCLBm2JIYt nGKBK0Llyvpld7BEitECBY78ZjX/2S9h8/IdzahAOHiyHiMpdXBUX91IA/VH1fUe D2nk/5OAg6IHCSXG94q0Z5FRXjzD71uQiKPz1Ky2XqDko99P/RZIiaRihzafkdfy pSODs6Ttdihs6itYjAdzqHt/qYyReEFhGBHUWAyCOfhPHKhO5XDQeDulNA2ELo62 2cbfbXlfcUL3IZqoUj2Tl25ZkKCH/jVxKBSYDJUWkepaXRDW3pMp42DIe/sYJliz 2SXcldXmkntXfIA9b0i/HolXKKBqtTXjmUcGvFXRivrXd4oGm0xBQG+TUxJ7cvQE m1WFXpJ7yZ2V+cmCtDI7 =wir2 -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- From nobody Tue Nov 3 17:05:23 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 995201A87D1 for ; Tue, 3 Nov 2015 17:05:22 -0800 (PST) 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 bv0FBAZXeajB for ; Tue, 3 Nov 2015 17:05:20 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0060.outbound.protection.outlook.com [207.46.100.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BAD61A87AF for ; Tue, 3 Nov 2015 17:05:20 -0800 (PST) Received: from SN1PR06MB1838.namprd06.prod.outlook.com (10.162.133.16) by SN1PR06MB1744.namprd06.prod.outlook.com (10.162.132.142) with Microsoft SMTP Server (TLS) id 15.1.312.18; Wed, 4 Nov 2015 01:05:18 +0000 Received: from SN1PR06MB1839.namprd06.prod.outlook.com (10.162.133.18) by SN1PR06MB1838.namprd06.prod.outlook.com (10.162.133.16) with Microsoft SMTP Server (TLS) id 15.1.312.18; Wed, 4 Nov 2015 01:05:16 +0000 Received: from SN1PR06MB1839.namprd06.prod.outlook.com ([10.162.133.18]) by SN1PR06MB1839.namprd06.prod.outlook.com ([10.162.133.18]) with mapi id 15.01.0312.014; Wed, 4 Nov 2015 01:05:16 +0000 From: Robin Wilton To: "openpgp@ietf.org" CC: "openpgp@ietf.org" Thread-Topic: openpgp Digest, Vol 30, Issue 7 Thread-Index: AQHRFnJKpRDO8K23PkuVXBXY2TgVg56LDNY7 Date: Wed, 4 Nov 2015 01:05:16 +0000 Message-ID: <86CB1513-F594-4A9B-A3B6-17ECB9CA9EB6@isoc.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=wilton@isoc.org; x-originating-ip: [133.93.68.247] x-microsoft-exchange-diagnostics: 1; SN1PR06MB1838; 5:Bt02eP6jYn+n0FHIt6/Yo2+QIZa/yP0Y1nwvXyg8mNdfXDS3HEKtvPhibm8HpaAb25Fs1dPLUeytwF2gyv5quuqhw6n4tgHOkDwsAKjnUqc5Q1f021jDaMJP5c7F7ak7AG+P+XzsRisQwAG4QEb7IQ==; 24:9J6bszPsbV5uwmrVjN+7e19M8bd2rp3+e67vbEzmvCPnLPR+KAREezGXyrCy51C3VIxm+2fFlRrhZ07vF9Dn7XeF2vCU0BTUfdJkloXjmy4=; 20:G8XA5A0qMUfJ7omJcdnP0hHf9MooGd6AKsMvdzZWXD8nzKouLz5xDg28eyfFfRYBJCZYE2BBfDWnshlaGy3AOw== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42134001)(42139001); SRVR:SN1PR06MB1838; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:SN1PR06MB1838; BCL:0; PCL:0; RULEID:; SRVR:SN1PR06MB1838; x-forefront-prvs: 0750463DC9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(18543002)(24454002)(189002)(27574002)(5403001)(199003)(10533003)(164054003)(50986999)(106356001)(450100001)(40100003)(110136002)(87936001)(66066001)(83716003)(5001960100002)(77096005)(76176999)(106116001)(122556002)(92566002)(15975445007)(19580395003)(54356999)(19580405001)(2950100001)(2900100001)(5002640100001)(105586002)(101416001)(189998001)(10400500002)(36756003)(97736004)(81156007)(2351001)(102836002)(82746002)(33656002)(5004730100002)(5007970100001)(561944003)(99286002)(15974865002)(86362001)(5008740100001)(2501003)(11100500001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR06MB1838; H:SN1PR06MB1839.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2015 01:05:16.0087 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR06MB1838 X-Microsoft-Exchange-Diagnostics: 1; SN1PR06MB1744; 2:iMBIVnRUs2VzYZbDAFTp2x22a51PpiWdN24Cf6bOLbB7aPTaW8RNTudr9qnc7Y/YXIbggPHdKjPGTfKj+R/3oU5l02U+RwCb/X9vEFV1Y/WO+MSV5naBrDplhj5jvF+jH3pqOosKgwrCC9bMLi5hN2vD1eWN7UMYn1QytvqAaSw=; 23:VidHAXLtFEmlVKwBdcfSS/R5Ort8+AWSouQ5HPsWmGj5WyXvNqhJHHekiDeGzBAS0mUkoYhZgfQiIXG7VjQC2I0IsMkK2UKI+uL5xuxeWYeFubsrVx4Rl0nej3V4cSA9OyhaVVmjqYO5jQcVWfKWnvGHddEqUEHJ+eRj8EG0PNNGOcPZHNJKd9JyMcDApg1j X-OriginatorOrg: isoc.org Archived-At: Subject: Re: [openpgp] openpgp Digest, Vol 30, Issue 7 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, 04 Nov 2015 01:05:22 -0000 On 4 Nov 2015, at 05:00, "openpgp-request@ietf.org" wrote: > Send openpgp mailing list submissions to > openpgp@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/openpgp > or, via email, send a message with subject or body 'help' to > openpgp-request@ietf.org >=20 > You can reach the person managing the list at > openpgp-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openpgp digest..." > Today's Topics: >=20 > 1. Re: Reducing the meta-data leak (Derek Atkins) > 2. Re: Reducing the meta-data leak (Neal H. Walfield) > "Neal H. Walfield" writes: >=20 >> Hi, >>=20 >> At the IETF 94 OpenPGP WG session, Bryan, if I recall correctly, >> suggested that we should try and hide more meta-data. For instance, >> instead of listing the recipients, someone decrypting a message would >> try each of their available secret keys in turn. Werner pointed out >> that these probes are a pain for people who use a passphrase protected >> key and I mentioned that it is a pain for people who use a smartcard, >> in paritcular, those who use more than one smartcard. >>=20 >> What about using a bloom filter for encoding the recipients? This, of >> course, doesn't eliminate the meta-data leak and it can lead to false >> positives (=3D gratuitious passphrase prompts / smartcard prompts), but >> it should reduce the metadata leak a fair amount, I think. Thoughts? >=20 > There was an extension at one point where you use the string 0x00...00 > for the keyID and that forced you to test all your secret keys. There > are certainly times where that is warranted; there are other times where > it is not. Right. What struck me about the proposed approach was the difficulty of usi= ng it in the other problematic use-case DKG described during the meeting - = where someone has sent you a 5Gb cipher text (or, worse, a stream) and you = have to decrypt some or all of it before you can tell whether you're using = the right key or not. I suspect the answer is to recognise that not all metadata is equal, and th= at it may be appropriate to have different levels of protection (including = zero) for different items of metadata. For example: if "recipient" is sent in clear, it simplifies the task of ide= ntifying the right key to use, but it would then be up to the communicating= parties to decide whether they should use other means to protect their ide= ntities... The remaining metadata (such as algorithm identifier and paramet= ers) could potentially be protected by other means.=20 R=20 >=20 > I wasn't at the meeting (in person or virtually) so I'm not sure I > completely understand what the use-case is where the above solution > doesn't work? >=20 >> Thanks, >>=20 >> :) Neal >=20 > -derek > --=20 > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant >=20 >=20 > At Tue, 03 Nov 2015 09:30:48 -0500, > Derek Atkins wrote: >> "Neal H. Walfield" writes: >>> At the IETF 94 OpenPGP WG session, Bryan, if I recall correctly, >>> suggested that we should try and hide more meta-data. For instance, >>> instead of listing the recipients, someone decrypting a message would >>> try each of their available secret keys in turn. Werner pointed out >>> that these probes are a pain for people who use a passphrase protected >>> key and I mentioned that it is a pain for people who use a smartcard, >>> in paritcular, those who use more than one smartcard. >>>=20 >>> What about using a bloom filter for encoding the recipients? This, of >>> course, doesn't eliminate the meta-data leak and it can lead to false >>> positives (=3D gratuitious passphrase prompts / smartcard prompts), but >>> it should reduce the metadata leak a fair amount, I think. Thoughts? >>=20 >> There was an extension at one point where you use the string 0x00...00 >> for the keyID and that forced you to test all your secret keys. There >> are certainly times where that is warranted; there are other times where >> it is not. >>=20 >> I wasn't at the meeting (in person or virtually) so I'm not sure I >> completely understand what the use-case is where the above solution >> doesn't work? >=20 > Bryan Ford proposed getting rid of all unencrypted meta-data. In > particular, he wanted to get rid of the recipients / number of > recipients. >=20 > There are some practical difficulties with this approach, > which I mentioned above. >=20 > My proposal is a blue sky idea to avoid having to try to decrypt a > message with every secret key while (hopefully) making it more > difficult to get at the list of recipients. >=20 > Neal >=20 >=20 > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Tue Nov 3 17:28: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 27A3C1A8892 for ; Tue, 3 Nov 2015 17:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 IHC3sQusHyQT for ; Tue, 3 Nov 2015 17:28:01 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 9BB591A8884 for ; Tue, 3 Nov 2015 17:28:00 -0800 (PST) Received: by wmff134 with SMTP id f134so29471903wmf.0 for ; Tue, 03 Nov 2015 17:27:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=Wo97beEKMyF/kiocMT9lobodTlGU8K20zZno+K8k0wI=; b=Y3tu27fleqC1IbKM1QVDxFHwiyl2hqotewGSBpdVPv6pSlDdjc2C0/Qypy5/av0Yar m+qi24NfvAtC9FBn8mGo5rpyg2QF4SDDhC0mHCwQEESiprkUVAx6I3J2u4EZyUnAXEFV JdJoEyUEVcUizHWBR+wExe1XA3gyPLeavLpwQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=Wo97beEKMyF/kiocMT9lobodTlGU8K20zZno+K8k0wI=; b=c1RHv3sx7/nePpVxnWokrjET18rwpA8sXUzikIWo+9s40fVyK4gUAlQVqTRqqV/aZA xVvkJnALjF9u4sTKidtMXneFtNq3kloaMmh81oj3utUA7r81uStVpQ3/Md6gyDgscScZ 08jkxZ8+eoZlGYrsFPwPet2WSl7b0u5/AReLcg2DKqiPjXMUgJer8aVtZFBI/rCX9Vva uIXcqO1FnOW/Jneb8IX20KJ0HY+MilEtsiFNLLdsvVF1pKFk0/k3pY+7bjoyvBANzoDD w9qbMmZPmWLQx0uO5USfS0K7y3GZjAIDL5NR+Rs9oSJSx90GzfHfAyDsnKUB2WL/czuJ GL7g== X-Gm-Message-State: ALoCoQnO/NupTGL4WloEYClsP3DJV5X3x/52f5Zz98zG5yn098Np1bULMprfYXgACegb8Z8iaY41 X-Received: by 10.28.170.196 with SMTP id t187mr24681131wme.1.1446600479243; Tue, 03 Nov 2015 17:27:59 -0800 (PST) Received: from [10.0.0.112] (chello080108049181.14.11.vie.surfer.at. [80.108.49.181]) by smtp.gmail.com with ESMTPSA id jh4sm30191988wjb.33.2015.11.03.17.27.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 03 Nov 2015 17:27:58 -0800 (PST) Message-ID: <56395F1A.4060609@azet.org> Date: Wed, 04 Nov 2015 02:27:54 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "brian m. carlson" References: <20151104010122.GA3896@vauxhall.crustytoothpaste.net> In-Reply-To: <20151104010122.GA3896@vauxhall.crustytoothpaste.net> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig0DFD123C7220751D7703B13A" Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] DRAFT minutes for OpenPGP at IETF 94 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, 04 Nov 2015 01:28:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0DFD123C7220751D7703B13A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Brian, brian m. carlson wrote: > A note on using patented algorithms: Some organizations, such as Debian= , > require that parts of software be able to be extracted and otherwise > used under the terms of the license. Even if the OCB patent is waived > for OpenPGP, that would not be sufficient to allow parts of an OpenPGP > implementation that use OCB to be used in non-OpenPGP software. That > might prevent such OpenPGP implementations from entering the main Debia= n > archive. Other organizations may have similar restrictions. >=20 > This is just something to consider when discussing the use of patented > algorithms. So in this case is non open-source software relevant at all? I don't think so. For open-source initiative licenses, public domain and CC there's a patent exemption anyway (since 2013): http://web.cs.ucdavis.edu/~rogaway/ocb/license1.pdf Another one exists for non-military software implementations: http://web.cs.ucdavis.edu/~rogaway/ocb/license2.pdf And another one specific to OpenSSL: http://web.cs.ucdavis.edu/~rogaway/ocb/license3.pdf See also: http://web.cs.ucdavis.edu/~rogaway/ocb/license.htm Aaron --------------enig0DFD123C7220751D7703B13A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWOV8bAAoJEOTbZJL9ubXViYsQAJGle8L/7Ol9ucnKYSIzwbjh g0fDGLA+m6kre8ne+QRnPEYhm/cNClqtuS1lV/8Sz6TfWYA3Uuzrdb4LExsW8CRr 10kccV8GFmOsm4xvFMrrMaqDLaof2qmvzGnYF2pHPX8Y2R+x/cB3ELLzo1ON6J+m 4BKR7AUqO3ESqPIqGglRGmeHnRo+/tUSIBgmL9GFNRDBByF7ArMQui4EN0qByKr+ MU3ZA0znGn9dAmWHxl2kul+7PCgx226j0RM7fYsxih0DWGkTU3KdnKyDO8cNkqdP 75d7DRaF8TrFnBqVHllmfWOI3d/NuHQF9PZjpAqP14hGb3HCZaNBVUeJj9I2V2AD 6K4jpYes92LyEHw6wMyTBL39GEKmszQhxz2K6VlzxqOQ5jhKPmH+Rg/PG7OK9AMz mTbkT5aqpDo40LJPRsiGoao8vboLOrPTMHZCz7BfXcF6Y5sLVqNd8d/9pPdkyBYE ehiYFa38CJ6EAvfMNdaLJt3+RioeQKCn5NmsDCZYffy3NUJSRObI+9fbnQH8ecFG bCLnUEd9NAtT0a/E8DPxkqCIaJ3gTbOgIG3mxyoEE2vTZ1gKhIhqpZQ5bfQhdG5H eQ/JUlOP5iiqQlwCKOwkDoLpjeq9Kcr4N+ubLGLOtQokfvfQsS7OiSg1nh7rloqu sNtryy/frJImFRhwcl86 =w6F5 -----END PGP SIGNATURE----- --------------enig0DFD123C7220751D7703B13A-- From nobody Tue Nov 3 18:08: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 6D0F01A8990 for ; Tue, 3 Nov 2015 18:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.411 X-Spam-Level: X-Spam-Status: No, score=-1.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 CTTST0O0UBoq for ; Tue, 3 Nov 2015 18:07:58 -0800 (PST) Received: from castro.crustytoothpaste.net (castro.crustytoothpaste.net [173.11.243.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E715B1A8989 for ; Tue, 3 Nov 2015 18:07:57 -0800 (PST) Received: from vauxhall.crustytoothpaste.net (unknown [IPv6:2001:470:1f05:79:f2de:f1ff:feb8:36fd]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by castro.crustytoothpaste.net (Postfix) with ESMTPSA id 12EB628094; Wed, 4 Nov 2015 02:07:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=crustytoothpaste.net; s=default; t=1446602876; bh=kv08C0We2RrNtNQIhM1Pl5YXYgvF/b3+vLwPPDHYPjE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ztj1bY+nSb+cDLL+IHcQSZVx5j2OLF5bMXgKZSKIvlGeopgpmYecJkzDIpku3pTd+ 38h3n+GgV5VMnmn5Mhk7QUwWYYHKPDz1tSIE4yVShNSz2Y7NoT5d0xmlaW2FkRbDx+ kySh7XcWk72tDbYZktyi5toifPKOtOyNmnT26YmoCeHLEjrMgQU2mIDH25R74g2o0P RCrwigRkMeyrYo0/6/gKif9fLppnCMQvzuGOz3G3/cXHqgXAxYivTzwPk499xErC03 TClpTf+XQ23v3kRvJaJe852WalirLRW+60nLC6pqHDuTeY718ERsGrfvqEnnmivuiA uSrnU6BnjQdb2Q5UEPMPk3HUkoQJzbsbYUezFTttzsV9Pi5/PuCsshcVEZy2XSL9cz CsDakvuD4LIzFsIOUKPsywtb9hbd9wvbQfDm+2A/dNvDSF8D6GRBlFed/zw/buI0Hk Ek6NTsDhyrYq7ZjGtKSdULX90QXRTu+DsL3fbIzVdTU/jVBNbT5 Date: Wed, 4 Nov 2015 02:07:52 +0000 From: "brian m. carlson" To: Aaron Zauner Message-ID: <20151104020752.GB3896@vauxhall.crustytoothpaste.net> References: <20151104010122.GA3896@vauxhall.crustytoothpaste.net> <56395F1A.4060609@azet.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="O5XBE6gyVG5Rl6Rj" Content-Disposition: inline In-Reply-To: <56395F1A.4060609@azet.org> X-Machine: Running on vauxhall using GNU/Linux on x86_64 (Linux kernel 4.2.0-1-amd64) User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] DRAFT minutes for OpenPGP at IETF 94 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, 04 Nov 2015 02:07:59 -0000 --O5XBE6gyVG5Rl6Rj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 04, 2015 at 02:27:54AM +0100, Aaron Zauner wrote: > brian m. carlson wrote: > > A note on using patented algorithms: Some organizations, such as Debian, > > require that parts of software be able to be extracted and otherwise > > used under the terms of the license. Even if the OCB patent is waived > > for OpenPGP, that would not be sufficient to allow parts of an OpenPGP > > implementation that use OCB to be used in non-OpenPGP software. That > > might prevent such OpenPGP implementations from entering the main Debian > > archive. Other organizations may have similar restrictions. > >=20 > > This is just something to consider when discussing the use of patented > > algorithms. >=20 > So in this case is non open-source software relevant at all? I don't > think so. For open-source initiative licenses, public domain and CC > there's a patent exemption anyway (since 2013): > http://web.cs.ucdavis.edu/~rogaway/ocb/license1.pdf I suspect this is probably sufficient for Debian's purposes, although I of course can't speak on their behalf. Whether it is suitable for Red Hat or other organizations with strict patent policies, I don't know. My personal view is that using patented algorithms[0] will prevent at least some adoption of the OpenPGP standard, even if that's overly cautious and defensive, and that there are sufficient secure alternatives such that we don't have to use patented algorithms. The less we can make implementers get lawyers involved, the better. > Another one exists for non-military software implementations: > http://web.cs.ucdavis.edu/~rogaway/ocb/license2.pdf Clearly this is not suitable for Debian's purposes, as they prohibit restrictions on fields of endeavor. [0] By "patented algorithms," I mean those that don't grant a flat royalty-free license. SHA-2 is patented, but available under such a royalty-free license. --=20 brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 --O5XBE6gyVG5Rl6Rj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.9 (GNU/Linux) iQIcBAEBCgAGBQJWOWh4AAoJEL9TXYEfUvaL7JoQAIVARyOJdZmmIwWscX4mBRbd InL3mtplV17R7weSBaJ2JRDquFGcs1X2KjXehAe9W/UFMWyf4qWAO/rHN+IqCa7l cTs0SXXdfv//I2t2g3cD0v5UxxROz5TMXKTORoSaDJgB19YdfieyKvEMNZnE29DV hKlsF3ZUzQCdzQAsNy6LJlvHFVUCADjKn+4JzmayHKjj+Y726qY3xWVKzIzpaILk pEAA5IB32YvGyNtvI3+9JVzVi57GfKTF6pFEsNRxsHCRLppul3PWIpc96KNq6fsR Cm/Pj5nZArgpdu45nQVkqyo+yGEwXIT42KnLlKrR7rODwjEENQT5AFkQn09t1w6t iQvnr4uz4aJLNJGmDcBSjgg7/m0Aql22NgoW4bpiVRb+xVinfzspJi2MeY+mk+5q SXsNz63jo5et5vkGTp7MOR6eJgBuGE30k4jkAAMkNLXDypLH97+NyNvd7mjE4fGx uRv28IP26/hWebtrKRhe9q34LxyRLsrxvQnhUySdHHq96hCEgqHTb9ynffkkA/nE 8qVK6zC0yR0CAU0Qut0TGFews79B1I1+QJuYrbxqNnss72qbIhBR8hF7oPIBdEl9 SGGZTHdoIwu/cHgA2DNkgBoAtIpd29dZsR3NJXX5WqV/ThqK1tYXt2eh642Yjqt2 URIZh3r7+zE/yJZ5CQYb =OF9L -----END PGP SIGNATURE----- --O5XBE6gyVG5Rl6Rj-- From nobody Wed Nov 4 00:11:26 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 EC5EA1B2B57 for ; Wed, 4 Nov 2015 00:11:25 -0800 (PST) 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 Ni5S2bB3HNsX for ; Wed, 4 Nov 2015 00:11:21 -0800 (PST) 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 2783B1A0151 for ; Wed, 4 Nov 2015 00:11:21 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZttA6-0008KK-Oo for ; Wed, 04 Nov 2015 09:11:18 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Ztt89-0008Hc-Ib; Wed, 04 Nov 2015 09:09:17 +0100 From: Werner Koch To: Peter Gutmann References: <5623AA95.4060903@googlemail.com> <874mh3q3ol.fsf@alice.fifthhorseman.net> <56382F70.5000501@iang.org> <56385A38.6000707@googlemail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B51C09@uxcn10-5.UoA.auckland.ac.nz> <563924D5.6020407@googlemail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B52B3E@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 , Nils Durner , "openpgp\@ietf.org" Date: Wed, 04 Nov 2015 09:09:17 +0100 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B52B3E@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Wed, 4 Nov 2015 00:33:51 +0000") Message-ID: <87fv0muqxe.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: Nils Durner , "openpgp@ietf.org" Subject: Re: [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: Wed, 04 Nov 2015 08:11:26 -0000 On Wed, 4 Nov 2015 01:33, pgut001@cs.auckland.ac.nz said: > So perhaps have type 4 = Argon2, type 5 = symmetric key transport, with a > safety note added to say that it's meant for randomly-generated symmetric keys > that are already, in effect, in the post-S2K state. That would be fine for new code. Nevertheless implementations need to support reading type 1 until all backup media as worn out. Thus I doubt that requiring an extra code path is the way to go. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Nov 4 00:21:23 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 2E0241A007C for ; Wed, 4 Nov 2015 00:21:22 -0800 (PST) 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 eMQgc77QttfW for ; Wed, 4 Nov 2015 00:21:21 -0800 (PST) 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 2B6531A0074 for ; Wed, 4 Nov 2015 00:21:21 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZttJm-0008P9-RV for ; Wed, 04 Nov 2015 09:21:18 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZttEI-0008Ik-0R; Wed, 04 Nov 2015 09:15:38 +0100 From: Werner Koch To: Nils Durner References: <563931B6.9050107@googlemail.com> 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: Nils Durner , "openpgp\@ietf.org" Date: Wed, 04 Nov 2015 09:15:37 +0100 In-Reply-To: <563931B6.9050107@googlemail.com> (Nils Durner's message of "Tue, 3 Nov 2015 23:14:14 +0100") Message-ID: <87bnbauqmu.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] Regulation of algo deprecation 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, 04 Nov 2015 08:21:22 -0000 On Tue, 3 Nov 2015 23:14, ndurner@googlemail.com said: > only Brainpool curves could be used: I don't see why. The 2014 version > of aforementioned catalog[0], as well as the 2015 draft (dated > 28.10.2014), merely recommend Brainpool, but don't require it. For the That is just one catalog but there are others. For the German VS-NfD (restricted level) other rules apply. And the Russians have a different catalog, as do the Japanese, and the Koreans, ... Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Nov 4 00:31:31 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 B657E1A0180 for ; Wed, 4 Nov 2015 00:31:29 -0800 (PST) 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 UOiK2XdpMrLD for ; Wed, 4 Nov 2015 00:31:28 -0800 (PST) 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 D3D181A019B for ; Wed, 4 Nov 2015 00:31:20 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZttTT-0008Sz-4Q for ; Wed, 04 Nov 2015 09:31:19 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZttNa-0008Ka-Lw; Wed, 04 Nov 2015 09:25:14 +0100 From: Werner Koch To: Aaron Zauner References: <563931B6.9050107@googlemail.com> <56394A8A.5070904@azet.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: Aaron Zauner , Nils Durner , "openpgp\@ietf.org" Date: Wed, 04 Nov 2015 09:25:14 +0100 In-Reply-To: <56394A8A.5070904@azet.org> (Aaron Zauner's message of "Wed, 04 Nov 2015 01:00:10 +0100") Message-ID: <877flyuq6t.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: Nils Durner , "openpgp@ietf.org" Subject: Re: [openpgp] Regulation of algo deprecation 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, 04 Nov 2015 08:31:29 -0000 On Wed, 4 Nov 2015 01:00, azet@azet.org said: > So my impression is that GnuPG / OpenPGP current support far to many > possible algorithm choices. We should really limit that. For novice Right. FWIW, I had a meeting in 2000 with PRZ and Jon Callas at the AES conference in Rome where Phil begged us to limit the number of supported algorithms. Nevertheless we added Twofish (which was a high ranked AES candidate then) anyway due to the need for 128 bit block cipher and later we added Camellia for political reasons. > CFRG recently recommended Curve25519 (or whatever nomenclature is > currently en vouge), so why bother with Brainpool at all? I took Brainpool merely as an example. These curves are not defined by an RFC but implementations may add them using an OID. Well, this OID thing is somewhat questionable but then we also do not specify an upper limit for RSA key sizes or require the support for certain key sizes. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Nov 4 02:31:23 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 22CB01B2CEB for ; Wed, 4 Nov 2015 02:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 neyORxvBrIBw for ; Wed, 4 Nov 2015 02:31:20 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 A818D1A1BB3 for ; Wed, 4 Nov 2015 02:31:19 -0800 (PST) Received: by wmll128 with SMTP id l128so110167362wml.0 for ; Wed, 04 Nov 2015 02:31:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=1YioXrBhe/CoUIjNmhAVzYvuSxQtL+iibZoKs4XpP+o=; b=GV9Rp8D1rRgAw3dvg6aHmhZWWdLRqMFK3TKpUxJH4tE6ZSQIMCOiyg2xzkwmR7H20K KsT1wZD2E9wStdUjC5TfkszZ0T+4XYmaIp2MpaJCY5kdz5W0bVQS8znMCSuTwxs6lGhb wHEHO/Si7SfMuSUIq6asHwrCs2wGY4uF+BT2A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=1YioXrBhe/CoUIjNmhAVzYvuSxQtL+iibZoKs4XpP+o=; b=OmCwaqhfThAJMaTlMobcpqKpSTR1IOaQv4NdgO9GNE1viWzuazFiGvNqo+aBYvtkt9 eLtf9MmoZhMTjm2zVP1PBJ4uuhhQtahtv+7YuvtMIz+lFf3qEfNklLShaX/4+Khvkc2l DcLe2XNocmwsY0tDVw7t48aO7ibXdJKXyomAHy7tAP2e+IEIXnXoC2ZAbrkM43pT2PMW RUJbX9SZU7yYxbzAAGUydmCcxyUcCiQtaVU4l3bKBCbW3D/7jG9OuUfNjEkuz1x1ZIJo gOiSxFclipoqK2DOABgBsfAe3uOxuL/rgZ9NSZd9gRFpMICEN4iTOfsTmIYce+p1xvvK a/uQ== X-Gm-Message-State: ALoCoQl+J8PTXQwZTdoiR/k49ZBsT1HDmZ41qxfJA/bGRKHl7AtRI4gX/g4BofzUukIErvTdjGJO X-Received: by 10.28.174.130 with SMTP id x124mr2618973wme.12.1446633078034; Wed, 04 Nov 2015 02:31:18 -0800 (PST) Received: from [10.0.0.112] (chello080108049181.14.11.vie.surfer.at. [80.108.49.181]) by smtp.gmail.com with ESMTPSA id bo7sm811812wjb.46.2015.11.04.02.31.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 Nov 2015 02:31:17 -0800 (PST) Message-ID: <5639DE71.8060209@azet.org> Date: Wed, 04 Nov 2015 11:31:13 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "brian m. carlson" References: <20151104010122.GA3896@vauxhall.crustytoothpaste.net> <56395F1A.4060609@azet.org> <20151104020752.GB3896@vauxhall.crustytoothpaste.net> In-Reply-To: <20151104020752.GB3896@vauxhall.crustytoothpaste.net> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigAE59C1A3AB6D81AF75B94C74" Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] DRAFT minutes for OpenPGP at IETF 94 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, 04 Nov 2015 10:31:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAE59C1A3AB6D81AF75B94C74 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Brian, brian m. carlson wrote: > I suspect this is probably sufficient for Debian's purposes, although I= > of course can't speak on their behalf. Whether it is suitable for Red > Hat or other organizations with strict patent policies, I don't know. Not sure either. Probably best to ask them? >> Another one exists for non-military software implementations: >> http://web.cs.ucdavis.edu/~rogaway/ocb/license2.pdf >=20 > Clearly this is not suitable for Debian's purposes, as they prohibit > restrictions on fields of endeavor. I know. I signed the Debian social contract a while ago as well. This was just for reference - I'm not sure that license is particularly useful to anyone. > [0] By "patented algorithms," I mean those that don't grant a flat > royalty-free license. SHA-2 is patented, but available under such a > royalty-free license. The only problem I currently see is with commercial, military software or hardware implementations. I'm not sure that is relevant to any open-source project though. Would be interesting to hear Fedora/RedHat people comment on this. Aaron --------------enigAE59C1A3AB6D81AF75B94C74 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWOd5yAAoJEOTbZJL9ubXVhCAQAOfGE4FvOP45k2xRtQSV9yL7 fNKI7lssDlllhtyyzeShEm+m1lj96Kn3BKgjgyQp958nN69L1nn4OzhznYrEumtH l6Y8Fo86BjeQ5EhbnUXw5qlLy51qGr+lB6Id6Zc3zfGoJKRrJ9FiYiuwFk85mUGP Y0zPe1KjnjH1RyT2M6kguem/q6w4fF09MAIFI0GobFAK2ZETiRkA10jFvCxFiIhI XoucdIpPqqqMo4jqPxtGqZOWJhYPElMJSpRCW1xBOhzbWlnpQYu/oOAcBiRnJkBL bSZgqs8rKOiNAWAciuLQmpKovoyCqiYooicWv9s0X9TM7f84pRA8X1dOG3dSDq6v ycVAOOEU6G685grAtZRFXD2+VtfHc5QEaVyVo9JZc2EzWZ9sA+2/gziICIEuvs87 FRWh4/llOnYBMfPexl7tMcqD+WVZXsu7GEUjqjTfc27GJxh7R1zAtsYFbiw4BYJQ d/I/FlhkrYV8SxiMVxuh6hONCJq7h383c5fMlIWEsgLb3j35iBz8lpeLLc5il6yM S8t+gSb8s06etCCw8fFTuUn7nnZIX77/epM64/TWlX/5eJ+56TekqV8d6YGnkZIL NXUgvIbBfiTd1w+2zOQtMpuH/oQXxlgs2OW+6sNJZrIUwOLwI/7PXpGCnd2gS1ZO QKFh3lYJz/B1t71EXj5V =tmkj -----END PGP SIGNATURE----- --------------enigAE59C1A3AB6D81AF75B94C74-- From nobody Wed Nov 4 02:51: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 7E2FE1B2D0E for ; Wed, 4 Nov 2015 02:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 5ERw-G8JUswQ for ; Wed, 4 Nov 2015 02:51:35 -0800 (PST) Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA821B2D0C for ; Wed, 4 Nov 2015 02:51:35 -0800 (PST) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id C34EE4012E6D1; Wed, 4 Nov 2015 02:51:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=futureinfosec.com; h=from :to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding; s= futureinfosec.com; bh=ERi/E+dDy2DlFG8gGrq8XKBGjBQ=; b=hgwBwVXw3N 5jqlf3YjbCdyStbuE/7YKJb8JP1/+f0mBPMMvUAICrwjnW1Ry3jlLiTRYAydWCeT 67nz5fU7O+9vNwwJckC8Ftr1IF9MvuIBwh2jh/g5ywQIIgbOIpFTAxyem5mu/Fqe TvsABNbxhad5x3SU2RGx5yszfizBWliFU= Received: from amtpw5302w8p (dhcp-30-45.meeting.ietf94.jp [133.93.30.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: stan@futureinfosec.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id A5AB54012E6CD; Wed, 4 Nov 2015 02:51:33 -0800 (PST) From: "Stan Borinski" To: "'Werner Koch'" , "'Nils Durner'" References: <563931B6.9050107@googlemail.com> <87bnbauqmu.fsf@vigenere.g10code.de> In-Reply-To: <87bnbauqmu.fsf@vigenere.g10code.de> Date: Wed, 4 Nov 2015 05:51:37 -0500 Message-ID: <011d01d116ee$c96f7f10$5c4e7d30$@futureinfosec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQL7Chs280Ho1Y5b18pV4ZRAscJo7wIOX+AHnCdFQ9A= Content-Language: en-us Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Regulation of algo deprecation 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, 04 Nov 2015 10:51:36 -0000 On Wednesday, November 4, 2015 at 3:16 AM, Werner Koch wrote: > To: Nils Durner > Cc: openpgp@ietf.org > Subject: Re: [openpgp] Regulation of algo deprecation > > On Tue, 3 Nov 2015 23:14, ndurner@googlemail.com said: > > > only Brainpool curves could be used: I don't see why. The 2014 version > > of aforementioned catalog[0], as well as the 2015 draft (dated > > 28.10.2014), merely recommend Brainpool, but don't require it. For the > > That is just one catalog but there are others. For the German VS-NfD (restricted > level) other rules apply. And the Russians have a different catalog, as do the > Japanese, and the Koreans, ... This was my general thought when I read Nils' e-mail advocating using regulation as guidance for deprecation. I'm surprised he wasn't flooded with responses. I don't like this for two main reasons: 1. As Werner alludes to, we'd have to research the regulations of many different countries. And which countries are we talking about?... do we have to come to agreement that we follow the guidelines/catalogs of only a subset of countries? This all seems very problematic. 2. If we're just going to rubber-stamp what Germany's Bundesnetzagentur, USA's NSA/NIST, and others are recommending, then what's the point of *us* going through the exercise of figuring out which algorithms that we recommend or require to be deprecated? Perhaps I'm taking Nil's use of the word "guidance" too strongly. My view is that our value as an IETF workgroup comes from an objective view of the current state, where we judge the security of cryptographic algorithms based on their technical and operational merits, unbiased by the view of any governments or their standards bodies. Regards, Stan Borinski From nobody Wed Nov 4 03:51: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 DCBD71B2DC8 for ; Wed, 4 Nov 2015 03:51:22 -0800 (PST) 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 rbspds5g3J9x for ; Wed, 4 Nov 2015 03:51:20 -0800 (PST) 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 89EBA1B2BFB for ; Wed, 4 Nov 2015 03:51:20 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Ztwb0-0001lG-Hc for ; Wed, 04 Nov 2015 12:51:18 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZtwVK-0000Qi-0P for ; Wed, 04 Nov 2015 12:45:26 +0100 From: Werner Koch To: openpgp@ietf.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: openpgp@ietf.org Date: Wed, 04 Nov 2015 12:45:25 +0100 Message-ID: <87lhaet2cq.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: Subject: [openpgp] First 4880bis drafts 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, 04 Nov 2015 11:51:23 -0000 Hi from your freshly appointed RFC-4880bis editor. I talked to dkg on how to get started and we agreed on taking my existing RFC-4880 version which I converted to Pandoc/Markdown format some time ago. Meanwhile I published two I-D based on this: https://tools.ietf.org/id/draft-koch-openpgp-rfc4880bis-00.txt This is RFC-4880 with errata 2270, 2271, 2242, 3298 applied and some editorial notes: { This is work in progress to update OpenPGP. Editorial notes are enclosed in curly braces. The section numbers from RFC4880 are also indicated in curly braces. } The second I-D is: https://tools.ietf.org/id/draft-koch-openpgp-rfc4880bis-01.txt With these additional changes (cf. Appendix A): o Added Camellia cipher from RFC 5581. o Incorporated RFC 6637 (ECC for OpenPGP) I also fixed up a couple of formatting issues in case you wonder about the longer diff betwee -00 and -01. I temporary moved the authors of RFC-4880 to an appendix to not annoy them with confirmation mails. I don't know how this is usually handled; thus please drop me a note if I shall move you to the authors section now and not only in later I-Ds. The diff between RFC-4880 and -00 can be viewed here: https://tools.ietf.org/rfcdiff?url2=draft-koch-openpgp-rfc4880bis-00.txt and the diff between -00 and -01 here: https://tools.ietf.org/rfcdiff?url2=draft-koch-openpgp-rfc4880bis-01.txt Please check them so we can get a stable base for our future work. Shalom-Salam, Werner p.s. To get the source you may run git clone git://git.gnupg.org/people/wk/rfc4880bis.git or follow at http://git.gnupg.org/cgi-bin/gitweb.cgi?p=people/wk/rfc4880bis.git In case anyone sees a problem hosting that under a gnupg address, dkg will probably be able to publish his repo. In any case the plan is to mail diffs. The above should be considered a clone of my working copy. To build a new draft you would run pandoc2rfc abstract.mkd middle.mkd back.mkd pandoc2rfc is availabe via https://tools.ietf.org -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Nov 4 06:31:59 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 4775C1B3083 for ; Wed, 4 Nov 2015 06:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 tTfC6gy5eJc1 for ; Wed, 4 Nov 2015 06:31:56 -0800 (PST) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB0861B3084 for ; Wed, 4 Nov 2015 06:31:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 27E13E2038; Wed, 4 Nov 2015 09:31:53 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 04267-06; Wed, 4 Nov 2015 09:31:50 -0500 (EST) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 1518CE2035; Wed, 4 Nov 2015 09:31:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1446647510; bh=N5Eb+pY8+47uviBjUOv+jSUJhTRTOW3oTovjw8VxiBo=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=GqsIJIp4vqb/fu0+KkT9L26LsJB5LJ55xnmeBxTbUQuHZBBiIP0gk24Bs6Q+DzhoF vW9DTD0PVRokQztD7bNJvjdzknVz3zB3JjtqvwtMoL0GIoI/DlDoX7ccx+P9L3YT8z JIyuFo5WHKZVDq02+t46oaQuV2H+KMrVhfMDfmlk= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id tA4EVnEY016400; Wed, 4 Nov 2015 09:31:49 -0500 From: Derek Atkins To: "Neal H. Walfield" References: <87io5j764u.wl-neal@walfield.org> <87h9l36tf1.wl-neal@walfield.org> Date: Wed, 04 Nov 2015 09:31:49 -0500 In-Reply-To: <87h9l36tf1.wl-neal@walfield.org> (Neal H. Walfield's message of "Tue, 03 Nov 2015 15:37:06 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Reducing the meta-data leak 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, 04 Nov 2015 14:31:58 -0000 "Neal H. Walfield" writes: > Bryan Ford proposed getting rid of all unencrypted meta-data. In > particular, he wanted to get rid of the recipients / number of > recipients. I'm not at all sure how you would remove the number of recipients; you still need N encrypted session key packets. Therefore anyone reading the message can count the ESKs. > There are some practical difficulties with this approach, > which I mentioned above. > > My proposal is a blue sky idea to avoid having to try to decrypt a > message with every secret key while (hopefully) making it more > difficult to get at the list of recipients. Is it really worth the overhead? > Neal -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Nov 4 09:34:43 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 91F431A036F for ; Wed, 4 Nov 2015 09:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 MbZz16Blh8wU for ; Wed, 4 Nov 2015 09:34:40 -0800 (PST) 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 C1A031A0371 for ; Wed, 4 Nov 2015 09:34:39 -0800 (PST) Received: by widen16 with SMTP id en16so604517wid.1 for ; Wed, 04 Nov 2015 09:34:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=aZ5SHCoaw3WZqyrzy4K1oa4CsrmEUMJHM3ZxOT1TXmo=; b=CO7JpJbuI6PSDeX91+gCq3qhtkF2G0rkX/MPEScwnUgyTJUgggSSHpjQYUKzd47DJu w7s70pduLSct4ZY94LdODEJmSPznaklXLiMHRsdKdPdMrtw5UTit4mNaBv9zQFOzPvyU 9W2f6xHgbFp6ABNA45VJifF/ncT+zz8PuCqE0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=aZ5SHCoaw3WZqyrzy4K1oa4CsrmEUMJHM3ZxOT1TXmo=; b=M0zoIYDW8a4OyJlXW40zPpc5RpzF4CdV/b8weAr6q7cVE6+OrktCQluX5dI19PMTj6 xofx+kEVZUw1eNYQb4QzKQxMIBibESdkguuIzYxCxFdpWLjA10tLPxUDulCeF2KAgp8y sgkn2U/SCjxCdGV0CNr3EdoJcx212gwfpLfWDe0av+04Ie1fN6dEArfZC9rmNNTRVw7c EcIP+8dVgpdCLbimKLeWepPnbvf/ClyRF91rp6ZLJXmUuEq5gXDLz9Y0dSsmf8jC6V5d 7Fn8Ops1AgJ/yGbLcxhToXEdE9fUc8spG6ws1bgbt9BlLV1ZBjeC/eB3VwSCzaNFDclf kmZw== X-Gm-Message-State: ALoCoQkczX15+JZT2tu3PowQ0mqI4hUKZzFGHrNZoVuK2RZ6Ek+FzrSjxlE+o30fc1OqzAT3+JwX X-Received: by 10.194.92.138 with SMTP id cm10mr3410501wjb.6.1446658478244; Wed, 04 Nov 2015 09:34:38 -0800 (PST) Received: from typhoon.azet.org (chello080108049181.14.11.vie.surfer.at. [80.108.49.181]) by smtp.gmail.com with ESMTPSA id z4sm2635395wjz.29.2015.11.04.09.34.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Nov 2015 09:34:37 -0800 (PST) Date: Wed, 4 Nov 2015 18:34:33 +0100 From: Aaron Zauner To: Werner Koch Message-ID: <20151104182705.86af2e43c8@baae13974eb4556> References: <87lhaet2cq.fsf@vigenere.g10code.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <87lhaet2cq.fsf@vigenere.g10code.de> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] First 4880bis drafts 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, 04 Nov 2015 17:34:41 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Werner Koch [04/11/2015 12:51:25] wrote: >=20 > o Added Camellia cipher from RFC 5581. Hrm. I'm against this. CAMELLIA is going to be deprecated in e.g. TLS because barely anyone uses it. I'm explicitly excluding anything other than AES128 or 256 from my GnuPG config currently, I haven't noticed any breakage in almost a year: https://github.com/azet/dotfiles/blob/master/.gnupg/gpg.conf If we're all going to choose our favorite cipher, without real arguments as to new security features or performance, we're going to end up like this: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml The ECC addition makes sense, but I'd also limit the number of possible curves to a few vetted ones instead of verbatim including all those NIST curves. For example: do we want to keep P256? Or are we going with a higher 'security level' alltogether? I consider this cruft that should be removed. Why not just use Curve25519 and Goldilocks? (Again; sorry if that has already been discussed, I've been very busy the last couple of months and didn't follow every e-mail thread, though I tired to look these topics up by searching them) Aaron --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWOkGnAAoJEOTbZJL9ubXV7swP/RrVLi9WLuN9lFZEoDctlsMD tHyAAn5zAvNazM3+C3W1ocz47Oetl7ll+jFb9fUcOCS/baQKyqGZg7fjwk2bcGNy KWyq1VnGm1DdfB2+9Thmuc4ATylttKON2osKzdtcElzulzm/I7sE2aJxNgjSEADb uQwixde+ahs1B5QP7+WUtBiUuZCggVG6W2Ag/i6Nxi5zIdgreP5cLcMfRnfaFvPt FTPAngHeQua3PLLgUFl7VrfqStyj1FTE2xkLJOyFuLEekJLOWxa1wwRVUZUBJpiZ TQa3l2ZpWRYnQ7u5vSTNR0Bm3uQbMMNJLgn3P82IcddBe5fNXFYph4z/9rDMMMrc MlGuOAnbtoItICeIApgqh5yR2iNNDO1p5x2XXetj2ykdjEa/r+2u3AUynv5iJO4U JHs+Rlnfm9jplKMOYsDwz6xRzDW92JJzW/bYSMzeM8hJUmvj7jHL6kBgTy2D4DPK 7ba4IAk7B63xUggWXueM15HTt6M8rHBW3FwpCZzalU2MxBXv9DVemHlDwCDkUUC0 0QeHZO7WCkAx7cuHhBvQhi6n7pa/NMHfdcGvHS3yl2wJGUX2NKsCvYTdGTvH8ouc LBxUhZRSMJ+q5fK/UB1pDYCkPBGbHx+EFxQVTt2cUCo1qCh0/ufi9hdJQDoPYVF1 SsKQkN380R566G4FmMte =ZHdv -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From nobody Wed Nov 4 11:16: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 73A541A90B4 for ; Wed, 4 Nov 2015 11:16:23 -0800 (PST) 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 S2k7ub-AlGXe for ; Wed, 4 Nov 2015 11:16:21 -0800 (PST) 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 9EDAE1A88ED for ; Wed, 4 Nov 2015 11:16:21 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Zu3Xf-0004pj-1p for ; Wed, 04 Nov 2015 20:16:19 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Zu3VZ-0001WO-4E; Wed, 04 Nov 2015 20:14:09 +0100 From: Werner Koch To: Aaron Zauner References: <87lhaet2cq.fsf@vigenere.g10code.de> <20151104182705.86af2e43c8@baae13974eb4556> 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: Aaron Zauner , openpgp@ietf.org Date: Wed, 04 Nov 2015 20:14:08 +0100 In-Reply-To: <20151104182705.86af2e43c8@baae13974eb4556> (Aaron Zauner's message of "Wed, 4 Nov 2015 18:34:33 +0100") Message-ID: <87bnb9tw5b.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] First 4880bis drafts 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, 04 Nov 2015 19:16:23 -0000 On Wed, 4 Nov 2015 18:34, azet@azet.org said: > Hrm. I'm against this. CAMELLIA is going to be deprecated in e.g. You may be against it but it is a matter of fact that CAMELLIA is an officially assigned OpenPGP cipher algorithm for 6 years. We may latter decide to deprecate certain algorithms but that is not a question right now. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Nov 4 15:53:39 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 81D5B1A1A6B for ; Wed, 4 Nov 2015 15:53:37 -0800 (PST) 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 4hAMgwwNVlt9 for ; Wed, 4 Nov 2015 15:53:36 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 88BA41A0856 for ; Wed, 4 Nov 2015 15:53:36 -0800 (PST) Received: from fifthhorseman.net (y125068.ppp.asahi-net.or.jp [118.243.125.68]) by che.mayfirst.org (Postfix) with ESMTPSA id D9709F984; Wed, 4 Nov 2015 18:53:34 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 19E9B1FFEF; Thu, 5 Nov 2015 08:53:33 +0900 (JST) From: Daniel Kahn Gillmor To: Werner Koch , Aaron Zauner In-Reply-To: <87bnb9tw5b.fsf@vigenere.g10code.de> References: <87lhaet2cq.fsf@vigenere.g10code.de> <20151104182705.86af2e43c8@baae13974eb4556> <87bnb9tw5b.fsf@vigenere.g10code.de> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Thu, 05 Nov 2015 08:53:33 +0900 Message-ID: <87611hnwxu.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] First 4880bis drafts 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, 04 Nov 2015 23:53:37 -0000 On Thu 2015-11-05 04:14:08 +0900, Werner Koch wrote: > On Wed, 4 Nov 2015 18:34, azet@azet.org said: > >> Hrm. I'm against this. CAMELLIA is going to be deprecated in e.g. > > You may be against it but it is a matter of fact that CAMELLIA is an > officially assigned OpenPGP cipher algorithm for 6 years. As discussed in the meeting tuesday, deprecation is a tricky subject for formats with stored data (as distinguished from on-the-wire network traffic). people have archives of encrypted data that may still use this cipher. > We may latter decide to deprecate certain algorithms but that is not a > question right now. The sense of the room in Yokohama was to deprecate as much as possible, and encourage a limited, sensible set of algorithms for message creation and signing. But sensible implementations will likely continue to allow decryption of these ciphers for years to come. regards, --dkg From nobody Wed Nov 4 17:31: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 2DBBB1A870A for ; Wed, 4 Nov 2015 17:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_12=0.6, SPF_FAIL=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 6J5dYqonuaKb for ; Wed, 4 Nov 2015 17:30:56 -0800 (PST) Received: from castro.crustytoothpaste.net (sandals-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:79::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E79261B35A8 for ; Wed, 4 Nov 2015 17:30:55 -0800 (PST) Received: from vauxhall.crustytoothpaste.net (unknown [IPv6:2001:470:1f05:79:f2de:f1ff:feb8:36fd]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by castro.crustytoothpaste.net (Postfix) with ESMTPSA id D493D28094; Thu, 5 Nov 2015 01:30:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=crustytoothpaste.net; s=default; t=1446687054; bh=doxFep1LlNOBQRr1jjykfYVaqH7HkP1bxyRiB8Ab8MM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=wYBKglvLmsE3ub2hoqBUcXw1M+VTQMX+AMNzHG8IW8rb6RxqoUJQ8VoHlCBccmBIP iBcz303IuIErwqA5LDD9zpEonY/K1/5NSn/0YThG1ccawrvVxWNbEk7XlzPX7vBfpd heSybqpULgATQw7rgNb5+vMQAA3oqOV2lJhDRisSdPmVJH1MNYRNQbv1l1j8uF7Q73 1ZuS/mvKPj77Ia/ktWABOfRjf96lehGNscA/pX2o7RuwtC/t1ChL/HJGgJz0LQGtrm lMNPLlCX3a/0Q2qHK0ExThjp0IcbTNc+girmuJrkDQ9n7kdL9SSt6BpJ3BJ/PmAmHi NIeh2BWfDPuOZe8sePi4RD4Q4UQfzACxvUfWiwImNYFVbpc7o4UcW4NR6pmdfh1FV2 /OFWrVAkC7YH7LqRdvNhTo9fViEeheALNGYCmcl1XwEGIZe++ttpKcEOxCbRQ0057e RK8ui5Z2r4miDDulbmzDK4Ix1T9s9MFAQ5FFBIabkYDdesOPMcO Date: Thu, 5 Nov 2015 01:30:51 +0000 From: "brian m. carlson" To: Aaron Zauner Message-ID: <20151105013051.GD3896@vauxhall.crustytoothpaste.net> References: <87lhaet2cq.fsf@vigenere.g10code.de> <20151104182705.86af2e43c8@baae13974eb4556> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lc9FT7cWel8HagAv" Content-Disposition: inline In-Reply-To: <20151104182705.86af2e43c8@baae13974eb4556> X-Machine: Running on vauxhall using GNU/Linux on x86_64 (Linux kernel 4.2.0-1-amd64) User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: Werner Koch , openpgp@ietf.org Subject: Re: [openpgp] First 4880bis drafts 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, 05 Nov 2015 01:30:57 -0000 --lc9FT7cWel8HagAv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 04, 2015 at 06:34:33PM +0100, Aaron Zauner wrote: > * Werner Koch [04/11/2015 12:51:25] wrote: > >=20 > > o Added Camellia cipher from RFC 5581. >=20 > Hrm. I'm against this. CAMELLIA is going to be deprecated in e.g. > TLS because barely anyone uses it. I'm explicitly excluding anything > other than AES128 or 256 from my GnuPG config currently, I haven't > noticed any breakage in almost a year: > https://github.com/azet/dotfiles/blob/master/.gnupg/gpg.conf As Werner pointed out, Camellia has been around for some time. It's also good to have enough diversity that if someone comes out with a major attack against AES, we're not totally sunk. Camellia is a Feistel cipher, while AES is a substitution-permutation network, which means that attacks are unlikely to work against both. Currently, if AES were to be broken, TLS implementations would not interoperate at a 128-bit or higher security level. OpenPGP would continue to function without much thought, which is a major asset. I'm for deprecating algorithms which provide less than a 128-bit security level, such as SHA-1 and 3DES. > The ECC addition makes sense, but I'd also limit the number of > possible curves to a few vetted ones instead of verbatim including > all those NIST curves. For example: do we want to keep P256? Or are > we going with a higher 'security level' alltogether? I consider this > cruft that should be removed. Why not just use Curve25519 and > Goldilocks? I believe Google's End-to-End is using the NIST curves, and there are already keys using these curves. I think Curve25519 and Goldilocks would be valuable due to their rigidity and the CFRG endorsement. --=20 brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 --lc9FT7cWel8HagAv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.9 (GNU/Linux) iQIcBAEBCgAGBQJWOrFLAAoJEL9TXYEfUvaLnfsP/ivrUbKRRicPsnjt5rf1vEz4 OiwEQfisg2DSZgiA7/sgzFyFJgtcXHyvm3ooukAapYH8tWTFCNsZGdTfOhI3vhA3 0qLv2F9kDDj17EiWHQQ/hWWjCKhApecfttsQ9UGrYLcWEkZ9g40ZnA/DsfIKjjXJ UAi9yWy9fmE9fBJVK2O+Wr7vyT5OkZMVoE7y7p6Ua8lC/5CUXZU4V0xFAhCicjn0 2lKR+DEBbY1ZSQMXYWz9hUtymOja7J7eKlrT3G12ZeqFX6J7rr4jZLF+IPbzp9LJ kPNCi679PIa54cuXPcN9bh9gTdaJX16hVv5wa8f88gXTULXguetJiAQ3PdlsVU/d I/YCUE2nqi4KTSqbCiomEdIb2+Y4z3Rapcq4EOTz8Yi1oVSWt4A2SH8xUnbzI1M7 hSAS86cPm0a0HoB/oThrWsFeD+50iu4piyhifO6JjKLSdNMwqw20SnVfC/HMacg4 LV0HVqUCcx2xxUW63C1XjM1f6+XF6YrYXEqd/5Jn3289gjzXXZ8BHYxw6q6namJM a5jhSQ04hbnnFb7U/jGGXOhvhZ7OGWH11eNFcGMHZ9f7Euf0B8Eh4el/kExzUgUh PLB7m4TATS44puQXa4g++wRQJpITmNduCF5l0k0prnJ/uft5w7s4Ks5CAXy1j2nA 8wkRZVSdfJR+/l/wvmQH =Hk7M -----END PGP SIGNATURE----- --lc9FT7cWel8HagAv-- From nobody Thu Nov 5 00:25: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 ED7231A8932 for ; Thu, 5 Nov 2015 00:25:36 -0800 (PST) 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 CCk867kkxAsF for ; Thu, 5 Nov 2015 00:25:34 -0800 (PST) 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 5F8591A8901 for ; Thu, 5 Nov 2015 00:25:34 -0800 (PST) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tA58P3EH015101 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 5 Nov 2015 09:25:04 +0100 From: Simon Josefsson To: Stephen Farrell References: <5623AA95.4060903@googlemail.com> <874mh3q3ol.fsf@alice.fifthhorseman.net> <56385818.2000606@googlemail.com> <20151103092006.3cd3e900@latte.josefsson.org> <563955F4.9030607@cs.tcd.ie> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151105:kathleen.moriarty.ietf@gmail.com::jujA4wA8GMJKPjSR:0k4 X-Hashcash: 1:22:151105:alex.biryukov@uni.lu::pO4yF1AJPn4qz0z5:0HtC X-Hashcash: 1:22:151105:openpgp@ietf.org::ivfwPuqV3HSk4zmy:0v9y X-Hashcash: 1:22:151105:ndurner@googlemail.com::/b8jTOTqA3tpPFLb:4vzP X-Hashcash: 1:22:151105:stephen.farrell@cs.tcd.ie::7KZE9QSe/6K7L3yR:BrIV X-Hashcash: 1:22:151105:khovratovich@gmail.com::5nRu3rANdS2oOnRA:G2bk X-Hashcash: 1:22:151105:dumitru-daniel.dinu@uni.lu::ri/FQlDjaSALLSKZ:JVOk X-Hashcash: 1:22:151105:joe@cdt.org::ADGibwOERHHLz+cc:ksHB Date: Thu, 05 Nov 2015 09:25:02 +0100 In-Reply-To: <563955F4.9030607@cs.tcd.ie> (Stephen Farrell's message of "Wed, 4 Nov 2015 00:48:52 +0000") Message-ID: <87mvus26qp.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: Nils Durner , Alex Biryukov , "openpgp@ietf.org" , Dmitry Khovratovich , Daniel Dinu , Kathleen Moriarty , Joseph Lorenzo Hall Subject: Re: [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: Thu, 05 Nov 2015 08:25:37 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable We have now pushed out a -00 strawman on Argon2 in ID form: https://tools.ietf.org/html/draft-josefsson-argon2-00 I'm not happy with the explanation of the H' and G functions, and the permutation P (from BLAKE2b) and the indexing section are missing. Reference code in a higher-level language like python would be useful. If those things, and an ASN.1 schema is added, I believe the document would be good to go. We need to have an IETF discussion whether we are interested in the Argon2d non-side-channel safe variant. The Argon2 paper implies that the Argon2i side-channel safe variant is for "dangerous settings" where you need side-channel safety. For Internet use I believe we have already passed the point where we can ignore side-channel concerns, since they have been used in several successful attacks already. This could be resolved in the security considerations, but I'm concerned about giving people too much rope here. /Simon Stephen Farrell writes: > Hiya, > > One way to handle this might be to add the winners as > co-authors on the Internet-draft. In that case, the > draft boilerplate text says that you're following the IETF > IPR rules and hence would have filed an IPR declaration > if one was needed. And if none is needed, we'd be done. > > I'm sure we can figure other options but the above would > be easiest from the IETF point of view. > > Cheers, > S. > > On 03/11/15 11:56, Joseph Lorenzo Hall wrote: >> Congratulations btw on winning the competition! >>=20 >> Kathleen and Stephen can confirm, but I believe you don't have to do >> anything in terms of adding any language in this case (no patent >> issued/sought, patent pending, etc.). When/if the document is adopted by >> the working group, the chair will request any disclosures. >>=20 >>=20 >>=20 >> On Tuesday, November 3, 2015, Alex Biryukov wrote: >>=20 >>> Hi all, >>> >>> We were not intending to patent it, so we can add a sentence about it. >>> Suggestions of lawyer-happy phrases are welcome. >>> >>> Alex >>> >>> On Tue, Nov 3, 2015 at 10:47 AM, Joseph Lorenzo Hall >> > wrote: >>> >>>> At IETF94 one question that came up in trying to move quickly to >>>> support Argon2 is the potential IPR that might be in Argon2. The code >>>> available now [1] is CC0 which, AFAICT, doesn't have any patent grant >>>> or implication for patents, etc., meaning the authors could still >>>> claim something, precluding it from use without a waiver (or whatever, >>>> IANAL) >>>> >>>> I'll CC the Argon2 authors (on the Argon2 spec [2]) here and see if we >>>> can clarify any potential IPR and whether that might affect using it >>>> in the future in OpenPGP. >>>> >>>> best, Joe >>>> >>>> [1]: https://github.com/p-h-c/phc-winner-argon2 >>>> [2]: https://password-hashing.net/argon2-specs.pdf >>>> >>>> On Tue, Nov 3, 2015 at 5:20 PM, Simon Josefsson >>> > wrote: >>>>> Den Tue, 3 Nov 2015 07:45:44 +0100 >>>>> skrev Re: [openpgp] [PATCH] RFC4880bis: Argon2i: >>>>> >>>>>> Hi Daniel, >>>>>> >>>>>>> If we introduce this as a normative dependency for OpenPGP, though, >>>>>>> we might also want to have an IETF RFC for Argon2. Do you know of >>>>>>> anyone working on such a draft? >>>>>> >>>>>> Simon Josefsson has expressed interest in helping with that. >>>>>> @Simon: are you working on this? >>>>> >>>>> I started on an Argon2 draft but after talking to the Argon2 team we >>>>> decided to wait until Argon2 was finalized. I suppose now is a good >>>>> time to resume that work. I'll put something up on gitlab.com so >>>>> people can review and help. If anyone wants to help, please let me >>>>> know and we'll coordinate something. >>>>> >>>>> /Simon >>>>> >>>>> _______________________________________________ >>>>> openpgp mailing list >>>>> openpgp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/openpgp >>>>> >>>> >>>> >>>> >>>> -- >>>> Joseph Lorenzo Hall >>>> Chief Technologist >>>> Center for Democracy & Technology >>>> 1634 I ST NW STE 1100 >>>> Washington DC 20006-4011 >>>> (p) 202-407-8825 >>>> (f) 202-637-0968 >>>> joe@cdt.org >>>> PGP: https://josephhall.org/gpg-key >>>> fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 >>>> >>> >>> >>> >>> -- >>> --------------------------------- >>> Prof. Dr. Alex Biryukov, >>> FSTC/CSC, University of Luxembourg, >>> 6, rue Richard Coudenhove-Kalergi, >>> L-1359 Luxembourg-Kirchberg >>> LUXEMBOURG >>> Tel: +352 46 66 44 6793 >>> Fax: +352 46 66 44 5500 >>> >>=20 >>=20 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWOxJeAAoJEIYLf7sy+BGdruQIAIuzkKA16xrcaPJ/QBm93Y/y EpzIeVisdWr7mBuR5k/zDYT/yuFf5YBs2TkNNOyoD91JfNFizv4pr+9ZEUI/m/9w dvTcaVyq6ko2N6m8NERwG3jx3QVa2N11S329szTIfhcTP0rmkZUm+nCkz+j93mIX 1YvB8jmW/XNfV6qX0QSb8GOp1zrH6j2aF8jX/KydN1l2ZyDkdriW/QIeYGwLMFj8 X4f1o8utbmuc/7p4Ql5PXPzwvAma67y6tpjViw0q2wEVnMtMRqk5zwXFB5rJFtHz CLGzJk73axRIDAH9bbT8Y8bsmHnb1lMcUYbbpTWQfzjGqmWjuoZFDO961cR13uQ= =FQ2N -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 5 00: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 54A9E1A008A for ; Thu, 5 Nov 2015 00:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_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 Ez4RbLlBuqVw for ; Thu, 5 Nov 2015 00:50:50 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6768A1A00BF for ; Thu, 5 Nov 2015 00:50:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AE086BDF9; Thu, 5 Nov 2015 08:50:47 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUrVdZbnLd1J; Thu, 5 Nov 2015 08:50:43 +0000 (GMT) Received: from [133.93.24.87] (unknown [133.93.24.87]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 27B82BDD0; Thu, 5 Nov 2015 08:50:39 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1446713443; bh=3lb0vtS366mF3ZN9nPAMgb3k4HLuVt7Iky6IodAQXwc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Q4jVldJ6dbrnCmdYE9W9S6dzDSzGYTGlSm2z6b/vfc3/cfugzcM4RlEsHp3BCX0Vs eTq0VsbyJbv7QLiWLd3WRP9h4db5dm6fwjdJHHS+g7nxKvwezPWypXbo+Jw1HJsk/+ 1HYBFQKMZnOurdNwoT57ekcz80/ChgkWsyqwMiTY= To: Dmitry Khovratovich , Simon Josefsson References: <5623AA95.4060903@googlemail.com> <874mh3q3ol.fsf@alice.fifthhorseman.net> <56385818.2000606@googlemail.com> <20151103092006.3cd3e900@latte.josefsson.org> <563955F4.9030607@cs.tcd.ie> <87mvus26qp.fsf@latte.josefsson.org> <1EE8655C-787C-47CB-BFC0-4DD5B1A4300E@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <563B185C.6080108@cs.tcd.ie> Date: Thu, 5 Nov 2015 08:50:36 +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: <1EE8655C-787C-47CB-BFC0-4DD5B1A4300E@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Nils Durner , Alex Biryukov , "openpgp@ietf.org" , Daniel Dinu , Kathleen Moriarty , Joseph Lorenzo Hall Subject: Re: [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: Thu, 05 Nov 2015 08:50:53 -0000 Process-wise, I think the thing to do with this is to handle it as a cfrg draft. (I'll forward this there and as if they wanna adopt it.) Cheers, S On 05/11/15 08:32, Dmitry Khovratovich wrote: > Thank you, Simon! > > I will review your draft and give comments ASAP > > Dmitry > > Sent from my iPad > >> On Nov 5, 2015, at 09:25, Simon Josefsson wrote: >> >> We have now pushed out a -00 strawman on Argon2 in ID form: >> >> https://tools.ietf.org/html/draft-josefsson-argon2-00 >> >> I'm not happy with the explanation of the H' and G functions, and the >> permutation P (from BLAKE2b) and the indexing section are missing. >> Reference code in a higher-level language like python would be useful. >> If those things, and an ASN.1 schema is added, I believe the document >> would be good to go. >> >> We need to have an IETF discussion whether we are interested in the >> Argon2d non-side-channel safe variant. The Argon2 paper implies that >> the Argon2i side-channel safe variant is for "dangerous settings" where >> you need side-channel safety. For Internet use I believe we have >> already passed the point where we can ignore side-channel concerns, >> since they have been used in several successful attacks already. This >> could be resolved in the security considerations, but I'm concerned >> about giving people too much rope here. >> >> /Simon >> >> Stephen Farrell writes: >> >>> Hiya, >>> >>> One way to handle this might be to add the winners as >>> co-authors on the Internet-draft. In that case, the >>> draft boilerplate text says that you're following the IETF >>> IPR rules and hence would have filed an IPR declaration >>> if one was needed. And if none is needed, we'd be done. >>> >>> I'm sure we can figure other options but the above would >>> be easiest from the IETF point of view. >>> >>> Cheers, >>> S. >>> >>>> On 03/11/15 11:56, Joseph Lorenzo Hall wrote: >>>> Congratulations btw on winning the competition! >>>> >>>> Kathleen and Stephen can confirm, but I believe you don't have to do >>>> anything in terms of adding any language in this case (no patent >>>> issued/sought, patent pending, etc.). When/if the document is adopted by >>>> the working group, the chair will request any disclosures. >>>> >>>> >>>> >>>>> On Tuesday, November 3, 2015, Alex Biryukov wrote: >>>>> >>>>> Hi all, >>>>> >>>>> We were not intending to patent it, so we can add a sentence about it. >>>>> Suggestions of lawyer-happy phrases are welcome. >>>>> >>>>> Alex >>>>> >>>>> On Tue, Nov 3, 2015 at 10:47 AM, Joseph Lorenzo Hall >>>> > wrote: >>>>> >>>>>> At IETF94 one question that came up in trying to move quickly to >>>>>> support Argon2 is the potential IPR that might be in Argon2. The code >>>>>> available now [1] is CC0 which, AFAICT, doesn't have any patent grant >>>>>> or implication for patents, etc., meaning the authors could still >>>>>> claim something, precluding it from use without a waiver (or whatever, >>>>>> IANAL) >>>>>> >>>>>> I'll CC the Argon2 authors (on the Argon2 spec [2]) here and see if we >>>>>> can clarify any potential IPR and whether that might affect using it >>>>>> in the future in OpenPGP. >>>>>> >>>>>> best, Joe >>>>>> >>>>>> [1]: https://github.com/p-h-c/phc-winner-argon2 >>>>>> [2]: https://password-hashing.net/argon2-specs.pdf >>>>>> >>>>>> On Tue, Nov 3, 2015 at 5:20 PM, Simon Josefsson >>>>> > wrote: >>>>>>> Den Tue, 3 Nov 2015 07:45:44 +0100 >>>>>>> skrev Re: [openpgp] [PATCH] RFC4880bis: Argon2i: >>>>>>> >>>>>>>> Hi Daniel, >>>>>>>> >>>>>>>>> If we introduce this as a normative dependency for OpenPGP, though, >>>>>>>>> we might also want to have an IETF RFC for Argon2. Do you know of >>>>>>>>> anyone working on such a draft? >>>>>>>> >>>>>>>> Simon Josefsson has expressed interest in helping with that. >>>>>>>> @Simon: are you working on this? >>>>>>> >>>>>>> I started on an Argon2 draft but after talking to the Argon2 team we >>>>>>> decided to wait until Argon2 was finalized. I suppose now is a good >>>>>>> time to resume that work. I'll put something up on gitlab.com so >>>>>>> people can review and help. If anyone wants to help, please let me >>>>>>> know and we'll coordinate something. >>>>>>> >>>>>>> /Simon >>>>>>> >>>>>>> _______________________________________________ >>>>>>> openpgp mailing list >>>>>>> openpgp@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/openpgp >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Joseph Lorenzo Hall >>>>>> Chief Technologist >>>>>> Center for Democracy & Technology >>>>>> 1634 I ST NW STE 1100 >>>>>> Washington DC 20006-4011 >>>>>> (p) 202-407-8825 >>>>>> (f) 202-637-0968 >>>>>> joe@cdt.org >>>>>> PGP: https://josephhall.org/gpg-key >>>>>> fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> --------------------------------- >>>>> Prof. Dr. Alex Biryukov, >>>>> FSTC/CSC, University of Luxembourg, >>>>> 6, rue Richard Coudenhove-Kalergi, >>>>> L-1359 Luxembourg-Kirchberg >>>>> LUXEMBOURG >>>>> Tel: +352 46 66 44 6793 >>>>> Fax: +352 46 66 44 5500 >>>>> >>>> >>>> > From nobody Thu Nov 5 03:06:00 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 93E3E1A0373 for ; Thu, 5 Nov 2015 03:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.949 X-Spam-Level: X-Spam-Status: No, score=0.949 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 a12mDy7QSTgW for ; Thu, 5 Nov 2015 03:05:58 -0800 (PST) Received: from mailout06.t-online.de (mailout06.t-online.de [194.25.134.19]) (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 E60571A0364 for ; Thu, 5 Nov 2015 03:05:57 -0800 (PST) Received: from fwd21.aul.t-online.de (fwd21.aul.t-online.de [172.20.27.66]) by mailout06.t-online.de (Postfix) with SMTP id D0F8E15D6EE; Thu, 5 Nov 2015 12:05:52 +0100 (CET) Received: from [10.0.1.11] (EXloJaZLYhP3pM3Olqhj45QFBIxCWnd1b-afk6pP1dEMkWZ3ngjfoUTJJn5l4CTQqO@[87.79.33.2]) by fwd21.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1ZuIMV-1jYK0G0; Thu, 5 Nov 2015 12:05:47 +0100 References: <5637B5E4.9050107@enigmail.net> To: Derek Atkins From: "nico@enigmail.net" Message-ID: <563B3805.1070204@enigmail.net> Date: Thu, 5 Nov 2015 12:05:41 +0100 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: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ID: EXloJaZLYhP3pM3Olqhj45QFBIxCWnd1b-afk6pP1dEMkWZ3ngjfoUTJJn5l4CTQqO X-TOI-MSGID: 258a7118-e824-4a16-853b-130631d2acf2 Archived-At: Cc: openpgp@ietf.org, gnugp-devel@gnupg.org Subject: Re: [openpgp] 2nd OpenPGP Summit on Dec 5/6 in Zurich X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: nico@enigmail.net List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 11:05:59 -0000 Hi Derek, yes, indeed we are focusing on email exchange with OpenPGP only. The goal is mainly to bring together all the developers/project from email clients (and servers) and to focus on things like header encryption, email validation, PGP/mime versus inline PGP, ... (thus interoperability issues). Hope this helps. Best Nico Am 03.11.2015 um 15:26 schrieb Derek Atkins: > > Hi Nico, > > Just to be clear, this is an "OpenPGP in EMAIL" Summit, not a general > OpenPGP Summit? > > -derek > > "nico@enigmail.net" writes: > -- Nicolai M. Josuttis www.josuttis.de mailto:nico@enigmail.net PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5 From nobody Thu Nov 5 03:33: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 056471ACE85 for ; Thu, 5 Nov 2015 03:33:53 -0800 (PST) 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 duDuND0KTVAa for ; Thu, 5 Nov 2015 03:33:50 -0800 (PST) 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 5B6201ACE81 for ; Thu, 5 Nov 2015 03:33:50 -0800 (PST) Received: from android-d7bdb37305f05cf4 (m90-141-210-239.cust.tele2.se [90.141.210.239]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tA5BXFtK000995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Nov 2015 12:33:21 +0100 User-Agent: K-9 Mail for Android In-Reply-To: References: <5623AA95.4060903@googlemail.com> <874mh3q3ol.fsf@alice.fifthhorseman.net> <56385818.2000606@googlemail.com> <20151103092006.3cd3e900@latte.josefsson.org> <563955F4.9030607@cs.tcd.ie> <87mvus26qp.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Simon Josefsson Date: Thu, 05 Nov 2015 12:31:22 +0100 To: Alex Biryukov Message-ID: X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: Nils Durner , "openpgp@ietf.org" , Dmitry Khovratovich , Daniel Dinu , Kathleen Moriarty , Joseph Lorenzo Hall , Stephen Farrell Subject: Re: [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: Thu, 05 Nov 2015 11:33:53 -0000 There is not a lot of cryptocurrency standardisation going on in the IETF, alas. What do you think about using the term "proof of work" in the title instead? It appears to be the cryptographic property that cryptocurrencies (and other applications!) want from a primitive. I perceive that other PoW-ideas may be standardized in the IETF before currencies are. Have you or anyone provided security reductions for Argon2 btw? Similar to the reductions that are available for Catena. They would help to substantiate any claims in the document that Argon2 is secure for its intended uses. /Simon Alex Biryukov skrev: (5 november 2015 12:07:17 CET) >We discussed it briefly, would it be possible to add "cryptocurrency" >to >the title to cover two main usage areas. Then it would make sense to >keep >both Argon2i and Argon2d in the standard. > >"The memory-hard Argon2 password and cryptocurrency hash function >draft-josefsson-argon2-00 > > >On Thu, Nov 5, 2015 at 9:25 AM, Simon Josefsson >wrote: > >> We have now pushed out a -00 strawman on Argon2 in ID form: >> >> https://tools.ietf.org/html/draft-josefsson-argon2-00 >> >> I'm not happy with the explanation of the H' and G functions, and the >> permutation P (from BLAKE2b) and the indexing section are missing. >> Reference code in a higher-level language like python would be >useful. >> If those things, and an ASN.1 schema is added, I believe the document >> would be good to go. >> >> We need to have an IETF discussion whether we are interested in the >> Argon2d non-side-channel safe variant. The Argon2 paper implies that >> the Argon2i side-channel safe variant is for "dangerous settings" >where >> you need side-channel safety. For Internet use I believe we have >> already passed the point where we can ignore side-channel concerns, >> since they have been used in several successful attacks already. >This >> could be resolved in the security considerations, but I'm concerned >> about giving people too much rope here. >> >> /Simon >> >> Stephen Farrell writes: >> >> > Hiya, >> > >> > One way to handle this might be to add the winners as >> > co-authors on the Internet-draft. In that case, the >> > draft boilerplate text says that you're following the IETF >> > IPR rules and hence would have filed an IPR declaration >> > if one was needed. And if none is needed, we'd be done. >> > >> > I'm sure we can figure other options but the above would >> > be easiest from the IETF point of view. >> > >> > Cheers, >> > S. >> > >> > On 03/11/15 11:56, Joseph Lorenzo Hall wrote: >> >> Congratulations btw on winning the competition! >> >> >> >> Kathleen and Stephen can confirm, but I believe you don't have to >do >> >> anything in terms of adding any language in this case (no patent >> >> issued/sought, patent pending, etc.). When/if the document is >adopted by >> >> the working group, the chair will request any disclosures. >> >> >> >> >> >> >> >> On Tuesday, November 3, 2015, Alex Biryukov >> wrote: >> >> >> >>> Hi all, >> >>> >> >>> We were not intending to patent it, so we can add a sentence >about it. >> >>> Suggestions of lawyer-happy phrases are welcome. >> >>> >> >>> Alex >> >>> >> >>> On Tue, Nov 3, 2015 at 10:47 AM, Joseph Lorenzo Hall > >>> > wrote: >> >>> >> >>>> At IETF94 one question that came up in trying to move quickly to >> >>>> support Argon2 is the potential IPR that might be in Argon2. The >code >> >>>> available now [1] is CC0 which, AFAICT, doesn't have any patent >grant >> >>>> or implication for patents, etc., meaning the authors could >still >> >>>> claim something, precluding it from use without a waiver (or >whatever, >> >>>> IANAL) >> >>>> >> >>>> I'll CC the Argon2 authors (on the Argon2 spec [2]) here and see >if we >> >>>> can clarify any potential IPR and whether that might affect >using it >> >>>> in the future in OpenPGP. >> >>>> >> >>>> best, Joe >> >>>> >> >>>> [1]: https://github.com/p-h-c/phc-winner-argon2 >> >>>> [2]: https://password-hashing.net/argon2-specs.pdf >> >>>> >> >>>> On Tue, Nov 3, 2015 at 5:20 PM, Simon Josefsson >> >>>> > wrote: >> >>>>> Den Tue, 3 Nov 2015 07:45:44 +0100 >> >>>>> skrev Re: [openpgp] [PATCH] RFC4880bis: Argon2i: >> >>>>> >> >>>>>> Hi Daniel, >> >>>>>> >> >>>>>>> If we introduce this as a normative dependency for OpenPGP, >though, >> >>>>>>> we might also want to have an IETF RFC for Argon2. Do you >know of >> >>>>>>> anyone working on such a draft? >> >>>>>> >> >>>>>> Simon Josefsson has expressed interest in helping with that. >> >>>>>> @Simon: are you working on this? >> >>>>> >> >>>>> I started on an Argon2 draft but after talking to the Argon2 >team we >> >>>>> decided to wait until Argon2 was finalized. I suppose now is a >good >> >>>>> time to resume that work. I'll put something up on gitlab.com >so >> >>>>> people can review and help. If anyone wants to help, please >let me >> >>>>> know and we'll coordinate something. >> >>>>> >> >>>>> /Simon >> >>>>> >> >>>>> _______________________________________________ >> >>>>> openpgp mailing list >> >>>>> openpgp@ietf.org > >> >>>>> https://www.ietf.org/mailman/listinfo/openpgp >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Joseph Lorenzo Hall >> >>>> Chief Technologist >> >>>> Center for Democracy & Technology >> >>>> 1634 I ST NW STE 1100 >> >>>> Washington DC 20006-4011 >> >>>> (p) 202-407-8825 >> >>>> (f) 202-637-0968 >> >>>> joe@cdt.org >> >>>> PGP: https://josephhall.org/gpg-key >> >>>> fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> --------------------------------- >> >>> Prof. Dr. Alex Biryukov, >> >>> FSTC/CSC, University of Luxembourg, >> >>> 6, rue Richard Coudenhove-Kalergi, >> >>> L-1359 Luxembourg-Kirchberg >> >>> LUXEMBOURG >> >>> Tel: +352 46 66 44 6793 >> >>> Fax: +352 46 66 44 5500 >> >>> >> >> >> >> >> -- Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet. From nobody Thu Nov 5 06:26: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 354E81B2D8D for ; Thu, 5 Nov 2015 06:26:05 -0800 (PST) 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 EUnN5-DPxfAo for ; Thu, 5 Nov 2015 06:25:59 -0800 (PST) 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 1AB2C1B2DD2 for ; Thu, 5 Nov 2015 06:25:54 -0800 (PST) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tA5EPWHu017782 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 5 Nov 2015 15:25:33 +0100 From: Simon Josefsson To: "brian m. carlson" References: <20151104010122.GA3896@vauxhall.crustytoothpaste.net> <56395F1A.4060609@azet.org> <20151104020752.GB3896@vauxhall.crustytoothpaste.net> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151105:azet@azet.org::dKktyy2c3zrU1W5P:u4T X-Hashcash: 1:22:151105:openpgp@ietf.org::Zsw3Y8409nr0NXbd:FXDg X-Hashcash: 1:22:151105:sandals@crustytoothpaste.net::wEnF08iCXcVSmVoA:8BUf Date: Thu, 05 Nov 2015 15:25:31 +0100 In-Reply-To: <20151104020752.GB3896@vauxhall.crustytoothpaste.net> (brian m. carlson's message of "Wed, 4 Nov 2015 02:07:52 +0000") Message-ID: <87a8qs1q1w.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: Aaron Zauner , openpgp@ietf.org Subject: Re: [openpgp] DRAFT minutes for OpenPGP at IETF 94 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, 05 Nov 2015 14:26:05 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable "brian m. carlson" writes: > On Wed, Nov 04, 2015 at 02:27:54AM +0100, Aaron Zauner wrote: >> brian m. carlson wrote: >> > A note on using patented algorithms: Some organizations, such as Debia= n, >> > require that parts of software be able to be extracted and otherwise >> > used under the terms of the license. Even if the OCB patent is waived >> > for OpenPGP, that would not be sufficient to allow parts of an OpenPGP >> > implementation that use OCB to be used in non-OpenPGP software. That >> > might prevent such OpenPGP implementations from entering the main Debi= an >> > archive. Other organizations may have similar restrictions. >> >=20 >> > This is just something to consider when discussing the use of patented >> > algorithms. >>=20 >> So in this case is non open-source software relevant at all? I don't >> think so. For open-source initiative licenses, public domain and CC >> there's a patent exemption anyway (since 2013): >> http://web.cs.ucdavis.edu/~rogaway/ocb/license1.pdf > > I suspect this is probably sufficient for Debian's purposes, although I > of course can't speak on their behalf. I'm not convinced that license is sufficient given how the term "Open Source Software" is defined. One right that a user has with, for example BSD or GPL licensed code, is to modify the code and sell/distribute the result to a third party (and in the case of GPL, provide source code) and not publish the code elsewhere. This is how many proprietary products use FOSS code, for example Microsoft Windows or your random Android app. The license only gives right to the patent for software projects which are publicly available through the wording "by anyone": =E2=80=9COpen Source Software=E2=80=9D means software whose source code = is published and made available for inspection and use by anyone because ... So, no, I don't think that license is sufficient, and that patent licensing terms in general, unfortunately, hampers wider adoption because evaluating whether they are permissible or not is too hard. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWO2bbAAoJEIYLf7sy+BGd5qkIAJmw2F1MJQO10Xs2RlJcgRRp l4ACc9G9EtIQ50BMBy5EzAda5vA//mNhXsKzi0wG4ZmD1fuWJKrnXp4mCs2rcrZc 4ezVr8Tx7hlakAatVzqp+zo4jCeRLMfbXlLQgXrCJdd2Hxqr3XIh0l2RhslFRGxe +OLismYWyRy9kcML7c9BrFdxq+hmoFzi803oV5wfxVQzfoYHxx8YqhEzoOSYvAUJ L++yjrVRQesm61bYOg8HMCFow4TQOPcjnkcllAHqePMOKvvqwJgE+V09Zf2bi7C2 DaMmB7B3+pZnFQze+iapb5YPj/Oksiwu/Spjkw2iKwgcmtVg+G6/Btxrp+7wOaA= =gs6T -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 5 07:12: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 61DD41B2EF6 for ; Thu, 5 Nov 2015 07:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_ORG=0.611] 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 X7e-9HnlAmVp for ; Thu, 5 Nov 2015 07:12:28 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30DF41B2EB9 for ; Thu, 5 Nov 2015 07:11:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 003DFE2038; Thu, 5 Nov 2015 10:11:12 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 17893-10; Thu, 5 Nov 2015 10:11:09 -0500 (EST) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 0DF86E2035; Thu, 5 Nov 2015 10:11:09 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1446736269; bh=/nDkC7qkoNIeKZPYr9GOW52YLjGlOYZW4Xtr2waaIxA=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=eKZHcoSsb06ABrfPdNqaq8EtCHU96W5CYc/MuNkZAKHgFVaTwRCyYstBWRQDJCYMi 8zxStxSaVtFF9Ytw+vWKxOH6fIg98/eNq8sgxAswZNWDDK+VmtC/a85JmsTfN0tkwI /hlrL4Ezx60WybS5Zze2aRvYRjj36qZM5URioSHA= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id tA5FB6qM021188; Thu, 5 Nov 2015 10:11:06 -0500 From: Derek Atkins To: nico@enigmail.net References: <5637B5E4.9050107@enigmail.net> <563B3805.1070204@enigmail.net> Date: Thu, 05 Nov 2015 10:11:06 -0500 In-Reply-To: <563B3805.1070204@enigmail.net> (nico@enigmail.net's message of "Thu, 5 Nov 2015 12:05:41 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: openpgp@ietf.org, gnugp-devel@gnupg.org Subject: Re: [openpgp] 2nd OpenPGP Summit on Dec 5/6 in Zurich 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, 05 Nov 2015 15:12:29 -0000 Nico, "nico@enigmail.net" writes: > Hi Derek, > > yes, indeed we are focusing on email exchange with OpenPGP only. > The goal is mainly to bring together all the developers/project > from email clients (and servers) and to focus on things like > header encryption, email validation, PGP/mime versus inline PGP, ... > (thus interoperability issues). > > Hope this helps. > Best > Nico Indeed, thank you. Going forward, may I suggest that next time you call it the OpenPGP Email Summit? -derek > Am 03.11.2015 um 15:26 schrieb Derek Atkins: >> >> Hi Nico, >> >> Just to be clear, this is an "OpenPGP in EMAIL" Summit, not a general >> OpenPGP Summit? >> >> -derek >> >> "nico@enigmail.net" writes: >> -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Nov 5 10:10:05 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 9D53A1A0461 for ; Thu, 5 Nov 2015 10:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 EfUzmg5Wuu08 for ; Thu, 5 Nov 2015 10:10:02 -0800 (PST) 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 BE23B1A044D for ; Thu, 5 Nov 2015 10:10:01 -0800 (PST) Received: by wicfv8 with SMTP id fv8so14963254wic.0 for ; Thu, 05 Nov 2015 10:10:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=K4JKfdLoNaU6vp2vxePpLN273uDIbQxWMDzLP3FEpoY=; b=NmA0GE46Sniu0JcHq708JzbJGQQxkk+0/23JeJjSXUHpI3BcazEFJBI8LFlMP/9zWs yI8diNgdlnbIWg79eKhE4YLva9N6Fm/phl9SsjiB2jW3sHuCY71w8KmOo/fhFsAyfTc/ NcB0n4WIgN1wVCzO5E5Llzih4Df7EaZKUjDOE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=K4JKfdLoNaU6vp2vxePpLN273uDIbQxWMDzLP3FEpoY=; b=P95X17H+np9IO6DYnle0T534XzMhtlRbyCB2VZam4cp1CxrSBWlicVQ/2kG48xKUq5 /G3f6VelPdveK0NZ9wAgXg1W1eulmv5gdZY85lVi4EEEASrHimyg7obvdheVOx/NA1oR Qacjrgl0A+tdKPgCR8VEifCAQ7gshYoXBG9RwThibTi1lPGdQugQ1u6nXB3od441Jd1J XiZcKuOKvGsPM4HFFeRL6gGGoZ9kHYUZT9kbd/9W1KvUxRvdj4CdRqul5by+X6B3jPYm eJCrOiDJH/aEZo2NV9GttbIsXF25i9eyYoZFfId53g+DkyMu8ZupR3Hi5FqIl4ijDwSW MfUw== X-Gm-Message-State: ALoCoQni44ETCFTHF5L8C718FC9ECyvaNPDaaGNBe9WGNGQZVToiz411IOQ4ri+cmNC7jm7u+f6B X-Received: by 10.194.174.202 with SMTP id bu10mr12087671wjc.74.1446747000276; Thu, 05 Nov 2015 10:10:00 -0800 (PST) Received: from [10.0.1.189] ([86.59.96.182]) by smtp.gmail.com with ESMTPSA id 184sm9612516wmk.10.2015.11.05.10.09.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Nov 2015 10:09:59 -0800 (PST) Message-ID: <563B9B77.4050901@azet.org> Date: Thu, 05 Nov 2015 19:09:59 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Simon Josefsson References: <20151104010122.GA3896@vauxhall.crustytoothpaste.net> <56395F1A.4060609@azet.org> <20151104020752.GB3896@vauxhall.crustytoothpaste.net> <87a8qs1q1w.fsf@latte.josefsson.org> In-Reply-To: <87a8qs1q1w.fsf@latte.josefsson.org> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigCBBBC7EF99DD887127DAAD76" Archived-At: Cc: openpgp@ietf.org, "brian m. carlson" Subject: Re: [openpgp] DRAFT minutes for OpenPGP at IETF 94 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, 05 Nov 2015 18:10:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCBBBC7EF99DD887127DAAD76 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, Simon Josefsson wrote: >=20 > =93Open Source Software=94 means software whose source code is publi= shed > and made available for inspection and use by anyone because ... >=20 > So, no, I don't think that license is sufficient, and that patent > licensing terms in general, unfortunately, hampers wider adoption > because evaluating whether they are permissible or not is too hard. >=20 A bit later in the same paragraph it says: ``` All licenses certified by the Open Source Initiative at opensource.org as of January 9, 2013 and all Creative Commons licenses identified on the creativecommons.org website as of January 9, 2013, including the Public License Fallback of the CC0 waiver, satisfy these requirements for the purposes of this license. ``` OSI licenses include BSD, MIT et cetera: http://opensource.org/licenses Don't get me wrong, I'm not trying to push this block cipher mode for OpenPGP, I'm just commenting because I've worked on a TLS related draft for OCB mode. IANAL. Aaron --------------enigCBBBC7EF99DD887127DAAD76 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWO5t4AAoJEOTbZJL9ubXVg7QP/Anuw7Mk3j7r4hW5tpyod+8A 36ZD7NPbfQIEgtL6jTqc86YyVu9Rf/LcDWmfYm2qVNeaSHiQQc54yRdnJFIqlk3N 15Vii58kQfkeFMj9+P2gRmncYX/kgZ6vcBfpXrgvhX6V/D9LIG45VsuEFqsWMpVu pPDNzKY7o7dGfP7w8whVoj+tYs7GeeXqqpDbtSlEqigpZLGz+EuRR4YKO/lQGJZg tDtva62oR2VLrm/s3CNMZnTy7Wj2uyXRJmlYn3hCTXmIkgL8q5nSAYJ4R8uGazIs qE7ctloSOTFdn26XOGthz0UYEYmklDuf11ZUCcwk+yEDa2ISwNtmt/sISh392BWF lx1gwQTymgWpxs43NFX9RL1Rt/rQj0LzgLdGtu/aSMBoJ6fi6puZFFACq26q8NU9 x2uOtS010Lox0W/HpNgif50XFQ/9K4Krw8OeHnyZBqXk4qFyhuNRr/cGhyVIidHn YBkBFCc+0HbpC/v7D8pKV8JQGmqxNoTVlIs217V/NN+oQOK/gXICq0AUovr3dc7J 8YzJFJqSRjMc9D4MtBjQxtYj7pg3oe4QpJ/ojp1Ksa732sDug6l0RbZRUyauaCRi SYxAS0jC9eLI7YUZLRqINHzeTnxi2FUut2+Q21vB9R8KZ4r+OkXWxFo37XRn014h qDbFFlY1HUHKG/5vi8u7 =cTIk -----END PGP SIGNATURE----- --------------enigCBBBC7EF99DD887127DAAD76-- From nobody Thu Nov 5 10:14:56 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 58FA81A1A57 for ; Thu, 5 Nov 2015 10:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 K32Dsn4gmA4x for ; Thu, 5 Nov 2015 10:14:53 -0800 (PST) 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 6FE651A1A4A for ; Thu, 5 Nov 2015 10:14:53 -0800 (PST) Received: by wicll6 with SMTP id ll6so15615878wic.0 for ; Thu, 05 Nov 2015 10:14:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=YX3hXT++8QqhhxSvJydtM53JTwH40FZDBT8j+2VlTuo=; b=Jjpywk1j806dsxpEiJbzvbm2wp8x7q34Xwb8qN/iw/FAO0Tu6h2UErCII7G9g0t4oS 0tFOLYKXlWvMnfvFCSRbFl4Lf9suyxlg7b3TSMvOevYTk9s+LbhfojAeFEe4Ec7XxSeu ts/CsPt8Ej1FvZ3MEv1wFnjjoWLbiiFRDlYrs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=YX3hXT++8QqhhxSvJydtM53JTwH40FZDBT8j+2VlTuo=; b=IU+6z3xsHxc0xrPQ69UTAkJZj+/h39I4VTIiDp5E9Q7sJ8V/uutIuDMGcNJv+0hmff gei3yyx2NiZkGz/Cm6HP1ziap4cXNP6x51vbvdCXJLjQGNIBG1n2wl3J96nwGIgGQHfC qX8/y9HhxqIDiphuibw0bDnK4BQZy6zLZnIxIXWv7qqlGTxsnzACtJCYfbailBVKYq61 MIMJGLBFcZ42rZUrw0dk78xQ/ve5vfA2lav9wxODwrNa9n9ptg4LbYhee4JSCZWCQxjb VNq7AYkQWFtzM6OyOlw8Z6hjgFCTcjFsAgvTvEE4etqDXCUuhSmXFWSk/NyCuFbMGPDb zWgw== X-Gm-Message-State: ALoCoQnSXVcg55uS+lD2s5RzAezS6WxXG/lblxRZaNAhzD4+Xco9XBCWK7u7KmfHL+LELeFBxHyf X-Received: by 10.194.78.109 with SMTP id a13mr10284055wjx.20.1446747292047; Thu, 05 Nov 2015 10:14:52 -0800 (PST) Received: from [10.0.1.189] ([86.59.96.182]) by smtp.gmail.com with ESMTPSA id q204sm35352087wmg.4.2015.11.05.10.14.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Nov 2015 10:14:51 -0800 (PST) Message-ID: <563B9C9C.7070106@azet.org> Date: Thu, 05 Nov 2015 19:14:52 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Daniel Kahn Gillmor References: <87lhaet2cq.fsf@vigenere.g10code.de> <20151104182705.86af2e43c8@baae13974eb4556> <87bnb9tw5b.fsf@vigenere.g10code.de> <87611hnwxu.fsf@alice.fifthhorseman.net> In-Reply-To: <87611hnwxu.fsf@alice.fifthhorseman.net> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigA877232984054D01C6672A4D" Archived-At: Cc: Werner Koch , openpgp@ietf.org Subject: Re: [openpgp] First 4880bis drafts 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, 05 Nov 2015 18:14:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA877232984054D01C6672A4D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Apparently my message came of the wrong way (and I'm to blame for that, because of my wording): Daniel Kahn Gillmor wrote: > On Thu 2015-11-05 04:14:08 +0900, Werner Koch wrote: >> On Wed, 4 Nov 2015 18:34, azet@azet.org said: >> >>> Hrm. I'm against this. CAMELLIA is going to be deprecated in e.g. >> You may be against it but it is a matter of fact that CAMELLIA is an >> officially assigned OpenPGP cipher algorithm for 6 years. >=20 > As discussed in the meeting tuesday, deprecation is a tricky subject fo= r > formats with stored data (as distinguished from on-the-wire network > traffic). people have archives of encrypted data that may still use > this cipher. Totally agree there. And PGP implementations will support these ciphers for years because of stored data that might have been encrypted with one of these ciphers. >=20 >> We may latter decide to deprecate certain algorithms but that is not a= >> question right now. >=20 > The sense of the room in Yokohama was to deprecate as much as possible,= > and encourage a limited, sensible set of algorithms for message creatio= n > and signing. But sensible implementations will likely continue to allo= w > decryption of these ciphers for years to come. >=20 Yes. But we should discourage further use. I'm not sure if the right place is the updated RFC or another document entirely. My concern is that we'll end up with a unmanageable 'cipher-zoo'. I'm happy to help with such a document and am _not_ trying to get in the way of updating the current OpenPGP spec. Hope that clears things up a bit, Aaron --------------enigA877232984054D01C6672A4D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWO5ycAAoJEOTbZJL9ubXV+08QAOlYjHkGJFV71EevgqpOHrgV SiEPdTxI6Y67coKG+nbi17qnvxE4ClkyFpokOFueGmL3tVAGrlB6Cmrs85z/HfWt UVcAjkHe8u9A74MAnOAsRTd82+XGxWq/90tR55WZfmJcR6QnXx+EGNjDE3J72j/C QupU/WdNAgAFCzxURd6bCr6T/Wt/pEW72XaUzgzK3yl83aSUehujL9V1mUxVpynq FMpRo9BayY+eJWun9P7MuANw0C74hhqFkIkSOv5BB95ptW7U9I9tvpOvy0NP9iC8 BWsirdrlKlgvw+ga4ZBEb3/aOueqmUZWOqDoxnirzeRFw0xXQTHze0Pm3qCUDN/T RULNfTwPQotXKZGlIpV9vvDtiZRaxrpVr/g2Z2b6Qd2fcAeHRsbQhegyZ3S6kw1n PGVcvKKmmSyTun+oTez82ajPIIAI9sEFUwCLoUx4y3wi1u0W2IStjCtX4xPVUnpx +YIAMxEvviRthOkbcZVDGSF46RyA610WWS4k08gb3clQ5Dd8utQYfzzSbN2fuEJ7 p5STRQdCPn3ofoiwGvVk5zyN+/I+ZGI0f1+S7sc3ybIDGtJEoDGrCajEEwCN+mFE JwFFpWvnC446uwr+cDv8bCLKBlGK3UcD5TshwLVNwLt+s785MxE//TR5KQb2tjeq s58+UqUTv9qrf/WwsSmP =DUZR -----END PGP SIGNATURE----- --------------enigA877232984054D01C6672A4D-- From nobody Thu Nov 5 10:19: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 037DD1A1B2A for ; Thu, 5 Nov 2015 10:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 bp1pL1k2GEod for ; Thu, 5 Nov 2015 10:19:08 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 51A5A1A1B34 for ; Thu, 5 Nov 2015 10:19:08 -0800 (PST) Received: by wmll128 with SMTP id l128so21219811wml.0 for ; Thu, 05 Nov 2015 10:19:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=ZIrxL/gWhl5zzs6olS5so6PCwAgBrEVw/hcsoQaqheI=; b=VwVvrndDIK4TVrgymi1BsBhmzYkAREC2Drwr1b9xNfbrCZncoTiBuDvs8eI1Z+LnZd t6W2YS7dQCw8Whp0SgIeCoR09ClEHrOOBzi7YFQYVuWOQUVUS/YffxnpRAlqD3NeJ7CD h40i8/Om79GSvsXDzZ2KIOxgh3RDodo7O8Y4M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=ZIrxL/gWhl5zzs6olS5so6PCwAgBrEVw/hcsoQaqheI=; b=Dni95JlSYyb7gbSsglFyfbjdNxtDJfEaTh71Z+v0BBj2j+2sY2e4w72zcn01kFYPdD F0ovmbJfbwFQwW4b95kOuXQklrY6+Zn4hNNaNpPiEhKC7qpKyjTWXGXbWfZt88m/9Fna s/uXyZORXjih5XMQxCioxr8Jo4uqnSYe3dkach7KqLXRGXH5AlIqcUtqgs/a9z4faTzt 5Axy9cEwfl5ybqSa6zisJsy83N/P6I49I/LFJZenrrEU13MqcFvVPEUL0wQBSy78x2cl hG5FFYTvdOdYD7xFnvegedZUHvKbwUUbsxWPd/eJEynKb55/BrXpJafaavDzCKqNZjp/ K3NQ== X-Gm-Message-State: ALoCoQkxrL0mae12UOUFgYX60TWEm/cCcZU35eUw0tb+7PULpiqDf1JnYgjmkqFu04Y3v82XMDRu X-Received: by 10.28.216.7 with SMTP id p7mr5243725wmg.61.1446747546878; Thu, 05 Nov 2015 10:19:06 -0800 (PST) Received: from [10.0.1.189] ([86.59.96.182]) by smtp.gmail.com with ESMTPSA id ki7sm8218298wjc.28.2015.11.05.10.19.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Nov 2015 10:19:06 -0800 (PST) Message-ID: <563B9D9B.6020603@azet.org> Date: Thu, 05 Nov 2015 19:19:07 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "brian m. carlson" References: <87lhaet2cq.fsf@vigenere.g10code.de> <20151104182705.86af2e43c8@baae13974eb4556> <20151105013051.GD3896@vauxhall.crustytoothpaste.net> In-Reply-To: <20151105013051.GD3896@vauxhall.crustytoothpaste.net> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig5D6A46E7E9EE9DE45B3F38E3" Archived-At: Cc: Werner Koch , openpgp@ietf.org Subject: Re: [openpgp] First 4880bis drafts 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, 05 Nov 2015 18:19:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5D6A46E7E9EE9DE45B3F38E3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable brian m. carlson wrote: > As Werner pointed out, Camellia has been around for some time. It's > also good to have enough diversity that if someone comes out with a > major attack against AES, we're not totally sunk. Camellia is a Feiste= l > cipher, while AES is a substitution-permutation network, which means > that attacks are unlikely to work against both. Ok - so what's the threat model here? Are we really expecting AES to be broken anytime soon? Really? And we're suggesting to keep ciphers around that have seen far less cryptanalysis? =2E.. > I believe Google's End-to-End is using the NIST curves, and there are > already keys using these curves. I think Curve25519 and Goldilocks > would be valuable due to their rigidity and the CFRG endorsement. Wasn't aware that end2end already has a userbase (after all, for a very long time the GitHub repo stated 'experimental code - do not use'). Likewise Curve25519 is available in GnuPG expert mode (it says use is discouraged though - and keyservers won't accept it). Aaron --------------enig5D6A46E7E9EE9DE45B3F38E3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWO52bAAoJEOTbZJL9ubXVKPMQAI7uskGTP7TZTH5B3Q5tOB13 co+OoLJDwqUgZwtViFjdVAJL1ttRnJ5iVnSBe4dObVoprtmjiqQIpCcA3RG1MwkU fhEF8jlE8i9P30khk6EnAHlhpvcTgCNhJ+d9D8fhwJq04DQHlLjqdtv+jkkQq9rA x8E5vb8Txo1aeNFsmi4oPO0hQzogSiQDldWsKivQnMT/4fnjMX62oViOSHXcKfa5 hwND4z/3egA5vmuzL7CIwcJmjg9WqJYUakfIsOmKBu0dX+4fvpkVR2xAJZkOSF9m UyBL1C2gt9LKcnSKTrz2/XhzJ+g1YmZLMdJEjBj0Nm4GjUymcjjLccMziJ81CmBm HTV0Ieszi01svu4I5UUsx12pUrSw90KQccoxtKoA6oCptv05i6kGPTzmi32Hyynf tcz/CQ7L1FiftKqk8d0YvjUtB5sQfCe/C40Nk8iRtuA095N0U2G69eRR4BdS6H4/ ud/TK/ApFxEuCOjrsMD0h35CQcdg8PlH6+kELP6pEDjuv5b4zIJIY4eyYfmiXyyo Q0yaVcbqkydMxrxxYHwKgglGXOuHl1JrhIEpQ3npFfQlwE1c8HfMVbhL8HxamJDn M1ESzwa2FYNydisallpOuZfnPKqdPvNzkEhMzQldOqzNVdCOKs2vuFOXMcr3J8UI bYrIOSZ0rE21fwFjhy9N =h4Od -----END PGP SIGNATURE----- --------------enig5D6A46E7E9EE9DE45B3F38E3-- From nobody Thu Nov 5 11:21: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 C18011AD244 for ; Thu, 5 Nov 2015 11:21:27 -0800 (PST) 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 W-xsmXlflyBN for ; Thu, 5 Nov 2015 11:21:26 -0800 (PST) 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 528E31ACE9E for ; Thu, 5 Nov 2015 11:21:26 -0800 (PST) Received: from Agent86.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 F1D036D747; Thu, 5 Nov 2015 14:21:24 -0500 (EST) To: openpgp@ietf.org References: <5623AA95.4060903@googlemail.com> <874mh3q3ol.fsf@alice.fifthhorseman.net> <56385818.2000606@googlemail.com> <20151103092006.3cd3e900@latte.josefsson.org> <563955F4.9030607@cs.tcd.ie> <87mvus26qp.fsf@latte.josefsson.org> From: Ian G Message-ID: <563BAC33.7020501@iang.org> Date: Thu, 5 Nov 2015 19:21:23 +0000 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [openpgp] cryptocurrency standardisation 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, 05 Nov 2015 19:21:27 -0000 On 05/11/2015 11:31, Simon Josefsson wrote: > There is not a lot of cryptocurrency standardisation going on in the IETF, alas. What do you think about using the term "proof of work" in the title instead? It appears to be the cryptographic property that cryptocurrencies (and other applications!) want from a primitive. I perceive that other PoW-ideas may be standardized in the IETF before currencies are. If argon is being proposed for a proof of work only then it should not include cryptocurrency in the title. Also, standardisation in the cryptocurrency world works a bit different to how it works in IETF WG fashion - I'm not sure I can see the benefit. Standardisation works best when the system is already out there and in use, not as sort of trial balloon - is argon in use in any systems as a PoW? Colour me skeptical! iang > Have you or anyone provided security reductions for Argon2 btw? Similar to the reductions that are available for Catena. They would help to substantiate any claims in the document that Argon2 is secure for its intended uses. > > /Simon > > Alex Biryukov skrev: (5 november 2015 12:07:17 CET) >> We discussed it briefly, would it be possible to add "cryptocurrency" >> to >> the title to cover two main usage areas. Then it would make sense to >> keep >> both Argon2i and Argon2d in the standard. >> >> "The memory-hard Argon2 password and cryptocurrency hash function >> draft-josefsson-argon2-00 >> >> From nobody Thu Nov 5 11:30:23 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 CBADF1B32C3 for ; Thu, 5 Nov 2015 11:30:21 -0800 (PST) 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 xssRUpasV_wt for ; Thu, 5 Nov 2015 11:30:20 -0800 (PST) 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 BE4661B32BF for ; Thu, 5 Nov 2015 11:30:20 -0800 (PST) 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 769005931BD for ; Thu, 5 Nov 2015 11:30:20 -0800 (PST) To: openpgp@ietf.org References: <87lhaet2cq.fsf@vigenere.g10code.de> <20151104182705.86af2e43c8@baae13974eb4556> <20151105013051.GD3896@vauxhall.crustytoothpaste.net> <563B9D9B.6020603@azet.org> From: "Robert J. Hansen" Message-ID: <563BAE4B.901@sixdemonbag.org> Date: Thu, 5 Nov 2015 14:30:19 -0500 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: <563B9D9B.6020603@azet.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Thu, 05 Nov 2015 11:30:20 -0800 (PST) Archived-At: Subject: Re: [openpgp] First 4880bis drafts 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, 05 Nov 2015 19:30:22 -0000 > Ok - so what's the threat model here? Are we really expecting AES to be > broken anytime soon? Really? As a police officer friend of mine is fond of saying, nobody wakes up in the morning and says "today I think I'll need my body armor." I doubt that anyone working on the RFC really expects AES to be broken any time soon. The inclusion of Camellia as a hedge against unpleasant surprises, though, seems wise. From nobody Thu Nov 5 11:30:56 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 BF1141B2C04 for ; Thu, 5 Nov 2015 11:30:55 -0800 (PST) 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 xGhnjVmbx8ZL for ; Thu, 5 Nov 2015 11:30:54 -0800 (PST) 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 491FC1A87BC for ; Thu, 5 Nov 2015 11:30:54 -0800 (PST) Received: from Agent86.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 842F56D748; Thu, 5 Nov 2015 14:30:53 -0500 (EST) To: openpgp@ietf.org References: <87lhaet2cq.fsf@vigenere.g10code.de> <20151104182705.86af2e43c8@baae13974eb4556> <20151105013051.GD3896@vauxhall.crustytoothpaste.net> From: Ian G Message-ID: <563BAE6C.6070100@iang.org> Date: Thu, 5 Nov 2015 19:30:52 +0000 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: <20151105013051.GD3896@vauxhall.crustytoothpaste.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] First 4880bis drafts 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, 05 Nov 2015 19:30:55 -0000 On 05/11/2015 01:30, brian m. carlson wrote: > On Wed, Nov 04, 2015 at 06:34:33PM +0100, Aaron Zauner wrote: >> * Werner Koch [04/11/2015 12:51:25] wrote: >>> o Added Camellia cipher from RFC 5581. >> Hrm. I'm against this. ++1++ >> CAMELLIA is going to be deprecated in e.g. >> TLS because barely anyone uses it. I'm explicitly excluding anything >> other than AES128 or 256 from my GnuPG config currently, I haven't >> noticed any breakage in almost a year: >> https://github.com/azet/dotfiles/blob/master/.gnupg/gpg.conf > As Werner pointed out, Camellia has been around for some time. Whatever - let implementations provide Camellia if they want to; they will to handle archives and so forth. The *standard* should do better, work for the benefit of all. The standard should have an aggressive role in deprecation. > It's > also good to have enough diversity that if someone comes out with a > major attack against AES, we're not totally sunk. This is hypothetical. It's never happened in our time. Our cryptographers are better than that, let's rely on them. > Camellia is a Feistel > cipher, while AES is a substitution-permutation network, which means > that attacks are unlikely to work against both. Sorry - can we worry about realistic user problems not hypothetical academic issues? > Currently, if AES were to be broken, TLS implementations would not > interoperate at a 128-bit or higher security level. OpenPGP would > continue to function without much thought, which is a major asset. ? AES isn't going to be broken. Software is going to be buggy - let's reduce complexity. Protocols might be flawed, let's make it simpler. But AES broken? No. Get realistic. > I'm for deprecating algorithms which provide less than a 128-bit > security level, such as SHA-1 and 3DES. It is the case that we face a threat around the 80 bit mark. Sure. So, I'd suspect we're going to set a mark for future OpenPGP at the 256 bit level. This would have been a no-brainer until recent NSA Suite B news. Does anyone have a feeling for where we'd like to draw the line now? iang From nobody Thu Nov 5 13:32: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 DEFA71B2AC4 for ; Thu, 5 Nov 2015 13:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 ODeiGjJFFKsm for ; Thu, 5 Nov 2015 13:32:09 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 A05C31B2AD2 for ; Thu, 5 Nov 2015 13:32:08 -0800 (PST) Received: by wmll128 with SMTP id l128so25298039wml.0 for ; Thu, 05 Nov 2015 13:32:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=J0wXdf/MQsV9KX7yyxkEGQHsSmPnvMcMbPBQKrn5wbo=; b=dH58WYjrdf4eySqd3hcN8ZntZF7cYqHUo4ZVahWmgqtlPn/albCCh/bn3Vc8OqkhuB +KxnFamEEjOjAr3Lyl9xSrQqK64YDC+yPMV0XgVJebdnSGljnK8sWdmBz2OSLEOJM2+Z JA9TJRR3uoIA4vX+uGbA9G1C2FVVaR0UhG9Ms= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=J0wXdf/MQsV9KX7yyxkEGQHsSmPnvMcMbPBQKrn5wbo=; b=BS5AEW6Q/3cdSXp25FyCLuyKJxsfX8BaGc3dhMK+bliRkJNnYeR+SExD/xO52/Wxz5 KImnT3sbjJ7dvjgTEqGAKupaHXpERmcvj8I8GeCaBLWS8jk9HnMyqVsyFFDBHIigA9nP ZchQxTRl1ESqOXnS9IdyB5mFXy/exXBoncAfSbUnJ9FVFOENWw/gfUPeTiiYg5WmKqsW +G2MLSQOR7j4r/aEdfFRh/mGvqAw78lV+8wTGODpNRYmdkQUTjEJCK2rcj+gXQdeI57f MSj3RtK+9v16f3XpGnYpKvm6+9ug0fE2o3hIEBJAexaqWyQCXF0qfWypRWsHze+F4jLN L5lA== X-Gm-Message-State: ALoCoQkTmTEGFlxERN1RDKwbGKPVCZWnRBMySMPDPlO7gij+sVx0X8exXbWtZdtRAZGLxYyFG6CH X-Received: by 10.28.174.195 with SMTP id x186mr6481726wme.87.1446759127164; Thu, 05 Nov 2015 13:32:07 -0800 (PST) Received: from [10.0.1.251] ([86.59.96.182]) by smtp.gmail.com with ESMTPSA id lf10sm8926174wjb.23.2015.11.05.13.32.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Nov 2015 13:32:06 -0800 (PST) Message-ID: <563BCAD7.3020403@azet.org> Date: Thu, 05 Nov 2015 22:32:07 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "Robert J. Hansen" References: <87lhaet2cq.fsf@vigenere.g10code.de> <20151104182705.86af2e43c8@baae13974eb4556> <20151105013051.GD3896@vauxhall.crustytoothpaste.net> <563B9D9B.6020603@azet.org> <563BAE4B.901@sixdemonbag.org> In-Reply-To: <563BAE4B.901@sixdemonbag.org> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig595E8DDA2F37AA9FBEB6B77D" Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] First 4880bis drafts 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, 05 Nov 2015 21:32:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig595E8DDA2F37AA9FBEB6B77D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Robert J. Hansen wrote: >> Ok - so what's the threat model here? Are we really expecting AES to b= e >> broken anytime soon? Really? >=20 > As a police officer friend of mine is fond of saying, nobody wakes up i= n > the morning and says "today I think I'll need my body armor." He still packs a firearm, pepper-spray and baton, I guess? :) >=20 > I doubt that anyone working on the RFC really expects AES to be broken > any time soon. The inclusion of Camellia as a hedge against unpleasant= > surprises, though, seems wise. I'm not saying that having alternatives to AES is a bad idea, I'm just saying that CAMELLIA may not be the best choice there. It has not seen a lot of cryptanalysis over the last couple of years (primarily because there's almost no interest in it). Aaron --------------enig595E8DDA2F37AA9FBEB6B77D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWO8rXAAoJEOTbZJL9ubXVkkMP/iF64vBdbp7Kqh2w9b++K8dz URMPMNEht4uuSzElrzELkibNajGpTPETT+yH7NtEoCodXAK3OlXBJu15nwuzLsqq 9wdifDkghuP5KF8ghdwtRyEk/ZeJbTRHOBII4RNTyofOSxA1IlEq4/Vk57JbfZdh XnxSe9UbquhV/WgKvcVF4+IfZAjysx73kbNRVU3xQpJvKxZFin54dFJPs1c2E3hK 2bQCBj5PODvo5chvq/6EQMOn5SxKHSphBAub8Ia1JDQmE1Hy1OEUzmp6/QSwOit+ NM1f+dn/Gz2TJxCdVcPCzl8cTAOnSIhAAX2lnU2+rOOXF7pmW7ANkEXJ2Mv9h31s UR3ci3M3VV3MqPGSBrqMCuQ4hfi8/FhVRV0RXRQG13jixoAUN9csC/6XXFcF4r7+ QneZ7gBn6Fu+rYl1bAODn3OiiZAMnreakRVUoBmc96H8gF2puqlczN9N3ZGG+I8q LUusRlnsiDqkcKaXmuc1WeJtYUMCnTSzjOfeqns7HAn7/Ruorle0F3S54MeQlH27 VX34rZyBgO+wyF2V1uDFNZk0k12/0LfJTo2RrUzc4AeDQNP4pcppHtC7A3Dpzhzc X4GdYnY8IFL7yj6xyi33iXscY8+5vxpC4RNywsVTv3WNjrpSVMuYDRf8T8acYJsy n15BWwTiU1YMZWrK6cpJ =s3cu -----END PGP SIGNATURE----- --------------enig595E8DDA2F37AA9FBEB6B77D-- From nobody Thu Nov 5 13:33: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 6A6ED1B2CCD for ; Thu, 5 Nov 2015 13:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 XWA79GXJvIKS for ; Thu, 5 Nov 2015 13:33:11 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 31B781B2CCA for ; Thu, 5 Nov 2015 13:33:11 -0800 (PST) Received: by wmnn186 with SMTP id n186so26023723wmn.1 for ; Thu, 05 Nov 2015 13:33:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=F/STpwEFQ0z8AM2wyrTN1x6GCdFw+JJDaGt7mUWDbBA=; b=PfBKQ8jewB0bCwV38a9r/ApluUfCO8CCwIAxFQDkSGxj87jcaUCL2/BTT9DD9ZH0tG 8BaTQKbqrHzghmSAijbBFFbPys66VCrFQ6Zop7dPKB1A65QiwfAvZQMJ3Th7f62xd5IG OZAGxII8SgmJjV5NuCQ6qBDT8OStBbZtkUb80= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=F/STpwEFQ0z8AM2wyrTN1x6GCdFw+JJDaGt7mUWDbBA=; b=GuHwerFeQ2yQTdDKK31Wic7gRsFLQcM5kbz9/DIpunKuIifsXSGx8JxuNSe+AJMRZ8 e+slYGUTilKkJJ0VUBMUA8CXtI0N2ACgx0KrytuOxc4aTdQkIBZIBU9tOEbVIn7WUoBn NayeVSF8qZXWXaTyh6HHvUCGP7MhYbOQEQH9/dOUSQDtPXaNOV6Ax4PGNE+COUe2Go9L DYiFAO5ndG6ki6S2fniQ6QD7urP57PkleeMt8dCHtJ5j864MOOeXog0TCvBhvryi/sVZ Fe5fq73dh+HIlaxXXKEPWOliqq29JIK7N+ygdtxSVSpARh0G3OXQ7TEVC2YY4GBzR0YV rwjA== X-Gm-Message-State: ALoCoQm/15pRsTzNteOt+ALUBEg5bw3z412qO6XNSUEWrLE2urCVgCrU2x/vIqfXD5AoOG2Y+Ygy X-Received: by 10.28.87.1 with SMTP id l1mr5947749wmb.72.1446759189816; Thu, 05 Nov 2015 13:33:09 -0800 (PST) Received: from [10.0.1.251] ([86.59.96.182]) by smtp.gmail.com with ESMTPSA id b12sm63311wma.6.2015.11.05.13.33.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Nov 2015 13:33:09 -0800 (PST) Message-ID: <563BCB16.9010104@azet.org> Date: Thu, 05 Nov 2015 22:33:10 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "Robert J. Hansen" References: <87lhaet2cq.fsf@vigenere.g10code.de> <20151104182705.86af2e43c8@baae13974eb4556> <20151105013051.GD3896@vauxhall.crustytoothpaste.net> <563B9D9B.6020603@azet.org> <563BAE4B.901@sixdemonbag.org> <563BCAD7.3020403@azet.org> In-Reply-To: <563BCAD7.3020403@azet.org> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig672CD3EF4639DC4436371F82" Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] First 4880bis drafts 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, 05 Nov 2015 21:33:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig672CD3EF4639DC4436371F82 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Aaron Zauner wrote: > I'm not saying that having alternatives to AES is a bad idea, I'm just > saying that CAMELLIA may not be the best choice there. It has not seen = a > lot of cryptanalysis over the last couple of years (primarily because > there's almost no interest in it). Also - having /too many/ alternatives is certainly a bad idea. Aaron --------------enig672CD3EF4639DC4436371F82 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWO8sWAAoJEOTbZJL9ubXVvO0QAIfQ1giBaVt3+qc7fD36T4l8 LRYjcWvs9JsvXv0hNMnAuWrS+QsdklqGLlMUDy8id8utGmj1DitVgN5xDSgmUMXp 4HDLsU7+BGgVYbQbmUkXAguza+Kc7LsxWtIDe2db/gHmcAH78yIMcXBOiynY12yu 0QqvLd0PQEWGxBxEjGvfQVv1SUCsv/0ferZD3P21PEDoumBIyju2AGK61T3GeJPg 51nIVJPBH65psv/lPeKG4eCr5Xp5P0VPZ/d4BUJeCMWomjspxm0gYWIFWF4Zb5lZ 9hLYmUHFZuhaSm9kIf/XA6nE0mSjRT+SsjRTMz5nsFWYTE3BEaoq/zuqQAYTcDVA CA+ySJ8b8d8AHO+PbFPPJ6WDVpmSYboIk3KJ/VvM7LFlDdkXN4vwluFHmrcBO6nZ puJF0eGsACRfB+CkUZu474n+lJO2clW7L07hxUKUgnkiCnwr4ukatICxuPiVLFn5 dVGS5ok8RZFJ0v/HEPqFejqlt+MU6402WDC5H+X9Kwo/oYh6zhEiUn8/iCryOPa/ CWCIbc++2Tn9sVgIvc4Op3KkClsXtxj+5JQ6WlIdN0Iew+T0V5httVs39ZZtkAOI Jy75G+Bq8J+PHLKUncLGVFxstHd/isjK0lV1c7DJnCnb1prDPFYpZZ1S6uTlHOyt ZD/czpHnuEh67GLwU4HQ =C+sp -----END PGP SIGNATURE----- --------------enig672CD3EF4639DC4436371F82-- From nobody Thu Nov 5 18:01: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 0B61D1A8A8E for ; Thu, 5 Nov 2015 18:01:00 -0800 (PST) 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 i33yl6UME8JK for ; Thu, 5 Nov 2015 18:00:58 -0800 (PST) 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 6C5A11B2B85 for ; Thu, 5 Nov 2015 18:00:58 -0800 (PST) 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 931476D748; Thu, 5 Nov 2015 21:00:56 -0500 (EST) To: openpgp@ietf.org References: From: ianG Message-ID: <563C09D7.8090404@iang.org> Date: Fri, 6 Nov 2015 02:00:55 +0000 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: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] DRAFT minutes for OpenPGP at IETF 94 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, 06 Nov 2015 02:01:00 -0000 Thanks Rich, adding my 2 yen. On 3/11/2015 09:41 am, Salz, Rich wrote: > - General issue of deprecration for stored data? Possibilities (? Marks possibly-controversial) > MD5; SHA1?; RIPE-MD > IDEA; 3DES?; CAST5?; Blowfish? Twofish? > DSA? Size limits on RSA? NIST ECC? ElGamal? > What does deprecation mean? Perhaps just encryption? Also decrypt if the content is known/believed to be not old Yes - practically, deprecated in the standard means no encryption, and implementations are free to decrypt older stuff. > Is signature verification different? No signing using old algos. > There are several usability issues around this; we need to be careful. > Consensus is not to create new content with deprecated algorithms. +1 > Perhaps address general issue of "what to do with old stuff"? And maybe answer is "lose it" No, download an old copy of gpg or pgp2.3 and decrypt it. > Stephen Farrell: Suggest reframe question as "everything deprecated unless shown that need to generate ones using old mechanism" > Discussion of how appropriate to put UI items in a protocol/data-format spec. > Strong consensus to start with everything removed, and then add the ones we want. the one :) > - Symmetric crypto (Bryan Ford), draft-ford-openpgp-format See slides in the proceedings. > Consensus to use a new packet type for AEAD-protected yes. > Lots of information exposed by plaintext metadata > Magic number -- this is an openpgp file, so its suspicious > Cipher -- is it worth trying to crack (e.g., is it rc4 :) > Passphrase: worth trying a password cracker > Recipient key-id's: where to point the rubber hose? > # of recipients: aha, it's *that* group of dissidents? > Should we aim to protect it all (at cost of "trial" encryptions)? Yes - indistinguishable from random is the target. This might not be achievable, but it should be the target. We won't get there unless we start on the journey. iang From nobody Thu Nov 5 18:09: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 CB1C01B2B91 for ; Thu, 5 Nov 2015 18:09:44 -0800 (PST) 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 DPnIao6rb3Au for ; Thu, 5 Nov 2015 18:09:43 -0800 (PST) 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 C148F1B2C01 for ; Thu, 5 Nov 2015 18:09:40 -0800 (PST) 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 A55486D748; Thu, 5 Nov 2015 21:09:39 -0500 (EST) To: openpgp@ietf.org References: <563931B6.9050107@googlemail.com> From: ianG Message-ID: <563C0BE2.80105@iang.org> Date: Fri, 6 Nov 2015 02:09:38 +0000 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: <563931B6.9050107@googlemail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Regulation of algo deprecation 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, 06 Nov 2015 02:09:44 -0000 On 3/11/2015 22:14 pm, Nils Durner wrote: > Hi, > > I would like to elaborate on why I feel that algorithm deprecation > should also be guided by regulations. For Germany, the algorithm catalog > for Electronic Signatures[0] issued by the Federal Network Agency, > dictates that >> SHA-1 and RIPEMD-160, respectively, are suitable only for verification >> of qualified certificates until the end of 2015. > > I feel that implementations should help users use crypto correctly - and > incorrect use also includes use of methods deemed insufficient by law, > IMO. IANAL, but repudiability based on algorithm choice should be > prevented against. I think this is an over-reading of the dig-sig laws. Although I haven't followed it for a couple of years, there have been court cases in Germany that have accepted digital signatures from non-qualified sources. Also, the qualified signature programme in Europe is basically a failure. I would recommend completely ignoring what some law says, and doing it right by the user. You'll get into more trouble in trying to align with the law than by doing the right thing, in my not so humble opinion. iang From nobody Fri Nov 6 00:58: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 E23211ACE53 for ; Fri, 6 Nov 2015 00:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.562 X-Spam-Level: X-Spam-Status: No, score=-1.562 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 8HzQ0vOV5TuW for ; Fri, 6 Nov 2015 00:58:41 -0800 (PST) Received: from annwfn.iks-jena.de (annwfn-eth.iks-jena.de [IPv6:2001:4bd8:0:104:20a:e4ff:fe80:3138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28BEB1ACE51 for ; Fri, 6 Nov 2015 00:58:40 -0800 (PST) X-SMTP-Sender: IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f Received: from belenus.iks-jena.de (belenus.iks-jena.de [IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f]) by annwfn.iks-jena.de (8.14.9/8.14.1) with ESMTP id tA68wR5b029343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2015 09:58:29 +0100 X-MSA-Host: belenus.iks-jena.de Received: (from lutz@localhost) by belenus.iks-jena.de (8.14.3/8.14.1/Submit) id tA68wQev025410; Fri, 6 Nov 2015 09:58:26 +0100 Date: Fri, 6 Nov 2015 09:58:26 +0100 From: Lutz Donnerhacke To: ianG Message-ID: <20151106085826.GA25362@belenus.iks-jena.de> References: <563C09D7.8090404@iang.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <563C09D7.8090404@iang.org> X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] DRAFT minutes for OpenPGP at IETF 94 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, 06 Nov 2015 08:58:43 -0000 On Fri, Nov 06, 2015 at 02:00:55AM +0000, ianG wrote: >> Perhaps address general issue of "what to do with old stuff"? And maybe answer is "lose it" > > No, download an old copy of gpg or pgp2.3 and decrypt it. I oppose that. One important use case for PGP is to sign binary blobs in archives in order to verify their integrity. (take for instance the distribution of software) Requiring the user to stick with old, unmaintained software (which might not even run on it's current system and can't be compiled for the new environment) is a no go. From nobody Fri Nov 6 06:16: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 2FAA01A90AC for ; Fri, 6 Nov 2015 06:16:24 -0800 (PST) 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 nDY-RecUM22D for ; Fri, 6 Nov 2015 06:16:22 -0800 (PST) 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 7BC6E1A9046 for ; Fri, 6 Nov 2015 06:16:22 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZuhoS-0007UJ-Kk for ; Fri, 06 Nov 2015 15:16:20 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Zuhjw-0007XQ-Nf; Fri, 06 Nov 2015 15:11:40 +0100 From: Werner Koch To: Lutz Donnerhacke References: <563C09D7.8090404@iang.org> <20151106085826.GA25362@belenus.iks-jena.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: Lutz Donnerhacke , ianG , openpgp@ietf.org Date: Fri, 06 Nov 2015 15:11:40 +0100 In-Reply-To: <20151106085826.GA25362@belenus.iks-jena.de> (Lutz Donnerhacke's message of "Fri, 6 Nov 2015 09:58:26 +0100") Message-ID: <87611frzdv.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, ianG Subject: Re: [openpgp] DRAFT minutes for OpenPGP at IETF 94 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, 06 Nov 2015 14:16:24 -0000 Hi Lutz, On Fri, 6 Nov 2015 09:58, lutz@iks-jena.de said: > Requiring the user to stick with old, unmaintained software (which might not > even run on it's current system and can't be compiled for the new We promised to keep on maintaining GnuPG 1.4, which is that old copy: all RFC-4880 features. You would need that for VMS anyway ;-). Thus there is at least one maintained old software. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Fri Nov 6 17:46:50 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 B6C011A6FAC for ; Fri, 6 Nov 2015 17:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 JffX1Iwiknex for ; Fri, 6 Nov 2015 17:46:43 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::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 7B32D1A6F9A for ; Fri, 6 Nov 2015 17:46:43 -0800 (PST) Received: by pabfh17 with SMTP id fh17so139086603pab.0 for ; Fri, 06 Nov 2015 17:46:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=mVwr8IO+IhwOh1lDN/ur96fqw4/X/VqFfIEwbLdNE4Q=; b=Vrc5G34TIFzb3YowkesoWujqLdyoKEgX8VVXAs5FHWyFNdlod16w+z4aWJRiWpjbKN k8IhgIl521w3xHaQg/7C3kFJ54uPyPHXN47w3C3iVNQLAOzjOznKBGYYaOALr6Y03ToX DWxgxV6/n5ep6jyO0/gTMdJ+5XXfCciZ552jhlTb2uubgxbIlGBEWMqQFeV4uQz80EPS PoHORT08sfCHh8qxoanVgniuVaVyXe/bUDRqQOMMbVj0nT37ppDVg4ABtjs7g4p58DbP IKdrdTjKLnrxC9tWPGjjxdD9jRmcAbwtzf82gmekB3hPyTqDw6aUWm5BxaSkka+4+dz1 U/sQ== X-Received: by 10.68.233.233 with SMTP id tz9mr21723869pbc.15.1446860803136; Fri, 06 Nov 2015 17:46:43 -0800 (PST) Received: from [192.168.11.11] (i223-218-148-140.s41.a014.ap.plala.or.jp. [223.218.148.140]) by smtp.gmail.com with ESMTPSA id ko11sm183461pbd.51.2015.11.06.17.46.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Nov 2015 17:46:40 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_7DF1BB2D-A879-4D92-82E9-EBBCB882AE05"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Bryan Ford In-Reply-To: Date: Sat, 7 Nov 2015 10:46:34 +0900 Message-Id: <3A98EA92-0C2F-46A7-8D06-880FC83CB110@gmail.com> References: <87twp91d8r.fsf@alice.fifthhorseman.net> To: openpgp@ietf.org, "cfrg@irtf.org" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Zooko Wilcox-OHearn , 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: Sat, 07 Nov 2015 01:46:46 -0000 --Apple-Mail=_7DF1BB2D-A879-4D92-82E9-EBBCB882AE05 Content-Type: multipart/alternative; boundary="Apple-Mail=_3151D626-71E8-44F3-AABB-7C3EAB8BEF41" --Apple-Mail=_3151D626-71E8-44F3-AABB-7C3EAB8BEF41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 To return to this thread - DKG brought up one important potential = functionality goal for the next OpenPGP message format (streaming-mode = integrity protection); then the thread diverged into a different and I = think orthogonal - though equally interesting - potential functionality = goal (namely random-access capability via Merkle trees as in = Tahoe-LAFS). I included a slide on this topic in my OpenPGP WG presentation = (https://drive.google.com/file/d/0BwK1bcoczINtMEI2Y3A1Rm52SXc/view?usp=3Ds= haring = slide 10) and was hoping to solicit discussion but there = wasn=E2=80=99t time, so perhaps we can continue here? To be clear, there are two separate use-cases, each of which make sense = without the other and require different technical solutions (but could = also make sense together): 1. Streaming-mode integrity protection: We want to make sure OpenPGP = can be used Unix filter-style on both encryption and decryption sides, = to process arbitrarily large files (e.g., huge backup tarballs), while = satisfying the following joint requirements: (a) Ensure that neither the encryptor nor decryptor ever has to = buffer the entire stream in memory or any other intermediate storage. (b) Ensure that the decryptor integrity-checks everything it = decrypts BEFORE passing it onto the next pipeline stage (e.g., un-tar). 2. Random-access: Once a potentially-huge OpenPGP-encrypted file has = been written to some random-access-capable medium, allow a reader to = decrypt and integrity-check parts of that encrypted file without = (re-)processing the whole thing: i.e., support integrity-protected = random-access reads. Let=E2=80=99s call these goals #1 and #2, respectively. Achieving either goal will require dividing encrypted files into chunks = of some kind, but the exact metadata these chunks need to have will vary = depending on which goal we want to achieve (or both). To achieve goal #1 properly, it appears that what we need is not only a = MAC per chunk but a signature per chunk. If the encryptor only signs a = single aggregate MAC at the end, then the decryptor needs to process its = input all the way to that signature at the end before it can be certain = that any (even the first) bytes of the decrypted data are valid. If the = encryptor produces a Merkle tree at the end and signs its root as in = Tahoe-LAFS (e.g., in pursuit of goal #2), the decryptor still needs to = read to the end of its input before being able to integrity-check = anything, and hence still fails to achieve goal #1. To achieve goal #2, the Merkle tree approach used in Tahoe-LAFS seems = well-suited. But it assumes/requires the decryptor has a complete, = random-access seekable copy of the encrypted file sitting somewhere, = which is certainly a reasonable assumption in the context of a file = system like Tahoe-LAFS, but violates requirement (a) of goal #1 and in = particular may not hold when OpenPGP is used to filter-decrypt from = unseekable media or a network stream to an un-tar type process. We could very well design an OpenPGP format that addresses both goals = together, if we decide both goals are valuable. The encryptor would = need to build its Merkle tree incrementally - without initially knowing = its total size - and after encrypting and outputting each chunk, = generate and sign a new Merkle tree root after each chunk. We = wouldn=E2=80=99t necessarily have to store an entirely new Merkle tree = after each chunk, only a log2(N)-size list of hashes comprising the = =E2=80=9Cupdate path=E2=80=9D from the new chunk back to the root, = reusing the un-updated parts of the Merkle tree already stored in = earlier parts of the encrypted file. (But this will require that = earlier Merkle trees be =E2=80=9Cincrementally updatable=E2=80=9D, which = might violate the properties of some of the Merkle tree proposals = suggested elsewhere in other threads.) There are some obvious tradeoffs here, both in storage and complexity = costs. I=E2=80=99m not that worried about the storage efficiency costs, = because even the costs of a log2(N)-size list of hashes per chunk can be = amortized fairly effectively by making the chunks moderately large, = e.g., 65KB or even 1MB. There=E2=80=99s also the compute cost of = performing a public-key signature rather than just a MAC per chunk, but = that can be similarly amortized by using relatively large chunks. On = the other hand, large chunks might not be ideal for embedded/constrained = devices. And the implementation-complexity is certainly an issue = regardless. So some questions about this: 1. How important is the ability to achieve goal #1 above in the OpenPGP = format (streaming-mode integrity-checking)? 2. How important is the ability to achieve goal #2 above in the OpenPGP = format (random-access integrity-checking)?=20 3. For whichever goal(s) we wish to be able to achieve, should those be = *mandatory* or *optional* in the format? That is, should *every* = OpenPGPv5-encrypted file satisfy either or both of these goals, or = should they be configurable or user-selectable (such that some encrypted = files might contain per-chunk signatures and/or Merkle trees while = others do not)? Making either of these goals =E2=80=9Csupported but = optional=E2=80=9D might help mitigate any performance/storage cost = concerns with either of them, but would only further increase the = complexity of the overall OpenPGP spec and increase the =E2=80=9Cusability= risk=E2=80=9D of a user accidentally failing to enable a relevant = option when he really should have (e.g., streaming-mode protection for = backups). 4. What are reasonable upper- and lower-bounds for chunk sizes, and what = are the considerations behind them? =20 Thanks Bryan --Apple-Mail=_3151D626-71E8-44F3-AABB-7C3EAB8BEF41 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 To return to this = thread - DKG brought up one important potential functionality goal for = the next OpenPGP message format (streaming-mode integrity protection); = then the thread diverged into a different and I think orthogonal - = though equally interesting - potential functionality goal (namely = random-access capability via Merkle trees as in Tahoe-LAFS).

I included a slide on = this topic in my OpenPGP WG presentation (https://drive.google.com/file/d/0BwK1bcoczINtMEI2Y3A1Rm52SXc/vi= ew?usp=3Dsharing slide 10) and was hoping to solicit discussion = but there wasn=E2=80=99t time, so perhaps we can continue = here?

To be = clear, there are two separate use-cases, each of which make sense = without the other and require different technical solutions (but could = also make sense together):

1. Streaming-mode integrity protection:  We want to make = sure OpenPGP can be used Unix filter-style on both encryption and = decryption sides, to process arbitrarily large files (e.g., huge backup = tarballs), while satisfying the following joint requirements:

(a) = Ensure that neither the encryptor nor decryptor ever has to buffer the = entire stream in memory or any other intermediate storage.
= (b) Ensure that the decryptor integrity-checks everything it = decrypts BEFORE passing it onto the next pipeline stage (e.g., = un-tar).

2. = Random-access: Once a potentially-huge OpenPGP-encrypted file has been = written to some random-access-capable medium, allow a reader to decrypt = and integrity-check parts of that encrypted file without (re-)processing = the whole thing: i.e., support integrity-protected random-access = reads.

Let=E2=80= =99s call these goals #1 and #2, respectively.

Achieving either goal will require = dividing encrypted files into chunks of some kind, but the exact = metadata these chunks need to have will vary depending on which goal we = want to achieve (or both).

To achieve goal #1 properly, it appears that what we need is = not only a MAC per chunk but a signature per chunk.  If the = encryptor only signs a single aggregate MAC at the end, then the = decryptor needs to process its input all the way to that signature at = the end before it can be certain that any (even the first) bytes of the = decrypted data are valid.  If the encryptor produces a Merkle tree = at the end and signs its root as in Tahoe-LAFS (e.g., in pursuit of goal = #2), the decryptor still needs to read to the end of its input before = being able to integrity-check anything, and hence still fails to achieve = goal #1.

To = achieve goal #2, the Merkle tree approach used in Tahoe-LAFS seems = well-suited.  But it assumes/requires the decryptor has a complete, = random-access seekable copy of the encrypted file sitting somewhere, = which is certainly a reasonable assumption in the context of a file = system like Tahoe-LAFS, but violates requirement (a) of goal #1 and in = particular may not hold when OpenPGP is used to filter-decrypt from = unseekable media or a network stream to an un-tar type = process.

We = could very well design an OpenPGP format that addresses both goals = together, if we decide both goals are valuable.  The encryptor = would need to build its Merkle tree incrementally - without initially = knowing its total size - and after encrypting and outputting each chunk, = generate and sign a new Merkle tree root after each chunk.  We = wouldn=E2=80=99t necessarily have to store an entirely new Merkle tree = after each chunk, only a log2(N)-size list of hashes comprising the = =E2=80=9Cupdate path=E2=80=9D from the new chunk back to the root, = reusing the un-updated parts of the Merkle tree already stored in = earlier parts of the encrypted file.  (But this will require that = earlier Merkle trees be =E2=80=9Cincrementally updatable=E2=80=9D, which = might violate the properties of some of the Merkle tree proposals = suggested elsewhere in other threads.)

There are some obvious tradeoffs here, = both in storage and complexity costs.  I=E2=80=99m not that worried = about the storage efficiency costs, because even the costs of a = log2(N)-size list of hashes per chunk can be amortized fairly = effectively by making the chunks moderately large, e.g., 65KB or even = 1MB.  There=E2=80=99s also the compute cost of performing a = public-key signature rather than just a MAC per chunk, but that can be = similarly amortized by using relatively large chunks.  On the other = hand, large chunks might not be ideal for embedded/constrained devices. =  And the implementation-complexity is certainly an issue = regardless.

So = some questions about this:

1. How important is the ability to achieve goal #1 above in = the OpenPGP format (streaming-mode integrity-checking)?

2. How important is the = ability to achieve goal #2 above in the OpenPGP format (random-access = integrity-checking)? 

3. For whichever goal(s) we wish to be able to achieve, = should those be *mandatory* or *optional* in the format?  That is, = should *every* OpenPGPv5-encrypted file satisfy either or both of these = goals, or should they be configurable or user-selectable (such that some = encrypted files might contain per-chunk signatures and/or Merkle trees = while others do not)?  Making either of these goals =E2=80=9Csupporte= d but optional=E2=80=9D might help mitigate any performance/storage cost = concerns with either of them, but would only further increase the = complexity of the overall OpenPGP spec and increase the =E2=80=9Cusability= risk=E2=80=9D of a user accidentally failing to enable a relevant = option when he really should have (e.g., streaming-mode protection for = backups).

4. What are reasonable upper- and lower-bounds for chunk = sizes, and what are the considerations behind them? =  

Thanks
Bryan


= --Apple-Mail=_3151D626-71E8-44F3-AABB-7C3EAB8BEF41-- --Apple-Mail=_7DF1BB2D-A879-4D92-82E9-EBBCB882AE05 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTExMDcwMTQ2MzVaMCMGCSqGSIb3DQEJBDEWBBQPi1YvmCOoeqKwLDTv+UFtwIowgjCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAUyIV8rJAEoXICfuRl/Z8b04Z/x9lmaiOJ053UuNBcxlNp7L0gUe8YvhIN2BOc9Ey YWZ3mxcfZGzesDDMw4QAy++7AEwjpZQTge9KZw76NuW/V9K05j1N+GzPgBR8vGLY6yndkksr47Bk sF0dNbiox9lWHsznRmSQMbL0Z7E5tkh7R1QC9neW3Nt4wD5wnydTEbiLga2kjtKGt2mW2/6dkM/U PECXbv6zYAXS7ZZV7vmNObofgRoKIMXXHBgvCfSWRlEj9j1DFA9LoIKR7TO8dmdvrCZzed2hOslB Yfu7XXc3qlVFmfN4BKuHXtkd3iikOSQbM8vXurb/FAdPeSgW3gAAAAAAAA== --Apple-Mail=_7DF1BB2D-A879-4D92-82E9-EBBCB882AE05-- From nobody Fri Nov 6 17:54:43 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 353DA1A0252 for ; Fri, 6 Nov 2015 17:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 aeFv-fgBdrYD for ; Fri, 6 Nov 2015 17:54:37 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::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 C17301A0121 for ; Fri, 6 Nov 2015 17:54:37 -0800 (PST) Received: by oies6 with SMTP id s6so33060692oie.1 for ; Fri, 06 Nov 2015 17:54:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital_net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=6YeLxp+fGzpfp8Bxmq+19zrTAirFktaKgapurTzlBH4=; b=IzVhcP8iTa7i8a4cCtIu7SNW4sRAFpr+FYFP05pVXfqHU9s47GR+/QdIrrNCzuXOXV 4yTgx2B3B4O13QH2jJaYBQ/9a+Tj0c46/iQfY1AnPJ5VkPhKCs05EFX7uFzJM4kqExs1 0FAHGT/9/bRfTcTn2IGRj78QF/2j8C7PR9PJZNeCS7ayshy9dtySs5R4Knf5bxdjrguz F5WxdW6ji0BsSkD5mRszV55A7IYLBuOCpr3UPuc6wmtC+BKFsGhBfe+DkStmTrXUYaSU i/2ZY0w6NPHpENGdyuKiICQZWdDVZ2jyS4pksdsQXqD8F6J+E5WizGJpadpsgZPRZ0VP i1OQ== 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:cc:content-type:content-transfer-encoding; bh=6YeLxp+fGzpfp8Bxmq+19zrTAirFktaKgapurTzlBH4=; b=DKIVNPlrcEIJyKxwoSxb2U1GyoVaiNpgiG+La8fkV7vYWRhMjMfFZw8KZRL2hakbJA GtfDnqB07yY4qqVhWa/OFnbLNKwY2Xq9wOvysfZccEkXVk91IxKoCgZ7Vd67on8hmt8q JjvsayFIiow0ZplXxLtVMhy56OAgBgyH3bWM9wmzwwgxi7OALMDZpelyHsZVxksrARxC T2dFmo5UuymjnEZ+jaatQ1TKqCqXJEy1hRi65KRAghFOTgxcaavfBEc54YBP7DRS+ZhB t3WWT7aQo9hlTJ7dcDQom8y4U9Puf1qLKRdBWGOWKfdauEUUCsmo7C5w7nDZ5eTIeaO1 7dKA== X-Gm-Message-State: ALoCoQnpmsXfGE/yOALIKhvcombbdlIouellDiDLN+u4zrX2QmiG6YROcF13RRHwS/HpyhW/ABuV X-Received: by 10.202.216.139 with SMTP id p133mr5428025oig.25.1446861277105; Fri, 06 Nov 2015 17:54:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.44.71 with HTTP; Fri, 6 Nov 2015 17:54:17 -0800 (PST) In-Reply-To: <3A98EA92-0C2F-46A7-8D06-880FC83CB110@gmail.com> References: <87twp91d8r.fsf@alice.fifthhorseman.net> <3A98EA92-0C2F-46A7-8D06-880FC83CB110@gmail.com> From: Andy Lutomirski Date: Fri, 6 Nov 2015 17:54:17 -0800 Message-ID: To: Bryan Ford 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: Sat, 07 Nov 2015 01:54:40 -0000 On Fri, Nov 6, 2015 at 5:46 PM, Bryan Ford wrote: > To return to this thread - DKG brought up one important potential > functionality goal for the next OpenPGP message format (streaming-mode > integrity protection); then the thread diverged into a different and I th= ink > orthogonal - though equally interesting - potential functionality goal > (namely random-access capability via Merkle trees as in Tahoe-LAFS). > > I included a slide on this topic in my OpenPGP WG presentation > (https://drive.google.com/file/d/0BwK1bcoczINtMEI2Y3A1Rm52SXc/view?usp=3D= sharing > slide 10) and was hoping to solicit discussion but there wasn=E2=80=99t t= ime, so > perhaps we can continue here? > > To be clear, there are two separate use-cases, each of which make sense > without the other and require different technical solutions (but could al= so > make sense together): > > 1. Streaming-mode integrity protection: We want to make sure OpenPGP can= be > used Unix filter-style on both encryption and decryption sides, to proces= s > arbitrarily large files (e.g., huge backup tarballs), while satisfying th= e > following joint requirements: > > (a) Ensure that neither the encryptor nor decryptor ever has to buffer th= e > entire stream in memory or any other intermediate storage. > (b) Ensure that the decryptor integrity-checks everything it decrypts BEF= ORE > passing it onto the next pipeline stage (e.g., un-tar). > > 2. Random-access: Once a potentially-huge OpenPGP-encrypted file has been > written to some random-access-capable medium, allow a reader to decrypt a= nd > integrity-check parts of that encrypted file without (re-)processing the > whole thing: i.e., support integrity-protected random-access reads. > > Let=E2=80=99s call these goals #1 and #2, respectively. > > Achieving either goal will require dividing encrypted files into chunks o= f > some kind, but the exact metadata these chunks need to have will vary > depending on which goal we want to achieve (or both). > > To achieve goal #1 properly, it appears that what we need is not only a M= AC > per chunk but a signature per chunk. If the encryptor only signs a singl= e > aggregate MAC at the end, then the decryptor needs to process its input a= ll > the way to that signature at the end before it can be certain that any (e= ven > the first) bytes of the decrypted data are valid. If the encryptor produ= ces > a Merkle tree at the end and signs its root as in Tahoe-LAFS (e.g., in > pursuit of goal #2), the decryptor still needs to read to the end of its > input before being able to integrity-check anything, and hence still fail= s > to achieve goal #1. > [...] > 1. How important is the ability to achieve goal #1 above in the OpenPGP > format (streaming-mode integrity-checking)? > Are you willing to accept a format that allows streaming decryption but not streaming encryption? If so, then you'd only need one signature if you organize your Merkle tree correctly. In fact: > 2. How important is the ability to achieve goal #2 above in the OpenPGP > format (random-access integrity-checking)? It's fairly easy to imagine a format that allows both streaming verification and random-access verification with minimal size overhead. You could even create the thing in a semi-streamy manner, where you'd stream out the bulk portion with blanks where the internal nodes go and then write the internal nodes after the fact. The best of all worlds might be to treat the Merkle data and the signature as a detached file. I bet that one could streamily encrypt and sign a big file and produce *two* output streams: the bulk data and a detached serialization of intermediate nodes, where there's a single signature at the end. A reader with access to both files could random-access it or seek the detached signature a bit and then stream the bulk file. --Andy From nobody Fri Nov 6 21:07:23 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 814431A9121 for ; Fri, 6 Nov 2015 21:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvOYpNHtzjU5 for ; Fri, 6 Nov 2015 21:07:18 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::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 9DE0A1A9060 for ; Fri, 6 Nov 2015 21:07:18 -0800 (PST) Received: by padhx2 with SMTP id hx2so134484234pad.1 for ; Fri, 06 Nov 2015 21:07:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=tR8IXTcDENES6GCWXp0DMgNo9xaYV2jnjkqEqZiEOQA=; b=jwGJ21qKrRFWAR5B6DCPuIKhJAd6MLp2dWTLqSI6RN6kAEtyBxICj7Q06iUm6GfXjr BCPy8wNn/y2krk+8vTMCIGq5YoKbfP0VHRUveHZ4lKuUl4xTDQaFhg6aRgpNRYDLZ4BG XuKaoubRxdqsB9ye6ml07KYTrDLYkeK9E+3UhQbl9bc+3xQfYxcGR+UEgrO+y3iERBAe p9Fkt4kUz1SFjYTy90K5UFYfOUuL4C7R2sxG1VmtXK8z/NiM1biTElQhYKm4WtLDU4QH BZV1LV1KVjoVBRkdcElrtWVLNJMxMrrV2OGQfTb47n1rO7YZQwf4eO52IFRtRl2gY3Az hd/g== X-Received: by 10.66.151.203 with SMTP id us11mr23160658pab.54.1446872838226; Fri, 06 Nov 2015 21:07:18 -0800 (PST) Received: from [10.11.0.66] (y255183.ppp.asahi-net.or.jp. [118.243.255.183]) by smtp.gmail.com with ESMTPSA id di2sm3067292pbc.64.2015.11.06.21.07.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Nov 2015 21:07:15 -0800 (PST) From: Bryan Ford Content-Type: multipart/signed; boundary="Apple-Mail=_37382D44-DA6B-486D-B4A2-93779441EFB9"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> Date: Sat, 7 Nov 2015 12:31:43 +0900 To: Christian Huitema , openpgp@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [openpgp] Keyholder-configurable fingerprint schemes? 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, 07 Nov 2015 05:07:21 -0000 --Apple-Mail=_37382D44-DA6B-486D-B4A2-93779441EFB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In the OpenPGP meeting, Christian brought up an idea that I thought was = interesting and perhaps deserved further consideration. Background summary: In the meeting a hum-poll was taken on the = =E2=80=9Csingle vs multiple fingerprints=E2=80=9D question, my = interpretation of whose result was that we should *not* create a system = that subjects users to juggling multiple, inconsistent fingerprints for = the same key (e.g., both a SHA-1 and a newer-hash-function-based = fingerprint for the same user=E2=80=99s public key). A =E2=80=9Cstrong = interpretation=E2=80=9D of that position is we should pick a single new = hash function for =E2=80=9Cnew fingerprints=E2=80=9D, and mandate that = all keys created with =E2=80=9Cnew signature schemes=E2=80=9D (e.g., = Ed448) have fingerprints computed using that new scheme, while leaving = the fingerprints of old schemes (e.g., RSA/DSA keypairs) fingerprinted = using the old approach to preserve consistency. A =E2=80=9Cweaker = interpretation=E2=80=9D of that position would be that for each new = signature scheme defined for use with OpenPGP, that scheme should also = define a suitable fingerprinting scheme to go along with it, but the = fingerprinting scheme may (in principle) vary from one =E2=80=9Cnew=E2=80=9D= keypair-type to another provided it remains consistent for any given = keypair. I see that the precise results of this hum-poll weren=E2=80=99t = precisely captured in Rich=E2=80=99s meeting minutes - understandable = since the precise results (or their proper interpretation) was a bit = fuzzy to me as well and I don=E2=80=99t feel confident either to suggest = exactly how that part of the minutes should be filled in. However, later in the meeting Christian brought up an interesting = possible approach to strengthening key-fingerprints against = prefix-attacks. For example, Eve wants to impersonate Alice, sees that = Alice=E2=80=99s fingerprint is 0x0413ecf2fd5e=E2=80=A6, assumes (likely = correctly) that most users are never going to eyeball-check more than = the first 8-10 digits or so, and simply invests some CPU time into = hunting for a public key whose fingerprint starts with (say) = 0x0413ecf2fd. This is of course the essential weakness that the = availability of =E2=80=9Cvanity fingerprints=E2=80=9D leads to: if you = can feasibly obtain a key with that vanity prefix, then likely so can = someone else who wants to impersonate you. My understanding of Christian=E2=80=99s idea (please correct me if = anything is inaccurate) is that we include some form of adjustable = proof-of-work (PoW) in the fingerprint creation process. For example, = the first digit of any fingerprint might indicate the general scheme (as = suggested elsewhere already), and the second digit of the fingerprint = might indicate the =E2=80=9Chardness parameter=E2=80=9D for the = scheme=E2=80=99s proof-of-work. If I=E2=80=99m generating a new = key-pair for myself, my OpenPGP implementation might either allow me to = choose the hardness parameter, or simply make some =E2=80=9Creasonable=E2=80= =9D choice on my behalf, such as the strongest PoW that completes in = whatever amount of time the user is willing to wait for key generation = on his/her device. I envision a =E2=80=9Cnice=E2=80=9D UI embodiment of = this might be for the key-generator to display, =E2=80=9CStrengthening = key fingerprint - currently at strength level # - click OK at any time = to stop and accept this strength level=E2=80=9D - where # gradually = increases as the key-generator solves progressively tougher PoWs. Once this fingerprint-generation process completes, the OpenPGP = key-generator then includes the PoW-protected fingerprint in the = keypair=E2=80=99s self-signed public key record. Anyone can quickly and = easily verify such a PoW-protected fingerprint against both the = public-key it is associated with and the hardness-factor it is = configured with (the second digit of the fingerprint). But now if Eve = wants to prefix-attack Alice=E2=80=99s public key by finding another key = whose PoW-protected fingerprint matches in the first (say) 10 digits, = she must compute on the order of B^8 proof-of-works of the same strength = as Alice=E2=80=99s (so the 2nd digit agrees) and using the same scheme = (so the 1st digit agrees), where B is whatever base the fingerprint = scheme uses (e.g., 16, 32, 64). This approach to fingerprint generation has the slightly-odd (certainly = unconventional) property that a single public/private keypair does not = have only one possible, deterministically-computed fingerprint (i.e., a = hash of the public key), but rather may in principle have many different = possible fingerprints (parameterized by the PoW and the salt that will = inevitably be required in that PoW). This might seem to violate the = =E2=80=9Cfingerprint consistency=E2=80=9D property that was discussed at = the meeting. However, as summarized above, my perception is that the = main fingerprint consistency concern is that we do not want to subject = users to multiple different fingerprints *for a single key*. In = Christian=E2=80=99s scheme, while any key could =E2=80=9Cin principle=E2=80= =9D have many different fingerprints, as long as the user generating the = key (or the user=E2=80=99s OpenPGP implementation) picks one particular = fingerprint and binds that fingerprint to the key in a fully verifiable = fashion as part of the self-signed public-key record, the fact that = fingerprint-generation is parameterized creates no user-perceivable = fingerprint-consistency issue that I can discern. So because of this, I have to say that I like the idea quite a lot in = general, and don=E2=80=99t see too many downsides other than a bit of = (significant but I think manageable) implementation complexity in = key-generation and key-verification for keypairs produced with new = signing schemes. There is of course the second-order question of =E2=80=9Cwhat type of = PoW exactly=E2=80=9D? Here are some (slightly random and divergent) = thoughts on this design space: 1. Just use a simple Bitcoin-like, hash-based PoW: i.e., if hardness is = K, you must hash the public key with different salts until you find one = whose hash starts with K zero-bits; then you use the remaining bits of = the hash to form the =E2=80=9Cactual=E2=80=9D key fingerprint. I think = this is more-or-less the PoW that Christian was suggesting, and seems = like a reasonable baseline design point (and may well be the only one we = should consider initially). 2. A =E2=80=9Cmemory-hard=E2=80=9D salted-hash scheme, such as the = Argon2 scheme to be used for passphrase hashing. Memory-hardness would = be nice to achieve, but schemes like Argon2 may not be directly = realistic in this context, because password-hashing schemes such as this = by design take a lot of work both at creation *and* verification time, = and we probably don=E2=80=99t want to impose seconds-long delays on = (say) importing someone=E2=80=99s key into my keyring and verifying its = consistency. It might not be completely a non-starter provided those = delays *only* occur during key-import and not overtime I touch or use = the key for any purpose, but it would still be a downer. Are there = =E2=80=9Cmemory-hard-to-create, but quick-to-verify=E2=80=9D PoW schemes = that might be worth considering? 3. Improving on Bitcoin-like PoWs in another direction, the recent = =E2=80=9CRandom Zoo=E2=80=9D paper by Arjen Lenstra=E2=80=99s group at = EPFL suggested a hard-to-generate, easy-to-check PoW scheme that also = tries to be *hard to parallelize*. In principle it would be very nice = if we could achieve such a hard-to-parallelize property in protection = against fingerprint-prefix attacks. However, it=E2=80=99s unfortunately = not as simple as just, say, adopting the modular-root-computation = primitive that the Random Zoo scheme uses for choosing bias-resistant = random numbers, because in the PoW-protected fingerprint application Eve = would still have available to her the =E2=80=9Cembarrassingly = parallel=E2=80=9D opportunity of running in parallel all her (say) B^8 = attempts to create a key whose PoW-protected fingerprint looks like = Alice=E2=80=99s. This suggests the question: is it possible to limit an = attacker=E2=80=99s (Eve=E2=80=99s) number of concurrent, parallel = =E2=80=9Cattack threads=E2=80=9D using different keys? I don=E2=80=99t = know, and it=E2=80=99s probably not easy, but perhaps worth thinking = about. 4. Leading in perhaps an even more far-fetched but interesting = direction, is it possible to ensure that Eve must incur some large = *financial* cost in order to prefix-attack Alice=E2=80=99s key = successfully? As a straw-man approach, suppose the work-factor encoded = in the 2nd digit of such a fingerprint scheme encodes the log2 of a = number of Bitcoins, which the key-creator must =E2=80=9Cverifiably = discard=E2=80=9D in order to validate the fingerprint. (It=E2=80=99s = easy to create a Bitcoin transaction that verifiably discards money: = just sign the coins over to a public key whose value is the output of a = hash, to which w.h.p. no one is ever going to be able to find a = corresponding private key with which to spend the coins.) Thus, Alice = must obtain and verifiably discard a small amount of Bitcoin - the = amount of her choosing - when generating the key; then if Eve wants to = prefix-attack Alice=E2=80=99s key she must spend around B^8 times the = amount of Bitcoin that Alice spent in order to match the first 10 = digits. The obvious practical issue here is that both the key-generator = and anyone importing and checking Alice=E2=80=99s key needs to talk to = the Bitcoin network to verify the presence of the relevant = coin-discarding transaction in the blockchain. Again not necessarily a = complete show-stopper in principle as long as this typically only has to = be done during key-generation and key-import, but still I=E2=80=99m not = sure how many OpenPGP implementors necessarily want to incorporate a = Bitcoin client into their OpenPGP implementations. :) At any rate, independent of these varying possible approaches to = fingerprint PoWs, I feel like at least the first approach above that = Christian suggested (simple PoW) seems practical, offers a nice = parametrizable strengthening against prefix attacks, and doesn=E2=80=99t = violate the essential consistency issue that users should need to deal = with only one fingerprint *per keypair*. And if we were careful in = specifying how the fingerprint-generation and fingerprint-validation = mechanism works, we could easily leave the door open to different, = further strengthened (and perhaps user-selectable) fingerprint = protection mechanisms later. Thoughts? Thanks Bryan --Apple-Mail=_37382D44-DA6B-486D-B4A2-93779441EFB9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTExMDcwMzMxNDNaMCMGCSqGSIb3DQEJBDEWBBSBI1jrMc1ygyNukl8K6qsl/vLfiTCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAiWadTpmz4M8uC45YjCvT6Y5EKhRGLVkS0IseBpnn7Px4VgBslLqbEalBPz/rDq5y OL1d/e4uXoD1pgUDqcICGMCkHolK7V8+qxVerxyxTtusvT137tKkgx5q8C8E+Y52Lnya+mUmgPei sdKgu4gUP/VWyiYeIpJzQykLbKuUsScXsw//eK/WCMCTAjWXFokpKz54ZLJl+aLwDX8sZCoyAS7M 1W+glLnmpJ5BQSSqnF4gpjM5mwvtnwJ4jv8tIvIvlpk0p4j3l0y3mQCPSFteu0tAUdexTd6LrsDW uzhpnDYNGTWsoyb99gBAKvcDUmmSsdD3vbLNjMlcvxn3JBDruwAAAAAAAA== --Apple-Mail=_37382D44-DA6B-486D-B4A2-93779441EFB9-- From nobody Fri Nov 6 23:19: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 DA3D01B2BC0 for ; Fri, 6 Nov 2015 23:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 ubThPA_lWoZe for ; Fri, 6 Nov 2015 23:19:25 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::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 6A2691B2BBF for ; Fri, 6 Nov 2015 23:19:25 -0800 (PST) Received: by pacdm15 with SMTP id dm15so120874576pac.3 for ; Fri, 06 Nov 2015 23:19:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=HGFUjSK9NCc5Aa4yAheTqHiQS29ajPSGyTc6qkqW758=; b=xNFYu71mzT3E73fxlEMExhI12+YutTGNvz3eHRmewQyNvmbkY/x7ckR8cn78dG3j97 zqbFX3x8ToT1IBcRUqtDKBcu2RGRRmmUiSYLmm/z1YqEnjMJFPUfYnz+sntke1LtkDsu 9qt4uepHxbst8hwiEEND9w3k8Zgt0yQi3cvDZiU39M/yVZtT7tf2z49MgyW5JF8cwtYD GQV70ZysyeKSkY3TVmHzzIHv5mk61Tknofy+1SKBdIHeEovEdx7jreT3QWQ5LoRzn/Gg XGIS84sVt1yNPlmMCDtUshmW8JAcURHLgoUe931yo0da3kRKMWsfO3y7+c8jHRuf+kw9 jnuA== X-Received: by 10.67.13.107 with SMTP id ex11mr23656196pad.126.1446880765004; Fri, 06 Nov 2015 23:19:25 -0800 (PST) Received: from [10.11.0.66] (y255183.ppp.asahi-net.or.jp. [118.243.255.183]) by smtp.gmail.com with ESMTPSA id rm10sm3334560pbc.96.2015.11.06.23.19.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Nov 2015 23:19:23 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_00EB7649-793A-42AD-B008-E1C26609DC92"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Bryan Ford In-Reply-To: Date: Sat, 7 Nov 2015 16:19:21 +0900 Message-Id: <663BA6ED-0316-4A14-AA28-EC4880CDD6D0@gmail.com> References: <87twp91d8r.fsf@alice.fifthhorseman.net> <3A98EA92-0C2F-46A7-8D06-880FC83CB110@gmail.com> To: Andy Lutomirski X-Mailer: Apple Mail (2.2104) 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: Sat, 07 Nov 2015 07:19:28 -0000 --Apple-Mail=_00EB7649-793A-42AD-B008-E1C26609DC92 Content-Type: multipart/alternative; boundary="Apple-Mail=_FBE92D17-674E-4572-9126-0320BEFAFE31" --Apple-Mail=_FBE92D17-674E-4572-9126-0320BEFAFE31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 7, 2015, at 10:54 AM, Andy Lutomirski = wrote: > On Fri, Nov 6, 2015 at 5:46 PM, Bryan Ford > wrote: >> 1. How important is the ability to achieve goal #1 above in the = OpenPGP >> format (streaming-mode integrity-checking)? >=20 > Are you willing to accept a format that allows streaming decryption > but not streaming encryption? If so, then you'd only need one > signature if you organize your Merkle tree correctly. In fact: That=E2=80=99s certainly one reasonable use-case to consider, but I = don=E2=80=99t think it fully satisfies the =E2=80=9Cfilter-mode = encrypted backup=E2=80=9D scenario that DKG originally brought up. If = I=E2=80=99m encrypting and streaming my huge backups to a huge network = connection, then I don=E2=80=99t want the encryption side to have to = store the whole huge backup tarball locally either. My intuition is = that if the "filter-mode streaming backup=E2=80=9D scenario is important = on either the encryption or decryption side, then it=E2=80=99s probably = important to be able to handle on both sides. On the other hand, it might be quite reasonable to define an encrypted = message format that allows either mode of operation, and have the = encryptor choose the mode of operation automatically depending on the = situation. If the encryptor sees that both its input and its output are = regular files, i.e., it knows the total length of its input and can seek = in its output, then the encryptor could (as you suggest) leave room for = a signed Merkle tree at the beginning, process everything, then go back = to the beginning and fill in the Merkle tree and the signature on its = root. Then a streaming-mode decryptor would get the signed Merkle tree = first and subsequently be able to integrity-check all subsequent chunks = independently. However, if the encryptor finds that either it doesn=E2=80= =99t know the length of its input in advance, or has been told to send = output to a non-seekable stream (e.g., over an SSH-forwarded network = pipe), then the encryptor might have to fall back to a more incremental = approach, with signatures (or signature-plus-incremental-Merkle-trees) = after each chunk. >> 2. How important is the ability to achieve goal #2 above in the = OpenPGP >> format (random-access integrity-checking)? >=20 > It's fairly easy to imagine a format that allows both streaming > verification and random-access verification with minimal size > overhead. You could even create the thing in a semi-streamy manner, > where you'd stream out the bulk portion with blanks where the internal > nodes go and then write the internal nodes after the fact. >=20 > The best of all worlds might be to treat the Merkle data and the > signature as a detached file. I bet that one could streamily encrypt > and sign a big file and produce *two* output streams: the bulk data > and a detached serialization of intermediate nodes, where there's a > single signature at the end. A reader with access to both files could > random-access it or seek the detached signature a bit and then stream > the bulk file. I think detached files sound convenient to implementers but prove = troublesome to users who need to know how to juggle and keep track of = two files where before they only need to keep track of one. :) B >=20 > --Andy --Apple-Mail=_FBE92D17-674E-4572-9126-0320BEFAFE31 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Nov 7, 2015, at 10:54 AM, Andy Lutomirski <luto@amacapital.net>= wrote:
On Fri, Nov 6, 2015 at 5:46 PM, Bryan Ford = <brynosaurus@gmail.com> wrote:
1. How important is the = ability to achieve goal #1 above in the OpenPGP
format = (streaming-mode integrity-checking)?

Are you willing to accept a format that allows = streaming decryption
but not streaming = encryption?  If so, then you'd only need one
signature if you organize your Merkle tree = correctly.  In fact:

That=E2=80=99s certainly one reasonable use-case = to consider, but I don=E2=80=99t think it fully satisfies the = =E2=80=9Cfilter-mode encrypted backup=E2=80=9D scenario that DKG = originally brought up.  If I=E2=80=99m encrypting and streaming my = huge backups to a huge network connection, then I don=E2=80=99t want the = encryption side to have to store the whole huge backup tarball locally = either.  My intuition is that if the "filter-mode streaming = backup=E2=80=9D scenario is important on either the encryption or = decryption side, then it=E2=80=99s probably important to be able to = handle on both sides.

On the other = hand, it might be quite reasonable to define an encrypted message format = that allows either mode of operation, and have the encryptor choose the = mode of operation automatically depending on the situation.  If the = encryptor sees that both its input and its output are regular files, = i.e., it knows the total length of its input and can seek in its output, = then the encryptor could (as you suggest) leave room for a signed Merkle = tree at the beginning, process everything, then go back to the beginning = and fill in the Merkle tree and the signature on its root.  Then a = streaming-mode decryptor would get the signed Merkle tree first and = subsequently be able to integrity-check all subsequent chunks = independently.  However, if the encryptor finds that either it = doesn=E2=80=99t know the length of its input in advance, or has been = told to send output to a non-seekable stream (e.g., over an = SSH-forwarded network pipe), then the encryptor might have to fall back = to a more incremental approach, with signatures (or = signature-plus-incremental-Merkle-trees) after each chunk.

2. How important is the ability to achieve goal #2 = above in the OpenPGP
format (random-access = integrity-checking)?

It's fairly easy to imagine a format that allows = both streaming
verification and = random-access verification with minimal size
overhead.  You could even create the thing = in a semi-streamy manner,
where you'd stream out the = bulk portion with blanks where the internal
nodes go and then write the internal nodes after = the fact.

The best of all worlds = might be to treat the Merkle data and the
signature as a detached file.  I bet that = one could streamily encrypt
and sign a big file and = produce *two* output streams: the bulk data
and a detached serialization of intermediate = nodes, where there's a
single signature at the = end.  A reader with access to both files could
random-access it or seek the detached signature = a bit and then stream
the bulk file.

I think = detached files sound convenient to implementers but prove troublesome to = users who need to know how to juggle and keep track of two files where = before they only need to keep track of one. :)

B


--Andy

= --Apple-Mail=_FBE92D17-674E-4572-9126-0320BEFAFE31-- --Apple-Mail=_00EB7649-793A-42AD-B008-E1C26609DC92 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTExMDcwNzE5MjJaMCMGCSqGSIb3DQEJBDEWBBSWYldrArrOKRdiCRLyOanfoO7qZjCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEALznLKkpoADT7FcOLa9ff57Dn5y1ai9lRyCfhBno9pvmQTR70a73X600lK9aCdNvZ bv6LA8KVlDMTmGCHYGsHA40qxzHzg6JrH9rOfXoLHsqmk+TNMw2tmxPW0dq0H1ALPFbtGW4xo94j rAGqoTZyOjaO4YgXE1uH5pdGj5M7tDcQOkFgb7mMCx7FZsTLA/p7VMJl7DFQ/DqRG0x0slAM0BBO Cs/dq25DrRGG5VO+GXoJn1HLOb5aJEqXxV8alK1r7M7JgYNMW1vCWaQnIbuLtHXvsVN+zpfAKUin oqzoct2ct9cD9pPST8UQed9cjFes1XYQK8jqXg4tbs7H9cGQPAAAAAAAAA== --Apple-Mail=_00EB7649-793A-42AD-B008-E1C26609DC92-- From nobody Sat Nov 7 03:34:12 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 B8E4A1B3223 for ; Sat, 7 Nov 2015 03:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 6Xl4Uj8uAdwk for ; Sat, 7 Nov 2015 03:34:03 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::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 CC6F21B3221 for ; Sat, 7 Nov 2015 03:34:02 -0800 (PST) Received: by pacdm15 with SMTP id dm15so125095703pac.3 for ; Sat, 07 Nov 2015 03:34:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=O98G160aSczmjs0LI5VUl3Q26JsRRcL4KY8ndtX7h5c=; b=MU6I7Vf0h2e6fgQPxrc2lT4LTdHLV56liEEjaRqIa9b9LgJeNLwg/MAfUVssiE+N7U BzGMCBns3AwnrFL+DxibNGD1NahpB5JTC8k5zbZ2ImG52gcKgRGlCjOjV49DwfwXYefr KUCqA26UaVMEr2HbRH7EB+WOAi0L10D9TDKhnKqrySPEAMjug6Js1F+U7OzEM+1S9YQQ k89Ukbn5mTGHTXurrQBgDgrHvat4jLqTptQwOWOUctySVbxJB82Gcs3iCnyqjknsgskN MBhU+dDStXStFfnnkjuBzymo7oyyf5dHdE2yQ8K+Tj/KwvewXFiK5W4/p+Zk0guA+Ogr +5iQ== X-Received: by 10.69.26.36 with SMTP id iv4mr25068830pbd.0.1446896042438; Sat, 07 Nov 2015 03:34:02 -0800 (PST) Received: from [10.11.0.66] (y255183.ppp.asahi-net.or.jp. [118.243.255.183]) by smtp.gmail.com with ESMTPSA id ws6sm5411078pbc.33.2015.11.07.03.33.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Nov 2015 03:34:00 -0800 (PST) From: Bryan Ford Content-Type: multipart/signed; boundary="Apple-Mail=_2DB6DB06-D96C-4406-9458-FC9C96D1CD24"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <160A8D98-3DF8-4F51-A38C-EF3E0DAE71EE@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Date: Sat, 7 Nov 2015 20:33:59 +0900 References: <86CB1513-F594-4A9B-A3B6-17ECB9CA9EB6@isoc.org> To: "openpgp@ietf.org" In-Reply-To: <86CB1513-F594-4A9B-A3B6-17ECB9CA9EB6@isoc.org> X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [openpgp] Reducing the meta-data leak 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, 07 Nov 2015 11:34:10 -0000 --Apple-Mail=_2DB6DB06-D96C-4406-9458-FC9C96D1CD24 Content-Type: multipart/alternative; boundary="Apple-Mail=_00CAF971-64DA-4EBB-ADA9-DC6A28D55DE8" --Apple-Mail=_00CAF971-64DA-4EBB-ADA9-DC6A28D55DE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m glad to see the metadata-leakage protection topic drawing = some interest, including some healthy skepticism on whether it=E2=80=99s = practical. :) I=E2=80=99ll try to summarize my scheme at least somewhat concisely, and = include this in a draft-of-a-draft that I have in progress. A = bare-bones (i.e., incomplete, badly-documented) but working = proof-of-concept implementation of this scheme is actually implemented = in the dedis crypto library for Go, available here: Code: https://github.com/DeDiS/crypto/tree/master/nego = GoDoc: https://godoc.org/github.com/DeDiS/crypto/nego = But I would recommend reading the conceptual summary below before trying = to understand the code. :) The main desirable properties the scheme has are (a) it produces uniform = random blobs with no unencrypted metadata; (b) it supports multiple = encryption schemes, both passphrase and/or public-key - though =E2=80=9Cto= o many=E2=80=9D schemes would get costly; (c) it supports multiple = passphrase and/or recipient public keys with each scheme; (d) for a = given scheme and a given passphrase or private key held by a recipient, = the recipient needs to perform at most one public-key crypto operation = and O(log N) symmetric-key crypto operations - and to read a similarly = small part of the input - in order to determine if the file is encrypted = for this recipient passphrase/keypair and unlock it if so. Let=E2=80=99s work from a simple case to progressively more = =E2=80=9Cinteresting=E2=80=9D and general cases: 1. Encryption using a single scheme (e.g., a single well-known = =E2=80=9Cciphersuite=E2=80=9D) via a single passphrase. 2. Single symmetric-key scheme, but multiple alternative passphrases = using that scheme. 3. Single public-key encryption scheme, with message encrypted for one = or multiple public keys compatible with that scheme. 4. Multiple symmetric and/or public-key schemes, allowing multiple = different passphrases and recipient public-keys each, respectively. =E2=80=94 1. Suppose simplistically we only want single-passphrase encryption = using a single well-known encryption scheme. More-or-less as usual for = PGP, we (a) choose a random session key, (b) use a password-hashing = scheme such as Argon2 to produce a symmetric encryption key that is used = to AEAD-encrypt the file=E2=80=99s session key, and (c) use the session = key to AEAD-encrypt the file=E2=80=99s content. Assume for now that we = encrypt the file in one big chunk, though chunking (with metadata = encryption) can be added as well using existing techniques (e.g., those = mentioned earlier analyzed in the context of SSH). So we basically have three important blobs of data to place in the file: = (a) the salt for the password-hashing scheme, (b) the AEAD-encrypted = session key encrypted using the password-hasher=E2=80=99s output, and = (c) the AEAD-encrypted file content encrypted using the session key. = Item (a) needs to be encoded in the file in =E2=80=9Ccleartext=E2=80=9D = since it needs to be available to the decryptor before it can decrypt = anything, but fortunately the salt can just be a uniformly random blob = anyway (of a length fixed by this well-known scheme). So for the moment = let=E2=80=99s just put it at the very beginning of the encoded file. = Then place the AEAD-encrypted session key blob (b) immediately = afterwards, whose size can also easily be fixed for this scheme. This = fixed-length session-key blob may contain encrypted metadata in addition = to the session key, such as the file offset of the AEAD-encrypted file = content, the (possibly padded) total size of the AEAD-encrypted blob, = and perhaps the size of the =E2=80=9Cuseful payload=E2=80=9D within that = blob after removing any padding. This metadata will of course appear as = uniform random bits to a non-recipient as long as the AEAD encryption = scheme is doing its job. Finally, place the AEAD-encrypted file content = (c), including any padding, after the encrypted session-key blob as the = rest of the file. =E2=80=94 Single passphrase-encryption scheme, multiple passphrases: Now assume we want to encrypt with multiple passphrases. Perhaps not a = highly compelling case, but it=E2=80=99s conceptually simpler to start = with than multiple recipient public-keys but addresses the same = technical issues. The approach Neal suggested of using Bloom filters is = not far off, but we at least wouldn=E2=80=99t want to use *unencrypted* = Bloom filters that might look distinguishable from random bits. As a straw-man design suppose we just pick an upper-bound on the number, = say N, of different passphrases with which we expect anyone might ever = want to encrypt a file. Then we lay out the encrypted file as follows: = (a) a single, uniformly random password-salt value of fixed length comes = first in the file, followed by (b) a hash table with room for not just = one but N consecutive AEAD-encrypted session-key blobs of the same kind = as for the single-password scheme above, and finally (c) the = AEAD-encrypted file content. Both the encryptor and decryptor use the = salt to hash the user=E2=80=99s password, then hash the output of that = to form both the AEAD-encryption key for the session-key blob and an = index into the N-entry hash table. The decryptor then simply attempts = to AEAD-decrypt and check that particular hash-table entry - or to allow = for rare hash collisions, attempts to decrypt (say) three consecutive = hash-table entries starting at that position and wrapping around mod N. = If any of those AEAD-decryptions works, the decryptor wins; if not, the = decryptor gives up and decides the passphrase doesn=E2=80=99t work. Since each passphrase will produce a different (pseudo-random) = hash-index, the session-key blobs for different passphrases will = typically occupy different positions in the hash-table, thereby allowing = decryption using any of the corresponding passphrases. Hash collisions = may occur, but if the number of actual passphrases is not too close to N = (i.e., the hash table not too full), the encryptor should be able to = squeeze in session-key blobs for all of them using the =E2=80=9Cslop=E2=80= =9D allowed by the 3-tries (or k-tries) search rule above, and/or by = simply retrying everything from scratch with a fresh salt if that = doesn=E2=80=99t work. Once the hash table is laid out and filled with = all useful session-key blobs, all remaining unused entries are just = filled with uniform random bits, so anyone not holding one of the = passphrases can=E2=80=99t distinguish =E2=80=9Cfull=E2=80=9D from = =E2=80=9Cempty=E2=80=9D hash-table entries. Now the next step we=E2=80=99d like is to avoid having to pick a = particular value of N: too large and we=E2=80=99re wasting a lot of = space at the beginning of every file on a hash table that often will = probably have only 1 entry populated; too small and we don=E2=80=99t = allow for multiple session key blobs. So instead of including just one = hash table in the file, we include a variable-length sequence of hash = tables whose sizes increase by powers of two. Thus, immediately after = the password-hashing salt, we encode a 1-entry hash table, followed by a = 2-entry hash table, followed by a 4-entry hash table, etc., stopping = wherever the encoder feels like stopping. The encoder takes the = passphrases it=E2=80=99s supposed to encrypt the file with, and = successively creates an encrypted session-key blob for each passphrase, = storing it at the appropriate hashed position (for that passphrase) - or = within a 3-tries distance - in the lowest-numbered hash table that has = room for it. Then the encoder writes out to the encrypted file: (a) the = common password-encryption salt, (b) all the *non-empty* hash tables = starting from the size-1 table, with any empty entries filled with = uniform random bits, and (c) the AEAD-encrypted file content, as usual. = Note that the encryptor can =E2=80=9Clay out=E2=80=9D the header and = figure out how many hash tables are actually needed before it does the = AEAD-encryption of the session key blobs, which means those session key = blobs can still contain the file offset and length metadata pointing to = the encrypted file content. On the decryptor side, given the salt at the beginning of the file and = the user=E2=80=99s passphrase, the decryptor now needs to generate a = hash-index for each possible hash table and try decrypting a few = consecutive entries per hash table. Neither the decryptor, nor anyone = else, initially knows the number of hash tables in the file. But note = that the decryptor only needs to do a single expensive password-hashing = operation (with that one salt and the entered password). Also, since = the total number of hash tables is log2(N) where N is an upper-bound on = the number of recipients, the total number of symmetric-key = trial-decryptions the recipient needs to perform to see if the = passphrase =E2=80=9Cworks" is O(log N), regardless of the number of = passphrases the file was actually encrypted for. We might want to set = some kind of upper bound on the maximum size that the header portion = might be, of course, but that can probably be fairly large (e.g., 1MB) = since it=E2=80=99s just an upper bound. In the common case when a file = is encrypted with only one passphrase, only the first, size-1 hash table = is non-empty, and the encrypted file is just as compact as it would be = in the =E2=80=9Cnaive=E2=80=9D base-case design above that only supports = a single passphrase. =E2=80=94 Single public-key encryption scheme, multiple recipient public keys: =20 We now assume that we wish to encrypt a file so as to be decryptable by = multiple receivers, the encoder has public keys for all those receivers, = and (most importantly) all those receivers=E2=80=99 public keys are in = the same group: e.g., they are all Ed25519 keys or all Ed448 keys. This = assumption is not very realistic for =E2=80=9Clegacy=E2=80=9D DSA keys = and not realistic at all for RSA keys, but let=E2=80=99s assume we=E2=80=99= re willing to live with that restriction at least for =E2=80=9Cnew=E2=80=9D= files encrypted this way. Structurally, the public-key multiple-receivers scheme works exactly the = same as above for passphrase encryption, but the encryptor (a) replaces = the password-hashing salt at the beginning of the file with an = Elligator-encoded ephemeral Diffie-Hellman public key, whose = corresponding private key was freshly picked by the encryptor; (b) = computes a shared Diffie-Hellman master secret using this ephemeral = private key and each receiver=E2=80=99s public key (which as stated = above we assume all to be in a common group); and (c) AEAD-encrypts all = the session-key blobs in the hash tables using these Diffie-Hellman = master secrets instead of password-based secrets. Everything else about = hash table layout and such works exactly the same way as discussed above = for multiple passphrases. For those not familiar with Elligator and its follow-on work (e.g., = Elligator 2, Elligator Squared, Binary Elligator Squared), all are ways = to encode an elliptic curve point usable for Diffie-Hellman key = exchange, such that the encoding appears indistinguishable from uniform = random bits. Different schemes apply to different subsets of elliptic = curves and impose different tradeoffs: e.g., the original scheme works = only for certain curves (including Ed25519) and is very compact but may = require the encoder to retry the generation of the ephemeral DH point = several times (no big deal in practice); other later schemes are a bit = less compact (e.g., require 2x the space for the representation) but = less constrained and can encode any point on the curve rather than only = about half the points, etc. The details aren=E2=80=99t important for = present purposes; only the fact that they exist and they work. :) So because Elligator encodes the initial DH key in uniform = representation, and everything else in the file is either an = AEAD-encoded blob or just random bits, the whole file looks like uniform = random bits to anyone not holding one of the recipients=E2=80=99 private = keys. A non-recipient can=E2=80=99t even tell whether the file is = encrypted to just one recipient (the Elligator-encoded point followed by = the size-1 hash table followed by the encrypted file content) or to many = (the Elligator point followed by several hash tables). The decryptor = doesn=E2=80=99t know this either without trying, but the decryptor only = needs to do the one public-key DH agreement calculation to compute its = ephemeral secret shared with the encryptor, and then perform at most = O(log N) AEAD trial decryptions to see if its key works near the = appropriate indexes of any of the O(log N) hash tables. =E2=80=94 4. Multiple symmetric-key and/or public-key schemes: This is where things start to get still a bit more hairy, although the = underlying principles remain pretty similar. The problem now is that we = may now have multiple, different and incompatible encryption schemes: = e.g., we might want to encrypt a file both with a passphrase *and* for = several public-key recipients, some of whom have (say) Ed25519 keypairs = while others have Ed448 keypairs while others have NIST P-* keypairs. = We=E2=80=99ll assume (a) that all public-key schemes are in = DH-compatible, Elligator-encodable groups of some kind, and (b) we will = administratively avoid needing to support a huge number of different = schemes all at once. (It feels like this assumption is compatible with = where the CFRG and OpenPGP WGs are headed anyway.) So as should be clear from the above by now, the =E2=80=9Ccornerstone=E2=80= =9D of each scheme is a salt value in the case of a passphrase scheme, = and an Elligator-encoded point in the case of a public-key scheme. = Passphrase salts can just be unstructured random bits, so in that case = one might imagine just starting the file with a single =E2=80=9Ccommon = salt=E2=80=9D large enough to seed all the passphrase-based schemes we = might want to support (if we even want to support more than one in a = given file, which might be unlikely). But an Elligator-encoded point = must be created rather carefully such that the encryptor knows the = corresponding private key for DH agreement, so it=E2=80=99s not feasible = to dump some random bits at the beginning of the file and expect it to = be usable as multiple different Elligator points for multiple different = curves: we really need to encode multiple distinct Elligator points for = distinct curves so that they=E2=80=99re all independently decodable. =20 Further compounding the challenge, we don=E2=80=99t want the decryptor = to have to perform multiple expensive public-key operations (or multiple = expensive password-hashing operations) per scheme. We can=E2=80=99t = avoid the decryptor having to do *one* expensive public-key or = password-hashing operation per scheme that the user might hold a key = for: e.g., if the user=E2=80=99s keychain holds both an Ed25519 private = key and an Ed448 private key, we=E2=80=99ll have to do two Elligator = point decodes and two DH key agreements, but we want to avoid having to = do more than two. (And for the common-case of users holding only one = private key, we want the user to have to do only one DH key agreement.) So to solve this, we=E2=80=99ll use a multiple-hash-table approach = similar to the above to allow a file to contain multiple = =E2=80=9Ccornerstone=E2=80=9D values (password salts and/or Elligator = points) at the beginning, but slightly modified to avoid the need for = multiple trial decryptions. For each scheme, we take that scheme=E2=80=99= s cornerstone value (e.g., Elligator point), and first round its size up = to the next power of two. Next, for each scheme, we pick (via = standardization) an upper bound on the total number of other *schemes* = we want this scheme to be compatible with now and in the near future = (i.e., number of other distinct cornerstone values we need to encode at = the beginning of the file). For each scheme, we then standardize a = small number of possible positions for that scheme=E2=80=99s cornerstone = value, perhaps chosen more-or-less randomly (but statically), one = position per hash table within a small number of hash tables laid out in = increasing power-of-two sizes exactly as earlier for session-key blobs. = We ensure, again via standardization, that among the set of schemes we = want to be compatible with each other, each scheme has at least one = possible position (perhaps the largest) for which its cornerstone can be = encoded so as to be disjoint and non-overlapping with at least one = possible position of every other scheme. For example, suppose we want to support Ed25519, Ed448, and P-384, and = may want to support other schemes later on whose recipient keys can be = intermixed with keys from these schemes. Let=E2=80=99s say that we can = Elligator-encode an Ed25519 point in 32 bytes (true), we can = Elligator-encode an Ed448 point in 64 bytes (not sure about this, but = either that or a 128-bit encoding should be feasible). We might pick 3 = possible cornerstone-value positions for each of these schemes as = follows: Ed25519: offset 0, offset (32 or 64), and offset (96, 128, 160, or 192). Ed448: offset 0, offset (64 or 128), and offset (192, 256, 320, or 384). For each of the parenthesized alternatives, give the OpenPGP WG chairs a = coin during some meeting and have them flip it to pick one of the two or = four alternatives for the second and third possible position for each = scheme. :) Future schemes we might add will come with their own list of possible = cornerstone-value positions, which can be of varying lengths, and = similarly can overlap (though all of them should have 0 as the base-case = offset) provided we maintain the invariant that each scheme we still = care about has some unique position that doesn=E2=80=99t overlap with = any other scheme we still care about. We can also optimize the possible = positions more carefully if we choose; the above example is just to keep = things conceptually simple. Now, when the encryptor is encrypting an OpenPGP file, it creates a = cornerstone value suitable for each scheme, and picks a position for = each scheme=E2=80=99s cornerstone value from the fixed list of available = positions for that scheme, such that the actually-picked cornerstone = value positions are as low as feasible but don=E2=80=99t overlap. For = example, if a file is encrypted with both Ed25519 and Ed448 receiver = keys, the =E2=80=9Cbest=E2=80=9D set of positions from those above might = be position 0 for the Ed448 key and position 64 for the Ed25519 (other = choices would also work but be a bit less space-efficient). But now the = encryptor needs to encode these cornerstone values so that the decryptor = can get exactly the cornerstone value it needs, on the =E2=80=9Cfirst = try=E2=80=9D, without actually knowing at which possible position for a = given scheme it was encoded. So here=E2=80=99s the trick: we use a variant of DC-nets or PIR-type = encoding techniques to =E2=80=9Canonymize=E2=80=9D the true position at = which a given cornerstone value is encoded. In particular, the encoder = arranges the file such that for each scheme, the decoder reads *all* of = the possible cornerstone value positions for that scheme, and XORs them = together, to reconstruct the =E2=80=9Cactual=E2=80=9D cornerstone value = for that scheme. That is, to get the Elligator-encoded Ed25519 point, = the decoder will read the 32 bytes starting at each of the three = positions defined for Ed25519, then XOR these 32-byte sequences = together, and use that as the Ed25519 point. Similarly for the other = schemes. The important point is that as long as the encoder picks some = =E2=80=9Cworkable=E2=80=9D order in which to encode all the cornerstone = values, it can treat previously-encoded cornerstone values in one scheme = as =E2=80=9Cnoise=E2=80=9D to be canceled (via XOR) when encoding = cornerstone values for other schemes. For example, suppose the = encryptor encodes the Ed448 point first at file offset 0. The encoder = fills the second and third possible positions for Ed448 with random = bits, then XORs those alternative positions with the actual Ed448 = cornerstone value and writes the result at offset 0. Now the = byte-ranges corresponding to those positions are fixed and no longer = changeable, but can be included as =E2=80=9Cnoise=E2=80=9D to be = canceled in writing other cornerstone values. For example, say now the = encryptor wants to encode the Ed25519 point: it obviously can=E2=80=99t = put it at position 0, but hopefully the second or third alternative = position for Ed25519 should be non-overlapping with the already-locked = Ed448 point positions. Say the second Ed25519 position is still = available: the encryptor fills the third position with random bits (and = the first, offset-0 position has already been filled with random-looking = bits), then XORs the contents of the first and third Ed25519 positions = and the true cornerstone value to fill the second Ed25519 position. OK, so it might look like we=E2=80=99ll always need to reserve a fairly = large chunk of header space for these cornerstone values (e.g., ~448 = bytes in the above example depending on the precise choices of the = cornerstone value positions). But it turns out that=E2=80=99s not true, = provided we (a) first reserve space for only *one* suitably-chosen = cornerstone-encoding position per scheme, (b) then lay out all the hash = tables containing symmetric-key blobs for all the schemes, (c) then lay = out and encrypt the file=E2=80=99s contents (or its first = substantial-size chunk of data in the streaming case), (d) encrypt all = the session-key blobs of all schemes into appropriate, already-reserved = positions in those schemes=E2=80=99 respective hash tables, (e) fill all = remaining unreserved space in this whole variable-length header region = with random bits, and finally (f) encode the cornerstone values at the = very end. This way, some of the possible positions for the cornerstone = values of each scheme can actually overlap with symmetric-key blobs = generated by the same or other schemes, since all those random-looking = bits will just be treated as pre-existing noise that gets XORed together = with the =E2=80=9Ctrue=E2=80=9D cornerstone value to be filled into the = =E2=80=9Clast position=E2=80=9D for the corresponding scheme. Going back to the question of the hash tables for the session-key blobs, = note that although we now have multiple hash tables of different sizes = for several different schemes, all those hash tables can actually = overlap, provided the encoder handles its layout properly. For example, = each scheme=E2=80=99s smallest, size-1 hash table might always be = defined to start immediately after the offset-0 position for that = scheme=E2=80=99s cornerstone value, and successive hash tables grow from = there. As the encryptor is choosing positions for session-key blobs in = any schemes, it basically just looks for a byte-range in one of that = scheme=E2=80=99s hash tables that hasn=E2=80=99t yet been allocated by = that or any other scheme. Thus, in the very likely common case of a file being encrypted to only = one recipient under only one scheme (e.g., Ed25519), the file can always = be =E2=80=9Cas small as possible=E2=80=9D and consist of simply (a) the = elligator-encoded Ed25519 cornerstone point for DH agreement, (b) the = single session-key blob encrypted using the DH key shared between the = encryptor=E2=80=99s cornerstone keypair and the recipient=E2=80=99s = keypair, and (c) the variable-length encrypted file content itself, all = back-to-back in one uniformly-random-looking blob. If a few but not = many different recipients are to be included in one or a few schemes, = the incurred header overhead grows gracefully with the number of = recipients, and no one without a key can tell how many recipients the = file is actually encrypted for. And the recipient only needs to do at = most public-key (or password-hashing) operation per scheme and O(log N) = AEAD trial decryptions per scheme for which the recipient holds a key. As a potentially nice little bonus, with this general scheme it=E2=80=99s = entirely possible that an encoder could create a file such that = different symmetric-key pairs actually lead to and enable access to = *different* file data chunks, effectively giving different receivers the = ability to =E2=80=9Copen=E2=80=9D different parts - or different subsets = - of encrypted data. And one receiver will not necessarily be able to = tell either how many other receivers there are or how much =E2=80=9Cother=E2= =80=9D data might be hiding in the file, beyond some upper bound. Kind = of like Truecrypt partitions, but with any number of hidden partitions = scattered anywhere you like in the volume with different passphrases. :) = This kind of thing may well reasonably be out-of-scope for what we want = OpenPGP to do, but interesting to think about. Cheers Bryan --Apple-Mail=_00CAF971-64DA-4EBB-ADA9-DC6A28D55DE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I=E2=80=99m glad to see the metadata-leakage = protection topic drawing some interest, including some healthy = skepticism on whether it=E2=80=99s practical. :)

I=E2=80=99ll try to summarize my scheme = at least somewhat concisely, and include this in a draft-of-a-draft that = I have in progress.  A bare-bones (i.e., incomplete, = badly-documented) but working proof-of-concept implementation of this = scheme is actually implemented in the dedis crypto library for Go, = available here:

= Code: https://github.com/DeDiS/crypto/tree/master/nego
= GoDoc: https://godoc.org/github.com/DeDiS/crypto/nego

But I would recommend = reading the conceptual summary below before trying to understand the = code. :)

The = main desirable properties the scheme has are (a) it produces uniform = random blobs with no unencrypted metadata; (b) it supports multiple = encryption schemes, both passphrase and/or public-key - though =E2=80=9Cto= o many=E2=80=9D schemes would get costly; (c) it supports multiple = passphrase and/or recipient public keys with each scheme; (d) for a = given scheme and a given passphrase or private key held by a recipient, = the recipient needs to perform at most one public-key crypto operation = and O(log N) symmetric-key crypto operations - and to read a similarly = small part of the input - in order to determine if the file is encrypted = for this recipient passphrase/keypair and unlock it if so.

Let=E2=80=99s work from = a simple case to progressively more =E2=80=9Cinteresting=E2=80=9D and = general cases:

1. Encryption using a single scheme (e.g., a single = well-known =E2=80=9Cciphersuite=E2=80=9D) via a single = passphrase.
2. Single symmetric-key scheme, but = multiple alternative passphrases using that scheme.
3. Single public-key encryption scheme, with message = encrypted for one or multiple public keys compatible with that = scheme.
4. Multiple symmetric and/or public-key = schemes, allowing multiple different passphrases and recipient = public-keys each, respectively.

=E2=80=94
1. = Suppose simplistically we only want single-passphrase encryption using a = single well-known encryption scheme.  More-or-less as usual for = PGP, we (a) choose a random session key, (b) use a password-hashing = scheme such as Argon2 to produce a symmetric encryption key that is used = to AEAD-encrypt the file=E2=80=99s session key, and (c) use the session = key to AEAD-encrypt the file=E2=80=99s content.  Assume for now = that we encrypt the file in one big chunk, though chunking (with = metadata encryption) can be added as well using existing techniques = (e.g., those mentioned earlier analyzed in the context of = SSH).

So we = basically have three important blobs of data to place in the file: (a) = the salt for the password-hashing scheme, (b) the AEAD-encrypted session = key encrypted using the password-hasher=E2=80=99s output, and (c) the = AEAD-encrypted file content encrypted using the session key.  Item = (a) needs to be encoded in the file in =E2=80=9Ccleartext=E2=80=9D since = it needs to be available to the decryptor before it can decrypt = anything, but fortunately the salt can just be a uniformly random blob = anyway (of a length fixed by this well-known scheme).  So for the = moment let=E2=80=99s just put it at the very beginning of the encoded = file.  Then place the AEAD-encrypted session key blob (b) = immediately afterwards, whose size can also easily be fixed for this = scheme.  This fixed-length session-key blob may contain encrypted = metadata in addition to the session key, such as the file offset of the = AEAD-encrypted file content, the (possibly padded) total size of the = AEAD-encrypted blob, and perhaps the size of the =E2=80=9Cuseful = payload=E2=80=9D within that blob after removing any padding.  This = metadata will of course appear as uniform random bits to a non-recipient = as long as the AEAD encryption scheme is doing its job.  Finally, = place the AEAD-encrypted file content (c), including any padding, after = the encrypted session-key blob as the rest of the file.

=E2=80=94
Single passphrase-encryption scheme, multiple = passphrases:

Now= assume we want to encrypt with multiple passphrases.  Perhaps not = a highly compelling case, but it=E2=80=99s conceptually simpler to start = with than multiple recipient public-keys but addresses the same = technical issues.  The approach Neal suggested of using Bloom = filters is not far off, but we at least wouldn=E2=80=99t want to use = *unencrypted* Bloom filters that might look distinguishable from random = bits.

As a = straw-man design suppose we just pick an upper-bound on the number, say = N, of different passphrases with which we expect anyone might ever want = to encrypt a file.  Then we lay out the encrypted file as follows: = (a) a single, uniformly random password-salt value of fixed length comes = first in the file, followed by (b) a hash table with room for not just = one but N consecutive AEAD-encrypted session-key blobs of the same kind = as for the single-password scheme above, and finally (c) the = AEAD-encrypted file content.  Both the encryptor and decryptor use = the salt to hash the user=E2=80=99s password, then hash the output of = that to form both the AEAD-encryption key for the session-key blob and = an index into the N-entry hash table.  The decryptor then simply = attempts to AEAD-decrypt and check that particular hash-table entry - or = to allow for rare hash collisions, attempts to decrypt (say) three = consecutive hash-table entries starting at that position and wrapping = around mod N.  If any of those AEAD-decryptions works, the = decryptor wins; if not, the decryptor gives up and decides the = passphrase doesn=E2=80=99t work.

Since each passphrase will produce a = different (pseudo-random) hash-index, the session-key blobs for = different passphrases will typically occupy different positions in the = hash-table, thereby allowing decryption using any of the corresponding = passphrases.  Hash collisions may occur, but if the number of = actual passphrases is not too close to N (i.e., the hash table not too = full), the encryptor should be able to squeeze in session-key blobs for = all of them using the =E2=80=9Cslop=E2=80=9D allowed by the 3-tries (or = k-tries) search rule above, and/or by simply retrying everything from = scratch with a fresh salt if that doesn=E2=80=99t work.  Once the = hash table is laid out and filled with all useful session-key blobs, all = remaining unused entries are just filled with uniform random bits, so = anyone not holding one of the passphrases can=E2=80=99t distinguish = =E2=80=9Cfull=E2=80=9D from =E2=80=9Cempty=E2=80=9D hash-table = entries.

Now = the next step we=E2=80=99d like is to avoid having to pick a particular = value of N: too large and we=E2=80=99re wasting a lot of space at the = beginning of every file on a hash table that often will probably have = only 1 entry populated; too small and we don=E2=80=99t allow for = multiple session key blobs.  So instead of including just one hash = table in the file, we include a variable-length sequence of hash tables = whose sizes increase by powers of two.  Thus, immediately after the = password-hashing salt, we encode a 1-entry hash table, followed by a = 2-entry hash table, followed by a 4-entry hash table, etc., stopping = wherever the encoder feels like stopping.  The encoder takes the = passphrases it=E2=80=99s supposed to encrypt the file with, and = successively creates an encrypted session-key blob for each passphrase, = storing it at the appropriate hashed position (for that passphrase) - or = within a 3-tries distance - in the lowest-numbered hash table that has = room for it.  Then the encoder writes out to the encrypted file: = (a) the common password-encryption salt, (b) all the *non-empty* hash = tables starting from the size-1 table, with any empty entries filled = with uniform random bits, and (c) the AEAD-encrypted file content, as = usual.  Note that the encryptor can =E2=80=9Clay out=E2=80=9D the = header and figure out how many hash tables are actually needed before it = does the AEAD-encryption of the session key blobs, which means those = session key blobs can still contain the file offset and length metadata = pointing to the encrypted file content.

On the decryptor side, given the salt = at the beginning of the file and the user=E2=80=99s passphrase, the = decryptor now needs to generate a hash-index for each possible hash = table and try decrypting a few consecutive entries per hash table. =  Neither the decryptor, nor anyone else, initially knows the number = of hash tables in the file.  But note that the decryptor only needs = to do a single expensive password-hashing operation (with that one salt = and the entered password).  Also, since the total number of hash = tables is log2(N) where N is an upper-bound on the number of recipients, = the total number of symmetric-key trial-decryptions the recipient needs = to perform to see if the passphrase =E2=80=9Cworks" is O(log N), = regardless of the number of passphrases the file was actually encrypted = for.  We might want to set some kind of upper bound on the maximum = size that the header portion might be, of course, but that can probably = be fairly large (e.g., 1MB) since it=E2=80=99s just an upper bound. =  In the common case when a file is encrypted with only one = passphrase, only the first, size-1 hash table is non-empty, and the = encrypted file is just as compact as it would be in the =E2=80=9Cnaive=E2=80= =9D base-case design above that only supports a single = passphrase.

=E2=80=94
Single public-key encryption = scheme, multiple recipient public keys:  

We now assume that we wish to encrypt a = file so as to be decryptable by multiple receivers, the encoder has = public keys for all those receivers, and (most importantly) all those = receivers=E2=80=99 public keys are in the same group: e.g., they are all = Ed25519 keys or all Ed448 keys.  This assumption is not very = realistic for =E2=80=9Clegacy=E2=80=9D DSA keys and not realistic at all = for RSA keys, but let=E2=80=99s assume we=E2=80=99re willing to live = with that restriction at least for =E2=80=9Cnew=E2=80=9D files encrypted = this way.

Structurally, the public-key multiple-receivers scheme works = exactly the same as above for passphrase encryption, but the encryptor = (a) replaces the password-hashing salt at the beginning of the file with = an Elligator-encoded ephemeral Diffie-Hellman public key, whose = corresponding private key was freshly picked by the encryptor; (b) = computes a shared Diffie-Hellman master secret using this ephemeral = private key and each receiver=E2=80=99s public key (which as stated = above we assume all to be in a common group); and (c) AEAD-encrypts all = the session-key blobs in the hash tables using these Diffie-Hellman = master secrets instead of password-based secrets.  Everything else = about hash table layout and such works exactly the same way as discussed = above for multiple passphrases.

For those not familiar with Elligator = and its follow-on work (e.g., Elligator 2, Elligator Squared, Binary = Elligator Squared), all are ways to encode an elliptic curve point = usable for Diffie-Hellman key exchange, such that the encoding appears = indistinguishable from uniform random bits.  Different schemes = apply to different subsets of elliptic curves and impose different = tradeoffs: e.g., the original scheme works only for certain curves = (including Ed25519) and is very compact but may require the encoder to = retry the generation of the ephemeral DH point several times (no big = deal in practice); other later schemes are a bit less compact (e.g., = require 2x the space for the representation) but less constrained and = can encode any point on the curve rather than only about half the = points, etc.  The details aren=E2=80=99t important for present = purposes; only the fact that they exist and they work. :)

So because Elligator = encodes the initial DH key in uniform representation, and everything = else in the file is either an AEAD-encoded blob or just random bits, the = whole file looks like uniform random bits to anyone not holding one of = the recipients=E2=80=99 private keys.  A non-recipient can=E2=80=99t = even tell whether the file is encrypted to just one recipient (the = Elligator-encoded point followed by the size-1 hash table followed by = the encrypted file content) or to many (the Elligator point followed by = several hash tables).  The decryptor doesn=E2=80=99t know this = either without trying, but the decryptor only needs to do the one = public-key DH agreement calculation to compute its ephemeral secret = shared with the encryptor, and then perform at most O(log N) AEAD trial = decryptions to see if its key works near the appropriate indexes of any = of the O(log N) hash tables.

=E2=80=94
4. = Multiple symmetric-key and/or public-key schemes:
This is where things start to get = still a bit more hairy, although the underlying principles remain pretty = similar.  The problem now is that we may now have multiple, = different and incompatible encryption schemes: e.g., we might want to = encrypt a file both with a passphrase *and* for several public-key = recipients, some of whom have (say) Ed25519 keypairs while others have = Ed448 keypairs while others have NIST P-* keypairs.  We=E2=80=99ll = assume (a) that all public-key schemes are in DH-compatible, = Elligator-encodable groups of some kind, and (b) we will = administratively avoid needing to support a huge number of different = schemes all at once.  (It feels like this assumption is compatible = with where the CFRG and OpenPGP WGs are headed anyway.)

So as should be clear = from the above by now, the =E2=80=9Ccornerstone=E2=80=9D of each scheme = is a salt value in the case of a passphrase scheme, and an = Elligator-encoded point in the case of a public-key scheme. =  Passphrase salts can just be unstructured random bits, so in that = case one might imagine just starting the file with a single =E2=80=9Ccommo= n salt=E2=80=9D large enough to seed all the passphrase-based schemes we = might want to support (if we even want to support more than one in a = given file, which might be unlikely).  But an Elligator-encoded = point must be created rather carefully such that the encryptor knows the = corresponding private key for DH agreement, so it=E2=80=99s not feasible = to dump some random bits at the beginning of the file and expect it to = be usable as multiple different Elligator points for multiple different = curves: we really need to encode multiple distinct Elligator points for = distinct curves so that they=E2=80=99re all independently decodable. =  

Further = compounding the challenge, we don=E2=80=99t want the decryptor to have = to perform multiple expensive public-key operations (or multiple = expensive password-hashing operations) per scheme.  We can=E2=80=99t = avoid the decryptor having to do *one* expensive public-key or = password-hashing operation per scheme that the user might hold a key = for: e.g., if the user=E2=80=99s keychain holds both an Ed25519 private = key and an Ed448 private key, we=E2=80=99ll have to do two Elligator = point decodes and two DH key agreements, but we want to avoid having to = do more than two.  (And for the common-case of users holding only = one private key, we want the user to have to do only one DH key = agreement.)

So = to solve this, we=E2=80=99ll use a multiple-hash-table approach similar = to the above to allow a file to contain multiple =E2=80=9Ccornerstone=E2=80= =9D values (password salts and/or Elligator points) at the beginning, = but slightly modified to avoid the need for multiple trial decryptions. =  For each scheme, we take that scheme=E2=80=99s cornerstone value = (e.g., Elligator point), and first round its size up to the next power = of two.  Next, for each scheme, we pick (via standardization) an = upper bound on the total number of other *schemes* we want this scheme = to be compatible with now and in the near future (i.e., number of other = distinct cornerstone values we need to encode at the beginning of the = file).  For each scheme, we then standardize a small number of = possible positions for that scheme=E2=80=99s cornerstone value, perhaps = chosen more-or-less randomly (but statically), one position per hash = table within a small number of hash tables laid out in increasing = power-of-two sizes exactly as earlier for session-key blobs.  We = ensure, again via standardization, that among the set of schemes we want = to be compatible with each other, each scheme has at least one possible = position (perhaps the largest) for which its cornerstone can be encoded = so as to be disjoint and non-overlapping with at least one possible = position of every other scheme.

For example, suppose we want to support = Ed25519, Ed448, and P-384, and may want to support other schemes later = on whose recipient keys can be intermixed with keys from these schemes. =  Let=E2=80=99s say that we can Elligator-encode an Ed25519 point in = 32 bytes (true), we can Elligator-encode an Ed448 point in 64 bytes (not = sure about this, but either that or a 128-bit encoding should be = feasible).  We might pick 3 possible cornerstone-value positions = for each of these schemes as follows:

Ed25519: offset 0, offset (32 or 64), = and offset (96, 128, 160, or 192).
Ed448: offset 0, = offset (64 or 128), and offset (192, 256, 320, or 384).

For each of the = parenthesized alternatives, give the OpenPGP WG chairs a coin during = some meeting and have them flip it to pick one of the two or four = alternatives for the second and third possible position for each scheme. = :)

Future = schemes we might add will come with their own list of possible = cornerstone-value positions, which can be of varying lengths, and = similarly can overlap (though all of them should have 0 as the base-case = offset) provided we maintain the invariant that each scheme we still = care about has some unique position that doesn=E2=80=99t overlap with = any other scheme we still care about.  We can also optimize the = possible positions more carefully if we choose; the above example is = just to keep things conceptually simple.

Now, when the encryptor is encrypting = an OpenPGP file, it creates a cornerstone value suitable for each = scheme, and picks a position for each scheme=E2=80=99s cornerstone value = from the fixed list of available positions for that scheme, such that = the actually-picked cornerstone value positions are as low as feasible = but don=E2=80=99t overlap.  For example, if a file is encrypted = with both Ed25519 and Ed448 receiver keys, the =E2=80=9Cbest=E2=80=9D = set of positions from those above might be position 0 for the Ed448 key = and position 64 for the Ed25519 (other choices would also work but be a = bit less space-efficient).  But now the encryptor needs to encode = these cornerstone values so that the decryptor can get exactly the = cornerstone value it needs, on the =E2=80=9Cfirst try=E2=80=9D, without = actually knowing at which possible position for a given scheme it was = encoded.

So = here=E2=80=99s the trick: we use a variant of DC-nets or PIR-type = encoding techniques to =E2=80=9Canonymize=E2=80=9D the true position at = which a given cornerstone value is encoded.  In particular, the = encoder arranges the file such that for each scheme, the decoder reads = *all* of the possible cornerstone value positions for that scheme, and = XORs them together, to reconstruct the =E2=80=9Cactual=E2=80=9D = cornerstone value for that scheme.  That is, to get the = Elligator-encoded Ed25519 point, the decoder will read the 32 bytes = starting at each of the three positions defined for Ed25519, then XOR = these 32-byte sequences together, and use that as the Ed25519 point. =  Similarly for the other schemes.

The important point is that as long as = the encoder picks some =E2=80=9Cworkable=E2=80=9D order in which to = encode all the cornerstone values, it can treat previously-encoded = cornerstone values in one scheme as =E2=80=9Cnoise=E2=80=9D to be = canceled (via XOR) when encoding cornerstone values for other schemes. =  For example, suppose the encryptor encodes the Ed448 point first = at file offset 0.  The encoder fills the second and third possible = positions for Ed448 with random bits, then XORs those alternative = positions with the actual Ed448 cornerstone value and writes the result = at offset 0.  Now the byte-ranges corresponding to those positions = are fixed and no longer changeable, but can be included as =E2=80=9Cnoise=E2= =80=9D to be canceled in writing other cornerstone values.  For = example, say now the encryptor wants to encode the Ed25519 point: it = obviously can=E2=80=99t put it at position 0, but hopefully the second = or third alternative position for Ed25519 should be non-overlapping with = the already-locked Ed448 point positions.  Say the second Ed25519 = position is still available: the encryptor fills the third position with = random bits (and the first, offset-0 position has already been filled = with random-looking bits), then XORs the contents of the first and third = Ed25519 positions and the true cornerstone value to fill the second = Ed25519 position.

OK, so it might look like we=E2=80=99ll always need to = reserve a fairly large chunk of header space for these cornerstone = values (e.g., ~448 bytes in the above example depending on the precise = choices of the cornerstone value positions).  But it turns out = that=E2=80=99s not true, provided we (a) first reserve space for only = *one* suitably-chosen cornerstone-encoding position per scheme, (b) then = lay out all the hash tables containing symmetric-key blobs for all the = schemes, (c) then lay out and encrypt the file=E2=80=99s contents (or = its first substantial-size chunk of data in the streaming case), (d) = encrypt all the session-key blobs of all schemes into appropriate, = already-reserved positions in those schemes=E2=80=99 respective hash = tables, (e) fill all remaining unreserved space in this whole = variable-length header region with random bits, and finally (f) encode = the cornerstone values at the very end.  This way, some of the = possible positions for the cornerstone values of each scheme can = actually overlap with symmetric-key blobs generated by the same or other = schemes, since all those random-looking bits will just be treated as = pre-existing noise that gets XORed together with the =E2=80=9Ctrue=E2=80=9D= cornerstone value to be filled into the =E2=80=9Clast position=E2=80=9D = for the corresponding scheme.

Going back to the question of the hash = tables for the session-key blobs, note that although we now have = multiple hash tables of different sizes for several different schemes, = all those hash tables can actually overlap, provided the encoder handles = its layout properly.  For example, each scheme=E2=80=99s smallest, = size-1 hash table might always be defined to start immediately after the = offset-0 position for that scheme=E2=80=99s cornerstone value, and = successive hash tables grow from there.  As the encryptor is = choosing positions for session-key blobs in any schemes, it basically = just looks for a byte-range in one of that scheme=E2=80=99s hash tables = that hasn=E2=80=99t yet been allocated by that or any other = scheme.

Thus, = in the very likely common case of a file being encrypted to only one = recipient under only one scheme (e.g., Ed25519), the file can always be = =E2=80=9Cas small as possible=E2=80=9D and consist of simply (a) the = elligator-encoded Ed25519 cornerstone point for DH agreement, (b) the = single session-key blob encrypted using the DH key shared between the = encryptor=E2=80=99s cornerstone keypair and the recipient=E2=80=99s = keypair, and (c) the variable-length encrypted file content itself, all = back-to-back in one uniformly-random-looking blob.  If a few but = not many different recipients are to be included in one or a few = schemes, the incurred header overhead grows gracefully with the number = of recipients, and no one without a key can tell how many recipients the = file is actually encrypted for.  And the recipient only needs to do = at most public-key (or password-hashing) operation per scheme and O(log = N) AEAD trial decryptions per scheme for which the recipient holds a = key.

As a = potentially nice little bonus, with this general scheme it=E2=80=99s = entirely possible that an encoder could create a file such that = different symmetric-key pairs actually lead to and enable access to = *different* file data chunks, effectively giving different receivers the = ability to =E2=80=9Copen=E2=80=9D different parts - or different subsets = - of encrypted data.  And one receiver will not necessarily be able = to tell either how many other receivers there are or how much = =E2=80=9Cother=E2=80=9D data might be hiding in the file, beyond some = upper bound.  Kind of like Truecrypt partitions, but with any = number of hidden partitions scattered anywhere you like in the volume = with different passphrases. :)  This kind of thing may well = reasonably be out-of-scope for what we want OpenPGP to do, but = interesting to think about.

Cheers
Bryan

= --Apple-Mail=_00CAF971-64DA-4EBB-ADA9-DC6A28D55DE8-- --Apple-Mail=_2DB6DB06-D96C-4406-9458-FC9C96D1CD24 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTExMDcxMTMzNTlaMCMGCSqGSIb3DQEJBDEWBBT5rAzRU93TVaX65mCG9gnSm3WSTTCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAZ9luQPxp0Xss2peFZ2kD6UzHMe+wUF0YTglioL/2kpy2DPqLrPpAWGMw5AC3e8vM 19ki/GLSY52TjHaQbmvJHpKP9FGvwsrpDdMRgoz+KoYddykAYMZEhTiujHgt9r6YFoyMKFopbwRb RuSrcF5e5az7xgRhaJHUSBH6FvdvKn8NEwYSDguN0UQTh/mXZI6qabdC73hDbW7cv2cXs4zJapFk Ef98Mocm0heVvHkRe9O/Al6oF8KVZmLuV2ea+/BKA8UXD+9/kyidmLhCaI66Eg6EEjj7SvT/Sst8 KJP3PpHuFZLHaEfrLlzj0c7sY/ajHD6YnRh3P3HQrKrHiy4EzgAAAAAAAA== --Apple-Mail=_2DB6DB06-D96C-4406-9458-FC9C96D1CD24-- From nobody Sat Nov 7 12:35: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 5DF761B3673 for ; Sat, 7 Nov 2015 12:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 AEFA5piqsohs for ; Sat, 7 Nov 2015 12:35:12 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAAD11B3672 for ; Sat, 7 Nov 2015 12:35:10 -0800 (PST) X-AuditID: 12074424-f79216d00000156e-da-563e607d7ade Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id A2.A9.05486.D706E365; Sat, 7 Nov 2015 15:35:09 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id tA7KZ8gg002180; Sat, 7 Nov 2015 15:35:09 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tA7KZ5LP014422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 7 Nov 2015 15:35:08 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id tA7KZ5ww029935; Sat, 7 Nov 2015 15:35:05 -0500 (EST) Date: Sat, 7 Nov 2015 15:35:05 -0500 (EST) From: Benjamin Kaduk To: Bryan Ford In-Reply-To: <160A8D98-3DF8-4F51-A38C-EF3E0DAE71EE@gmail.com> Message-ID: References: <86CB1513-F594-4A9B-A3B6-17ECB9CA9EB6@isoc.org> <160A8D98-3DF8-4F51-A38C-EF3E0DAE71EE@gmail.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-617396658-1446928505=:26829" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUixCmqrFubYBdmcGKqssXEV3dYLRr+PWR3 YPLYOesuu8eSJT+ZApiiuGxSUnMyy1KL9O0SuDIeH/7LXvCereLxg7vMDYw3WLsYOTkkBEwk mia9YoKwxSQu3FvP1sXIxSEksJhJ4ta01WBFQgIbGCUa/kRCJA4ySfQcfgmVqJd413qBDcRm EdCSuLj4IzuIzSagIjHzzUawuIiAmsSTlv9gNrOApsSLc1OZQWxhASOJuRNmgsU5BWwlbt// CHQFBwevgKPEyb3ZELtmM0p0PJkPViMqoCOxev8UFhCbV0BQ4uTMJywQMwMkfh55wTyBUXAW ktQsJCkIW12i8cFZNghbW+L+zTa2BYwsqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3TN9XIzS/RS U0o3MYICm91FZQdj8yGlQ4wCHIxKPLwbftiECbEmlhVX5h5ilORgUhLlPRVqFybEl5SfUpmR WJwRX1Sak1p8iFGCg1lJhNdRCyjHm5JYWZValA+TkuZgURLn3fSDL0RIID2xJDU7NbUgtQgm K8PBoSTByxYP1ChYlJqeWpGWmVOCkGbi4AQZzgM0XBWkhre4IDG3ODMdIn+KUZdjwY/ba5mE WPLy81KlxHk9QYoEQIoySvPg5oAT0m4m1VeM4kBvCfOGgVTxAJMZ3KRXQEuYgJY4RNmALClJ REhJNTDGfq81ncx9YLVAgcstL+E1L34uyeoUvCFVH7TPo+2B1cMD/yam3eR6vFkv+VI9u+Pr gEX8O6cv6bi67++F6seOdoqfDRgYi5TVNmSZbdCvsNr364JT49MAA34WnbTCxo2fTydJSTSw xDZNCT8/7c/RiLku/yYvjAq5JcC4yVm9/5OZhE+4/0ElluKMREMt5qLiRABwtEXKIwMAAA== Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] Reducing the meta-data leak 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, 07 Nov 2015 20:35:13 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-617396658-1446928505=:26829 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Sat, 7 Nov 2015, Bryan Ford wrote: > I=E2=80=99m glad to see the metadata-leakage protection topic drawing som= e interest, including some healthy skepticism on whether it=E2=80=99s pract= ical. :) > > I=E2=80=99ll try to summarize my scheme at least somewhat concisely, and = include > this in a draft-of-a-draft that I have in progress. A bare-bones (i.e., If this is the "concise summary", I am not sure that I would want a software implementing something this complicated in the critical security path for anything I do. -Ben ---559023410-617396658-1446928505=:26829-- From nobody Sun Nov 8 02:43: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 F35D11A87C7 for ; Sun, 8 Nov 2015 02:43:07 -0800 (PST) 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 5c3mc4rc3DnF for ; Sun, 8 Nov 2015 02:43:05 -0800 (PST) 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 B796F1A8796 for ; Sun, 8 Nov 2015 02:43:05 -0800 (PST) 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 1E9EB6D72F; Sun, 8 Nov 2015 05:43:04 -0500 (EST) To: openpgp@ietf.org References: <87twp91d8r.fsf@alice.fifthhorseman.net> <3A98EA92-0C2F-46A7-8D06-880FC83CB110@gmail.com> From: ianG Message-ID: <563F2736.6090603@iang.org> Date: Sun, 8 Nov 2015 10:43:02 +0000 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: <3A98EA92-0C2F-46A7-8D06-880FC83CB110@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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, 08 Nov 2015 10:43:08 -0000 On 7/11/2015 01:46 am, Bryan Ford wrote: > To be clear, there are two separate use-cases, each of which make sense > without the other and require different technical solutions (but could > also make sense together): > > 1. Streaming-mode integrity protection: We want to make sure OpenPGP > can be used Unix filter-style on both encryption and decryption sides, > to process arbitrarily large files (e.g., huge backup tarballs), while > satisfying the following joint requirements: > > (a) Ensure that neither the encryptor nor decryptor ever has to buffer > the entire stream in memory or any other intermediate storage. Yes. > (b) Ensure that the decryptor integrity-checks everything it decrypts > BEFORE passing it onto the next pipeline stage (e.g., un-tar). ok. So this is where a program-level option comes in. In streaming mode, the streamer can keep decrypting and passing it across to the reader, and then break when an integrity check fails. In streaming mode, this is how we would expect it to operation. A user program can however offer some options in this case. Eg., do an integrity check pass before hand as a separate option; and turn the integrity checks into warnings, keep decrypting the data, knowing that there is garble in there, keep streaming. Both two useful options a program could offer. So I'd say NO - streaming is streaming, and there isn't a requirement in the spec to be sure about the entire file before hand. That's just a quirk of the streaming mode that users will have to accept. > 2. Random-access: Once a potentially-huge OpenPGP-encrypted file has > been written to some random-access-capable medium, allow a reader to > decrypt and integrity-check parts of that encrypted file without > (re-)processing the whole thing: i.e., support integrity-protected > random-access reads. > > Let’s call these goals #1 and #2, respectively. ... > We could very well design an OpenPGP format that addresses both goals > together, if we decide both goals are valuable. ... > > There are some obvious tradeoffs here, both in storage and complexity > costs. I’m not that worried about the storage efficiency costs,... > And the implementation-complexity is certainly an issue regardless. Nod. Let's see how the requirements go first, and whether there is a reasonable design possible second. > So some questions about this: > > 1. How important is the ability to achieve goal #1 above in the OpenPGP > format (streaming-mode integrity-checking)? It's certainly important. If we want to bring everyone across to a new format, and start ditching the old (from the standard) then we have to provide an equivalent to common use cases. I'm inclined to say that stream-mode must be integrity checked. We want to achieve the same standard across the board, we don't want to say "if X, then Y, but if the Z, then not Y and maybe W..." and complicate the user understanding. > 2. How important is the ability to achieve goal #2 above in the OpenPGP > format (random-access integrity-checking)? Random access is a new feature. It's certainly an *attractive* feature for the inner geek, just because. But I am not seeing a clear use case as yet, at the user level. If I think about the command line, I can't see a way a user would say "decrypt from blocks 1234 to 8960" without getting into some arcane geeky construction like doing dd(1) or somesuch ... which no sane end-user does. What I am seeing is that this would be an API call to other systems which do know what they want. This would be quite useful for a backup for example, or an rsync-like tool. Being able to re-start the backup is incredibly useful, being able to set off a backup to do a sort of "rsync" phased copy from "state N" without phase errors would be fantastic. We would be then entering into the library space rather than the end-user interface space. This might actually be a good thing, it might tear our childlike grip from the command line and drag us into the new millenium in time for the next decade. It might finally kill off our obsession with email :) Or it could be mission creep, scope enlargement, or the sinking of the project if we become all things to all other projects building GUIs on top? > 3. For whichever goal(s) we wish to be able to achieve, should those be > *mandatory* or *optional* in the format? I'd really like to see one format. The boolean logic that goes with different formats just ripples through the users minds and creates confusions. Every confusion creates loss of users. Every user we lose to confusion is a breach of security because they go on to do it cleartext or some other inadequate tool. If we have 10 such confusions scattered across the code, we'll probably half the number of users. That's without even talking about bugs, and security snafus and the potential for choosing the wrong mode and breaking the lot... E.g., it took me 2 years to find out the reason why SVN would break every month was that the client side was mounted on a Mac OSX drive that had an *option* to select case insensitivity... dozens of mandays lost in rectification/recovery/rebuilding client repos because of an obscure option. There is a reason the MiB run around and insert multiple-mode madness into people's minds in groups. It makes security brittle. It makes it easy for them to futz. > That is, should *every* > OpenPGPv5-encrypted file satisfy either or both of these goals, or > should they be configurable or user-selectable (such that some encrypted > files might contain per-chunk signatures and/or Merkle trees while > others do not)? Making either of these goals “supported but optional” > might help mitigate any performance/storage cost concerns with either of > them, but would only further increase the complexity of the overall > OpenPGP spec and increase the “usability risk” of a user accidentally > failing to enable a relevant option when he really should have (e.g., > streaming-mode protection for backups). Yup. And then he goes off an uses another tool. Coz the sales force have realised that taking options away makes the sale easier, and the user can't see the schlock under the hood anyway. > 4. What are reasonable upper- and lower-bounds for chunk sizes, and what > are the considerations behind them? Defer to later. iang From nobody Sun Nov 8 02:49:43 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 017EB1A899F for ; Sun, 8 Nov 2015 02:49:42 -0800 (PST) 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 3oAj0gB6ULBw for ; Sun, 8 Nov 2015 02:49:41 -0800 (PST) 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 EF0911A8986 for ; Sun, 8 Nov 2015 02:49:40 -0800 (PST) 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 A81DB6D731; Sun, 8 Nov 2015 05:49:39 -0500 (EST) To: openpgp@ietf.org References: <5623AA95.4060903@googlemail.com> <874mh3q3ol.fsf@alice.fifthhorseman.net> <56382F70.5000501@iang.org> <56385A38.6000707@googlemail.com> From: ianG Message-ID: <563F28C2.4040508@iang.org> Date: Sun, 8 Nov 2015 10:49:38 +0000 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: <56385A38.6000707@googlemail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [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, 08 Nov 2015 10:49:42 -0000 On 3/11/2015 06:54 am, Nils Durner wrote: > Hi Ian, > >> I agree with all the rest, but can we also deprecate some old stuff as >> well? >> >> Can we construct a plan e.g., that no existing S2K be used with new >> keys and the new form not be used with old keys? > > I have made salt-based methods mandatory in my patch: >> +Implementations MUST generate S2K specifiers that include salts >> +(either type 2, 3 or 4), as simple S2K specifiers are more vulnerable to > (type 2 should actually be "type 1") >> +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. > > We can of course raise the bar by excluding types 1 & 3 entirely. That's what I would do. Mode 4 is the only produced option in the new format. + Implementations MUST write in Argon2i and SHOULD read old formats. Implementations will of course offer options to add back in 0,1,3, especially where the reading code is stuck on old format, and the writing code is new format. But they won't be compliant. And we can ostracise them accordingly, tell them they're using worse than MD5 and they're to blame for global warming and bad coffee. iang From nobody Sun Nov 8 02:54:59 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 AB2041A9075 for ; Sun, 8 Nov 2015 02:54:57 -0800 (PST) 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 e4o4_T7LfLKb for ; Sun, 8 Nov 2015 02:54:56 -0800 (PST) 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 B75261A9063 for ; Sun, 8 Nov 2015 02:54:56 -0800 (PST) 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 051096D731; Sun, 8 Nov 2015 05:54:55 -0500 (EST) To: openpgp@ietf.org References: <563C09D7.8090404@iang.org> <20151106085826.GA25362@belenus.iks-jena.de> <87611frzdv.fsf@vigenere.g10code.de> From: ianG Message-ID: <563F29FF.9070001@iang.org> Date: Sun, 8 Nov 2015 10:54:55 +0000 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: <87611frzdv.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] DRAFT minutes for OpenPGP at IETF 94 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, 08 Nov 2015 10:54:57 -0000 On 6/11/2015 14:11 pm, Werner Koch wrote: > Hi Lutz, > > On Fri, 6 Nov 2015 09:58, lutz@iks-jena.de said: > >> Requiring the user to stick with old, unmaintained software (which might not >> even run on it's current system and can't be compiled for the new > > We promised to keep on maintaining GnuPG 1.4, which is that old copy: > all RFC-4880 features. You would need that for VMS anyway ;-). > > Thus there is at least one maintained old software. Exactly. It doesn't matter what we write in the standard - some software maintainers will do the right thing because their users will revolt if they don't. However, the "right thing" is a slippery concept. It isn't a universal good, it's not a UN-mandated personal right. Werner's right thing is not the right thing for the future and not the right thing for new users or other users or even for his users - all of them or all of the time. If we want everyone in 2025 to be using the good stuff we design today in 2015, then *we have to be fierce* about chopping away the old 2.3 cruft every chance we get. iang From nobody Sun Nov 8 03:09: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 AA8501A92F2 for ; Sun, 8 Nov 2015 03:09:13 -0800 (PST) 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 lTdqiqx3ZQ4R for ; Sun, 8 Nov 2015 03:09:12 -0800 (PST) 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 481271A92E7 for ; Sun, 8 Nov 2015 03:09:12 -0800 (PST) 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 8A92A6D732; Sun, 8 Nov 2015 06:09:11 -0500 (EST) To: openpgp@ietf.org References: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> From: ianG Message-ID: <563F2D56.5050809@iang.org> Date: Sun, 8 Nov 2015 11:09:10 +0000 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: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] Keyholder-configurable fingerprint schemes? 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, 08 Nov 2015 11:09:13 -0000 On 7/11/2015 03:31 am, Bryan Ford wrote: > In the OpenPGP meeting, Christian brought up an idea that I thought was interesting and perhaps deserved further consideration. > > Background summary: In the meeting a hum-poll was taken on the “single vs multiple fingerprints” question, my interpretation of whose result was that we should *not* create a system that subjects users to juggling multiple, inconsistent fingerprints for the same key (e.g., both a SHA-1 and a newer-hash-function-based fingerprint for the same user’s public key). Definitely. Strong hum. > A “strong interpretation” of that position is we should pick a single new hash function for “new fingerprints”, and mandate that all keys created with “new signature schemes” (e.g., Ed448) have fingerprints computed using that new scheme, while leaving the fingerprints of old schemes (e.g., RSA/DSA keypairs) fingerprinted using the old approach to preserve consistency. Hmm. In both senses. > A “weaker interpretation” of that position would be that for each new signature scheme defined for use with OpenPGP, that scheme should also define a suitable fingerprinting scheme to go along with it, but the fingerprinting scheme may (in principle) vary from one “new” keypair-type to another provided it remains consistent for any given keypair. That. The author of the signature scheme has to *select* a fingerprint scheme. We fully expect that in 2025 we'll be re-doing the signature scheme, because the old one is crufty and brittle - the same applies to the fingerprint scheme. The author at the time has the responsibility and the knowledge to match all the components together to get a good security across the board. HMMM > I see that the precise results of this hum-poll weren’t precisely captured in Rich’s meeting minutes - understandable since the precise results (or their proper interpretation) was a bit fuzzy to me as well and I don’t feel confident either to suggest exactly how that part of the minutes should be filled in. thanks. And no, I don't see it as "weaker" but in fact stronger design principle :) iang From nobody Sun Nov 8 03:18: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 8C8051ACD96 for ; Sun, 8 Nov 2015 03:18:51 -0800 (PST) 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 0WPvBuuEbQPe for ; Sun, 8 Nov 2015 03:18:50 -0800 (PST) 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 315821ACD92 for ; Sun, 8 Nov 2015 03:18:50 -0800 (PST) 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 357266D732; Sun, 8 Nov 2015 06:18:48 -0500 (EST) To: openpgp@ietf.org References: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> From: ianG Message-ID: <563F2F97.8060300@iang.org> Date: Sun, 8 Nov 2015 11:18:47 +0000 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: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] Keyholder-configurable fingerprint schemes? 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, 08 Nov 2015 11:18:51 -0000 If the author of the signature scheme wants to protect against the attack, then fine. I'm not sure it is worth the effort myself, but I think the author of the scheme should be given leeway to predict the future for the next 20 years and take their best shot at it. Go for it. On 7/11/2015 03:31 am, Bryan Ford wrote: > 2. A “memory-hard” salted-hash scheme, such as the Argon2 scheme to be used for passphrase hashing. Memory-hardness would be nice to achieve, but schemes like Argon2 may not be directly realistic in this context, because password-hashing schemes such as this by design take a lot of work both at creation *and* verification time, and we probably don’t want to impose seconds-long delays on (say) importing someone’s key into my keyring and verifying its consistency. It might not be completely a non-starter provided those delays *only* occur during key-import and not overtime I touch or use the key for any purpose, but it would still be a downer. Are there “memory-hard-to-create, but quick-to-verify” PoW schemes that might be worth considering? That. If we're adding Argon2 then let's use it for every applicable case. Sure there might be other better ones, but adding new algorithms to achieve marginal benefits on paper results in developers having to code new stuff up and implementations having to bloat and potentially not fit in tight places. Both of these costs will cause multiplier effects that lose us far more users. Lost users are a security breach. We'll lose far more security in bloat and developer cost than we're ever likely to gain by this PoW work feature. > At any rate, independent of these varying possible approaches to fingerprint PoWs, I feel like at least the first approach above that Christian suggested (simple PoW) seems practical, offers a nice parametrizable strengthening against prefix attacks, and doesn’t violate the essential consistency issue that users should need to deal with only one fingerprint *per keypair*. And if we were careful in specifying how the fingerprint-generation and fingerprint-validation mechanism works, we could easily leave the door open to different, further strengthened (and perhaps user-selectable) fingerprint protection mechanisms later. Thoughts? From where I sit in my armchair, I'd frown against it. But I'd not vote against the author of the ciphersuite if they want it. iang From nobody Sun Nov 8 04:03: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 E3D661B2ABB for ; Sun, 8 Nov 2015 04:03:01 -0800 (PST) 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 3aDkD6ogiICm for ; Sun, 8 Nov 2015 04:03:00 -0800 (PST) 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 523451B2ABA for ; Sun, 8 Nov 2015 04:03:00 -0800 (PST) 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 4E34A6D732; Sun, 8 Nov 2015 07:02:58 -0500 (EST) To: openpgp@ietf.org References: <86CB1513-F594-4A9B-A3B6-17ECB9CA9EB6@isoc.org> <160A8D98-3DF8-4F51-A38C-EF3E0DAE71EE@gmail.com> From: ianG Message-ID: <563F39F1.5040608@iang.org> Date: Sun, 8 Nov 2015 12:02:57 +0000 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: <160A8D98-3DF8-4F51-A38C-EF3E0DAE71EE@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] Reducing the meta-data leak 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, 08 Nov 2015 12:03:02 -0000 On 7/11/2015 11:33 am, Bryan Ford wrote: > I’m glad to see the metadata-leakage protection topic drawing some > interest, including some healthy skepticism on whether it’s practical. :) > > I’ll try to summarize my scheme at least somewhat concisely, and include > this in a draft-of-a-draft that I have in progress. [snip] > Let’s work from a simple case to progressively more “interesting” and > general cases: > > 1. Encryption using a single scheme (e.g., a single well-known > “ciphersuite”) via a single passphrase. Why is there a number for this.... Oh, because > 2. Single symmetric-key scheme, but multiple alternative passphrases > using that scheme. > 3. Single public-key encryption scheme, with message encrypted for one > or multiple public keys compatible with that scheme. > 4. Multiple symmetric and/or public-key schemes, allowing multiple > different passphrases and recipient public-keys each, respectively. Ug :( > — > 1. Suppose simplistically we only want single-passphrase encryption > using a single well-known encryption scheme. More-or-less as usual for > PGP, we (a) choose a random session key, (b) use a password-hashing > scheme such as Argon2 to produce a symmetric encryption key that is used > to AEAD-encrypt the file’s session key, and (c) use the session key to > AEAD-encrypt the file’s content. Assume for now that we encrypt the > file in one big chunk, though chunking (with metadata encryption) can be > added as well using existing techniques (e.g., those mentioned earlier > analyzed in the context of SSH). so far so good. > So we basically have three important blobs of data to place in the file: > (a) the salt for the password-hashing scheme, (b) the AEAD-encrypted > session key encrypted using the password-hasher’s output, and (c) the > AEAD-encrypted file content encrypted using the session key. Item (a) > needs to be encoded in the file in “cleartext” since it needs to be > available to the decryptor before it can decrypt anything, but > fortunately the salt can just be a uniformly random blob anyway (of a > length fixed by this well-known scheme). So for the moment let’s just > put it at the very beginning of the encoded file. Then place the > AEAD-encrypted session key blob (b) immediately afterwards, whose size > can also easily be fixed for this scheme. This fixed-length session-key > blob may contain encrypted metadata in addition to the session key, such > as the file offset of the AEAD-encrypted file content, the (possibly > padded) total size of the AEAD-encrypted blob, and perhaps the size of > the “useful payload” within that blob after removing any padding. I'd suggest also: * the version number of the OpenPGP format, like v4 or whatever it is supposed to be - thus causing a stab at how we handle rollover of this format, at least of the following file content. * a self-MAC on the blob. This is the proof that you've found the right password, and can proceed. This would be calculated over the blob with the self-MAC field set to all zeroes. Extra points if the calculation also includes the salt (a). * any primary MACs over the file data including the padding, pending those other discussions on integrity checking. > This > metadata will of course appear as uniform random bits to a non-recipient > as long as the AEAD encryption scheme is doing its job. Finally, place > the AEAD-encrypted file content (c), including any padding, after the > encrypted session-key blob as the rest of the file. Yup. On the remaining SM stuff, I'd like to hear that there is widespread support for this before subjecting myself to the pain. iang From nobody Mon Nov 9 08:16:50 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 486791B2FAA for ; Mon, 9 Nov 2015 08:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2x3b6DV1Byv for ; Mon, 9 Nov 2015 08:16:46 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 87D4B1B2FA9 for ; Mon, 9 Nov 2015 08:16:45 -0800 (PST) Received: by wmec201 with SMTP id c201so77228743wme.1 for ; Mon, 09 Nov 2015 08:16:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=SOOvGMKm7x9YnFtNejbMKo1ylTRWRUIOIXl0dnuoVrQ=; b=bDB5y+yfMD0ziuyx5r9I7XYFzb66HV2UKx0SlpqSHT365AfiBUFTSzQnOmxIP/axOH k8pI1oaUyOvINnVKZlxE0Y2hYcTHDlSlu8q5uRi8ZuIyeo2cptDMStwiaH8oPKrdcXNx 3pBOt37nYlsQM3jKLQh5w0dbPGB8g/MnVYVrZAwfc8SErkWXytO6/WabCT/AFCE8mHjc wIU1obMuRbYRAFH7sSd4eFDCLeNWkkoL4YEcdnU6Fnbq8ATyB2pSpJ9CsTXEpzTAl8oP Ua6MvKPwGB4XlEnreY2A8AzY+MOkkoLgAWaUscXxxHLblzTtbclYbP4nm/RxF8AHEsgo i1Aw== X-Received: by 10.28.139.143 with SMTP id n137mr25582525wmd.8.1447085804010; Mon, 09 Nov 2015 08:16:44 -0800 (PST) Received: from tsf-476-wpa-3-250.epfl.ch (tsf-476-wpa-3-250.epfl.ch. [128.179.179.250]) by smtp.gmail.com with ESMTPSA id y77sm15043042wme.15.2015.11.09.08.16.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Nov 2015 08:16:42 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_710DEDB0-2408-467B-8D03-98DAE4776BA2"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Bryan Ford In-Reply-To: <563F39F1.5040608@iang.org> Date: Mon, 9 Nov 2015 17:16:41 +0100 Message-Id: <9F39DEC7-593E-4B26-B84F-3E0AF8ADE658@gmail.com> References: <86CB1513-F594-4A9B-A3B6-17ECB9CA9EB6@isoc.org> <160A8D98-3DF8-4F51-A38C-EF3E0DAE71EE@gmail.com> <563F39F1.5040608@iang.org> To: ianG X-Mailer: Apple Mail (2.2104) Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Reducing the meta-data leak 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, 09 Nov 2015 16:16:48 -0000 --Apple-Mail=_710DEDB0-2408-467B-8D03-98DAE4776BA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks Ian for the feedback! (and the patience :) ) On Nov 8, 2015, at 1:02 PM, ianG wrote: > On 7/11/2015 11:33 am, Bryan Ford wrote: >> [=85] >> So we basically have three important blobs of data to place in the = file: >> (a) the salt for the password-hashing scheme, (b) the AEAD-encrypted >> session key encrypted using the password-hasher=92s output, and (c) = the >> AEAD-encrypted file content encrypted using the session key. Item = (a) >> needs to be encoded in the file in =93cleartext=94 since it needs to = be >> available to the decryptor before it can decrypt anything, but >> fortunately the salt can just be a uniformly random blob anyway (of a >> length fixed by this well-known scheme). So for the moment let=92s = just >> put it at the very beginning of the encoded file. Then place the >> AEAD-encrypted session key blob (b) immediately afterwards, whose = size >> can also easily be fixed for this scheme. This fixed-length = session-key >> blob may contain encrypted metadata in addition to the session key, = such >> as the file offset of the AEAD-encrypted file content, the (possibly >> padded) total size of the AEAD-encrypted blob, and perhaps the size = of >> the =93useful payload=94 within that blob after removing any padding. >=20 > I'd suggest also: >=20 > * the version number of the OpenPGP format, like v4 or whatever it is = supposed to be - thus causing a stab at how we handle rollover of this = format, at least of the following file content. Indeed, that should be added (inside the blob) and is easy to add. And = the stuff inside the blob could look as much like a conventional PGP = packet-stream as we like. > * a self-MAC on the blob. This is the proof that you've found the = right password, and can proceed. This would be calculated over the blob = with the self-MAC field set to all zeroes. Extra points if the = calculation also includes the salt (a). Since both the session-key blobs and the main file/payload blob are = AEAD-encrypted, those AEAD-encrypted blobs have MACs attached to them by = the AEAD algorithm. Thus, the decryptor knows he=92s got the right = password when the AEAD decryption algorithm (applied to the correct = session-key blob at the correct range of bytes in the file) successfully = checks whatever MAC the AEAD scheme defines and returns =93All=92s = well.=94 Of course all this could be defined just as well separating the = encryption for the MAC-checking, but I just thought it was easiest to go = with the AEAD-based definition. > * any primary MACs over the file data including the padding, pending = those other discussions on integrity checking. Yes. Any payload padding gets changed, the AEAD=92s MAC fails. There=92s a second-order subtlety, regarding how strongly we would want = to protect against a (very) active attacker using selective corruption = to =93probe=94 the size and shape of the header region _before_ the = padded payload even begins. If some of that region is just random bits = (e.g., unused hash table entries) or symmetric-key blobs for =93other=94 = recipients, then in my scheme=92s basic formulation, the attacker can = corrupt bits in those regions and the decryptor might still accept it, = whereas the decryptor will refuse to accept it if =93its=94 particular = symmetric-key blob (or anything in the payload) gets corrupted. Thus, a = (very) active attacker who can use a decryptor as a =93like/don=92t-like=94= oracle can effectively do "corruption tomography=94 to learn the shape = of the header area, thereby possibly learning back a bit of the metadata = that we=92re trying to hide. I know of a way to enable the decryptor to = check the whole header for corruption as well, but it=92s a bit scarily = complex and creates other tradeoffs so I haven=92t decided if it=92s = worth the effort. (Basically it making the header-generation scheme = deterministic such that the decryptor can re-run the header-layout code = and scream if anything is other than the way the encryptor =93should = have=94 done it, including the values of the [pseudo-]random bit in = unused hash table entries and such.) >> This >> metadata will of course appear as uniform random bits to a = non-recipient >> as long as the AEAD encryption scheme is doing its job. Finally, = place >> the AEAD-encrypted file content (c), including any padding, after the >> encrypted session-key blob as the rest of the file. >=20 >=20 > Yup. >=20 > On the remaining SM stuff, I'd like to hear that there is widespread = support for this before subjecting myself to the pain. Understandable, sorry if my text was a bit impenetrable - I realize I = need to work on some better examples and diagrams. :) B= --Apple-Mail=_710DEDB0-2408-467B-8D03-98DAE4776BA2 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTExMDkxNjE2NDFaMCMGCSqGSIb3DQEJBDEWBBSuwNmyPHjAQhZz0N7jzsenhPppIDCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEADybdMJPj7uzOSVxwAs2Fb/ivo1ImyXmCdbb7zfWtajyBHwYP5b25C+ooG3NKT3i+ vl8DOjw/9dy4jp6pfJMsN2Mv/VZ4gQPa2l3bhAfLnYV9d3bfuQ/mtpQ0CuKEf8tjRtmHBcjjOoxc fNFel0ynidaqLB5k6q4GcgEtZ4gI2FTSbJJFC7EZoKw7JBpfP0Mao2T95RewZttfuEJsGW6lXNi+ tsOR3LGVR8Lgotu4SjADx6VcIiXMrYHigZ5gXpf/TyRVWQSL2Xv1lU1eNL6cRdcEHZa6X2k77sLE RyXg7BFWdQ21458qBvUTANcGZZ2VBpruSqH5Q+9RIrtiBj7AJgAAAAAAAA== --Apple-Mail=_710DEDB0-2408-467B-8D03-98DAE4776BA2-- From nobody Mon Nov 9 18:19:52 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 485D21B2DB6 for ; Mon, 9 Nov 2015 18:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.411 X-Spam-Level: X-Spam-Status: No, score=-1.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 3RIQyWIIkDop for ; Mon, 9 Nov 2015 18:19:50 -0800 (PST) Received: from castro.crustytoothpaste.net (castro.crustytoothpaste.net [173.11.243.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B2A11B2D71 for ; Mon, 9 Nov 2015 18:19:50 -0800 (PST) Received: from vauxhall.crustytoothpaste.net (unknown [IPv6:2001:470:1f05:79:f2de:f1ff:feb8:36fd]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by castro.crustytoothpaste.net (Postfix) with ESMTPSA id D64F328094 for ; Tue, 10 Nov 2015 02:19:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=crustytoothpaste.net; s=default; t=1447121989; bh=OtQyKDN9vgE3DqZZWFXhR9WzcOvV9hjLO701yBnxwsI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=EEd1ARuSSEx0Vk5e9pu7Mpwx7tUzcIRGcBFbJACvh36Gp9Jnq1T1fgUKRkfv6s0Cs Lp8OeSffAWRxuW7b+9UQ2VY3cMu0JYCrPTmbcNkEjcDklEh2YB+eHn70S+HjNcY4W9 bSBkTexSzvsaBBcPeWCnY9p+Xgry/67DpvQ+/fgBkrlz2Tf+TKnMC7qoniBj79UMJX X87wrrIqYKppmBHAQ77TERmOIzhgroPHwL7GHGEH0zU6D7sV1E2OEvXQald8lyJJEH w35HjUc7uct0k4yJt4iVIaoHHKQIA3vnW2WWgtpeTV7VfqyyaJM0jIsGSnSbKG+YzN 7J3NZ/dEHc4c3ndP84kpS/1v0GxRj5orhyVN2Ngmf5Pzg1Ic7WZZMgR700pA8Jxr72 3HhTi+ZsfH+PQycx88QzDJ/eA+ZKDaarLAax2VRyZteAkE4eXGfzAWPgYBhmzCstDx O1yNAWTRzxeke45GTbCtgKFrVr8VQf5XKLlBhKKyTj4Nss6vzfV Date: Tue, 10 Nov 2015 02:19:43 +0000 From: "brian m. carlson" To: openpgp@ietf.org Message-ID: <20151110021943.GH3896@vauxhall.crustytoothpaste.net> References: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fU0UwhtRbpo05rnG" Content-Disposition: inline In-Reply-To: <43986BDA-010F-4DBF-8989-53E71B74E66A@gmail.com> X-Machine: Running on vauxhall using GNU/Linux on x86_64 (Linux kernel 4.2.0-1-amd64) User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [openpgp] Keyholder-configurable fingerprint schemes? 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, 10 Nov 2015 02:19:51 -0000 --fU0UwhtRbpo05rnG Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 07, 2015 at 12:31:43PM +0900, Bryan Ford wrote: > This approach to fingerprint generation has the slightly-odd > (certainly unconventional) property that a single public/private > keypair does not have only one possible, deterministically-computed > fingerprint (i.e., a hash of the public key), but rather may in > principle have many different possible fingerprints (parameterized by > the PoW and the salt that will inevitably be required in that PoW). > This might seem to violate the =E2=80=9Cfingerprint consistency=E2=80=9D = property that > was discussed at the meeting. However, as summarized above, my > perception is that the main fingerprint consistency concern is that we > do not want to subject users to multiple different fingerprints *for a > single key*. In Christian=E2=80=99s scheme, while any key could =E2=80= =9Cin > principle=E2=80=9D have many different fingerprints, as long as the user > generating the key (or the user=E2=80=99s OpenPGP implementation) picks o= ne > particular fingerprint and binds that fingerprint to the key in a > fully verifiable fashion as part of the self-signed public-key record, > the fact that fingerprint-generation is parameterized creates no > user-perceivable fingerprint-consistency issue that I can discern. I think not having a single unique fingerprint is in general a bad idea. Earlier discussion on the list reflected wanting to remove creation timestamps so we had a fingerprint that was consistent and represented the actual key bits uniquely. Using a parameterized proof-of-work scheme defeats that goal. Furthermore, one of the benefits of elliptic curve algorithms is the tiny keys. You could theoretically send an entire EC public key in a QR code and still get the same fingerprint on both sides. Including a proof-of-work makes that impossible. Finally, there's been a lot of discussion about simplifying the standard. This doesn't seem like a move in that direction. --=20 brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 --fU0UwhtRbpo05rnG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.9 (GNU/Linux) iQIcBAEBCgAGBQJWQVQ+AAoJEL9TXYEfUvaLF4oP/0Twt1ncfcanLnA2HGLVjAPw cdvuK5KEdKV8Yn8B7gIUvmVmtFF9hKMKSiNCmssWE9QyitQoaNRW9x8ub2tiI8AW NgWmnSS17JPAeJh0lySG2bWEi3Q0sqEQ7XBr38PqU1VrzVs3gJ5EspdUSljuUwh0 O7F8yQlM+sbWyNghDBI0IimEpu7R5yVnGOLimHzx+kCAlSMHltI06unRjPFgs49C LnpuhXzEhlpaCbyX04MDvFEgRhqLsnGdiAtC9lQ1bQ+XTRXfaSD2H7lb6kWGIaRy Vt2JxeE97JBhQHlbwofBgFGTOa7sx9RZ8C/lk8fh70yCiV+pft5t/s0JpOwFkwkq g4gesa6gzBHwGcSCT8xJAPY3hpGOT9XfFJXaxfTxT2MzMGIhoTlyrigiypJcXjCh G7jhDAK03o5VSxzeZWQX/5/vsCHWGCXxbTBhpb3llVW+j1JAwi8BQxaGbO1ARP/Q jCA1Lz93UiK5O2VFuOyTttVtJJqmxOcaoNQOi8cGhqtQPY74+bbxqqU2XIhvvALn QT5yDs38Ilr3h9wxWH5oDpvw0RJIOavaIXVdrE1rXaxxP+OAZi3jVXSaD56rds18 dz1l1sHOOkhg3x6KVPPWiskgbH580LWXQd/JNn3Dwb6SLxjeJhQkJYm/GPtfkwLf IQTIqKCs4cBy29bChf4j =pzcD -----END PGP SIGNATURE----- --fU0UwhtRbpo05rnG--