From nobody Thu Mar 13 14:03:29 2014 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 12BE61A075E for ; Thu, 13 Mar 2014 14:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.998 X-Spam-Level: X-Spam-Status: No, score=0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, MANGLED_TIME=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 tYzVvcWm1Cfv for ; Thu, 13 Mar 2014 14:03:23 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2.hushmail.com [65.39.178.134]) by ietfa.amsl.com (Postfix) with ESMTP id 246AD1A09E8 for ; Thu, 13 Mar 2014 14:03:22 -0700 (PDT) Received: from smtp2.hushmail.com (localhost [127.0.0.1]) by smtp2.hushmail.com (Postfix) with SMTP id 5EC6EA020F for ; Thu, 13 Mar 2014 21:03:16 +0000 (UTC) Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp2.hushmail.com (Postfix) with ESMTPS for ; Thu, 13 Mar 2014 21:03:16 +0000 (UTC) Message-ID: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> Date: Thu, 13 Mar 2014 17:03:13 -0400 From: Vincent Yu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: openpgp@ietf.org X-Enigmail-Version: 1.6 OpenPGP: id=d28d7c4078b3742a; url=https://v-yu.com/pubkeys/openpgp.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WWhgD7eSLjLc8NQ8uhxgD44Du9v1hbCRx" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/PZzHYqcGmYyOl2TDauDJeVEcukM Subject: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 13 Mar 2014 21:03:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WWhgD7eSLjLc8NQ8uhxgD44Du9v1hbCRx Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable I propose an extension to RFC 4880 to add support for ring signatures=20 based on a separable scheme published by Abe et al. in 2002 [AOS04]. The following additions to RFC 4880 are proposed: 1. A new public-key algorithm, ID 22, for ring signatures. 2. A new signature subpacket, ID 33, which lists the key-specific=20 algorithm IDs (see below) and key IDs of the possible signers of a ring=20 signature. 3. A new registry of ring signature key-specific algorithm IDs with the=20 following initial values: ID Algorithm -- --------- 1 - RSA signing 2 - Schnorr signing 3 - EC-Schnorr signing 1. Overview =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ring signatures allow a signer to specify a set of possible signers=20 without revealing who actually signed the message. The proposed scheme=20 is compatible with existing RSA, DSA, and ECDSA keys. Furthermore, it is = unconditionally signer-ambiguous: even if the private keys of all=20 possible signers of a message are revealed, it remains impossible to=20 determine which private key was used to sign the message. The current OpenPGP specification lacks a straightforward way for Alice=20 to send Bob an authenticated message that can only be verified by Bob.=20 Right now, if such a signature is desired, the best that Alice can do is = to send Bob a signed-then-encrypted message. Unfortunately, this means=20 that Bob can show others the decrypted signature to prove to others that = Alice signed the message. This ability of Bob to transfer Alice's=20 signature to others is often undesirable from Alice's point of view. Ring signatures provide an easy way for Alice to authenticate a message=20 to Bob without concomitantly giving Bob the ability to transfer her=20 signature. Alice simply creates a ring signature that specifies Alice=20 and Bob as the possible signers of a message. Upon receipt of the=20 message and ring signature, Bob is assured that the message is signed by = Alice, but he cannot prove to others that Alice signed the message=20 because Bob could have created the ring signature himself. The scenario outlined above is typical of two-party email=20 communications: when we communicate with someone by email, we often wish = ensure the authenticity and privacy of our messages. Thus we sign and=20 encrypt messages. However, we do not usually intend to grant our=20 recipient the ability to authenticate our private messages to others.=20 For such communications, I suggest that using ring signatures with=20 encryption is an option that better reflects our intentions. The proposed scheme closely follows Abe et al's scheme [AOS04], with=20 small modifications made to better integrate with the current OpenPGP=20 specification. Where possible, the notation and variable names in the=20 following sections are the same as those in their paper. Compatibility with DSA and ECDSA keys is achieved by using them as=20 Schnorr and EC-Schnorr keys in the ring signature generation algorithm=20 in Section 3. For now, I ignore ECDSA keys in following sections because = I have not yet gone through the process of creating a ring signature=20 using an ECDSA key to make sure that I comprehend RFC 6637. However, I=20 believe that there are no issues with using ECDSA keys in a way=20 analogous to the way that DSA keys are used in the proposed scheme. 2. Ring signature packet format =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D To create a ring signature, a V4 signature packet MUST be used, and V3=20 signature packets MUST NOT be used. The public-key algorithm field MUST=20 have the value 22 (0x16), which is a new algorithm type for ring signatur= es. A signature subpacket of type 33 (0x21) MUST be present in the hashed=20 subpacket data, and it SHOULD be placed ahead of any other hashed=20 subpacket. This new subpacket type holds a list of pairs of key-specific = algorithm ID and key ID of possible signers. The subpacket body is=20 formed as the concatenation of the following 9-octet pairs: (1 octet algorithm ID, 8 octet key ID) Each key ID is a possible signer of the ring signature, and the=20 prepended algorithm ID specifies how the public key is used in the ring=20 signature generation algorithm presented in Section 3. Currently, RSA=20 keys MUST have a prepended algorithm ID value of 1 (indicating that they = are to be used as RSA keys) and DSA keys MUST have a prepended algorithm = ID value of 2 (indicating that they are to be used as Schnorr keys). The 9-octet pairs SHOULD be ordered such that their key IDs appear in=20 big-endian ascending order. To illustrate the format of the subpacket body, suppose that we wish to=20 create a ring signature with three possible signers, with two DSA key IDs= : F2AD85AC1E42B367 4F0540D577F95F95 And an RSA key ID: 6B1947C7B5BAA022 The correct subpacket body here would be (spaces are inserted for=20 readability only): 02 4F0540D577F95F95 01 6B1947C7B5BAA022 02 F2AD85AC1E42B367 Once the hashed subpacket data has been prepared (it would be normal to=20 include a signature creation time subpacket), a hash of the message to=20 be signed is produced as specified in Section 5.2.4 of RFC 4880. The algorithm-specific fields of a ring signature packet form a=20 concatenated list of MPIs that are generated as prescribed in Section 3. 3. Ring signature generation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D The ring signature generation algorithm takes the hashed message and=20 prepends a single octet containing the hash algorithm ID (identified in=20 Section 9.4 of RFC 4880) of the hash function used (this is done to=20 prevent length-extension shenanigans with hash functions based on the=20 Merkle=E2=80=93Damg=C3=A5rd construction). That is, given the hashed mess= age m, we=20 define: hm =3D hash_algorithm_id || m To generate a ring signature, the actual signer must have available to=20 them the public keys of all the possible signers, as well as the private = key of one of the public keys. Label the public keys from 1 to n in the same order as in the ring=20 signature key-specific IDs and key IDs subpacket. Let k be the label of=20 the public key for which the signer has the private key (so k is one of=20 the integers from 1 to n). For each public key, given its label i, use the following variable names = for the unsigned integers that form the key material (the names are the=20 same as those used in Section 5.5.2 of RFC 4880): if RSA(i): (n_i, e_i) if Schnorr(i): (p_i, q_i, g_i, y_i) For the private key (same as Section 5.5.3 of RFC 4880): if RSA(k): (d_k, p_k, q_k, u_k) if Schnorr(k): (x_k) Define the functions Random(n), MPI(n), and Hash() as follows. Random(n) returns a uniformly random integer from 0 to n-1 inclusive. MPI(n) returns a string of octets that is the unique MPI representation=20 of the unsigned integer n, as defined in Section 3.2 of RFC 4880. Hash() is the same hash function as that used to hash the message. Now evaluate the following to generate the ring signature. Initialize the ring signature: if RSA(k): r =3D Random(n_k) a_k =3D r if Schnorr(k): r =3D Random(q_k) a_k =3D g_k**r mod p_k c_(k+1) =3D Hash(hm || MPI(a_k)) For i =3D k+1, ..., n, 1, ..., k-1: if RSA(i): s_i =3D Random(n_i) a_i =3D (c_i + s_i**e_i) mod n_i if Schnorr(i): s_i =3D Random(q_i) a_i =3D (g_i**s_i * y_i**c_i) mod p_i c_(i+1) =3D Hash(hm || MPI(a_i)) Close the ring signature: if RSA(k): s_k =3D (r - c_k)**d_k mod n_k if Schnorr(k): s_k =3D (r - x_k*c_k) mod q_k The ring signature output is a concatenated list of n+1 MPIs: MPI(c_1) || MPI(s_1) || MPI(s_2) || ... || MPI(s_n) Note that in the degenerate case where n=3D1, the middle loop is skipped = and the resulting signature is simply a randomized RSA signature or a=20 standard Schnorr signature. 4. Ring signature verification =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Given a message and a ring signature packet, the signature can be=20 verified by following the same steps as in the signature generation to=20 hash the message, then prepending the hash algorithm ID to get hm, then=20 finally evaluating the following loop. For i =3D 1, ..., n: if RSA(i): a_i =3D (c_i + s_i**e_i) mod n_i if Schnorr(i): a_i =3D (g_i**s_i * y_i**c_i) mod p_i c_(i+1) =3D Hash(hm || MPI(a_i)) Accept the signature if and only if the computed c_1 (i.e., c_(n+1)) is=20 identical to the input c_1. 5. Notes for implementers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= As outlined in the overview in Section 1, an intended use of ring=20 signatures is to provide non-transferable authenticity in two-party=20 communications. Ring signatures can be used for other purposes (see=20 [RST06]). This proposal does not give a strict prescription for the=20 usage of ring signatures, and decisions regarding the creation and=20 interpretation of ring signatures is left to the implementation. It is common for an OpenPGP key bundle to contain multiple keys that are = capable of producing signatures. For instance, this is the case when the = primary certification key and a subkey both have their signing flags set = (see Section 5.2.3.21 of RFC 4880). When a user wishes to create a ring=20 signature that includes a key ID in a bundle that contains other keys=20 capable of signing, it would make sense to include all signing-capable=20 keys in the ring signature. This is illustrated in Appendix A. 6. Summary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In this message, I proposed an extension to RFC 4880 that adds support=20 for ring signatures and provided specifications for the packet format=20 and signature generation algorithm. I would like to hear your comments on this proposal. Vincent Selected references =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D For readers unfamiliar with ring signatures, I recommend first reading=20 [RST06], then Sections 1=E2=80=933 of [BSS02], then finally [AOS04]. [AOS04] M. Abe, M. Ohkubo, and K. Suzuki (2004). 1-out-of-n signatures from a variety of keys. https://v-yu.com/lib/2004_Abe,%20Ohkubo,%20Suzuki.pdf This is a newer version of an earlier conference paper that was=20 published at ASIACRYPT 2002. [BSS02] E. Bresson, J. Stern, and M. Szydlo (2002). Threshold ring signatures and applications to ad-hoc groups. https://www.di.ens.fr/~bresson/papers/BreSteSzy02_full.pdf This is the full version of an extended abstract that was published at=20 CRYPTO 2002. [RST06] R. L. Rivest, A. Shamir, and Y. Tauman (2006). How to leak a secret: Theory and applications of ring signatures. doi:10.1007/11685654_7 https://v-yu.com/lib/2006_Rivest,%20Shamir,%20Tauman.pdf This is an updated version of an earlier conference paper that was=20 published at ASIACRYPT 2001. Appendix A. Example of a ring signature following the current proposal =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 This message is used to demonstrate a ring signature. -----BEGIN PGP SIGNATURE----- wsBFBAEWCAAjHCECTwVA1Xf5X5UBaxlHx7W6oCIC8q2FrB5Cs2cFAlLW2wcAAD9a AP0Ra1gFBVBxgoeOxaTcujSOAMbgf6HLF4N1bb0OLHcseACdFcWeQO4kUeSaMuRh qbmi6hzbZ64D+gImlNxP3/gKNF5QP445LZfjvVULr+H3WCZylP4GhEnieMas+X+s XUDMAQSKL/O7qO+i1/k85yDWLod3Fv8ki3n4QF8N/wlzhuRHpT6Z4f0lZcdlA0be DCa2bRBa3rriUt/yTtKVjpRKfHOkV+FLdWvWoYIs9mBTvgJ6MwfgKz4HAOC4Eo8+ MqWNgrr7Y8/byd8wQSmx3mTDHScc7oOP =3D0Hrj -----END PGP SIGNATURE----- To demonstrate the proposed specification and to eliminate ambiguity, I=20 have prepared the cleartext ring signature above. The signed message=20 complies with the cleartext signature framework in Section 7 of RFC=20 4880. The base64-encoded data contains a ring signature packet that=20 follows the current proposal. Three key IDs are identified as the=20 possible signers: 4F0540D577F95F95 - Werner's DSA signing subkey. 6B1947C7B5BAA022 - RSA signing key that I created for this occasion.= F2AD85AC1E42B367 - Werner's DSA primary key. Werner's public keys are available at: http://werner.eifelkommune.de/mykey.asc The private key for 6B1947C7B5BAA022 is provided in Appendix B. This=20 private key was used to create the ring signature. The value of r used in the ring signature generation algorithm can be=20 recovered from the signature, but let me provide it here anyway for your = convenience in case you wish to reproduce an exact copy of the ring=20 signature: r =3D 0x5202a86b534ac6e7680c3db32f1b409a8529d1e8d51baf648e9f0d 9fc35bd8bc6b8327636666511566a5bd54a1f2c01d376ae6a38af39c bb3682a89604299c32c3843709124c4dd25a08c2a8ba8c8ad215337c 951ed330444bccb04d4d74b75e3f0e6c04e168d2d93c903fddabc89d 884082022fcc01eaa2be9e3b14ae909732 The following is an overview of the signature structure in hex: C2 C045 New packet format holding a signature packet with data length 261. 04 01 16 08 V4 signature of canonical text document using a ring signature with SHA25= 6. 0023 Length of hashed subpacket data: 35 octets. 1C 21 02 4F0540D577F95F95 01 6B1947C7B5BAA022 02 F2AD85AC1E42B367 28-octet hashed subpacket containing the ring signature key-specific=20 algorithm IDs and key IDs. 05 02 52D6DB07 5-octet hashed subpacket containing the signature creation time. 0000 Length of unhashed subpacket data: 0 octets. 3F5A 2-octet field containing the leftmost 16 bits of the hashed message. The remaining packet data is a concatenated list of four MPIs that form=20 the ring signature, generated as prescribed in Section 3. Appendix B. Private key for 6B1947C7B5BAA022 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The following private key was used in the ring signature generation=20 algorithm to create the ring signature displayed in Appendix A. pub 1024R/6B1947C7B5BAA022 created: 2014-01-15 expires: never usage: S= C Key fingerprint =3D 2AA7 1619 35F1 2D1D 2BA6 78B2 6B19 47C7 B5BA A= 022 uid This key is for testing only -----BEGIN PGP PRIVATE KEY BLOCK----- Version: GnuPG v2.0.20 (GNU/Linux) lQHYBFLWxR8BBADVrNPuPADyr9Do3Ev4nObRWh8T8hM32A4+tI+lKxkiT7FPHnAy HDGrsrA2nLYgKM0ulunWRMNKnNRVM9NcK9QNDXMvAE7xaIimGMislBQYVwoKQp6m pa4uoddGBh1y/1E9QqL5FXO5cEuXsKYAmOvpZlkoM1+dil8qFE2aCxk7bQARAQAB AAP/RYBaywHfeRDxDd0iJPK8LVp4A1/ZGm//aiwHET1shnmPfeGzssjy6xtLL+hX YSyEWOQjmVtyfmF2u2QJGtDyvtf1mVAOzqMxIEdQYcYkKGgEUUwwwkylhj9h3A2Q Ir95OFGZWiAqAvDwUhOZIsyU9hrSwqqZj7B33GJFqbQ0Oc0CAOXN7yVeI+C7WOPE Maodt9nJaBVj4k943ltDZhfIKql8T8/eUsRQuR+NQYeiE2T1QM+E1SKh0fjy9wyg f9CwETMCAO4INsS1ziq+3GMvVwMcSIp0MnwtZRMv4v4+tlme+rBC6QTjUxAhGj5t JGg3mO0EHNQpdrp27/3Y2Sngt9/cwN8B+QEXEvYKpxBtPyDdyXVkS+cB2elS8yGF qXdgUMb3ix5q6eWN/SlCXnU7AO5jEGwI3FR7vJPcCfoouAjaLZmY9RydbrQcVGhp cyBrZXkgaXMgZm9yIHRlc3Rpbmcgb25seYi4BBMBAgAiBQJS1sUfAhsDBgsJCAcD AgYVCAIJCgsEFgIDAQIeAQIXgAAKCRBrGUfHtbqgImOdBACwhoADhwKIZBh8wnDT UGK6R2Dww9nwhUSMXXBWWPgxWDAIIbeh8HRiumeaHC/9B9apG1mKuJ6UVjho5bK/ RzST92eB0v7Yu+Xrhgq89KTGaA43I501jol+WbjxpaFmj4rWhUPWOkxq7PTAOCyW T/FZ0tYoeBwVWMOlui2PlQyj1g=3D=3D =3D88Gm -----END PGP PRIVATE KEY BLOCK----- --WWhgD7eSLjLc8NQ8uhxgD44Du9v1hbCRx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREKAAYFAlMiHRIACgkQHE22W/Uzb8SzmwEAqiyfGrNWWIVkOSljfHcHqtyt b94eyh2GVOD6fZKjH+QA/jp7PQv7YnxR/1ceOqfwV9J5JOekG0VwdXMNZM/03M6y =22Wr -----END PGP SIGNATURE----- --WWhgD7eSLjLc8NQ8uhxgD44Du9v1hbCRx-- From nobody Thu Mar 13 14:12:11 2014 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 DF4951A0496 for ; Thu, 13 Mar 2014 14:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OfYkl3TTqUy for ; Thu, 13 Mar 2014 14:12:06 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9114B1A09CE for ; Thu, 13 Mar 2014 14:12:06 -0700 (PDT) Received: from [10.70.10.55] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 47B7FF984; Thu, 13 Mar 2014 17:11:58 -0400 (EDT) Message-ID: <53221F13.4090706@fifthhorseman.net> Date: Thu, 13 Mar 2014 17:11:47 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: Vincent Yu , openpgp@ietf.org References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> In-Reply-To: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cgdRs3GUTCdh83VAMDkAb1D3WcCVpuGlb" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/5q_AijSp3Fc6YS5mZbwyeN2nyrc Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 13 Mar 2014 21:12:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cgdRs3GUTCdh83VAMDkAb1D3WcCVpuGlb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/13/2014 05:03 PM, Vincent Yu wrote: > I propose an extension to RFC 4880 to add support for ring signatures > based on a separable scheme published by Abe et al. in 2002 [AOS04]. >=20 > The following additions to RFC 4880 are proposed: >=20 > 1. A new public-key algorithm, ID 22, for ring signatures. a claim has already been made for public key algorithm ID 22 for EdDSA. See: http://thread.gmane.org/gmane.ietf.openpgp/7419/focus=3D7421 I think it would be a mistake to force a collision here. I haven't had a chance to review the meat of the proposal yet, but i think proposals like are better off starting with an experimental public key algorithm ID so that the discussion can be about the algorithm itself and its use within OpenPGP, rather than opening up ID assignment quibbling. thanks for the proposal, --dkg --cgdRs3GUTCdh83VAMDkAb1D3WcCVpuGlb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTIh8TXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc+8cQAMXUxyPhmAL//1WLjVOwfXs6 1mofBgsS07uqRJAC4d+Ao5jX/YWw+DT/eIyd2UnIQCEGxl7FqBFF7wdcjGwzHyou 7rSV4n54gexNAUQGdPnIPRi2q/syX8gDx1lwxelqoHvTVAF2+pIMu1q8SE4TEKUH F/vPOKmBjqmi40pJO65vS8qbjR1zu9VwSOCneN+y5zzjEvnozbF6y9q+FIRr4CFJ KTEIZ6VjbYf4qTAoKxN5p9Vi4UgnxfsZMDcfhU7bPBZh7RIezVQeHzco4diE7ztW xPq98WUkKECa7BQxNEb1XPbHSq7z8w1w5cMypa9a582qQ4WrYQ3BTKBGivjdWAvd brSNpPquw5IB+b/qrWCtxVHiIyHkjkTDrtraWA9iEvKDiIyuMKnfRGzBBXXfEZ1U RwKCA/F+aLd5B6+0YG66PgYSNputzZTQpcgkT+D5P7zcpJqgmZojxgJQ9B97IahH e+oIrxmJ+yPkTmfLbyOfulhiKBHqeQfLUIrZ0mbmRAxIyVuT+vO4MYfN5espMq+q K3nAuy6YCTpw9RXiD/GpoDVDAVGWjP8prmikWyQ02KgsjsJE0+wESEdFekJb2NVi Px6UvzcKi0hCQmT7g+bIYLi/UmQ86Sr/YFYQkdkYbZw71p5CVYkTXLU9eK1eh83y U6MnWSJw1SFymjDNB0Kx =CHmX -----END PGP SIGNATURE----- --cgdRs3GUTCdh83VAMDkAb1D3WcCVpuGlb-- From nobody Thu Mar 13 14:25:39 2014 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 72E421A076C for ; Thu, 13 Mar 2014 14:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYtIelACyiwW for ; Thu, 13 Mar 2014 14:25:34 -0700 (PDT) Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.200]) by ietfa.amsl.com (Postfix) with ESMTP id B8F9B1A075E for ; Thu, 13 Mar 2014 14:25:34 -0700 (PDT) Received: from smtp3.hushmail.com (localhost [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 18649E0190 for ; Thu, 13 Mar 2014 21:25:28 +0000 (UTC) Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp3.hushmail.com (Postfix) with ESMTPS; Thu, 13 Mar 2014 21:25:27 +0000 (UTC) Message-ID: <3dcb8c4c25c735f7384c8753b7c190c2@smtp.hushmail.com> Date: Thu, 13 Mar 2014 17:25:24 -0400 From: Vincent Yu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , openpgp@ietf.org References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <53221F13.4090706@fifthhorseman.net> In-Reply-To: <53221F13.4090706@fifthhorseman.net> X-Enigmail-Version: 1.6 OpenPGP: id=d28d7c4078b3742a; url=https://v-yu.com/pubkeys/openpgp.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Mcm3IRURe5E4nNBHbTAQBgJ2KtrIKUUUv" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/31VKA6GxY_RGI08_fKlI-iH7SO0 Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 13 Mar 2014 21:25:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Mcm3IRURe5E4nNBHbTAQBgJ2KtrIKUUUv Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 03/13/2014 05:11 PM, Daniel Kahn Gillmor wrote: > a claim has already been made for public key algorithm ID 22 for EdDSA= =2E > > See: > > http://thread.gmane.org/gmane.ietf.openpgp/7419/focus=3D7421 > > I think it would be a mistake to force a collision here. > > I haven't had a chance to review the meat of the proposal yet, but i > think proposals like are better off starting with an experimental publ= ic > key algorithm ID so that the discussion can be about the algorithm > itself and its use within OpenPGP, rather than opening up ID assignmen= t > quibbling. Whoops. Thanks, that's a good point. It's too late now for me to modify the example I gave in Appendix A, but = if I create any more examples, I'll use experimental IDs instead of 22=20 and 33. Vincent --Mcm3IRURe5E4nNBHbTAQBgJ2KtrIKUUUv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREKAAYFAlMiIkYACgkQHE22W/Uzb8R4EwD+P8+ShkpJQuNh84BoVMDx7GYn Rdpx+AJIItyR4iATG4sA/j02lSbollLqZ6in3x2a5/jLwImKTLjXNx7x7+nMUumv =Etap -----END PGP SIGNATURE----- --Mcm3IRURe5E4nNBHbTAQBgJ2KtrIKUUUv-- From nobody Thu Mar 13 15:03:39 2014 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 3D4DA1A0747 for ; Thu, 13 Mar 2014 15:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dFqw2YuICbPL for ; Thu, 13 Mar 2014 15:03:35 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id B7DAD1A0644 for ; Thu, 13 Mar 2014 15:03:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 82C1E4F244B9; Thu, 13 Mar 2014 15:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWOip8+8UrAL; Thu, 13 Mar 2014 15:03:11 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 39DD04F244A7; Thu, 13 Mar 2014 15:03:05 -0700 (PDT) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Thu, 13 Mar 2014 15:03:11 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 13 Mar 2014 15:03:11 -0700 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Jon Callas In-Reply-To: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> Date: Thu, 13 Mar 2014 15:02:58 -0700 Message-Id: <23C2DE82-93B7-48A6-95A6-14B4F5DD1F42@callas.org> References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> To: Vincent Yu X-Mailer: Apple Mail (2.1874) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/eXR-dBAOwsRoky-yYrrs6ndIt_g Cc: openpgp@ietf.org, Jon Callas Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 13 Mar 2014 22:03:37 -0000 My suggestion is that you write up an I-D, and push it. My quick read looks like this is a useful thing, and it would be nice to = have. Just as Andrey pushed an ECC draft and there have been others, = it'd be a great way to go. As DKG noted, we have a constant collision, but that's not a big deal. = That's why we have IANA. Jon From nobody Thu Mar 13 18:28:31 2014 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 5FAD31A07DA for ; Thu, 13 Mar 2014 18:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqVPXi1Z-cjf for ; Thu, 13 Mar 2014 18:28:26 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1.hushmail.com [65.39.178.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4504D1A07D9 for ; Thu, 13 Mar 2014 18:28:26 -0700 (PDT) Received: from smtp1.hushmail.com (localhost [127.0.0.1]) by smtp1.hushmail.com (Postfix) with SMTP id A915040176 for ; Fri, 14 Mar 2014 01:28:19 +0000 (UTC) Received: from smtp.hushmail.com (w4.hushmail.com [65.39.178.50]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp1.hushmail.com (Postfix) with ESMTPS; Fri, 14 Mar 2014 01:28:19 +0000 (UTC) Message-ID: <3e9143bf60d2252a67149eb4b984bcdb@smtp.hushmail.com> Date: Thu, 13 Mar 2014 21:28:15 -0400 From: Vincent Yu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Jon Callas References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <23C2DE82-93B7-48A6-95A6-14B4F5DD1F42@callas.org> In-Reply-To: <23C2DE82-93B7-48A6-95A6-14B4F5DD1F42@callas.org> X-Enigmail-Version: 1.6 OpenPGP: id=d28d7c4078b3742a; url=https://v-yu.com/pubkeys/openpgp.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MxxdxCobXVElxkEKGTGc4ifJdXSDDCQsp" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/bnlFNB2aXTUTPNQNd9aHsosUdL8 Cc: openpgp@ietf.org Subject: [openpgp] Non-SHA-1 fingerprints in signatures [was: Proposal for a separable ring signature scheme...] 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, 14 Mar 2014 01:28:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MxxdxCobXVElxkEKGTGc4ifJdXSDDCQsp Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 03/13/2014 06:02 PM, Jon Callas wrote: > My suggestion is that you write up an I-D, and push it. > > My quick read looks like this is a useful thing, and it would be nice t= o have. Just as Andrey pushed an ECC draft and there have been others, it= 'd be a great way to go. > > As DKG noted, we have a constant collision, but that's not a big deal. = That's why we have IANA. > > Jon Thanks for your comments. I plan to write up and submit an I-D if no one = points out egregious problems with the current proposal. In past threads, there were discussions about supporting non-SHA-1=20 fingerprints [1] and including full issuer fingerprints in signatures=20 [2]. You forwarded to this list a proposal for a new fingerprint [3].=20 Did anything concrete come out of that proposal or other discussions? In my proposal, I am using key IDs (i.e., the rightmost 8 octets of=20 SHA-1 fingerprints) in a new signature subpacket, but I would like to=20 switch to non-SHA-1 fingerprints if there is a standard or consensus=20 about how they should be formatted. This is an opportune time to=20 introduce such fingerprints since backward compatibility is not a=20 relevant consideration. Comments on this are welcome from everyone. Vincent [1]: https://www.ietf.org/mail-archive/web/openpgp/current/msg00253.html [2]: https://www.ietf.org/mail-archive/web/openpgp/current/msg00405.html [3]: https://www.ietf.org/mail-archive/web/openpgp/current/msg00259.html --MxxdxCobXVElxkEKGTGc4ifJdXSDDCQsp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREKAAYFAlMiWzEACgkQHE22W/Uzb8R94wD+KMgjYpWt7rHRwfQC7rL5GXtS 3NAADcJaKRoS+tSZTE0A/iMwX/XeNsoqUQZoVxbAjpvA/w3tN8lGjD9MeAd9sRl3 =toDr -----END PGP SIGNATURE----- --MxxdxCobXVElxkEKGTGc4ifJdXSDDCQsp-- From nobody Thu Mar 13 19:27:00 2014 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 058F11A06C3 for ; Thu, 13 Mar 2014 19:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmLZ1GnEOkGW for ; Thu, 13 Mar 2014 19:26:56 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id DCD821A06C1 for ; Thu, 13 Mar 2014 19:26:55 -0700 (PDT) Received: from [192.168.13.159] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 22F5EF984; Thu, 13 Mar 2014 22:26:47 -0400 (EDT) Message-ID: <532268E5.8090001@fifthhorseman.net> Date: Thu, 13 Mar 2014 22:26:45 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <23C2DE82-93B7-48A6-95A6-14B4F5DD1F42@callas.org> <3e9143bf60d2252a67149eb4b984bcdb@smtp.hushmail.com> In-Reply-To: <3e9143bf60d2252a67149eb4b984bcdb@smtp.hushmail.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Pj5O3lcXRxdsBvj1VwKlTJoQaCM8BdPVH" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/jpei6Eb4L_fwl7BMMlQA3aogxnQ Cc: Vincent Yu Subject: Re: [openpgp] Non-SHA-1 fingerprints in signatures [was: Proposal for a separable ring signature scheme...] 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, 14 Mar 2014 02:26:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Pj5O3lcXRxdsBvj1VwKlTJoQaCM8BdPVH Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/13/2014 09:28 PM, Vincent Yu wrote: > In past threads, there were discussions about supporting non-SHA-1 > fingerprints [1] and including full issuer fingerprints in signatures > [2]. You forwarded to this list a proposal for a new fingerprint [3]. > Did anything concrete come out of that proposal or other discussions? >=20 > In my proposal, I am using key IDs (i.e., the rightmost 8 octets of > SHA-1 fingerprints) in a new signature subpacket, but I would like to > switch to non-SHA-1 fingerprints if there is a standard or consensus > about how they should be formatted. This is an opportune time to > introduce such fingerprints since backward compatibility is not a > relevant consideration. the OpenPGP fingerprint revision discussions have not yet terminated in a clear conclusion -- the last stage we reached was was "wait until SHA-3 has settled down and then reconsider". You should *not* use keyIDs as distinct identifiers in the subpacket body of the ring signature design; the use of keyIDs in the traditional issuer subpacket is a mistake that i hope we don't propagate if/when OpenPGPv5 ever gets standardized. Your I-D should have the subpacket body built from either OpenPGPv4 fingerprints, or full public key packets. the search space for key IDs is too small to distinguish "bad signature" from "i don't have the appropriate key" with sufficient confidence, which causes all sorts of nasty UI edge cases. --dkg --Pj5O3lcXRxdsBvj1VwKlTJoQaCM8BdPVH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTImjlXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcImQP/3RZclx4XR33PoCHrRFSJbvR ToTW0It1IP+neIqdaAUuRijX/fA652lb0korkTJhVEnRRPjH1y0MkM/Im47dGAB6 RcwRVIrf9fcSGYXjSFLXvdwqzJRgwG3vJL2rSfRbEc9YVphLItZCY3iTU0r+qymr 3GaNXOtdwv0ocT2OXnQgjuCe6IXWqf8BIiSoHA8AJqgjFz50PQ+eNVw67pAKrqu7 k9DsYB8PBm1pfjV670Yqi8NnKFf3VYMODeQ0dZKPKj+mMiq56FqwBBTUQSCsX836 ZayVSTunnzYEmItpGbJcfy5oigotnubKIJP9IW/Lb3s2e2bAXYfBwcTgsYxO1wsW QeCwAS3p4i3xOOdcirG/szPMPKHWgUp7MOUmhq/W8K3CY7UYYTNARvZCyxIrgKXI hoPxuACt7OsRrl3rXaZmrxF0msYNaRVs2TgSgI2GStyolRDxTp8pvZxbtSaiTq0m EVChck6thCypAulflhO8p98qQDZ0kzjoZYThO12/fprhiZHVRSEt1TYJ+zK4QaGY RdEmT1REwbyuTqQ19lo9PPQhc/gdxxOdKCcJ8vxaJX+fP7KZiOtwNsWQksYKfpjd myuCWlP3adx85Ug2H1x64UQFHkN4/hiS7Rk5E4yYcep3tM1clOgeAhFf/aMc52mr pHfkc+Jr7eOFk7Fm2jbz =OSui -----END PGP SIGNATURE----- --Pj5O3lcXRxdsBvj1VwKlTJoQaCM8BdPVH-- From nobody Thu Mar 13 19:39:46 2014 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 649071A06C8 for ; Thu, 13 Mar 2014 19:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUXNJqGWi47Z for ; Thu, 13 Mar 2014 19:39:42 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2.hushmail.com [65.39.178.134]) by ietfa.amsl.com (Postfix) with ESMTP id 60B111A06C3 for ; Thu, 13 Mar 2014 19:39:42 -0700 (PDT) Received: from smtp2.hushmail.com (localhost [127.0.0.1]) by smtp2.hushmail.com (Postfix) with SMTP id B33B9A03E7 for ; Fri, 14 Mar 2014 02:39:35 +0000 (UTC) Received: from smtp.hushmail.com (w7.hushmail.com [65.39.178.32]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp2.hushmail.com (Postfix) with ESMTPS; Fri, 14 Mar 2014 02:39:35 +0000 (UTC) Message-ID: <1e053aff143a868d303cb483949bcd31@smtp.hushmail.com> Date: Thu, 13 Mar 2014 22:39:31 -0400 From: Vincent Yu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , openpgp@ietf.org References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <23C2DE82-93B7-48A6-95A6-14B4F5DD1F42@callas.org> <3e9143bf60d2252a67149eb4b984bcdb@smtp.hushmail.com> <532268E5.8090001@fifthhorseman.net> In-Reply-To: <532268E5.8090001@fifthhorseman.net> X-Enigmail-Version: 1.6 OpenPGP: id=d28d7c4078b3742a; url=https://v-yu.com/pubkeys/openpgp.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jsQN2bAk3PnKI8hTggUEafKE7nlmNaea7" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/Km6NEqcv01OYZQ5ABw8lfnui-VM Subject: Re: [openpgp] Non-SHA-1 fingerprints in signatures [was: Proposal for a separable ring signature scheme...] 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, 14 Mar 2014 02:39:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jsQN2bAk3PnKI8hTggUEafKE7nlmNaea7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 03/13/2014 10:26 PM, Daniel Kahn Gillmor wrote: > the OpenPGP fingerprint revision discussions have not yet terminated in= > a clear conclusion -- the last stage we reached was was "wait until > SHA-3 has settled down and then reconsider". > > You should *not* use keyIDs as distinct identifiers in the subpacket > body of the ring signature design; the use of keyIDs in the traditional= > issuer subpacket is a mistake that i hope we don't propagate if/when > OpenPGPv5 ever gets standardized. > > Your I-D should have the subpacket body built from either OpenPGPv4 > fingerprints, or full public key packets. the search space for key IDs= > is too small to distinguish "bad signature" from "i don't have the > appropriate key" with sufficient confidence, which causes all sorts of > nasty UI edge cases. > > --dkg Thanks for the info. I will likely follow your suggestion and modify my=20 proposal to use V4 fingerprints rather than key IDs. Vincent --jsQN2bAk3PnKI8hTggUEafKE7nlmNaea7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREKAAYFAlMia+UACgkQHE22W/Uzb8QhSAD/dMVIPGT+M9fnP+naOuUaMYzS 4Ue1hHYJjZm+z7ENQ/UA/jsIC4gJ2qmgWkfSqhKOSftqwgHcRz7nI//QbI8E5d+m =Vj0f -----END PGP SIGNATURE----- --jsQN2bAk3PnKI8hTggUEafKE7nlmNaea7-- From nobody Thu Mar 13 19:40:33 2014 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 CAE061A06C3 for ; Thu, 13 Mar 2014 19:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 LsW1GV4mxBgq for ; Thu, 13 Mar 2014 19:40:29 -0700 (PDT) Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by ietfa.amsl.com (Postfix) with ESMTP id B5ED51A0700 for ; Thu, 13 Mar 2014 19:40:29 -0700 (PDT) Received: from grover.home.jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) (authenticated bits=0) by walrus.jabberwocky.com (8.14.4/8.14.4) with ESMTP id s2E2eLF9011994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Mar 2014 22:40:22 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: David Shaw In-Reply-To: <3e9143bf60d2252a67149eb4b984bcdb@smtp.hushmail.com> Date: Thu, 13 Mar 2014 22:40:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <538571C5-9219-4226-B50E-26851A475FB8@jabberwocky.com> References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <23C2DE82-93B7-48A6-95A6-14B4F5DD1F42@callas.org> <3e9143bf60d2252a67149eb4b984bcdb@smtp.hushmail.com> To: Vincent Yu X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/VTRVEdTg6VLYCqKeWfrsVnjRC3o Cc: IETF OpenPGP Subject: Re: [openpgp] Non-SHA-1 fingerprints in signatures [was: Proposal for a separable ring signature scheme...] 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, 14 Mar 2014 02:40:32 -0000 On Mar 13, 2014, at 9:28 PM, Vincent Yu wrote: > On 03/13/2014 06:02 PM, Jon Callas wrote: >> My suggestion is that you write up an I-D, and push it. >>=20 >> My quick read looks like this is a useful thing, and it would be nice = to have. Just as Andrey pushed an ECC draft and there have been others, = it'd be a great way to go. >>=20 >> As DKG noted, we have a constant collision, but that's not a big = deal. That's why we have IANA. >>=20 >> Jon >=20 > Thanks for your comments. I plan to write up and submit an I-D if no = one points out egregious problems with the current proposal. >=20 > In past threads, there were discussions about supporting non-SHA-1 = fingerprints [1] and including full issuer fingerprints in signatures = [2]. You forwarded to this list a proposal for a new fingerprint [3]. = Did anything concrete come out of that proposal or other discussions? >=20 > In my proposal, I am using key IDs (i.e., the rightmost 8 octets of = SHA-1 fingerprints) in a new signature subpacket, but I would like to = switch to non-SHA-1 fingerprints if there is a standard or consensus = about how they should be formatted. This is an opportune time to = introduce such fingerprints since backward compatibility is not a = relevant consideration. Changing fingerprints raises a lot of complexity that you may not want = tied to your I-D. I suspect that non-SHA-1 fingerprints will not happen = without an accompanying V5 key format. With regards to your I-D, I recommend using the full fingerprint instead = of the 64-bit key ID in your sig subpacket. That is the least ambiguous = way to specify a key today, and while it is V4 specific, it can be = easily changed if and when the fingerprint changes, just like the = revocation key subpacket will need to be. (Though see = https://www.ietf.org/mail-archive/web/openpgp/current/msg00260.html ) David From nobody Fri Mar 14 03:01:56 2014 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 4B7C81A00C6 for ; Fri, 14 Mar 2014 03:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 Jk_hhGBXUkAs for ; Fri, 14 Mar 2014 03:01:52 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id 40FFB1A00EA for ; Fri, 14 Mar 2014 03:01:52 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1WOOvv-0007WM-VT for ; Fri, 14 Mar 2014 11:01:44 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1WOOko-0006xl-U5; Fri, 14 Mar 2014 10:50:14 +0100 From: Werner Koch To: Vincent Yu References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Fri, 14 Mar 2014 10:50:14 +0100 In-Reply-To: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> (Vincent Yu's message of "Thu, 13 Mar 2014 17:03:13 -0400") Message-ID: <8761nh1549.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: http://mailarchive.ietf.org/arch/msg/openpgp/Rv8Q6Zzt1VQZD1FRBauTl68EigY Cc: openpgp@ietf.org Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 14 Mar 2014 10:01:54 -0000 Hi, On Thu, 13 Mar 2014 22:03, v@v-yu.com said: > 3. A new registry of ring signature key-specific algorithm IDs with the > following initial values: > > ID Algorithm > -- --------- > 1 - RSA signing > 2 - Schnorr signing > 3 - EC-Schnorr signing Why do we need a new registry? I can't see a problem in using the existing public algorithms ids and declare that only certain algorithms may be used for ring signatures (i.e. exclude the algo for a ring signature). I would also suggest to settle for ECC algorithms and not bother with RSA or DSA anymore. > (1 octet algorithm ID, 8 octet key ID) Until a v5 public key packet format has been defined, I would strongly suggest to use the full SHA-1 fingerprint instead of a key id. Creating long key id collisions is quite possible and thus would require extra code for trial verification. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Fri Mar 14 06:55:19 2014 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 200D21A015A for ; Fri, 14 Mar 2014 06:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIrnsUNVwnbA for ; Fri, 14 Mar 2014 06:55:14 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5.hushmail.com [65.39.178.142]) by ietfa.amsl.com (Postfix) with ESMTP id E35E51A014F for ; Fri, 14 Mar 2014 06:55:12 -0700 (PDT) Received: from smtp5.hushmail.com (localhost [127.0.0.1]) by smtp5.hushmail.com (Postfix) with SMTP id 1839D607FE for ; Fri, 14 Mar 2014 13:55:06 +0000 (UTC) Received: from smtp.hushmail.com (w6.hushmail.com [65.39.178.92]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp5.hushmail.com (Postfix) with ESMTPS; Fri, 14 Mar 2014 13:55:05 +0000 (UTC) Message-ID: Date: Fri, 14 Mar 2014 09:55:02 -0400 From: Vincent Yu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Werner Koch References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> In-Reply-To: <8761nh1549.fsf@vigenere.g10code.de> X-Enigmail-Version: 1.6 OpenPGP: id=d28d7c4078b3742a; url=https://v-yu.com/pubkeys/openpgp.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mlprSUdDIegAwX5wMkBC1OXoSnr0lJB3f" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/PGnbsyoQQDJ3dJQZvS8V1vnjJxE Cc: openpgp@ietf.org Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 14 Mar 2014 13:55:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mlprSUdDIegAwX5wMkBC1OXoSnr0lJB3f Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 03/14/2014 05:50 AM, Werner Koch wrote: > Why do we need a new registry? I can't see a problem in using the > existing public algorithms ids and declare that only certain algorithms= > may be used for ring signatures This is a good point. I was worried that some people might object to=20 having DSA keys being used as Schnorr keys, which is what's being done=20 in the current proposal. The registry provides a way for a signer to=20 state explicitly that this is intended, and provides some=20 future-proofing in case a future extension to ring signatures uses DSA=20 keys differently. I anticipated potential objections because it is possible to modify or=20 augment the proposal to use DSA keys in ways that more closely resemble=20 DSA. The main alternative I considered is to use something like what Ren = and Harn published in 2008 [RH08]. Their scheme provides a way to use=20 ElGamal keys in a ring signature, and I think it can possibly be=20 modified and integrated with Abe et al's scheme to use DSA keys directly = as DSA keys. I didn't do so for the following reasons: 1. This alternative scheme produces signatures that are up to double the = size of those from the current scheme. 2. Abe et al's scheme is much more widely read and cited (their paper=20 has been cited more than 250 times, whereas Ren and Harn's paper has=20 been cited less than 20 times). I'd prefer to stick to well-known schemes= =2E 3. I had trouble parsing Ren and Harn's security proofs (but this could=20 just be me being stupid). But this is all beside the point since no one has actually objected so=20 far. Looking back at my proposal, it does seem rather silly to have a=20 registry that is currently redundant. I agree with you that it is mostly useless. Unless someone has a better=20 idea, I will remove the registry and modify the new signature subpacket=20 to hold only the fingerprints of possible signers. This will nicely=20 simplify things. > (i.e. exclude the algo for a ring signature). > > I would also suggest to settle for ECC algorithms and not bother with > RSA or DSA anymore. A major consideration in the proposed scheme is to make sure that it is=20 separable; i.e., that different types of existing keys can be used=20 together without a dedicated setup. In the current scheme, signers are=20 able to produce a ring signature without any cooperation or setup from=20 the other possible signers (as long as they each have an RSA, DSA, or=20 ECDSA signing key). I think this is an essential feature; otherwise, it=20 would be a pain to make sure that all possible signers have the correct=20 type of key. Thus, I think it is important to have a new algorithm ID for ring=20 signatures so that signers are free to mix together different types of=20 keys in the ring signature. I would also prefer to leave RSA and DSA=20 keys in the scheme for the same reason. What ECC signing algorithms does the current development version of=20 GnuPG support? > Until a v5 public key packet format has been defined, I would strongly > suggest to use the full SHA-1 fingerprint instead of a key id. Creatin= g > long key id collisions is quite possible and thus would require extra > code for trial verification. Okay. dkg and David suggested similarly. I will modify my proposal to=20 use full SHA-1 fingerprints. Thanks! Vincent [RH08] J. Ren and L. Harn (2008). Generalized ring signatures. doi:10.1109/TDSC.2008.22 https://v-yu.com/lib/2008_Ren,%20Harn.pdf --mlprSUdDIegAwX5wMkBC1OXoSnr0lJB3f Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREKAAYFAlMjCjcACgkQHE22W/Uzb8RnoAEAi4IChaVUE/Rj/aYJasW4FC0Z DOdY1iIs+DRq+ujmbZMBAJH6c4A+m6nC7//pL99nkf1JeRa8PDbz35FA6+1PTlTM =0qwb -----END PGP SIGNATURE----- --mlprSUdDIegAwX5wMkBC1OXoSnr0lJB3f-- From nobody Fri Mar 14 07:25:01 2014 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 57A141A014F for ; Fri, 14 Mar 2014 07:25:00 -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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 So_WCNRuiVPW for ; Fri, 14 Mar 2014 07:24:57 -0700 (PDT) Received: from nimbus.fccf.net (nimbus.fccf.net [77.77.144.35]) by ietfa.amsl.com (Postfix) with ESMTP id B27F51A014E for ; Fri, 14 Mar 2014 07:24:57 -0700 (PDT) Received: from straylight.m.ringlet.net (unknown [78.90.13.150]) by nimbus.fccf.net (Postfix) with ESMTPSA id 6E84D388 for ; Fri, 14 Mar 2014 16:24:49 +0200 (EET) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id dae09e by straylight.m.ringlet.net (DragonFly Mail Agent v0.9); Fri, 14 Mar 2014 16:24:48 +0200 Date: Fri, 14 Mar 2014 16:24:47 +0200 From: Peter Pentchev To: Vincent Yu Message-ID: <20140314142447.GA6744@straylight.m.ringlet.net> References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <23C2DE82-93B7-48A6-95A6-14B4F5DD1F42@callas.org> <3e9143bf60d2252a67149eb4b984bcdb@smtp.hushmail.com> <532268E5.8090001@fifthhorseman.net> <1e053aff143a868d303cb483949bcd31@smtp.hushmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline In-Reply-To: <1e053aff143a868d303cb483949bcd31@smtp.hushmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/6IyYs5KAEYfnLA6osdf4NxWp8YU Cc: openpgp@ietf.org, Daniel Kahn Gillmor Subject: Re: [openpgp] Non-SHA-1 fingerprints in signatures [was: Proposal for a separable ring signature scheme...] 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, 14 Mar 2014 14:25:00 -0000 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 13, 2014 at 10:39:31PM -0400, Vincent Yu wrote: > On 03/13/2014 10:26 PM, Daniel Kahn Gillmor wrote: > >the OpenPGP fingerprint revision discussions have not yet terminated in > >a clear conclusion -- the last stage we reached was was "wait until > >SHA-3 has settled down and then reconsider". > > > >You should *not* use keyIDs as distinct identifiers in the subpacket > >body of the ring signature design; the use of keyIDs in the traditional > >issuer subpacket is a mistake that i hope we don't propagate if/when > >OpenPGPv5 ever gets standardized. > > > >Your I-D should have the subpacket body built from either OpenPGPv4 > >fingerprints, or full public key packets. the search space for key IDs > >is too small to distinguish "bad signature" from "i don't have the > >appropriate key" with sufficient confidence, which causes all sorts of > >nasty UI edge cases. >=20 > Thanks for the info. I will likely follow your suggestion and modify > my proposal to use V4 fingerprints rather than key IDs. Hm, how exactly would this deal with the existence of multiple signing subkeys, all associated with the same master public key? Your current proposal explicitly allows for that, using the key IDs; I guess there might be a need to include *both* the fingerprint of the master key *and* some kind of identification of the subkey actually used for signing. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org p.penchev@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 I am jealous of the first word in this sentence. --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJTIxEjAAoJEGUe77AlJ98T1YYP/2LQ9wkhy6Uvir1gQf96iAMT IqTljVtWKonqn7hu3BBJoSUScVIKkbol0Zt/4TKZahIf1A2SOjbkwsdCWE+Klnz4 Hw6+4cPzYuP8D1F5BitGc0jjn27Ij9+3aA3KCaJrjmg7PpxqQKMwur4O5oOei6QC XIiFFD9qEIXSYO4+eQD7SUMOjuJLatyRv8AxYwclAkYLGdbT/lNZCZmcJA+N/wPy 3B3+LNhN9ln+ILvZDDbOFHqSxp+Njjg3gDqBx63LhWiV8e4zqpk95AAAT03CIYT7 msXmGBY1RtBW3Nwq6kALhQhbJe97irigvOf40AEHLsJKsL9G6y7qfwcKwGTU/Hh7 Yw6WiQEtd9qt/ZnvqKO94qFkAOcacawjl9S89jR1jRVWT0AJjpTgdivHncg85/nm SsddthXdGL1uq0QOCmZUqPC66tEaA3ANDdTlOl6pq5lKodRGtcCo1N4KU+1GbRyq Ki3XRLP/MWv/KccL3g13TrbEm0N5DgXZtBc2vYcTYaJlFU7ZNXZSZ8C+2zOMhAsA IlBczK1XoakzTbtOUupgrrB0FVfnGAMuHwty5VY/7UVh4Nr1hbz1R5fw9Q7G/PXF rJrSrGGz0DCzCRWx5VENTjxPCgp0Zpte4DEdqxDEs2sGJMr4ybZJde5h7T29P4YQ slnwUJDqZUhSvHJp8nAp =8dit -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ-- From nobody Fri Mar 14 07:36:39 2014 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 CAE8E1A014F for ; Fri, 14 Mar 2014 07:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYVJCnQoe59Q for ; Fri, 14 Mar 2014 07:36:35 -0700 (PDT) Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.200]) by ietfa.amsl.com (Postfix) with ESMTP id D17D91A0154 for ; Fri, 14 Mar 2014 07:36:35 -0700 (PDT) Received: from smtp3.hushmail.com (localhost [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 317A1E0739 for ; Fri, 14 Mar 2014 14:36:29 +0000 (UTC) Received: from smtp.hushmail.com (w6.hushmail.com [65.39.178.92]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp3.hushmail.com (Postfix) with ESMTPS; Fri, 14 Mar 2014 14:36:27 +0000 (UTC) Message-ID: <891a98dba0a4fc958cc40dcef9c83825@smtp.hushmail.com> Date: Fri, 14 Mar 2014 10:36:23 -0400 From: Vincent Yu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Peter Pentchev References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <23C2DE82-93B7-48A6-95A6-14B4F5DD1F42@callas.org> <3e9143bf60d2252a67149eb4b984bcdb@smtp.hushmail.com> <532268E5.8090001@fifthhorseman.net> <1e053aff143a868d303cb483949bcd31@smtp.hushmail.com> <20140314142447.GA6744@straylight.m.ringlet.net> In-Reply-To: <20140314142447.GA6744@straylight.m.ringlet.net> X-Enigmail-Version: 1.6 OpenPGP: id=d28d7c4078b3742a; url=https://v-yu.com/pubkeys/openpgp.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iBsSK7noad0TtiLeX39MKKnF5BNOicfxS" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/Xd9-urxZsfTP-q04NP01_lf3xu4 Cc: openpgp@ietf.org, Daniel Kahn Gillmor Subject: Re: [openpgp] Non-SHA-1 fingerprints in signatures [was: Proposal for a separable ring signature scheme...] 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, 14 Mar 2014 14:36:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iBsSK7noad0TtiLeX39MKKnF5BNOicfxS Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 03/14/2014 10:24 AM, Peter Pentchev wrote: > On Thu, Mar 13, 2014 at 10:39:31PM -0400, Vincent Yu wrote: >> Thanks for the info. I will likely follow your suggestion and modify >> my proposal to use V4 fingerprints rather than key IDs. > > Hm, how exactly would this deal with the existence of multiple signing > subkeys, all associated with the same master public key? Your current > proposal explicitly allows for that, using the key IDs; I guess there > might be a need to include *both* the fingerprint of the master key > *and* some kind of identification of the subkey actually used for > signing. Isn't there a V4 fingerprint defined for every key, including for each=20 subkey? I think it would be okay just to include the fingerprints of all = possible signing keys, regardless of whether they are primary keys or=20 subkeys. If I've misunderstood something, please let me know. Thanks, Vincent --iBsSK7noad0TtiLeX39MKKnF5BNOicfxS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREKAAYFAlMjE+kACgkQHE22W/Uzb8REjQD7BrdXCImOP4N5w50/X3EARjpY IV2QqLcJch2Y6f8X1fQA/0q32rFOmsnZpLwdSiRH1MWhlJjAaQmZaERQHA7MgR+Z =mWUh -----END PGP SIGNATURE----- --iBsSK7noad0TtiLeX39MKKnF5BNOicfxS-- From nobody Fri Mar 14 07:38:14 2014 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 4E4BA1A015B for ; Fri, 14 Mar 2014 07:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGdRT89t3LUQ for ; Fri, 14 Mar 2014 07:38:04 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id A025B1A014F for ; Fri, 14 Mar 2014 07:38:04 -0700 (PDT) Received: from [10.70.10.55] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 73EF2F984; Fri, 14 Mar 2014 10:37:56 -0400 (EDT) Message-ID: <5323143A.7060707@fifthhorseman.net> Date: Fri, 14 Mar 2014 10:37:46 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: Peter Pentchev , Vincent Yu References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <23C2DE82-93B7-48A6-95A6-14B4F5DD1F42@callas.org> <3e9143bf60d2252a67149eb4b984bcdb@smtp.hushmail.com> <532268E5.8090001@fifthhorseman.net> <1e053aff143a868d303cb483949bcd31@smtp.hushmail.com> <20140314142447.GA6744@straylight.m.ringlet.net> In-Reply-To: <20140314142447.GA6744@straylight.m.ringlet.net> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HLb9npcHc70r4Qb9aj6FW1ETrxX5MchOO" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/nWFl7s2JkchFMlNdEsfvZy2fa4E Cc: openpgp@ietf.org Subject: Re: [openpgp] Non-SHA-1 fingerprints in signatures [was: Proposal for a separable ring signature scheme...] 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, 14 Mar 2014 14:38:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HLb9npcHc70r4Qb9aj6FW1ETrxX5MchOO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/14/2014 10:24 AM, Peter Pentchev wrote: > Hm, how exactly would this deal with the existence of multiple signing > subkeys, all associated with the same master public key? Your current > proposal explicitly allows for that, using the key IDs; I guess there > might be a need to include *both* the fingerprint of the master key > *and* some kind of identification of the subkey actually used for > signing. Vincent's original spec says: >> It is common for an OpenPGP key bundle to contain multiple keys that=20 >> are capable of producing signatures. For instance, this is the case=20 >> when the primary certification key and a subkey both have their signin= g=20 >> flags set (see Section 5.2.3.21 of RFC 4880). When a user wishes to=20 >> create a ring signature that includes a key ID in a bundle that=20 >> contains other keys capable of signing, it would make sense to include= =20 >> all signing-capable keys in the ring signature.=20 But I'm not convinced by this last conclusion. Why include all the signing-capable keys? I have a primary signing-capable key and a subkey that is also signing-capable. When i sign this message, i will only sign it with one of them. What is the rationale for including all the keys? It seems like it just makes the signature creation take longer, and i don't see the benefit. presumably the signing keys are likely to be all controlled by the same person, right? --dkg --HLb9npcHc70r4Qb9aj6FW1ETrxX5MchOO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTIxQ6XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc6UcQANfz8dshnI0kx1bwBdv9wu78 D+w3AUbz3HnWe9pRIxHKguQZ6aew4kgh93ijMMPoCsTD/iIfS0TQSjnWEnHc1b1Z ckoGLb3z7TiYbYGeHEKNZlOaHxgsJSYB879IVH0ouo2bupQaKAZV3fZXy4nPy24e gRxYBrC/quRE2FR+7PGEdmQkd0qKVhFIoZh6Q6SDTGss9AwDka/9rmoORfwVWp52 KkOcjQL5AqriIWDDyv5TiCi+z5UUpt/6pj50VbhcyJ7rkm1hiw5OC+A4MaZ4SJQ3 1kX5uNHmhNTtc58Y7D6ArZbyeruUaJ7qUrQedeCYbJ38ORUkl9tsB50zzwsVGsiP 3eZTanwSXcran6sbRrbKYrFOGMyiIKfsTAQWgIzVkeU3fo94ohN9vCTRrsLdyjCP MdzasnpNv/uuaNprsD3BC9DuNol2+guFN8OCWwkkMn4zSHy8MgJ5lCms/e+DZ6ky nPUDWOhECo75/i7RSU3GPvc0RfT0p9WAviPZmU2hcEM5aWjvllgqA0/bUUcuJwtI DNKVpBgpm5G1Ta3pI9oAD2oMgoKLx2MTqucCJqVC+aFj93R6CtppZ+3Ya/KAPg8F Gtcos5Cy1SO/hJfjcMZ0iNL85OMydO+ihyZMFBez7dqCmJLVdeVqwp7oiBHUalYi ZAYstReAtD/0nLfqbFdt =BVMw -----END PGP SIGNATURE----- --HLb9npcHc70r4Qb9aj6FW1ETrxX5MchOO-- From nobody Fri Mar 14 07:38:53 2014 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 2B95B1A015D for ; Fri, 14 Mar 2014 07:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EOwmDF_JuDl for ; Fri, 14 Mar 2014 07:38:45 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 52B2A1A015E for ; Fri, 14 Mar 2014 07:38:45 -0700 (PDT) Received: from [10.70.10.55] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 3B8DAF986; Fri, 14 Mar 2014 10:38:37 -0400 (EDT) Message-ID: <5323146D.4050006@fifthhorseman.net> Date: Fri, 14 Mar 2014 10:38:37 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: Vincent Yu , Werner Koch References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mCew2SI7UdEQqMwjtXnGaRTSI36xvRDhe" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/g5I9s2jLKRz8YuNR5od776Q57lI Cc: openpgp@ietf.org Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 14 Mar 2014 14:38:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mCew2SI7UdEQqMwjtXnGaRTSI36xvRDhe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/14/2014 09:55 AM, Vincent Yu wrote: > I agree with you that it is mostly useless. Unless someone has a better= > idea, I will remove the registry and modify the new signature subpacket= > to hold only the fingerprints of possible signers. This will nicely > simplify things. For extra safety, you could still include the public key's algorithm ID in the subpacket as a separate one-byte marker, just using the value from https://tools.ietf.org/html/rfc4880#section-9.1 instead of pulling the values from a new/duplicate registry. > A major consideration in the proposed scheme is to make sure that it is= > separable; i.e., that different types of existing keys can be used > together without a dedicated setup. In the current scheme, signers are > able to produce a ring signature without any cooperation or setup from > the other possible signers (as long as they each have an RSA, DSA, or > ECDSA signing key). I think this is an essential feature; otherwise, it= > would be a pain to make sure that all possible signers have the correct= > type of key. >=20 > Thus, I think it is important to have a new algorithm ID for ring > signatures so that signers are free to mix together different types of > keys in the ring signature. I would also prefer to leave RSA and DSA > keys in the scheme for the same reason. i still haven't gotten my head around the particular details of the proposed scheme, but i agree it would be nice for users to be able to have this feature without requiring their peers to opt into the scheme by making a new EC key or designating a new usage flag for this purpose. Sticking with widespread existing keys and the common "data signing" usage flag seems like the way to go. I note that you've specified the ring signature approach as a generic public key algorithm for arbitrary signature packets, and left "decisions regarding creation and interpretation" up to the implementation. I think a bit more guidance would be helpful in at least two cases: signature types: at the moment, i only see this as a useful mechanism for data signatures (sigtype 0x00 and 0x01) ; i don't see a reasonable use case here for identity certifications (sigtypes 0x10 through 0x13), or other signature types currently available: https://tools.ietf.org/html/rfc4880#section-5.2.1 -- i'm not suggesting that we need to say these MUST NOT be made as ring signatures, but it might be worth considering the applicability to the other signature types= =2E Guidance would also be useful for implementations processing (or generating) ring signatures that were made by one of a set of keys where some of those keys appear to be expired or revoked. (i haven't thought this use case through in sufficient detail, but i could see implementations getting tripped up here or behaving in wildly divergent ways if there is no clear guidance) --dkg --mCew2SI7UdEQqMwjtXnGaRTSI36xvRDhe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTIxRtXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcU9YP/2265rADoECHd0vUgkyxX3W9 MfO4u720p3BVJXIKYHQoyPETzMTkh9lPmk+jo66iSZ+bSlLAEbL4hwNnvIQRSe/L Hr8QF28DnqNtsmJhZz7thblJDlqSZf5zmBSxw8nieJgKaYiLka4xws1v98CHDoYT SAODSj1W+EvPTe4wpvz/Cl44dBFFfTD0ufZ6PXlnk378ACeltJnJP1aiKLp3FaIa OUr/W8GJLXxFdl/w3P0T2bhf0SvICUPk8pJogrtVPK7ZVCBL7cOXqg2ko8K1JdqT dYIjQeX/YIHnzE4fTpw8okQHKYFk9tkicZzwJaoCLVYy6mRR3kFb2nqF4mSzlkmO NZcLpMh8VGWhIpthK9fm3SnovITb4YTp8jsrOX1jkA0qrobJAUNFzeiG0tgJEwL+ 0L3ZHxE/4QbXMw7qhJXXkknvwojXOMAo52nqapESXvSWYdZ48cfrQOzwpHAWjwZv 8Fqp1JzOCsGYCMCOa2l2Kb3CgWAbzNgWbbCloaUO3c16uqgKATNAaej7Z7tYXASZ ObzrFM4HGPQhbV4kVV4ebbfIJ65meAf2/zz/67H0eaiGG6J8b7ysDxPaA21ZeDwS oe6aGnA4geAmxyYpiKauaN9URY/y1mIi+KyRv8QZhw3lbuVw49SXhc7iMi5QR0/y gTaTHlI7hhAUbUhvzznD =6yjN -----END PGP SIGNATURE----- --mCew2SI7UdEQqMwjtXnGaRTSI36xvRDhe-- From nobody Fri Mar 14 07:44:32 2014 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 279351A015B for ; Fri, 14 Mar 2014 07:44:29 -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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 usYcBDV67Rw1 for ; Fri, 14 Mar 2014 07:44:26 -0700 (PDT) Received: from nimbus.fccf.net (nimbus.fccf.net [77.77.144.35]) by ietfa.amsl.com (Postfix) with ESMTP id 646221A0154 for ; Fri, 14 Mar 2014 07:44:26 -0700 (PDT) Received: from straylight.m.ringlet.net (unknown [78.90.13.150]) by nimbus.fccf.net (Postfix) with ESMTPSA id 0FAEC389 for ; Fri, 14 Mar 2014 16:44:19 +0200 (EET) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id dae09e by straylight.m.ringlet.net (DragonFly Mail Agent v0.9); Fri, 14 Mar 2014 16:44:16 +0200 Date: Fri, 14 Mar 2014 16:44:15 +0200 From: Peter Pentchev To: Vincent Yu Message-ID: <20140314144414.GB6744@straylight.m.ringlet.net> References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <23C2DE82-93B7-48A6-95A6-14B4F5DD1F42@callas.org> <3e9143bf60d2252a67149eb4b984bcdb@smtp.hushmail.com> <532268E5.8090001@fifthhorseman.net> <1e053aff143a868d303cb483949bcd31@smtp.hushmail.com> <20140314142447.GA6744@straylight.m.ringlet.net> <891a98dba0a4fc958cc40dcef9c83825@smtp.hushmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cvVnyQ+4j833TQvp" Content-Disposition: inline In-Reply-To: <891a98dba0a4fc958cc40dcef9c83825@smtp.hushmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/tcmmDHpaVwttrAdUXGksPJhNq-Y Cc: openpgp@ietf.org, Daniel Kahn Gillmor Subject: Re: [openpgp] Non-SHA-1 fingerprints in signatures [was: Proposal for a separable ring signature scheme...] 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, 14 Mar 2014 14:44:29 -0000 --cvVnyQ+4j833TQvp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 14, 2014 at 10:36:23AM -0400, Vincent Yu wrote: > On 03/14/2014 10:24 AM, Peter Pentchev wrote: > >On Thu, Mar 13, 2014 at 10:39:31PM -0400, Vincent Yu wrote: > >>Thanks for the info. I will likely follow your suggestion and modify > >>my proposal to use V4 fingerprints rather than key IDs. > > > >Hm, how exactly would this deal with the existence of multiple signing > >subkeys, all associated with the same master public key? Your current > >proposal explicitly allows for that, using the key IDs; I guess there > >might be a need to include *both* the fingerprint of the master key > >*and* some kind of identification of the subkey actually used for > >signing. >=20 > Isn't there a V4 fingerprint defined for every key, including for > each subkey? I think it would be okay just to include the > fingerprints of all possible signing keys, regardless of whether > they are primary keys or subkeys. >=20 > If I've misunderstood something, please let me know. Argh, sorry, stupid of me; of course you're right. I was a bit misled by the fact that GnuPG, by default, only outputs the fingerprint of the primary key when --fingerprint is specified on the command line; I kind of missed the part where --fingerprint may be given more than once and it will output the fingerprints of all the subkeys. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org p.penchev@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 If the meanings of 'true' and 'false' were switched, then this sentence wou= ldn't be false. --cvVnyQ+4j833TQvp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJTIxWxAAoJEGUe77AlJ98TOYkQAIcSfoZ3Ko5UiDn/uUIoHLkr aDY5k44xnNHG4R6FQZ1366/VjNSfBg46h+mPr+XoD0zvzPuCcrluxOMKl8ZSRHO0 uQGWUXp+JOMF3ph4z3GZv3fFxRsbRV4CbfTuHLiNGpi1ve3ISEMBlOh/+ZwAi3Rj exHDGpPaddcxwyb9hwNrng1fLeVH6tfPFnizZ9pJTYt9g1Y7pQssFspt9AdNM2MK SiIlZUCo2hrpIrg5i0cjjeV5XreQOaRpOORcYuUweulJCiWh9nyqPnX73jDMaPeG j6Ug8miQF5j2i554C5P8lleGGz+XHPKtITt3eZFK+p5bTfb6LVKJ7ZaOuWIai/VV ++U2/5MBvB1APukq3DQG24q+ArsAK3nVSFM8nICAzKaEAFbRGN6J8pgu8sFAhkH3 opDNy+e6a+kaZglJZzhICWOzAohnGGfs22J0RSYWHcy/gxEcDeEXIthqx11IxG6n 2mFp6vVHhbTGrzlvPwY491tODxqM4044Ooqaba5AKvCydHwUQ80OsA8u3QNjClTN pY51FWy64GUvr2M5e3aBjZFj8eRAX1zvX+qz7SulNY6iG/CkAHvciqS9d2qnFmF0 48kcv32G830NsJZ86FQ+LC0oG3kzAp6TFT1/2iwLuQABQOrZXmOVVnhU1hqLH3OQ pab63OQaLjsjeFgKEeas =n/59 -----END PGP SIGNATURE----- --cvVnyQ+4j833TQvp-- From nobody Fri Mar 14 09:40:41 2014 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 352161A016F for ; Fri, 14 Mar 2014 09:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Frrgi2abr7Al for ; Fri, 14 Mar 2014 09:40:37 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id B93BC1A0190 for ; Fri, 14 Mar 2014 09:40:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 79E1E4F334F2; Fri, 14 Mar 2014 09:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xlnt8c6Y05qN; Fri, 14 Mar 2014 09:40:28 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 103594F334E6; Fri, 14 Mar 2014 09:40:27 -0700 (PDT) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Fri, 14 Mar 2014 09:40:28 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 14 Mar 2014 09:40:28 -0700 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Jon Callas In-Reply-To: <20140314142447.GA6744@straylight.m.ringlet.net> Date: Fri, 14 Mar 2014 09:40:28 -0700 Message-Id: <734B3AC5-150D-4E34-8FE2-F3FFAB468D3A@callas.org> References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <23C2DE82-93B7-48A6-95A6-14B4F5DD1F42@callas.org> <3e9143bf60d2252a67149eb4b984bcdb@smtp.hushmail.com> <532268E5.8090001@fifthhorseman.net> <1e053aff143a868d303cb483949bcd31@smtp.hushmail.com> <20140314142447.GA6744@straylight.m.ringlet.net> To: Peter Pentchev X-Mailer: Apple Mail (2.1874) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/MsE0807yqaLvTtWIEsTzcAMIzGs Cc: "openpgp@ietf.org OpenPGP" Subject: Re: [openpgp] Non-SHA-1 fingerprints in signatures [was: Proposal for a separable ring signature scheme...] 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, 14 Mar 2014 16:40:39 -0000 On Mar 14, 2014, at 7:24 AM, Peter Pentchev wrote: >=20 > Hm, how exactly would this deal with the existence of multiple signing > subkeys, all associated with the same master public key? Your current > proposal explicitly allows for that, using the key IDs; I guess there > might be a need to include *both* the fingerprint of the master key > *and* some kind of identification of the subkey actually used for > signing. Well, today, the KeyID is exactly that -- the identifier for a key. You = have to backtrack from the signing key to its owner in your key = database. There's nothing to stop me from using the same signing key in = multiple masters. Despite any distress that may give, it can't be = stopped, so we might as well embrace it. Jon From nobody Fri Mar 14 09:56:58 2014 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 C06A01A0186 for ; Fri, 14 Mar 2014 09:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 UnUL8XZ1XFfm for ; Fri, 14 Mar 2014 09:56:51 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id 38F501A015B for ; Fri, 14 Mar 2014 09:56:51 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1WOVPY-0003FQ-2g for ; Fri, 14 Mar 2014 17:56:44 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1WOVFg-0008II-MH; Fri, 14 Mar 2014 17:46:32 +0100 From: Werner Koch To: Vincent Yu References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Fri, 14 Mar 2014 17:46:32 +0100 In-Reply-To: (Vincent Yu's message of "Fri, 14 Mar 2014 09:55:02 -0400") Message-ID: <87y50cybh3.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: http://mailarchive.ietf.org/arch/msg/openpgp/bY-lGcwPCJrw7Lw_srrEibW_-gg Cc: openpgp@ietf.org Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 14 Mar 2014 16:56:54 -0000 On Fri, 14 Mar 2014 14:55, v@v-yu.com said: > A major consideration in the proposed scheme is to make sure that it > is separable; i.e., that different types of existing keys can be used > together without a dedicated setup. In the current scheme, signers are Old implementations won't be able to handle ring signatures at all. To use existing keys, users can simply use dedicated subkeys. > able to produce a ring signature without any cooperation or setup from > the other possible signers (as long as they each have an RSA, DSA, or You better need some setup from the other possible signers: They should be able to create ring signatures. If you look at a ring signature and you can figure out that only key has been created with a software version capable of handling ring signatures it would be easy to single out who actually did the signature. Unfortunately we can't completely hide all hints on the software version used. For example analyzing signed mails from mailing list archives should allow to guess which software version is used. > Thus, I think it is important to have a new algorithm ID for ring > signatures so that signers are free to mix together different types of Agreed, > What ECC signing algorithms does the current development version of > GnuPG support? ECDSA. EdDSA (Bernstein et al's Schnorr variant) will likely be added soon. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Fri Mar 14 10:26:57 2014 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 CCB381A0191 for ; Fri, 14 Mar 2014 10:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmKrqHtE97SN for ; Fri, 14 Mar 2014 10:26:53 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3E61A0198 for ; Fri, 14 Mar 2014 10:26:52 -0700 (PDT) Received: from [10.70.10.55] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id B425CF984; Fri, 14 Mar 2014 13:26:43 -0400 (EDT) Message-ID: <53233BD4.4020804@fifthhorseman.net> Date: Fri, 14 Mar 2014 13:26:44 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: Werner Koch , Vincent Yu References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <87y50cybh3.fsf@vigenere.g10code.de> In-Reply-To: <87y50cybh3.fsf@vigenere.g10code.de> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2cPNDb1PgMHlA81MHkx9hnhIwhKXO8V03" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/BohTCiQ-2gyk1VxAkS0JAR5bgfc Cc: openpgp@ietf.org Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 14 Mar 2014 17:26:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2cPNDb1PgMHlA81MHkx9hnhIwhKXO8V03 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/14/2014 12:46 PM, Werner Koch wrote: > You better need some setup from the other possible signers: They should= > be able to create ring signatures. If you look at a ring signature and= > you can figure out that only key has been created with a software > version capable of handling ring signatures it would be easy to single > out who actually did the signature. Unfortunately we can't completely > hide all hints on the software version used. For example analyzing > signed mails from mailing list archives should allow to guess which > software version is used. I'm not sure i agree with this line of reasoning. older keys can be imported into newer software (i've done that multiple times). if the goal here is simply cryptographic non-repudiability, Alice's peer is presumably trying to prove to a third-party judge that the peer didn't make the signature, therefore Alice did. But the peer cannot prove that their key material has never been used with a different implementation -- they can only assert that claim; but they could just as well assert that they didn't make the signature in the first place. Why should the judge believe one claim over the other? Put another way, i can produce a ring signature over a set of very reasonable text that claims to be *from* a peer's public key and/or a throwaway key, and introduce that as a piece of correspondence -- i could even do this with the body of a message that the peer actually did send to me, thereby "demonstrating" that the peer is capable of making ring signatures. it doesn't make sense to rely on non-cryptographic signals (e.g. typical OpenPGP implemnetation version information, etc) to rule out possible cryptographic signers. --dkg --2cPNDb1PgMHlA81MHkx9hnhIwhKXO8V03 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTIzvUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc4CQP/2e6Yh0z1i+miwFs3nP6k0rM 8SP6NVSWeC+UhvBV75MW7rdEOY6NXdT2UEmb+/7aYhSDqxI9i/m23the5SH5B92m NQ0VBl9C0qw3Lc/R3VJfC8uslJht3Q0rCJdq3uXIqXPOspEer1xjphv8HcTNhJcB Bfdob3hhv+zcHAFkfn2NUPOrwVPF3eptIKrPDrDSI7y2rWFXH/pLznYgtH8yRh91 ynNSemJV/tzo+6hRHqbdWWW15q5t0yLg6q7GYVx4KFfNZKcxH4hSxYnirjBTdQwk KH+R+GjUVPhaL06ufHhDM6UCMfNrWmhs15L+ig4NAO9sJVxUgFQNgNGjajX/50XR Ey+mI5xdnTEdf9oq/W847vmtgs//bMQScZ+EK6OAbIAo+fma4xa4WkBNFJVEAPw5 XseSjqXj6jrly4Ok7gduaQjr3h9xn1Nae+e62Cbu4tsGlsNV1pfNpLWOhA4UgoCk fqlR1INbYt+e2m88vsKHM3EWDaBE1JJi0C+B6qnOb0hOQZWrp70E2Tsp+f2tV/KY zy0J5SjoCbvIxYAyIMxEJnPnom4dOcLgM73NaaKLOG7oQ6NYiZ7o0mPCi1S8JRr2 Ns/QzB7wTC/ttVomfYSjU78Y9AG5SbsO6Pse2YF9xrR5hbEntqSrcMdFl36Vo9aP QvylsypqakiXLcHsQKQa =ywfr -----END PGP SIGNATURE----- --2cPNDb1PgMHlA81MHkx9hnhIwhKXO8V03-- From nobody Fri Mar 14 10:47:06 2014 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 C96CC1A0170 for ; Fri, 14 Mar 2014 10:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 FoMJA2Xp3vOK for ; Fri, 14 Mar 2014 10:47:01 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id CE1EC1A01C9 for ; Fri, 14 Mar 2014 10:46:51 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1WOWBw-0003dc-LY for ; Fri, 14 Mar 2014 18:46:44 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1WOW39-00021f-Vg; Fri, 14 Mar 2014 18:37:40 +0100 From: Werner Koch To: Daniel Kahn Gillmor References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <87y50cybh3.fsf@vigenere.g10code.de> <53233BD4.4020804@fifthhorseman.net> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Fri, 14 Mar 2014 18:37:39 +0100 In-Reply-To: <53233BD4.4020804@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 14 Mar 2014 13:26:44 -0400") Message-ID: <87lhwcy93w.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: http://mailarchive.ietf.org/arch/msg/openpgp/It2tAl7Hg73-wdzeFNuoOkgeHlk Cc: openpgp@ietf.org, Vincent Yu Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 14 Mar 2014 17:47:02 -0000 On Fri, 14 Mar 2014 18:26, dkg@fifthhorseman.net said: > I'm not sure i agree with this line of reasoning. older keys can be > imported into newer software (i've done that multiple times). if the It is all about probability. > goal here is simply cryptographic non-repudiability, Alice's peer is There is no such thing as mechanically created non-reputability. But why make it too easy. > it doesn't make sense to rely on non-cryptographic signals (e.g. typical > OpenPGP implemnetation version information, etc) to rule out possible > cryptographic signers. I case we are speaking about this: The whole point of criminial investigations is to collect lots of evidence from _different sources_ to prove or disprove a claim. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Fri Mar 14 11:00:38 2014 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 98E7E1A019F for ; Fri, 14 Mar 2014 11:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id az6iViPlEwVD for ; Fri, 14 Mar 2014 11:00:34 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 512051A019C for ; Fri, 14 Mar 2014 11:00:27 -0700 (PDT) Received: from [10.70.10.55] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id D5004F984; Fri, 14 Mar 2014 14:00:18 -0400 (EDT) Message-ID: <532343B3.7090807@fifthhorseman.net> Date: Fri, 14 Mar 2014 14:00:19 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: Werner Koch References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <87y50cybh3.fsf@vigenere.g10code.de> <53233BD4.4020804@fifthhorseman.net> <87lhwcy93w.fsf@vigenere.g10code.de> In-Reply-To: <87lhwcy93w.fsf@vigenere.g10code.de> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mbw26Vh4WXIUqr3PejLeFUrlsHP5voG8l" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/bcLPA0sxXYH0PaEMDdfz7aQlva0 Cc: openpgp@ietf.org, Vincent Yu Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 14 Mar 2014 18:00:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mbw26Vh4WXIUqr3PejLeFUrlsHP5voG8l Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/14/2014 01:37 PM, Werner Koch wrote: > It is all about probability. >=20 >> goal here is simply cryptographic non-repudiability, Alice's peer is >=20 > There is no such thing as mechanically created non-reputability. But > why make it too easy. >=20 >> it doesn't make sense to rely on non-cryptographic signals (e.g. typic= al >> OpenPGP implemnetation version information, etc) to rule out possible >> cryptographic signers. >=20 > I case we are speaking about this: The whole point of criminial > investigations is to collect lots of evidence from _different sources_ > to prove or disprove a claim. sure, i'm not claiming that cryptographic deniability is a particularly useful feature in the courts. Even with the extra limits you're proposing, i'm not convinced it has much utility, though. I've written about this here (slightly different context, but much of the reasoning applies): https://www.debian-administration.org/users/dkg/weblog/104 Do you think that saying "ring signatures are limited to these new-fangled keys" would make the arguments for deniability stronger? if so, why does making the specification *possible* to use with older keys make them any weaker? That is, if the spec makes it possible to work with multiple key types, two users exchanging ring signatures with ECC keys will be no worse off than if the spec constrains its users to only allow ECC keys. But a user corresponding with someone who still uses an RSA key has *no way* to make a ring signature under the constrained proposal, thereby removing what little argument they could have made otherwise. Why not leave the proposal open to those users? So perhaps some guidance is suggested, along the lines of "Due to the novelty of this scheme within OpenPGP as of this writing, making a ring signature over multiple ECC keys offers more plausible deniability than a ring signature covering an ECC key and any other form of public key" Is there another argument for constraining ring signatures to ECC keys, though? for example, arguments by implementation simplicity, efficiency, or mathematical clarity might be a good reason to constrain the spec to new key types. --dkg --mbw26Vh4WXIUqr3PejLeFUrlsHP5voG8l Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTI0OzXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcxuwQAMiAzsugmno2MXswG4Dx1zZ3 NrkNFAO2228JWuYqxC+RM9/Le5S7Fa57+WqHpSkS8qyBvAASJMQzPTRHEdLqAZ3A 6jVpZnIQ616VWVPj7Xl6wGDb1xK3F9OgVOnBMvM4+2xGc0WZdd88QZrwasn26H41 pn9rihBcz2Jbdq3E43WaY4SYz5u9h0ffqgMQC/Jjaknxxy4tdy2FitY15sS+BBFb 7uL7Oo7+6bZ8WNyO37/sDLfGlWRUZdhRYWkNNfm8ZEgOQdP1zdmRGk9XaCne4325 CLH1a/VgpNGfQVAnytrCXcHn7Vkn/84h42G/nOz02fXrsIHk1iaYE1Hz3tA2H3Ax b+BJt/VunNPWXaImxKzF4tfWzrqhdNXVw84cQBRtcbyyO16H4DQEeJ3Y1tpAxm9o eWbl7wcuZHo7kiLMjHgQ6Vqv6ZT3M+Rzv9jD4HB+LyG5mb/avJqZtE9xP+495Z4E +7ap6ZQoRxgbtJHM0EJvxxggPW8BvrG8jYYN5TOy3yKNMUTDyFBzMQVYUohbQBfl C18azlVnzEwGtkBi/06/uyMRINk2qFmlRDOLR+HKviYEwJqp/j8VnIxLFOfSUl90 2lIJolKJIR3UQqIUkjjtF1cy0bGlnz31L///Q4Xj1s/82IBDw99l3JoQ3w/k4icu qeTfZbl0SB+sXPAYZSOf =elmn -----END PGP SIGNATURE----- --mbw26Vh4WXIUqr3PejLeFUrlsHP5voG8l-- From nobody Fri Mar 14 11:36:01 2014 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 752361A019E for ; Fri, 14 Mar 2014 11:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWTxpFXHK3CB for ; Fri, 14 Mar 2014 11:35:58 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5.hushmail.com [65.39.178.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3341A0185 for ; Fri, 14 Mar 2014 11:35:58 -0700 (PDT) Received: from smtp5.hushmail.com (localhost [127.0.0.1]) by smtp5.hushmail.com (Postfix) with SMTP id 4239A60187 for ; Fri, 14 Mar 2014 18:35:51 +0000 (UTC) Received: from smtp.hushmail.com (w7.hushmail.com [65.39.178.32]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp5.hushmail.com (Postfix) with ESMTPS for ; Fri, 14 Mar 2014 18:35:51 +0000 (UTC) Message-ID: Date: Fri, 14 Mar 2014 14:35:47 -0400 From: Vincent Yu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: openpgp@ietf.org X-Enigmail-Version: 1.6 OpenPGP: id=d28d7c4078b3742a; url=https://v-yu.com/pubkeys/openpgp.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xq7pPR1KamSIrcgOV4ragnkE37A09Ood2" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/II2rt35PMAJsS__25k9fyLZmW-g Subject: [openpgp] Ring signatures and subkeys 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, 14 Mar 2014 18:36:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xq7pPR1KamSIrcgOV4ragnkE37A09Ood2 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Thank you for your comments, dkg and Werner. Both of you brought up good = points about the use of subkeys with ring signatures, so I am starting a = new thread to discuss them. At its heart, a ring signature knows very little about the nature of the = keys that are fed to it. It knows nothing about the relation between=20 primary keys and subkeys. It also knows nothing about the ring signing=20 capabilities of its possible signers. Given that ring signatures are=20 unable to take such considerations into account, I think it would be a=20 mistake to try to encode or to enforce which subkeys can be used for=20 ring signatures. To be more concrete, when a recipient of ring signature can dictate=20 which subkey must be used for ring signatures, there are certain attacks = on non-transferability that the recipient can execute against senders. Suppose that Alice has been talking to Bob, and has been using ring=20 signatures to provide non-transferable authenticity. Bob expects to=20 receive from Alice some juicy message that he wants to share with Eve,=20 and he wants to prove to Eve that Alice signed the message. He can=20 attack Alice's non-transferability as follows: cooperate with Eve to=20 create a bait by having Eve create a subkey that Bob claims as his new=20 subkey (key binding signatures can be computed both ways without=20 requiring Eve to reveal her bait's private key). Bob deploys this bait=20 by getting its public key into Alice's keyring. This can be done in many = ways; for instance, if Alice synchronizes regularly with key servers,=20 then Bob can inconspicuously put the bait on a key server. If Alice's=20 software creates new ring signatures to Bob using only the bait, then=20 Bob can prove to Eve that Alice signed the new messages (because Eve=20 knows that Bob does not have the bait's private key). Among all this,=20 Alice never realizes that Bob has destroyed the non-transferability of=20 her ring signatures. The attack outlined above is a specific instance of a class of attacks=20 that exploit the fact that users can have public subkeys for which they=20 provably do not possess the private key. My biggest worry about such=20 attacks is that they are incredibly easy to execute in the current=20 framework with key server synchronization being good practice, and the=20 typical victim might never realize that the attack has occurred. On 03/14/2014 10:37 AM, Daniel Kahn Gillmor wrote: > Vincent's original spec says: > >>> It is common for an OpenPGP key bundle to contain multiple keys that >>> are capable of producing signatures. For instance, this is the case >>> when the primary certification key and a subkey both have their signi= ng >>> flags set (see Section 5.2.3.21 of RFC 4880). When a user wishes to >>> create a ring signature that includes a key ID in a bundle that >>> contains other keys capable of signing, it would make sense to includ= e >>> all signing-capable keys in the ring signature. > > But I'm not convinced by this last conclusion. Why include all the > signing-capable keys? I have a primary signing-capable key and a subke= y > that is also signing-capable. When i sign this message, i will only > sign it with one of them. What is the rationale for including all the > keys? It seems like it just makes the signature creation take longer, > and i don't see the benefit. presumably the signing keys are likely to= > be all controlled by the same person, right? You are right that my recommendation there results in signatures that=20 are potentially larger and take more time to generate and verify. I intended that to be a recommendation for a safer default that can be=20 overridden by users who know what they are doing. The main alternative=20 default that I considered is to use either the newest or the oldest=20 signing subkey, which falls too easily to the outlined attack. However, I now realize that even with my recommendation in place, the=20 attack is still easy if Bob's primary certification key does not have=20 the signing flag set: he simply needs to revoke all signing-capable=20 subkeys and execute the attack as before. With this in mind, I=20 tentatively suggest that ring signatures should (again, as an=20 overridable default) include the primary certification key, even if its=20 signing flag is not set. All primary keys are intrinsically=20 signing-capable, so there should be no issue implementing this. I'm=20 unsure about this and would be interested in everyone's comments. On 03/14/2014 12:46 PM, Werner Koch wrote: > On Fri, 14 Mar 2014 14:55, v@v-yu.com said: > >> A major consideration in the proposed scheme is to make sure that it >> is separable; i.e., that different types of existing keys can be used >> together without a dedicated setup. In the current scheme, signers are= > > Old implementations won't be able to handle ring signatures at all. To= > use existing keys, users can simply use dedicated subkeys. > >> able to produce a ring signature without any cooperation or setup from= >> the other possible signers (as long as they each have an RSA, DSA, or > > You better need some setup from the other possible signers: They should= > be able to create ring signatures. If you look at a ring signature and= > you can figure out that only key has been created with a software > version capable of handling ring signatures it would be easy to single > out who actually did the signature. Unfortunately we can't completely > hide all hints on the software version used. For example analyzing > signed mails from mailing list archives should allow to guess which > software version is used. I think there is a large security / usability trade-off here. On the one = hand, the non-transferability "guarantee" of a ring signature is indeed=20 much greater if everyone involved had a dedicated key for which they=20 explicitly claim to have ring signing capabilities. On the other hand,=20 that requires significant setup on both ends and I don't see it becoming = general practice. When a protocol requires cooperation from both sides,=20 it's hard for it to gain any ground at all, especially when the=20 alternative (basic signing) is already well-established. But when it=20 requires only one side to cooperate, users who want it can use it=20 whenever they want. My hope is that one day creating a ring signature requires no more from=20 Alice than updating to the latest version of GnuPG and running: gpg2 --clearsign --ring-signature --recipient Bob Bob will not be able to verify the signature if he does not have an=20 implementation that supports ring signatures, but at the very least=20 Alice can still create a ring signature without requiring Bob to set=20 things up. Vincent --xq7pPR1KamSIrcgOV4ragnkE37A09Ood2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREKAAYFAlMjTAUACgkQHE22W/Uzb8SehQD+ORh4iVPSGQypaiOLc/YatiAR fx72nFdF/N1q7301HTYA/1fPI0KejuLFXknODDzaILeB4BFP2D2uncCNy66/mIyi =0i1a -----END PGP SIGNATURE----- --xq7pPR1KamSIrcgOV4ragnkE37A09Ood2-- From nobody Fri Mar 14 11:56:55 2014 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 12A5B1A019F for ; Fri, 14 Mar 2014 11:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 mQhEd5iP43p8 for ; Fri, 14 Mar 2014 11:56:52 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id EE1641A0196 for ; Fri, 14 Mar 2014 11:56:51 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1WOXHg-00043D-Of for ; Fri, 14 Mar 2014 19:56:44 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1WOX8P-0006MB-2F; Fri, 14 Mar 2014 19:47:09 +0100 From: Werner Koch To: Daniel Kahn Gillmor References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <87y50cybh3.fsf@vigenere.g10code.de> <53233BD4.4020804@fifthhorseman.net> <87lhwcy93w.fsf@vigenere.g10code.de> <532343B3.7090807@fifthhorseman.net> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Fri, 14 Mar 2014 19:47:08 +0100 In-Reply-To: <532343B3.7090807@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 14 Mar 2014 14:00:19 -0400") Message-ID: <877g7wy5w3.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: http://mailarchive.ietf.org/arch/msg/openpgp/f5TcvOh5pV1UdXr2oSri1hLyjzc Cc: openpgp@ietf.org, Vincent Yu Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 14 Mar 2014 18:56:53 -0000 On Fri, 14 Mar 2014 19:00, dkg@fifthhorseman.net said: > Do you think that saying "ring signatures are limited to these > new-fangled keys" would make the arguments for deniability stronger? No. > So perhaps some guidance is suggested, along the lines of "Due to the > novelty of this scheme within OpenPGP as of this writing, making a ring > signature over multiple ECC keys offers more plausible deniability than > a ring signature covering an ECC key and any other form of public key" Well, by only allowing only the use of ECC keys, we would do the same without having to write this down. > Is there another argument for constraining ring signatures to ECC keys, > though? for example, arguments by implementation simplicity, Implementation simplicity is always a valid argument. To take this further I would even suggest to make the use of EdDSA a MUST and and all other algos a MAY. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Fri Mar 14 15:31:06 2014 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 15F131A020A for ; Fri, 14 Mar 2014 15:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoqjCqVX-HJ1 for ; Fri, 14 Mar 2014 15:31:02 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5.hushmail.com [65.39.178.142]) by ietfa.amsl.com (Postfix) with ESMTP id AB86C1A0208 for ; Fri, 14 Mar 2014 15:31:02 -0700 (PDT) Received: from smtp5.hushmail.com (localhost [127.0.0.1]) by smtp5.hushmail.com (Postfix) with SMTP id AA299601DA for ; Fri, 14 Mar 2014 22:30:55 +0000 (UTC) Received: from smtp.hushmail.com (w9.hushmail.com [65.39.178.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp5.hushmail.com (Postfix) with ESMTPS; Fri, 14 Mar 2014 22:30:55 +0000 (UTC) Message-ID: Date: Fri, 14 Mar 2014 18:30:51 -0400 From: Vincent Yu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Werner Koch References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <87y50cybh3.fsf@vigenere.g10code.de> In-Reply-To: <87y50cybh3.fsf@vigenere.g10code.de> X-Enigmail-Version: 1.6 OpenPGP: id=d28d7c4078b3742a; url=https://v-yu.com/pubkeys/openpgp.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XJoXRqxShOvQkSGIf1dJOGaf0JciVbuTp" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/aXxxIiVw6tsNx8dD7S2RwPBIgto Cc: openpgp@ietf.org Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 14 Mar 2014 22:31:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XJoXRqxShOvQkSGIf1dJOGaf0JciVbuTp Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 03/14/2014 12:46 PM, Werner Koch wrote: > On Fri, 14 Mar 2014 14:55, v@v-yu.com said: >> What ECC signing algorithms does the current development version of >> GnuPG support? > > ECDSA. > > EdDSA (Bernstein et al's Schnorr variant) will likely be added soon. Thanks. Are there any other signature algorithms or schemes that are likely to=20 appear within the next few years in either OpenPGP or GnuPG? Right now, my understanding is that RSA, DSA, ECDSA, and EdDSA are the=20 only signing keys / algorithms. Is this correct? I only have specifications for RSA and DSA keys in the current proposal, = but I think there is no issue augmenting the proposal to support ECDSA=20 and EdDSA keys. If there other types of signing keys that are likely to=20 appear, I would like to take a look to see whether they can be included=20 successfully in the proposed ring signature scheme. Vincent --XJoXRqxShOvQkSGIf1dJOGaf0JciVbuTp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREKAAYFAlMjgx0ACgkQHE22W/Uzb8Q77wD8Dyqk0f6KKaS8Ue5a5bekKNtR qBZhyQHFzVqwolSufSsBAJNgHadISTQxFjlMEq9meb9W0AzCITsQIXZtwH4NV/b9 =TAmW -----END PGP SIGNATURE----- --XJoXRqxShOvQkSGIf1dJOGaf0JciVbuTp-- From nobody Fri Mar 14 16:42:44 2014 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 32B551A0218 for ; Fri, 14 Mar 2014 16:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyambD7xDZDA for ; Fri, 14 Mar 2014 16:42:38 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10.hushmail.com [65.39.178.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9AADB1A0215 for ; Fri, 14 Mar 2014 16:42:38 -0700 (PDT) Received: from smtp10.hushmail.com (localhost [127.0.0.1]) by smtp10.hushmail.com (Postfix) with SMTP id B3F43C019A for ; Fri, 14 Mar 2014 23:42:31 +0000 (UTC) Received: from smtp.hushmail.com (w9.hushmail.com [65.39.178.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp10.hushmail.com (Postfix) with ESMTPS; Fri, 14 Mar 2014 23:42:30 +0000 (UTC) Message-ID: Date: Fri, 14 Mar 2014 19:42:27 -0400 From: Vincent Yu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , Werner Koch References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <5323146D.4050006@fifthhorseman.net> In-Reply-To: <5323146D.4050006@fifthhorseman.net> X-Enigmail-Version: 1.6 OpenPGP: id=d28d7c4078b3742a; url=https://v-yu.com/pubkeys/openpgp.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WQecS0gEChleLEDlVdwID72wGK1c9ce8G" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/z3cfWMGNPwIQkPXoWnkiRxm3G18 Cc: openpgp@ietf.org Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 14 Mar 2014 23:42:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WQecS0gEChleLEDlVdwID72wGK1c9ce8G Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 03/14/2014 10:38 AM, Daniel Kahn Gillmor wrote: > On 03/14/2014 09:55 AM, Vincent Yu wrote: >> I agree with you that it is mostly useless. Unless someone has a bette= r >> idea, I will remove the registry and modify the new signature subpacke= t >> to hold only the fingerprints of possible signers. This will nicely >> simplify things. > > For extra safety, you could still include the public key's algorithm ID= > in the subpacket as a separate one-byte marker, just using the value > from https://tools.ietf.org/html/rfc4880#section-9.1 instead of pulling= > the values from a new/duplicate registry. I think I will simply remove the one-byte marker; it just seems like a=20 bad idea for me to have added it in the first place. It doesn't seem to=20 provide any security or practical benefit, since each public key already = has a well-defined algorithm associated with it. If the verifier lacks=20 one of the public keys, knowing the algorithm ID is not going to help=20 them in any way. > I note that you've specified the ring signature approach as a generic > public key algorithm for arbitrary signature packets, and left > "decisions regarding creation and interpretation" up to the > implementation. I think a bit more guidance would be helpful in at > least two cases: > > signature types: at the moment, i only see this as a useful mechanism > for data signatures (sigtype 0x00 and 0x01) ; i don't see a reasonable > use case here for identity certifications (sigtypes 0x10 through 0x13),= > or other signature types currently available: > https://tools.ietf.org/html/rfc4880#section-5.2.1 -- i'm not suggestin= g > that we need to say these MUST NOT be made as ring signatures, but it > might be worth considering the applicability to the other signature typ= es. Yes, it sounds like a good idea to provide a bit more guidance for=20 implementers. I agree that signatures of binary documents (0x00) and=20 canonical text documents (0x01) are the intended targets of ring=20 signatures, and I also don't see reasonable usage scenarios for other=20 signature types. Perhaps I should add a short recommendation to fail all = ring signatures with types other than 0x00 and 0x01. If the implementer=20 thinks they have a genuine use for ring signatures with other types,=20 they are still free to create them, but they should not expect other=20 implementations to verify them. > Guidance would also be useful for implementations processing (or > generating) ring signatures that were made by one of a set of keys wher= e > some of those keys appear to be expired or revoked. (i haven't thought= > this use case through in sufficient detail, but i could see > implementations getting tripped up here or behaving in wildly divergent= > ways if there is no clear guidance) I think a good general recommendation here would be to look at each=20 public key individually and output the same warnings and errors that=20 would be output if this were a standard signature. Are there significant = issues that you see with this? Vincent --WQecS0gEChleLEDlVdwID72wGK1c9ce8G Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREKAAYFAlMjk+UACgkQHE22W/Uzb8T4cAD/ZfaR057mkrkXJCshBOSAV7nl CdPuZm/2zRKiZc3Q2lgA/32Rf4vKm34PxdPPWOlgeBdZ/CGg5aTg2MRUhWeV/WMi =p8Ui -----END PGP SIGNATURE----- --WQecS0gEChleLEDlVdwID72wGK1c9ce8G-- From nobody Fri Mar 14 22:03:49 2014 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 4E5D51A0002 for ; Fri, 14 Mar 2014 22:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKOgKygF-Vc7 for ; Fri, 14 Mar 2014 22:03:45 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 295E51A0007 for ; Fri, 14 Mar 2014 22:03:45 -0700 (PDT) Received: from [10.0.0.4] (h-67-100-110-8.nycm.ny.dynamic.megapath.net [67.100.110.8]) by che.mayfirst.org (Postfix) with ESMTPSA id 55AE5F984; Sat, 15 Mar 2014 01:03:36 -0400 (EDT) Message-ID: <5323DF28.5070809@fifthhorseman.net> Date: Sat, 15 Mar 2014 01:03:36 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: Vincent Yu , Werner Koch References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <5323146D.4050006@fifthhorseman.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6ForcDNj3l6vcRDXIFVUWsDOLGBI8BQH6" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/cspL7rXAsRayJzlea7dJl2H3Kco Cc: openpgp@ietf.org Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 15 Mar 2014 05:03:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6ForcDNj3l6vcRDXIFVUWsDOLGBI8BQH6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/14/2014 07:42 PM, Vincent Yu wrote: > On 03/14/2014 10:38 AM, Daniel Kahn Gillmor wrote: >> Guidance would also be useful for implementations processing (or >> generating) ring signatures that were made by one of a set of keys whe= re >> some of those keys appear to be expired or revoked. (i haven't though= t >> this use case through in sufficient detail, but i could see >> implementations getting tripped up here or behaving in wildly divergen= t >> ways if there is no clear guidance) >=20 > I think a good general recommendation here would be to look at each > public key individually and output the same warnings and errors that > would be output if this were a standard signature. Are there significan= t > issues that you see with this? i'm just imagining a troubling use case in terms of UI (maybe it isn't an issue): Alice and Bob have keys; Alice decides she wants to frame Bob. Alice makes a ring signature with her key and with Bob's key at time T over a document that is particularly terrible. She then sets her computer's clock back to time T-1 and expires or revokes her own key. Carol comes along and checks the signature on the terrible document. her OpenPGP implementation says "this signature was made by either Alice or Bob, but Alice's key was expired/revoked" If Carol is naive, the implication she might take away from such a UI is that Alice couldn't have made the signature, therefore it must have been Bob that said the terrible thing. I don't know how to clarify the UI to avoid giving that impression. --dkg --6ForcDNj3l6vcRDXIFVUWsDOLGBI8BQH6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTI98oXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcd1sP/jH9EqI1SlNdEkvvE5ealUW7 pBU72YRaBMt7z4FSjv3tafDRgLcnzx4atTa/qVtl7dhqJeRT0zLQqTlqJuWlBWyo k8T8M9+1RVy3tG384x683u9f48IwV5s6cNOPiSAVRN4QMcXkjGx3L/3ouuNketWh Kui1b/KMYsvsROX2uzdMIChmU4WUQrn1XuKfxZD3gTVIlSu9W8ynqE6KVWULRLpd Eyj5WYoqL2EbB8Nd8BmK+047LDXk8DhFPxXDa+J5JAu3XSTPtTGzvaAf1zz8x8dF 3PmPIV6tp/bBDkARGrNylV27wZKzJc6PSKATJxz9JlePjQDrUULnbnWYI7u5mqYX giqxWxUQOfMJ7cY/K9dEFl8vQJdKL4fCA3pSxq281ENi+o1WLUysTk3/J/ZHBgqM PTFVKhKhfB0HYVnxwKx7gtVFNJLq6jJXhqRT/iM+TXl3Inx+dyWNnq1Y37sPrEpI 3o0E+ZxXHdd5j1/x1TGD/S9yBUN1w8KUAICszAQX3nXY8FfNZRNYUprN1qh9Rk+g d9Xu9jLqnfupRA1D+ADS1FOzCPq+akZMReUvfk5AR+y4vSxcUKzxp0hHE96PIHSE kLer/NlwjKJ7Leo7TCVsXWWaf19b4ORLbNqbzYp91jlAf6YtB45HF3vGpxH2xjrT Ofs/lgcZyjiI8QKOudBd =mm+N -----END PGP SIGNATURE----- --6ForcDNj3l6vcRDXIFVUWsDOLGBI8BQH6-- From nobody Fri Mar 14 22:26:49 2014 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 C24121A0020 for ; Fri, 14 Mar 2014 22:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsYnkPbxP33a for ; Fri, 14 Mar 2014 22:26:45 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2.hushmail.com [65.39.178.134]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6A71A0002 for ; Fri, 14 Mar 2014 22:26:45 -0700 (PDT) Received: from smtp2.hushmail.com (localhost [127.0.0.1]) by smtp2.hushmail.com (Postfix) with SMTP id 947A1A022D for ; Sat, 15 Mar 2014 05:26:38 +0000 (UTC) Received: from smtp.hushmail.com (w4.hushmail.com [65.39.178.50]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp2.hushmail.com (Postfix) with ESMTPS; Sat, 15 Mar 2014 05:26:37 +0000 (UTC) Message-ID: <8ab357017d32acdb2afedcfbabe63ac3@smtp.hushmail.com> Date: Sat, 15 Mar 2014 01:26:34 -0400 From: Vincent Yu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , Werner Koch References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <5323146D.4050006@fifthhorseman.net> <5323DF28.5070809@fifthhorseman.net> In-Reply-To: <5323DF28.5070809@fifthhorseman.net> X-Enigmail-Version: 1.6 OpenPGP: id=d28d7c4078b3742a; url=https://v-yu.com/pubkeys/openpgp.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Og1ANmLhsOPDsAt8g8GOXjOLxO414mLrI" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/pbQSggxg38YI-AKDqM4O59sYvi0 Cc: openpgp@ietf.org Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 15 Mar 2014 05:26:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Og1ANmLhsOPDsAt8g8GOXjOLxO414mLrI Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 03/15/2014 01:03 AM, Daniel Kahn Gillmor wrote: > On 03/14/2014 07:42 PM, Vincent Yu wrote: >> On 03/14/2014 10:38 AM, Daniel Kahn Gillmor wrote: >>> Guidance would also be useful for implementations processing (or >>> generating) ring signatures that were made by one of a set of keys wh= ere >>> some of those keys appear to be expired or revoked. (i haven't thoug= ht >>> this use case through in sufficient detail, but i could see >>> implementations getting tripped up here or behaving in wildly diverge= nt >>> ways if there is no clear guidance) >> >> I think a good general recommendation here would be to look at each >> public key individually and output the same warnings and errors that >> would be output if this were a standard signature. Are there significa= nt >> issues that you see with this? > > i'm just imagining a troubling use case in terms of UI (maybe it isn't > an issue): > > Alice and Bob have keys; Alice decides she wants to frame Bob. Alice= > makes a ring signature with her key and with Bob's key at time T over a= > document that is particularly terrible. She then sets her computer's > clock back to time T-1 and expires or revokes her own key. > > Carol comes along and checks the signature on the terrible document. > her OpenPGP implementation says "this signature was made by either Alic= e > or Bob, but Alice's key was expired/revoked" > > If Carol is naive, the implication she might take away from such a UI i= s > that Alice couldn't have made the signature, therefore it must have bee= n > Bob that said the terrible thing. > > I don't know how to clarify the UI to avoid giving that impression. > > --dkg Hm. Yes, scenarios like that sound like they can confuse the typical=20 user and possibly lead to incorrect conclusions. It seems like it would=20 be prudent for implementations to issue conspicuous errors when any=20 aspect of a ring signature fails to verify, and to warn the user against = drawing any conclusion other than the fact that the ring signature did=20 not verify correctly. But at the end of the day, the security of the scheme and the behavior=20 of the implementation don't matter if users misuse them... A possibly=20 more important thing to do is to provide easy-to-read references that=20 users can look up. If ring signatures ever get implemented in GnuPG (or=20 elsewhere), we should take care to write up clear and concise=20 explanations for end users. (This is a difficult task.) Vincent --Og1ANmLhsOPDsAt8g8GOXjOLxO414mLrI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREKAAYFAlMj5IsACgkQHE22W/Uzb8QN2QD+JH3KpyhlgIvtfhUny9qp8EVc 7aIxbOOXTdzZFap/i5gA/1nLGuyzhVddqht9OW+SeCSQPZ8CvIGgvndULjLRrgYE =blRS -----END PGP SIGNATURE----- --Og1ANmLhsOPDsAt8g8GOXjOLxO414mLrI-- From nobody Sat Mar 15 02:54:58 2014 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 4E3A41A00CB for ; Sat, 15 Mar 2014 02:54:55 -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 AczyCkpvzR1M for ; Sat, 15 Mar 2014 02:54:54 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 803AB1A00D1 for ; Sat, 15 Mar 2014 02:54:52 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id x3so3980272qcv.25 for ; Sat, 15 Mar 2014 02:54:45 -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=O/E/LgePrmYHh1turkRgcj7xHemow4UdgSD3hg5OVVA=; b=P/eAIYaw5Fh9R7qd9hnflVyRdx0LrXEpUHqidAqjJwzvcsM3nyT84J5/8OThFCX1e1 LFr1orN/EwxM0Kcs4B7YQkbfInYRFbUcb6YPHUkKzYywlFzxxqfk8ZMrcQQ66vHCsnlJ AsieNeMu+LArEccQ5V6XxeulWieKMHYQ+PQlvy37jFieTPZhh6H2PW9k6jRTIza6Mhvb FNr4zNaaNF8PeFNuFVNPuRxUi7XvOO0iCu/ew2LC5QYN4kKoMekB3gcWWIKqFmNWW1GB 0fRAeSp3lE8E0iGGvFoHAvhHMClnCfIkTqnp9IuUy8Ijf+Mlu0fJ3mnGSpnazjfRei9S z9Fw== MIME-Version: 1.0 X-Received: by 10.224.167.19 with SMTP id o19mr15470138qay.77.1394877285204; Sat, 15 Mar 2014 02:54:45 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.96.157.137 with HTTP; Sat, 15 Mar 2014 02:54:45 -0700 (PDT) In-Reply-To: <87lhwcy93w.fsf@vigenere.g10code.de> References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <87y50cybh3.fsf@vigenere.g10code.de> <53233BD4.4020804@fifthhorseman.net> <87lhwcy93w.fsf@vigenere.g10code.de> Date: Sat, 15 Mar 2014 09:54:45 +0000 X-Google-Sender-Auth: uG1IdWgCsDxqndD6tsQAioixpbI Message-ID: From: Ben Laurie To: Werner Koch Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/TjCehdsGIFATLuzyGtPK5bK2P7I Cc: openpgp@ietf.org, Vincent Yu , Daniel Kahn Gillmor Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 15 Mar 2014 09:54:55 -0000 On 14 March 2014 17:37, Werner Koch wrote: > On Fri, 14 Mar 2014 18:26, dkg@fifthhorseman.net said: > >> I'm not sure i agree with this line of reasoning. older keys can be >> imported into newer software (i've done that multiple times). if the > > It is all about probability. So if I want to deny that I'm the one that made a ring signature, I make sure I only use the new s/w for ring signatures. Then probability says its not me, according to you. From nobody Sat Mar 15 10:47:19 2014 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 03BB71A0180 for ; Sat, 15 Mar 2014 10:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ZPeQo8a4ZDFI for ; Sat, 15 Mar 2014 10:47:14 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id D05821A0174 for ; Sat, 15 Mar 2014 10:47:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 97E7F4F46FF0 for ; Sat, 15 Mar 2014 10:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYcy3u80FYaE for ; Sat, 15 Mar 2014 10:47:05 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 7AEF24F46FE5 for ; Sat, 15 Mar 2014 10:47:05 -0700 (PDT) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Sat, 15 Mar 2014 10:47:05 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Sat, 15 Mar 2014 10:47:05 -0700 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Jon Callas In-Reply-To: <5323DF28.5070809@fifthhorseman.net> Date: Sat, 15 Mar 2014 10:47:10 -0700 Message-Id: References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <5323146D.4050006@fifthhorseman.net> <5323DF28.5070809@fifthhorseman.net> To: "openpgp@ietf.org OpenPGP" X-Mailer: Apple Mail (2.1874) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/cJrck53zxAAIFF1MgyqhM_Y-Dfw Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 15 Mar 2014 17:47:17 -0000 On Mar 14, 2014, at 10:03 PM, Daniel Kahn Gillmor = wrote: > i'm just imagining a troubling use case in terms of UI (maybe it isn't > an issue): >=20 > Alice and Bob have keys; Alice decides she wants to frame Bob. Alice > makes a ring signature with her key and with Bob's key at time T over = a > document that is particularly terrible. She then sets her computer's > clock back to time T-1 and expires or revokes her own key. >=20 > Carol comes along and checks the signature on the terrible document. > her OpenPGP implementation says "this signature was made by either = Alice > or Bob, but Alice's key was expired/revoked" >=20 > If Carol is naive, the implication she might take away from such a UI = is > that Alice couldn't have made the signature, therefore it must have = been > Bob that said the terrible thing. >=20 > I don't know how to clarify the UI to avoid giving that impression. I confess that I don't see it as an issue. There's part of me that wants to say ironically, "Well, I guess we = shouldn't do it, then!" But I don't want to be dismissive of your point. But I would also say that a lot of what you're saying is just hard to do = -- like revocation. Revocation doesn't work and *can't* work the way one = might naively expect it. The situation you describe exists today in a = slightly mutated form. Here's an example: Bob is a politician and wants to repudiate a previous position he used = to have, so he sets his clock back, revokes his own key and then claims = that all the signatures made after that date come from his computer = having been hacked back in the day. It's really the same problem, just with a one-person variety. It boils = down to the fact that revocation doesn't really work, beyond trivial = cases. Now on the other hand, ages ago, we discussed ring signatures, and a use = case that I wanted to do was to make it so that whenever Alice sends Bob = a signed email or other casual message, she would (could?) sign it with = a ring signature of her key and Bob's. Bob knows that he didn't sign it = so he knows that Alice did.=20 Of course, it's one of those things that are cool, and yet it's hard to = say what it actually does to improve anything. Jon= From nobody Sat Mar 15 13:33:37 2014 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 7783A1A01B3 for ; Sat, 15 Mar 2014 13:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J873TINK3dz7 for ; Sat, 15 Mar 2014 13:33:34 -0700 (PDT) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id B9B0C1A01A9 for ; Sat, 15 Mar 2014 13:33:33 -0700 (PDT) Received: by mail-ee0-f41.google.com with SMTP id t10so2662978eei.0 for ; Sat, 15 Mar 2014 13:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+Ab19FojsJuXXwJJXm7OUuCH3gpZz+pD+ff3rfexSso=; b=WWuyb8WIMP4pGEjoEdFsDXYhOycETejNgyIEw/Gmyu86iC1Cw8PfQieXTn1+z1PoTK TcQ6ZEpUflBgPp6rhb6tp0AYKklw62oh9OW7Agiig0L2LxMfZ4e7wwPXif7xYr+slyyd nBOKMf/twgNwSg7lFeTTx6o43iy7APHwkYsxUTIOb0lf/9pZeobhk1+LJNdEdvcGGtb8 SrzI5u33DHWv3gE/DH+gNplzXEu/DGth0B8W20/QWhQPcr0e1z+Ki+81u3cGUX3qbubi rwZqvQ2yn3/WfIvdHxLX4m1dDTFFnc+uhyXglN0PAFB32fufX9miOTvcpERWWVACeaCO 2+uw== MIME-Version: 1.0 X-Received: by 10.15.65.68 with SMTP id p44mr108777eex.63.1394915606036; Sat, 15 Mar 2014 13:33:26 -0700 (PDT) Received: by 10.14.80.135 with HTTP; Sat, 15 Mar 2014 13:33:25 -0700 (PDT) In-Reply-To: References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <5323146D.4050006@fifthhorseman.net> <5323DF28.5070809@fifthhorseman.net> Date: Sat, 15 Mar 2014 20:33:25 +0000 Message-ID: From: Nicholas Cole To: openpgp@ietf.org Content-Type: multipart/alternative; boundary=001a11c3f37230887804f4ab1999 Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/RH6mJ4TENbubvw4O0qjNF0cDWe0 Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 15 Mar 2014 20:33:36 -0000 --001a11c3f37230887804f4ab1999 Content-Type: text/plain; charset=ISO-8859-1 On Saturday, 15 March 2014, Jon Callas wrote: > On Mar 14, 2014, at 10:03 PM, Daniel Kahn Gillmor > > wrote: > > > i'm just imagining a troubling use case in terms of UI (maybe it isn't > > an issue): > > > > Alice and Bob have keys; Alice decides she wants to frame Bob. Alice > > makes a ring signature with her key and with Bob's key at time T over a > > document that is particularly terrible. She then sets her computer's > > clock back to time T-1 and expires or revokes her own key. > > > > Carol comes along and checks the signature on the terrible document. > > her OpenPGP implementation says "this signature was made by either Alice > > or Bob, but Alice's key was expired/revoked" > > > > If Carol is naive, the implication she might take away from such a UI is > > that Alice couldn't have made the signature, therefore it must have been > > Bob that said the terrible thing. > > > > I don't know how to clarify the UI to avoid giving that impression. > > I confess that I don't see it as an issue. > > There's part of me that wants to say ironically, "Well, I guess we > shouldn't do it, then!" But I don't want to be dismissive of your point. > > But I would also say that a lot of what you're saying is just hard to do > -- like revocation. Revocation doesn't work and *can't* work the way one > might naively expect it. The situation you describe exists today in a > slightly mutated form. Here's an example: > > Bob is a politician and wants to repudiate a previous position he used to > have, so he sets his clock back, revokes his own key and then claims that > all the signatures made after that date come from his computer having been > hacked back in the day. That is an interesting 'attack' on your own key. Never rely on the date of a revocakation signature is obvious when you think about it. It does make you wonder if signature packets like this should have dates at all. They make everything much more complicated in some ways... It's really the same problem, just with a one-person variety. It boils down > to the fact that revocation doesn't really work, beyond trivial cases. > > Now on the other hand, ages ago, we discussed ring signatures, and a use > case that I wanted to do was to make it so that whenever Alice sends Bob a > signed email or other casual message, she would (could?) sign it with a > ring signature of her key and Bob's. Bob knows that he didn't sign it so he > knows that Alice did. > > Of course, it's one of those things that are cool, and yet it's hard to > say what it actually does to improve anything. > It also breaks the metaphor of a 'signature' too: the signatures we currently have work in a very similar way to the ideal real-world signature. This type of signature doesn't: it is a signature only specific people can verify, or rather, a signature that could have been made by any one of a number of people. The problem might then become proving you were *not* the person who made it, rather than the person who did, and proving a negative is impossible. I think for that reason I'm not sure would welcome it being added to gpg. "Yes, that is a signature that I could have made, but I didn't" is not an easy position... N. --001a11c3f37230887804f4ab1999 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Saturday, 15 March 2014, Jon Callas <jon@callas.org> wrote:
O= n Mar 14, 2014, at 10:03 PM, Daniel Kahn Gillmor <d= kg@fifthhorseman.net> wrote:

> i'm just imagining a troubling use case in terms of UI (maybe it i= sn't
> an issue):
>
> Alice and Bob have keys; Alice decides she wants to frame Bob. =A0Alic= e
> makes a ring signature with her key and with Bob's key at time T o= ver a
> document that is particularly terrible. =A0She then sets her computer&= #39;s
> clock back to time T-1 and expires or revokes her own key.
>
> Carol comes along and checks the signature on the terrible document. > her OpenPGP implementation says "this signature was made by eithe= r Alice
> or Bob, but Alice's key was expired/revoked"
>
> If Carol is naive, the implication she might take away from such a UI = is
> that Alice couldn't have made the signature, therefore it must hav= e been
> Bob that said the terrible thing.
>
> I don't know how to clarify the UI to avoid giving that impression= .

I confess that I don't see it as an issue.

There's part of me that wants to say ironically, "Well, I guess we= shouldn't do it, then!" But I don't want to be dismissive of = your point.

But I would also say that a lot of what you're saying is just hard to d= o -- like revocation. Revocation doesn't work and *can't* work the = way one might naively expect it. The situation you describe exists today in= a slightly mutated form. Here's an example:

Bob is a politician and wants to repudiate a previous position he used to h= ave, so he sets his clock back, revokes his own key and then claims that al= l the signatures made after that date come from his computer having been ha= cked back in the day.

That is an interesting 'attack' on your own key= . Never rely on the date of a revocakation signature is obvious when you th= ink about it. =A0It does make you wonder if signature packets like this sho= uld have dates at all. =A0They make everything much more complicated in som= e ways...


It's really the same problem, just with a one-person variety. It boils = down to the fact that revocation doesn't really work, beyond trivial ca= ses.

Now on the other hand, ages ago, we discussed ring signatures, and a use ca= se that I wanted to do was to make it so that whenever Alice sends Bob a si= gned email or other casual message, she would (could?) sign it with a ring = signature of her key and Bob's. Bob knows that he didn't sign it so= he knows that Alice did.

Of course, it's one of those things that are cool, and yet it's har= d to say what it actually does to improve anything.

It also breaks the metaphor of a 'sign= ature' too: the signatures we currently have work in a very similar way= to the ideal real-world signature. This type of signature doesn't: it = is a signature only specific people can verify, or rather, a signature that= could have been made by any one of a number of people. The problem might t= hen become proving you were *not* the person who made it, rather than the p= erson who did, and proving a negative is impossible. I think for that reaso= n I'm not sure would welcome it being added to gpg. =A0"Yes, that = is a signature that I could have made, but I didn't" is not an eas= y position...

N.=A0
--001a11c3f37230887804f4ab1999-- From nobody Sat Mar 15 13:40:40 2014 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 C63E51A020A for ; Sat, 15 Mar 2014 13:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxqhErtuviit for ; Sat, 15 Mar 2014 13:40:35 -0700 (PDT) Received: from mail-ee0-x22b.google.com (mail-ee0-x22b.google.com [IPv6:2a00:1450:4013:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5071E1A01B6 for ; Sat, 15 Mar 2014 13:40:35 -0700 (PDT) Received: by mail-ee0-f43.google.com with SMTP id e53so2619645eek.16 for ; Sat, 15 Mar 2014 13:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=PiUKx0CGST8TjjTK5h5RnQ/mGtTL/+ryG4NPA+Cm6pA=; b=uCtiICuaz70TuxS1F8+93Zd4+gJt31cr5jqadRNYOOrS9NISmWBAvUCeejMp6DsvJd FeRJkdYJlh7A2wFvHEb7lQ4OYR1A1FxACgHwH3sY4dRZNMNhLEMwiSpQxZ/aWAbpxP/x gpfDH2LZlxvLl1G8YA4bp+B97UB7x9SDSQvKCMqS0BKQLfzWyIyLOhF4F8Pa2E6sM5KI 7BSblAkfw8XzJ/1FvGJF/qHgx1R3wb38sLHo/II1T+xxGHuCrbMGfSaZ5Zz03UOM+mGu Km8t2S28lqHUqbSO5nc9jqcoT33ciL8to+XFLQR69K726C9XibhMniaZZVqkQtZc0bWo 7HPA== MIME-Version: 1.0 X-Received: by 10.14.174.5 with SMTP id w5mr15620688eel.14.1394916027526; Sat, 15 Mar 2014 13:40:27 -0700 (PDT) Received: by 10.14.80.135 with HTTP; Sat, 15 Mar 2014 13:40:27 -0700 (PDT) In-Reply-To: References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <5323146D.4050006@fifthhorseman.net> <5323DF28.5070809@fifthhorseman.net> Date: Sat, 15 Mar 2014 20:40:27 +0000 Message-ID: From: Nicholas Cole To: openpgp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/x0a3o76J3de0J-46bbw2Dhm_sAo Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 15 Mar 2014 20:40:38 -0000 On Sat, Mar 15, 2014 at 8:33 PM, Nicholas Cole wrote: > > > On Saturday, 15 March 2014, Jon Callas wrote: >> >> On Mar 14, 2014, at 10:03 PM, Daniel Kahn Gillmor >> wrote: >> >> > i'm just imagining a troubling use case in terms of UI (maybe it isn't >> > an issue): >> > >> > Alice and Bob have keys; Alice decides she wants to frame Bob. Alice >> > makes a ring signature with her key and with Bob's key at time T over a >> > document that is particularly terrible. She then sets her computer's >> > clock back to time T-1 and expires or revokes her own key. >> > >> > Carol comes along and checks the signature on the terrible document. >> > her OpenPGP implementation says "this signature was made by either Alice >> > or Bob, but Alice's key was expired/revoked" >> > >> > If Carol is naive, the implication she might take away from such a UI is >> > that Alice couldn't have made the signature, therefore it must have been >> > Bob that said the terrible thing. >> > >> > I don't know how to clarify the UI to avoid giving that impression. >> >> I confess that I don't see it as an issue. >> >> There's part of me that wants to say ironically, "Well, I guess we >> shouldn't do it, then!" But I don't want to be dismissive of your point. >> >> But I would also say that a lot of what you're saying is just hard to do >> -- like revocation. Revocation doesn't work and *can't* work the way one >> might naively expect it. The situation you describe exists today in a >> slightly mutated form. Here's an example: >> >> Bob is a politician and wants to repudiate a previous position he used to >> have, so he sets his clock back, revokes his own key and then claims that >> all the signatures made after that date come from his computer having been >> hacked back in the day. > > > That is an interesting 'attack' on your own key. Never rely on the date of a > revocakation signature is obvious when you think about it. It does make you > wonder if signature packets like this should have dates at all. They make > everything much more complicated in some ways... > > >> It's really the same problem, just with a one-person variety. It boils >> down to the fact that revocation doesn't really work, beyond trivial cases. >> >> Now on the other hand, ages ago, we discussed ring signatures, and a use >> case that I wanted to do was to make it so that whenever Alice sends Bob a >> signed email or other casual message, she would (could?) sign it with a ring >> signature of her key and Bob's. Bob knows that he didn't sign it so he knows >> that Alice did. >> >> Of course, it's one of those things that are cool, and yet it's hard to >> say what it actually does to improve anything. > > > It also breaks the metaphor of a 'signature' too: the signatures we > currently have work in a very similar way to the ideal real-world signature. > This type of signature doesn't: it is a signature only specific people can > verify, or rather, a signature that could have been made by any one of a > number of people. The problem might then become proving you were *not* the > person who made it, rather than the person who did, and proving a negative > is impossible. I think for that reason I'm not sure would welcome it being > added to gpg. "Yes, that is a signature that I could have made, but I > didn't" is not an easy position... And thinking about it even further, it compounds a problem that someone (was it you, Jon?) has written about in the past. Even though we all know that key UIDs can be signed by complete strangers, users are *often* disconcerted by this fact (which is why there is a no-modifier flag, even if keyservers have never respected it and even if it would make the use of OpenPGP even more complicated). Still, a naive user of an OpenPGP program may draw incorrect inferences about social relationships from UID signatures. Imagine the outcry of users if they discovered that documents were in the wild that 'might' have been signed by them... N. From nobody Sat Mar 15 14:40:52 2014 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 41A3B1A01AC for ; Sat, 15 Mar 2014 14:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uguRI7yfRaL9 for ; Sat, 15 Mar 2014 14:40:46 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10.hushmail.com [65.39.178.143]) by ietfa.amsl.com (Postfix) with ESMTP id 68E591A01BB for ; Sat, 15 Mar 2014 14:40:44 -0700 (PDT) Received: from smtp10.hushmail.com (localhost [127.0.0.1]) by smtp10.hushmail.com (Postfix) with SMTP id 30B5DC00F6 for ; Sat, 15 Mar 2014 21:40:36 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp10.hushmail.com (Postfix) with ESMTPS; Sat, 15 Mar 2014 21:40:35 +0000 (UTC) Message-ID: <029427f6d271b61840ad3f919796c18c@smtp.hushmail.com> Date: Sat, 15 Mar 2014 17:40:32 -0400 From: Vincent Yu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Nicholas Cole , openpgp@ietf.org References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <5323146D.4050006@fifthhorseman.net> <5323DF28.5070809@fifthhorseman.net> In-Reply-To: X-Enigmail-Version: 1.6 OpenPGP: id=d28d7c4078b3742a; url=https://v-yu.com/pubkeys/openpgp.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TBqkS0j86Ev4AQQGGTUiFhoW9u3aR4mFv" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/eSAMXbHVwYj0Lo0-YKc5U005Tyk Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 15 Mar 2014 21:40:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TBqkS0j86Ev4AQQGGTUiFhoW9u3aR4mFv Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 03/15/2014 04:40 PM, Nicholas Cole wrote: > On Sat, Mar 15, 2014 at 8:33 PM, Nicholas Cole wrote: >> >> >> On Saturday, 15 March 2014, Jon Callas wrote: >>> Now on the other hand, ages ago, we discussed ring signatures, and a = use >>> case that I wanted to do was to make it so that whenever Alice sends = Bob a >>> signed email or other casual message, she would (could?) sign it with= a ring >>> signature of her key and Bob's. Bob knows that he didn't sign it so h= e knows >>> that Alice did. >>> >>> Of course, it's one of those things that are cool, and yet it's hard = to >>> say what it actually does to improve anything. >> >> >> It also breaks the metaphor of a 'signature' too: the signatures we >> currently have work in a very similar way to the ideal real-world sign= ature. >> This type of signature doesn't: it is a signature only specific people= can >> verify, or rather, a signature that could have been made by any one of= a >> number of people. The problem might then become proving you were *not*= the >> person who made it, rather than the person who did, and proving a nega= tive >> is impossible. I think for that reason I'm not sure would welcome it b= eing >> added to gpg. "Yes, that is a signature that I could have made, but I= >> didn't" is not an easy position... > > And thinking about it even further, it compounds a problem that > someone (was it you, Jon?) has written about in the past. Even though > we all know that key UIDs can be signed by complete strangers, users > are *often* disconcerted by this fact (which is why there is a > no-modifier flag, even if keyservers have never respected it and even > if it would make the use of OpenPGP even more complicated). Still, a > naive user of an OpenPGP program may draw incorrect inferences about > social relationships from UID signatures. Imagine the outcry of users > if they discovered that documents were in the wild that 'might' have > been signed by them... > > N. This reminds me that I used the name "signer-ambiguous signature" in=20 some of the early drafts of my proposal. This name concisely describes=20 the most important property of ring signatures. Now that I think about=20 it, that is a much better name than "ring signature" for implementations = to present to their end users. "Signer-ambiguity" was coined by Rivest et al. to describe ring=20 signatures in their seminal paper in 2001, so it's well-connected to the = concept of ring signatures in the literature. Unless there are severe objections, I will modify the proposal to use=20 the phrase "signer-ambiguous signature" to refer generally to the=20 signatures produced by the scheme, and use "ring signature" only as=20 technical term for the specific scheme that was chosen to provide=20 signer-ambiguity. Vincent --TBqkS0j86Ev4AQQGGTUiFhoW9u3aR4mFv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREKAAYFAlMkyNEACgkQHE22W/Uzb8T5NwEAhplcHJHjHMGTkv8xLiCBZ10i kvUKHfxlTMZdUDKAF1IA/2s9oQ4iIJhpTFEBdjPbOCcvb/h5RhFXr5zLS0XtBD9R =E1NW -----END PGP SIGNATURE----- --TBqkS0j86Ev4AQQGGTUiFhoW9u3aR4mFv-- From nobody Sat Mar 15 15:02:34 2014 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 B2A2F1A01DA for ; Sat, 15 Mar 2014 15:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvLeoP3FBtUC for ; Sat, 15 Mar 2014 15:02:29 -0700 (PDT) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 53CF01A01D8 for ; Sat, 15 Mar 2014 15:02:29 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id b57so2001565eek.26 for ; Sat, 15 Mar 2014 15:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=7EYu0SP5HrVof8fx7IFPPjEOq52VZ03wvmVJ/VgKDrg=; b=q+6JnnRxexla2469N+zSEKygMzU5eC8Y77jJsPToJbd8GURAa9JwYF+VzV8k50T7DB foGbQUbatqxeS0wWUxuK6hbfA45/e9E2zukRQzxBMwAN3Li/hNWU7yEg8PVQSe2kPOaV x+np6RB4t+fkBha4/CLD8CxfSJlTvFvPh7npEAG1ulUENT8QHOdvgrsOUl69/ql/LqRu 9Sx3LZ94oUIiqAgFY+8i3JFMG4dPrtX6ZsL0/7A4yE6kyjeUW5zSBn9Gh46z9hdyg/6N uussFdx2aWZXTHdWjfZnV5ourkPDcIXWByhCbk16qKpxyJoWbk4Q8xwqOW5kJqhUzLuY vbSQ== MIME-Version: 1.0 X-Received: by 10.15.21.2 with SMTP id c2mr332976eeu.78.1394920941546; Sat, 15 Mar 2014 15:02:21 -0700 (PDT) Received: by 10.14.80.135 with HTTP; Sat, 15 Mar 2014 15:02:21 -0700 (PDT) In-Reply-To: <029427f6d271b61840ad3f919796c18c@smtp.hushmail.com> References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <5323146D.4050006@fifthhorseman.net> <5323DF28.5070809@fifthhorseman.net> <029427f6d271b61840ad3f919796c18c@smtp.hushmail.com> Date: Sat, 15 Mar 2014 22:02:21 +0000 Message-ID: From: Nicholas Cole To: openpgp@ietf.org Content-Type: multipart/alternative; boundary=089e0160d2b835f39a04f4ac5763 Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/en8CNwThB3ijy3PUkT6ll7WUXxY Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 15 Mar 2014 22:02:32 -0000 --089e0160d2b835f39a04f4ac5763 Content-Type: text/plain; charset=ISO-8859-1 On Saturday, 15 March 2014, Vincent Yu wrote: > On 03/15/2014 04:40 PM, Nicholas Cole wrote: > >> On Sat, Mar 15, 2014 at 8:33 PM, Nicholas Cole >> wrote: >> >>> >>> >>> On Saturday, 15 March 2014, Jon Callas wrote: >>> >>>> Now on the other hand, ages ago, we discussed ring signatures, and a use >>>> case that I wanted to do was to make it so that whenever Alice sends >>>> Bob a >>>> signed email or other casual message, she would (could?) sign it with a >>>> ring >>>> signature of her key and Bob's. Bob knows that he didn't sign it so he >>>> knows >>>> that Alice did. >>>> >>>> Of course, it's one of those things that are cool, and yet it's hard to >>>> say what it actually does to improve anything. >>>> >>> >>> >>> It also breaks the metaphor of a 'signature' too: the signatures we >>> currently have work in a very similar way to the ideal real-world >>> signature. >>> This type of signature doesn't: it is a signature only specific people >>> can >>> verify, or rather, a signature that could have been made by any one of a >>> number of people. The problem might then become proving you were *not* >>> the >>> person who made it, rather than the person who did, and proving a >>> negative >>> is impossible. I think for that reason I'm not sure would welcome it >>> being >>> added to gpg. "Yes, that is a signature that I could have made, but I >>> didn't" is not an easy position... >>> >> >> And thinking about it even further, it compounds a problem that >> someone (was it you, Jon?) has written about in the past. Even though >> we all know that key UIDs can be signed by complete strangers, users >> are *often* disconcerted by this fact (which is why there is a >> no-modifier flag, even if keyservers have never respected it and even >> if it would make the use of OpenPGP even more complicated). Still, a >> naive user of an OpenPGP program may draw incorrect inferences about >> social relationships from UID signatures. Imagine the outcry of users >> if they discovered that documents were in the wild that 'might' have >> been signed by them... >> >> N. >> > > This reminds me that I used the name "signer-ambiguous signature" in some > of the early drafts of my proposal. This name concisely describes the most > important property of ring signatures. Now that I think about it, that is a > much better name than "ring signature" for implementations to present to > their end users. > > "Signer-ambiguity" was coined by Rivest et al. to describe ring signatures > in their seminal paper in 2001, so it's well-connected to the concept of > ring signatures in the literature. > > Unless there are severe objections, I will modify the proposal to use the > phrase "signer-ambiguous signature" to refer generally to the signatures > produced by the scheme, and use "ring signature" only as technical term for > the specific scheme that was chosen to provide signer-ambiguity. I think that is a better name. It gets away from the idea that there is a 'ring' of people who have authorized each other to make signatures. But still, I think that this proposal will bring more problems than benefits. Signatures will appear that 'might' have been made by all kinds of people on all kinds of documents. User interfaces will struggle to help users to make good decisions as a result. I can't help feeling that this kind of signature belongs in very specific applications, and not in general purpose tools. But I could be wrong. N. --089e0160d2b835f39a04f4ac5763 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Saturday, 15 March 2014, Vincent Yu <v@v-yu.com> wrote:
On 03/15= /2014 04:40 PM, Nicholas Cole wrote:
On Sat, Mar 15, 2014 at 8:33 PM, Nicholas Cole <nicholas.cole@gmail.c= om> wrote:


On Saturday, 15 March 2014, Jon Callas <jon@callas.org> wrote:=
Now on the other hand, ages ago, we discussed ring signatures, and a use case that I wanted to do was to make it so that whenever Alice sends Bob a<= br> signed email or other casual message, she would (could?) sign it with a rin= g
signature of her key and Bob's. Bob knows that he didn't sign it so= he knows
that Alice did.

Of course, it's one of those things that are cool, and yet it's har= d to
say what it actually does to improve anything.


It also breaks the metaphor of a 'signature' too: the signatures we=
currently have work in a very similar way to the ideal real-world signature= .
This type of signature doesn't: it is a signature only specific people = can
verify, or rather, a signature that could have been made by any one of a number of people. The problem might then become proving you were *not* the<= br> person who made it, rather than the person who did, and proving a negative<= br> is impossible. I think for that reason I'm not sure would welcome it be= ing
added to gpg. =A0"Yes, that is a signature that I could have made, but= I
didn't" is not an easy position...

And thinking about it even further, it compounds a problem that
someone (was it you, Jon?) has written about in the past. =A0Even though we all know that key UIDs can be signed by complete strangers, users
are *often* disconcerted by this fact (which is why there is a
no-modifier flag, even if keyservers have never respected it and even
if it would make the use of OpenPGP even more complicated). =A0Still, a
naive user of an OpenPGP program may draw incorrect inferences about
social relationships from UID signatures. =A0Imagine the outcry of users if they discovered that documents were in the wild that 'might' hav= e
been signed by them...

N.

This reminds me that I used the name "signer-ambiguous signature"= in some of the early drafts of my proposal. This name concisely describes = the most important property of ring signatures. Now that I think about it, = that is a much better name than "ring signature" for implementati= ons to present to their end users.

"Signer-ambiguity" was coined by Rivest et al. to describe ring s= ignatures in their seminal paper in 2001, so it's well-connected to the= concept of ring signatures in the literature.

Unless there are severe objections, I will modify the proposal to use the p= hrase "signer-ambiguous signature" to refer generally to the sign= atures produced by the scheme, and use "ring signature" only as t= echnical term for the specific scheme that was chosen to provide signer-amb= iguity.

I think that is a better name. =A0It gets away from the= idea that there is a 'ring' of people who have authorized each oth= er to make signatures. =A0But still, I think that this proposal will bring = more problems than benefits. =A0Signatures will appear that 'might'= have been made by all kinds of people on all kinds of documents. =A0User i= nterfaces will struggle to help users to make good decisions as a result. = =A0I can't help feeling that this kind of signature belongs in very spe= cific applications, and not in general purpose tools. But I could be wrong.=

N.=A0=A0
--089e0160d2b835f39a04f4ac5763-- From nobody Sat Mar 15 19:28:29 2014 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 1E4471A024E for ; Sat, 15 Mar 2014 19:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HsGcp-puMGv for ; Sat, 15 Mar 2014 19:28:26 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10.hushmail.com [65.39.178.143]) by ietfa.amsl.com (Postfix) with ESMTP id F34F31A022D for ; Sat, 15 Mar 2014 19:28:25 -0700 (PDT) Received: from smtp10.hushmail.com (localhost [127.0.0.1]) by smtp10.hushmail.com (Postfix) with SMTP id 7DA5EC016A for ; Sun, 16 Mar 2014 02:28:18 +0000 (UTC) Received: from smtp.hushmail.com (w9.hushmail.com [65.39.178.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp10.hushmail.com (Postfix) with ESMTPS; Sun, 16 Mar 2014 02:28:17 +0000 (UTC) Message-ID: <78443bf532834a1dfdd4e0c80af2bea3@smtp.hushmail.com> Date: Sat, 15 Mar 2014 22:28:14 -0400 From: Vincent Yu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Nicholas Cole , openpgp@ietf.org References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <5323146D.4050006@fifthhorseman.net> <5323DF28.5070809@fifthhorseman.net> <029427f6d271b61840ad3f919796c18c@smtp.hushmail.com> In-Reply-To: X-Enigmail-Version: 1.6 OpenPGP: id=d28d7c4078b3742a; url=https://v-yu.com/pubkeys/openpgp.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="afe0e6bA62nffC633nt70CRj59SrggkQ7" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/tBkLIdG3p1foDRoZzcVIAnpL6r8 Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 16 Mar 2014 02:28:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --afe0e6bA62nffC633nt70CRj59SrggkQ7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 03/15/2014 06:02 PM, Nicholas Cole wrote: > > > On Saturday, 15 March 2014, Vincent Yu >= > wrote: > This reminds me that I used the name "signer-ambiguous signature" i= n > some of the early drafts of my proposal. This name concisely > describes the most important property of ring signatures. Now that = I > think about it, that is a much better name than "ring signature" fo= r > implementations to present to their end users. > > "Signer-ambiguity" was coined by Rivest et al. to describe ring > signatures in their seminal paper in 2001, so it's well-connected t= o > the concept of ring signatures in the literature. > > Unless there are severe objections, I will modify the proposal to > use the phrase "signer-ambiguous signature" to refer generally to > the signatures produced by the scheme, and use "ring signature" onl= y > as technical term for the specific scheme that was chosen to provid= e > signer-ambiguity. > > > I think that is a better name. It gets away from the idea that there i= s > a 'ring' of people who have authorized each other to make signatures. > But still, I think that this proposal will bring more problems than > benefits. Signatures will appear that 'might' have been made by all > kinds of people on all kinds of documents. User interfaces will > struggle to help users to make good decisions as a result. I can't hel= p > feeling that this kind of signature belongs in very specific > applications, and not in general purpose tools. But I could be wrong. I share your concerns, but on the whole, I think it is a net positive to = offer signers the option to create signer-ambiguous signatures. Let me=20 go into more detail. Within benign use cases, there are two sides to signer-ambiguous=20 signatures: the recipient's side and the signer's side. The recipient would generally prefer to receive standard signatures=20 rather than signer-ambiguous signatures because standard signatures=20 offer stronger guarantees and grant them the power to prove to others=20 what they received. However, recipients would prefer to receive=20 signer-ambiguous signatures rather than no signature. So from the=20 recipient's perspective, signer-ambiguous signatures can be bad or good, = depending on whether the alternative is a standard signature or no=20 signature. However, signer-ambiguous signatures are designed with the signer in=20 mind. The signer would find signer-ambiguous signatures useful in=20 situations where they wish to ensure authenticity without granting=20 recipients the power to transfer their signatures (here, I am=20 considering only two-party communications; there are potentially other=20 applications of signer-ambiguous signatures). Signer-ambiguous=20 signatures are always good from the signer's perspective, because they=20 provide an extra option that they may choose to use. Within malicious use cases, there is the attacker's side. At the end of=20 the day, a new signature type will indeed create a potential attack=20 vector, and it is hard to predict exactly what types of attack will=20 become possible because the details will depend on the interactions=20 between users and implementations. It seems to me that your worries fall mainly within scenarios with an=20 attacker. Without an attacker, there is little reason to worry about=20 verifier confusion because the goals of signers coincide with those of=20 recipients: signatures are a way for signers to provide a guarantee to=20 recipients. If it turns out that recipients get excessively confused=20 over signer-ambiguous signatures, then signers will simply decide not to = use them. In the long run, signers will adapt and use signer-ambiguous=20 signatures only when they judge that the benefits outweigh the potential = confusion. So we need only worry about the potential for verifier confusion in=20 scenarios with an attacker. Here, I think implementations have a good=20 response available if attacks grow rampant: they simply refuse to verify = signer-ambiguous signatures. Without the cooperation of implementations, = attackers can do no harm. That is the worst case scenario. However, I consider it unlikely that=20 attacks using signer-ambiguous signatures will ever become common enough = to outweigh the benefits to signers. Perhaps our intuitions differ here. The main point I wish to reemphasize is that signers are free not to=20 create signer-ambiguous signatures if they think that the potential for=20 confusion outweighs the benefits. Their goals are aligned with those of=20 recipients. Vincent --afe0e6bA62nffC633nt70CRj59SrggkQ7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREKAAYFAlMlDEAACgkQHE22W/Uzb8QSBAD/S6BOAt+jVPg4GFvH7fvJzkVx 6KZk1gy1DJOqnYsNYb8A/jiqDw9xM0oWH8iCRstgSGUWa1O88U/hmn/IWXeEUer9 =rVqv -----END PGP SIGNATURE----- --afe0e6bA62nffC633nt70CRj59SrggkQ7-- From nobody Sat Mar 15 20:30:08 2014 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 A33BF1A02BD for ; Sat, 15 Mar 2014 20:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsyL2grxn8pG for ; Sat, 15 Mar 2014 20:30:03 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5.hushmail.com [65.39.178.142]) by ietfa.amsl.com (Postfix) with ESMTP id D60611A0271 for ; Sat, 15 Mar 2014 20:29:59 -0700 (PDT) Received: from smtp5.hushmail.com (localhost [127.0.0.1]) by smtp5.hushmail.com (Postfix) with SMTP id 0CF23601AF for ; Sun, 16 Mar 2014 03:29:52 +0000 (UTC) Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp5.hushmail.com (Postfix) with ESMTPS for ; Sun, 16 Mar 2014 03:29:51 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id E9E462038C; Sun, 16 Mar 2014 03:29:51 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 15 Mar 2014 23:29:51 -0400 To: openpgp@ietf.org From: vedaal@nym.hush.com In-Reply-To: References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <5323146D.4050006@fifthhorseman.net> <5323DF28.5070809@fifthhorseman.net> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20140316032951.E9E462038C@smtp.hushmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/ySvdBdaB9VWiAbG11j4niXJkrz4 Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 16 Mar 2014 03:30:06 -0000 On 03/15/2014 at 1:47 PM, "Jon Callas" wrote: >It's really the same problem, just with a one-person variety. It >boils down to the fact that revocation doesn't really work, beyond >trivial cases. > >Now on the other hand, ages ago, we discussed ring signatures, and >a use case that I wanted to do was to make it so that whenever >Alice sends Bob a signed email or other casual message, she would >(could?) sign it with a ring signature of her key and Bob's. Bob >knows that he didn't sign it so he knows that Alice did. But isn't it obvious that the key revocation is a scam, when the time of the revocation and the time of its receipt by a key-server, are too far apart? (anything more than an hour should be suspicious.) The only plausibility Alice may have, is that she couldn't get online soon enough after she revoked her key, and this is discoverable if she went online for any other reason. If there were some way to make the revocation process not be complete until received and verified by a keyserver, and then listed as revoked as of the keyserver's receipt time, then it might do away with the 'change the clock and revoke scam' and make revocation more workable. vedaal From nobody Sat Mar 15 21:12:29 2014 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 3FCE11A02C1 for ; Sat, 15 Mar 2014 21:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-0.547, 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 MoILqDKnT2oe for ; Sat, 15 Mar 2014 21:12:24 -0700 (PDT) Received: from smtp.iridiumlinux.org (akira.iridiumlinux.org [184.70.203.174]) by ietfa.amsl.com (Postfix) with ESMTP id C20F61A02C0 for ; Sat, 15 Mar 2014 21:12:23 -0700 (PDT) Received: by smtp.iridiumlinux.org (Postfix, from userid 65534) id F1D3813F4406; Sat, 15 Mar 2014 22:12:15 -0600 (MDT) X-Spam-ASN: Received: from [10.20.207.216] (unknown [204.239.250.1]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.iridiumlinux.org (Postfix) with ESMTPSA id 3136213F4257 for ; Sat, 15 Mar 2014 22:12:13 -0600 (MDT) Message-ID: <53252495.4090501@iridiumlinux.org> Date: Sat, 15 Mar 2014 21:12:05 -0700 From: Falcon Darkstar Momot User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <5323146D.4050006@fifthhorseman.net> <5323DF28.5070809@fifthhorseman.net> <20140316032951.E9E462038C@smtp.hushmail.com> In-Reply-To: <20140316032951.E9E462038C@smtp.hushmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/0U41b3EeaHzpuUGwWw2VYzz0S74 Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 16 Mar 2014 04:12:27 -0000 On 3/15/2014 8:29 PM, vedaal@nym.hush.com wrote: > > But isn't it obvious that the key revocation is a scam, when the time of the revocation and the time of its receipt by a key-server, are too far apart? > (anything more than an hour should be suspicious.) > > The only plausibility Alice may have, is that she couldn't get online soon enough after she revoked her key, > and this is discoverable if she went online for any other reason. > > If there were some way to make the revocation process not be complete until received and verified by a keyserver, > and then listed as revoked as of the keyserver's receipt time, > then it might do away with the 'change the clock and revoke scam' and make revocation more workable. > > > vedaal > Even assuming there were protocol support for this (please correct me if in fact there is), you've also made a great leap in deciding to effectively trust keyservers as timestamping authorities. Keep in mind that this would require changes to the keyserver software; SKS does not have any mechanism I am aware of to make such an assertion. Bear also in mind when thinking about these two points that the lamentable policy of refusing to ever purge data (save once) including key vandalism, fraudulent keys, and similar abuse is traditionally justified by a lack of time to implement support (or by revocation persistence which is a separate issue) even for that. Moreover, most public keyservers are run by volunteers on an at-will basis, and synchronize with varying speeds. Virtually anyone may operate them and there is no standard or process for protecting their security either individually or as a network. Shall each of them keep their own different timestamp for each piece of data? Or shall they trust each other's assertions as to timestamping? Shall new keyservers trust existing timestamps and is this different from the synchronization process? How shall you decide to trust timestamp data, and which copy of it to trust, with respect to edge cases where a timestamp to be verified falls within the delta between any two keyservers' receipt of the timestamped information? What happens when conflicting timestamps are asserted between keyservers? When a timestamp on data from a timestamping keyserver differs from the timestamp in the signed packet (ie. revocation), what else will be trusted? Will the revocation be discarded as fraudulent? If it is, can you assume the key is compromised? If validation succeeds (drift within the threshold), will the timestamper's timestamp, or the timestamp in the data be used? Why is an hour the proper threshold for clock drift? Is it even appropriate to specify maximum drift in the standard? What about keys which are exchanged without a mediating keyserver? How will the protocol work when data is not available? How will existing data without associated timestamps be treated? What about offline verification? Does any problem arise if that data is arbitrarily timestamped with the current time as of a keyserver software update? What happens when timestamp-less data is received during inter-keyserver synchronization? There are other questions that need to be answered as well for such a proposal to work. However, in the signer-agnostic signatures draft this surprisingly complex new logic would be pollution (and totally eclipse the intent of the draft); perhaps you should consider making a proposal of your own if you can answer those questions well. The lack of a useful mechanism for this and other timestamping is indeed a deficiency and there would be some value in developing an appropriate scheme. This has of course been discussed before to some extent (at least https://www.ietf.org/mail-archive/web/openpgp/current/msg07136.html). --Falcon Darkstar Momot From nobody Sun Mar 16 03:15:41 2014 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 678C01A01C5 for ; Sun, 16 Mar 2014 03:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqShKftq1eRm for ; Sun, 16 Mar 2014 03:15:36 -0700 (PDT) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 393991A00C2 for ; Sun, 16 Mar 2014 03:15:36 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id c13so2984085eek.24 for ; Sun, 16 Mar 2014 03:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w9IYtG4S7a6HSG3ln36hss+9XbzOh4cssMsuwYIKJ7c=; b=JsmEFFA4g0qpoGljmDJqSCTNDMfEgrywdzMVtq4z+lI7m3+64V1XBLF9uJZwC0k0Cn e3BiPp474mOu3FO7SeZtSyN0xS+HcSMrSsNTB25Jtg8KhYuMbUL+6eNg2q9BxrQ/P/9/ i3vwqw21ZzGoD86WTa1DWS3AgFSiAUAHudxawRvbH6CwKBxUKBYH31y8+C1oON5WF4eS Qn7c9mZsznrYsrokfVdy7/sQd7AP8sjf2HOWj4mZvB4XeJBVXrjZ//XgKdXK5bQHptzM 7bMS1fOflXa/e8/IEPKPkyQIvV4A2lsS/4DdsH/wolETSV5fEQS10JlWB0QpoEIG6ZMR SDTg== MIME-Version: 1.0 X-Received: by 10.15.65.68 with SMTP id p44mr2437721eex.63.1394964928285; Sun, 16 Mar 2014 03:15:28 -0700 (PDT) Received: by 10.14.80.135 with HTTP; Sun, 16 Mar 2014 03:15:28 -0700 (PDT) In-Reply-To: <78443bf532834a1dfdd4e0c80af2bea3@smtp.hushmail.com> References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <5323146D.4050006@fifthhorseman.net> <5323DF28.5070809@fifthhorseman.net> <029427f6d271b61840ad3f919796c18c@smtp.hushmail.com> <78443bf532834a1dfdd4e0c80af2bea3@smtp.hushmail.com> Date: Sun, 16 Mar 2014 10:15:28 +0000 Message-ID: From: Nicholas Cole To: Vincent Yu Content-Type: multipart/alternative; boundary=001a11c3f3720652d404f4b69555 Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/yLHlf24sggGpqOKWTs--P5JMZAg Cc: "openpgp@ietf.org" Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 16 Mar 2014 10:15:39 -0000 --001a11c3f3720652d404f4b69555 Content-Type: text/plain; charset=ISO-8859-1 On Sunday, 16 March 2014, Vincent Yu wrote: > On 03/15/2014 06:02 PM, Nicholas Cole wrote: > >> >> >> On Saturday, 15 March 2014, Vincent Yu > >> wrote: >> This reminds me that I used the name "signer-ambiguous signature" in >> some of the early drafts of my proposal. This name concisely >> describes the most important property of ring signatures. Now that I >> think about it, that is a much better name than "ring signature" for >> implementations to present to their end users. >> >> "Signer-ambiguity" was coined by Rivest et al. to describe ring >> signatures in their seminal paper in 2001, so it's well-connected to >> the concept of ring signatures in the literature. >> >> Unless there are severe objections, I will modify the proposal to >> use the phrase "signer-ambiguous signature" to refer generally to >> the signatures produced by the scheme, and use "ring signature" only >> as technical term for the specific scheme that was chosen to provide >> signer-ambiguity. >> >> >> I think that is a better name. It gets away from the idea that there is >> a 'ring' of people who have authorized each other to make signatures. >> But still, I think that this proposal will bring more problems than >> benefits. Signatures will appear that 'might' have been made by all >> kinds of people on all kinds of documents. User interfaces will >> struggle to help users to make good decisions as a result. I can't help >> feeling that this kind of signature belongs in very specific >> applications, and not in general purpose tools. But I could be wrong. >> > > I share your concerns, but on the whole, I think it is a net positive to > offer signers the option to create signer-ambiguous signatures. Let me go > into more detail. > > Within benign use cases, there are two sides to signer-ambiguous > signatures: the recipient's side and the signer's side. > > The recipient would generally prefer to receive standard signatures rather > than signer-ambiguous signatures because standard signatures offer stronger > guarantees and grant them the power to prove to others what they received. > However, recipients would prefer to receive signer-ambiguous signatures > rather than no signature. So from the recipient's perspective, > signer-ambiguous signatures can be bad or good, depending on whether the > alternative is a standard signature or no signature. > > However, signer-ambiguous signatures are designed with the signer in mind. > The signer would find signer-ambiguous signatures useful in situations > where they wish to ensure authenticity without granting recipients the > power to transfer their signatures (here, I am considering only two-party > communications; there are potentially other applications of > signer-ambiguous signatures). Signer-ambiguous signatures are always good > from the signer's perspective, because they provide an extra option that > they may choose to use. > > Within malicious use cases, there is the attacker's side. At the end of > the day, a new signature type will indeed create a potential attack vector, > and it is hard to predict exactly what types of attack will become possible > because the details will depend on the interactions between users and > implementations. > > It seems to me that your worries fall mainly within scenarios with an > attacker. Without an attacker, there is little reason to worry about > verifier confusion because the goals of signers coincide with those of > recipients: signatures are a way for signers to provide a guarantee to > recipients. If it turns out that recipients get excessively confused over > signer-ambiguous signatures, then signers will simply decide not to use > them. In the long run, signers will adapt and use signer-ambiguous > signatures only when they judge that the benefits outweigh the potential > confusion. > > So we need only worry about the potential for verifier confusion in > scenarios with an attacker. Here, I think implementations have a good > response available if attacks grow rampant: they simply refuse to verify > signer-ambiguous signatures. Without the cooperation of implementations, > attackers can do no harm. > > That is the worst case scenario. However, I consider it unlikely that > attacks using signer-ambiguous signatures will ever become common enough to > outweigh the benefits to signers. Perhaps our intuitions differ here. > > The main point I wish to reemphasize is that signers are free not to > create signer-ambiguous signatures if they think that the potential for > confusion outweighs the benefits. Their goals are aligned with those of > recipients. > > Vincent > I understand the two use-cases you outline, and why from a signer's point of view the scheme can make sense. But the original paper that introduced this scheme was called, "How to leak a secret". This is a scheme deliberately designed to throw suspicion on to others, so I don't think I'm being too pedantic in insisting on thinking about attackers. The scheme was originally designed so that a staffer in a political organization could leak data to a third party but create doubt about who had done it. I suppose you could argue that we just have to hope that such tools would be used responsibly, or even that such signatures could be created with key material that is already available. I suppose I just get uneasy about a signature scheme that is designed to deliberately throw suspicion on to third parties. Have there been any attacks on the scheme? --001a11c3f3720652d404f4b69555 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sunday, 16 March 2014, Vincent Yu <v@v-yu.com> wrote:
On 03/15/20= 14 06:02 PM, Nicholas Cole wrote:


On Saturday, 15 March 2014, Vincent Yu <v@v-yu.com <mailto:= v@v-yu.com>>
wrote:
=A0 =A0 This reminds me that I used the name "signer-ambiguous signatu= re" in
=A0 =A0 some of the early drafts of my proposal. This name concisely
=A0 =A0 describes the most important property of ring signatures. Now that = I
=A0 =A0 think about it, that is a much better name than "ring signatur= e" for
=A0 =A0 implementations to present to their end users.

=A0 =A0 "Signer-ambiguity" was coined by Rivest et al. to describ= e ring
=A0 =A0 signatures in their seminal paper in 2001, so it's well-connect= ed to
=A0 =A0 the concept of ring signatures in the literature.

=A0 =A0 Unless there are severe objections, I will modify the proposal to =A0 =A0 use the phrase "signer-ambiguous signature" to refer gene= rally to
=A0 =A0 the signatures produced by the scheme, and use "ring signature= " only
=A0 =A0 as technical term for the specific scheme that was chosen to provid= e
=A0 =A0 signer-ambiguity.


I think that is a better name. =A0It gets away from the idea that there is<= br> a 'ring' of people who have authorized each other to make signature= s.
=A0 But still, I think that this proposal will bring more problems than
benefits. =A0Signatures will appear that 'might' have been made by = all
kinds of people on all kinds of documents. =A0User interfaces will
struggle to help users to make good decisions as a result. =A0I can't h= elp
feeling that this kind of signature belongs in very specific
applications, and not in general purpose tools. But I could be wrong.

I share your concerns, but on the whole, I think it is a net positive to of= fer signers the option to create signer-ambiguous signatures. Let me go int= o more detail.

Within benign use cases, there are two sides to signer-ambiguous signatures= : the recipient's side and the signer's side.

The recipient would generally prefer to receive standard signatures rather = than signer-ambiguous signatures because standard signatures offer stronger= guarantees and grant them the power to prove to others what they received.= However, recipients would prefer to receive signer-ambiguous signatures ra= ther than no signature. So from the recipient's perspective, signer-amb= iguous signatures can be bad or good, depending on whether the alternative = is a standard signature or no signature.

However, signer-ambiguous signatures are designed with the signer in mind. = The signer would find signer-ambiguous signatures useful in situations wher= e they wish to ensure authenticity without granting recipients the power to= transfer their signatures (here, I am considering only two-party communica= tions; there are potentially other applications of signer-ambiguous signatu= res). Signer-ambiguous signatures are always good from the signer's per= spective, because they provide an extra option that they may choose to use.=

Within malicious use cases, there is the attacker's side. At the end of= the day, a new signature type will indeed create a potential attack vector= , and it is hard to predict exactly what types of attack will become possib= le because the details will depend on the interactions between users and im= plementations.

It seems to me that your worries fall mainly within scenarios with an attac= ker. Without an attacker, there is little reason to worry about verifier co= nfusion because the goals of signers coincide with those of recipients: sig= natures are a way for signers to provide a guarantee to recipients. If it t= urns out that recipients get excessively confused over signer-ambiguous sig= natures, then signers will simply decide not to use them. In the long run, = signers will adapt and use signer-ambiguous signatures only when they judge= that the benefits outweigh the potential confusion.

So we need only worry about the potential for verifier confusion in scenari= os with an attacker. Here, I think implementations have a good response ava= ilable if attacks grow rampant: they simply refuse to verify signer-ambiguo= us signatures. Without the cooperation of implementations, attackers can do= no harm.

That is the worst case scenario. However, I consider it unlikely that attac= ks using signer-ambiguous signatures will ever become common enough to outw= eigh the benefits to signers. Perhaps our intuitions differ here.

The main point I wish to reemphasize is that signers are free not to create= signer-ambiguous signatures if they think that the potential for confusion= outweighs the benefits. Their goals are aligned with those of recipients.<= br>
Vincent

I understand the two use-cases you outline= , and why from a signer's point of view the scheme can make sense. =A0B= ut the original paper that introduced this scheme=A0was called, "How t= o leak a secret". This is a scheme deliberately designed to throw susp= icion on to others, so I don't think I'm being too pedantic in insi= sting on thinking about attackers. The scheme was originally designed so th= at a staffer in a political organization could leak data to a third party b= ut create doubt about who had done it.

I suppose you could argue that we just have to hope tha= t such tools would be used responsibly, or even that such signatures could = be created with key material that is already available.

I suppose I just get uneasy about a signature scheme that is designed = to deliberately throw suspicion on to third parties.

Have there been any attacks on the scheme?
--001a11c3f3720652d404f4b69555-- From nobody Sun Mar 16 04:56:03 2014 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 1FE511A0104 for ; Sun, 16 Mar 2014 04:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkjFurKyZuUi for ; Sun, 16 Mar 2014 04:56:00 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9491A00FB for ; Sun, 16 Mar 2014 04:55:59 -0700 (PDT) Received: from tormenta.local (www2.futureware.at [78.41.115.142]) by virulha.pair.com (Postfix) with ESMTPSA id 0CBC66D451; Sun, 16 Mar 2014 07:55:48 -0400 (EDT) Message-ID: <53259142.3020101@iang.org> Date: Sun, 16 Mar 2014 11:55:46 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <5323146D.4050006@fifthhorseman.net> <5323DF28.5070809@fifthhorseman.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/j86xx_-SAX7FvX6ioQPk2jcTi0Q Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 16 Mar 2014 11:56:02 -0000 On 15/03/2014 17:47 pm, Jon Callas wrote: > Now on the other hand, ages ago, we discussed ring signatures, and a use case that I wanted to do was to make it so that whenever Alice sends Bob a signed email or other casual message, she would (could?) sign it with a ring signature of her key and Bob's. Bob knows that he didn't sign it so he knows that Alice did. Which might be a nice property, but if it goes further it might be problematic. Where I'm thinking is experiences with the oddly-named OTR, which raises questions on two counts. Firstly, it isn't OTR because it is a protocol, not a record-keeping or securing agent [0]. The protocol instead claims something that we might call "deniability" as in "plausible deniability." Which leads to fubar #2. "Plausible deniability" might work in the movies, but it doesn't work in court, being precisely the place were we might want to be able to claim something didn't happen. Unfortunately, deniability is also the weapon the courts are most used to, and they test for exactly this [1]. In short words, that's their game, and they're daring you to try it... Fubar #3 is that because of the claim of off-the-record and ability to plausibly deny, the presence of the product itself can be evidence against the victim. If for example one were to "plausibly deny" a record or transcript of a chat session, you're already damned by having used the product. > Of course, it's one of those things that are cool, and yet it's hard to say what it actually does to improve anything. Which all is really sad, because other than that, the OTR protocol and system has really filled a gap and been quite successful. With the fall of skype, it's about the only game out there for widespread secure chat. It's just the name and claims that run into unforeseen consequences. Drifting more OT somewhat, what I think is far more useful is disappearing messages. I believe that Snapchat was on the money, because it disappeared the messages & photos, which was much closer to what the user needed. Snapchat is a $16bn lesson to the cryptography industry. Anyway, I'm out west of Tahiti by now... iang [0] The name is less of relevance here, so in footnotes: The record is kept or not kept by the app. It might be that this latter is useful but what is not useful is advertising a property such as "off the record" that the protocol cannot provide, and has no way of knowing if the app provides it or not. [1] For the exact same reason, non-repudiation is a concept that the courts reject in general and in concept. Oops. From nobody Sun Mar 16 13:47:25 2014 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 8BD021A0310 for ; Sun, 16 Mar 2014 13:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 e4pCpmTlyhFZ for ; Sun, 16 Mar 2014 13:47:21 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 865BE1A01F9 for ; Sun, 16 Mar 2014 13:47:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id B4C934F5CB8E; Sun, 16 Mar 2014 13:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gR5aJ8JBzue; Sun, 16 Mar 2014 13:47:13 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 077224F5CB80; Sun, 16 Mar 2014 13:47:11 -0700 (PDT) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Sun, 16 Mar 2014 13:47:13 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Sun, 16 Mar 2014 13:47:13 -0700 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Jon Callas In-Reply-To: Date: Sun, 16 Mar 2014 13:47:10 -0700 Message-Id: <3AE1B152-EDF0-4B40-AD6A-952FB9913238@callas.org> References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <5323146D.4050006@fifthhorseman.net> <5323DF28.5070809@fifthhorseman.net> To: Nicholas Cole X-Mailer: Apple Mail (2.1874) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/jrF5Wjd7TRUwZ4iQ7spa5ar0wM8 Cc: openpgp@ietf.org, Jon Callas Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 16 Mar 2014 20:47:23 -0000 On Mar 15, 2014, at 1:40 PM, Nicholas Cole = wrote: > And thinking about it even further, it compounds a problem that > someone (was it you, Jon?) has written about in the past. Even though > we all know that key UIDs can be signed by complete strangers, users > are *often* disconcerted by this fact (which is why there is a > no-modifier flag, even if keyservers have never respected it and even > if it would make the use of OpenPGP even more complicated). Still, a > naive user of an OpenPGP program may draw incorrect inferences about > social relationships from UID signatures. Imagine the outcry of users > if they discovered that documents were in the wild that 'might' have > been signed by them... Yes, I'm probably the person. I created the no-modify and other = properties of 2440 and 4880 precisely because it was something that I = saw as a barrier to OpenPGP adoption and a personal peeve of mine. = (Also, at an IETF meeting that happened to be on April First, I did an = April Fools OpenPGP presentation where I presented the anti-identity = signature, whereby if enough people over a threshold signed an = anti-identity signature, you'd lose your identity and they could give it = to someone else. That was also an expression of my peeve in this space.) Jon From nobody Mon Mar 17 00:32:00 2014 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 3539D1A006E for ; Mon, 17 Mar 2014 00:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 9O-ZEv_DK9Qc for ; Mon, 17 Mar 2014 00:31:54 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id DA5891A03A0 for ; Mon, 17 Mar 2014 00:31:53 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1WPS1R-0001uK-3U for ; Mon, 17 Mar 2014 08:31:45 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1WPRtm-000859-Fk; Mon, 17 Mar 2014 08:23:50 +0100 From: Werner Koch To: Vincent Yu References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <87y50cybh3.fsf@vigenere.g10code.de> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Mon, 17 Mar 2014 08:23:50 +0100 In-Reply-To: (Vincent Yu's message of "Fri, 14 Mar 2014 18:30:51 -0400") Message-ID: <87mwgpwant.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: http://mailarchive.ietf.org/arch/msg/openpgp/b2-Mn6IFMmxd71CW17e6EnZW3oA Cc: openpgp@ietf.org Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 17 Mar 2014 07:31:56 -0000 On Fri, 14 Mar 2014 23:30, v@v-yu.com said: > Are there any other signature algorithms or schemes that are likely to > appear within the next few years in either OpenPGP or GnuPG? We can't predicts the future. > Right now, my understanding is that RSA, DSA, ECDSA, and EdDSA are the > only signing keys / algorithms. Is this correct? RSA and DSA are specified by RFC-4880. ECDSA is specified by RFC-6637. EdDSA ist not yet specified for OpenPGP (and unfortunately the work on an RFC to describe this algo and other new curves has been deferred). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Mar 17 00:36:57 2014 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 D82511A0124 for ; Mon, 17 Mar 2014 00:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 JF6gbslK3PRO for ; Mon, 17 Mar 2014 00:36:54 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE511A0245 for ; Mon, 17 Mar 2014 00:36:54 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1WPS6I-0001zo-6f for ; Mon, 17 Mar 2014 08:36:46 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1WPRva-00085v-Uy; Mon, 17 Mar 2014 08:25:42 +0100 From: Werner Koch To: Ben Laurie References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <87y50cybh3.fsf@vigenere.g10code.de> <53233BD4.4020804@fifthhorseman.net> <87lhwcy93w.fsf@vigenere.g10code.de> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Mon, 17 Mar 2014 08:25:42 +0100 In-Reply-To: (Ben Laurie's message of "Sat, 15 Mar 2014 09:54:45 +0000") Message-ID: <87iordwakp.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: http://mailarchive.ietf.org/arch/msg/openpgp/UT6EHbu09A8WMpyu1czXmj2te8o Cc: openpgp@ietf.org, Vincent Yu , Daniel Kahn Gillmor Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 17 Mar 2014 07:36:56 -0000 On Sat, 15 Mar 2014 10:54, ben@links.org said: > So if I want to deny that I'm the one that made a ring signature, I > make sure I only use the new s/w for ring signatures. Then probability > says its not me, according to you. Right, you would decrease the probability that you created it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Mar 17 00:43:56 2014 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 B81DB1A03B8 for ; Mon, 17 Mar 2014 00:43:53 -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 wcN7WhLhQv3j for ; Mon, 17 Mar 2014 00:43:52 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 589B61A03B5 for ; Mon, 17 Mar 2014 00:43:51 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id m20so5448849qcx.7 for ; Mon, 17 Mar 2014 00:43:43 -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=/i89jV5aI1UWcBXKl2eahCYSAj/4aeKtD/nZKIoN42Q=; b=VAJD5fClHcXCTbJd6gMdHJQjhqPty9lai2nLZquM3AIL8v07EM02J68euIcuGLALbu Q6Xt87/to6iGW4XPK4U1pAaJdfcYepErwJNl4stpM5WCe8eJhvti9OAHYo0HvN+uRBxb gAmds8+PKUnJddNGVRdV57eOPv8WoBnyJkVCe9f3g0B85+jcBR75wj2vpIv+YuArEruT 3KGHyJBLShddkCzfmbalPbvKA5cUGlmZfiocGltMKLW1WxW/K201s5V7mKh/pviqAme4 V7VE7kmI2ypNUhANiYOMhKJbW+00HwxZqCseEYS0zOvAeylRMei1p2uBZ4gJiUla99g9 2aDQ== MIME-Version: 1.0 X-Received: by 10.229.219.133 with SMTP id hu5mr26508272qcb.5.1395042223365; Mon, 17 Mar 2014 00:43:43 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.96.157.137 with HTTP; Mon, 17 Mar 2014 00:43:42 -0700 (PDT) In-Reply-To: <87iordwakp.fsf@vigenere.g10code.de> References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <87y50cybh3.fsf@vigenere.g10code.de> <53233BD4.4020804@fifthhorseman.net> <87lhwcy93w.fsf@vigenere.g10code.de> <87iordwakp.fsf@vigenere.g10code.de> Date: Mon, 17 Mar 2014 07:43:42 +0000 X-Google-Sender-Auth: xWzFtNIkCRgTA-cOZp0KrEuLuXI Message-ID: From: Ben Laurie To: Werner Koch Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/gUoeqRD9Ehmyy2SRODiR9l27X_M Cc: openpgp@ietf.org, Vincent Yu , Daniel Kahn Gillmor Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 17 Mar 2014 07:43:54 -0000 On 17 March 2014 07:25, Werner Koch wrote: > On Sat, 15 Mar 2014 10:54, ben@links.org said: > >> So if I want to deny that I'm the one that made a ring signature, I >> make sure I only use the new s/w for ring signatures. Then probability >> says its not me, according to you. > > Right, you would decrease the probability that you created it. Clearly not. From nobody Mon Mar 17 03:26:58 2014 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 8000B1A03D6 for ; Mon, 17 Mar 2014 03:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 Rp5abDjfCuns for ; Mon, 17 Mar 2014 03:26:55 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6C61A00A6 for ; Mon, 17 Mar 2014 03:26:55 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1WPUko-0002q5-2g for ; Mon, 17 Mar 2014 11:26:46 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1WPUZy-0000pF-Df; Mon, 17 Mar 2014 11:15:34 +0100 From: Werner Koch To: Ben Laurie References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <87y50cybh3.fsf@vigenere.g10code.de> <53233BD4.4020804@fifthhorseman.net> <87lhwcy93w.fsf@vigenere.g10code.de> <87iordwakp.fsf@vigenere.g10code.de> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Mon, 17 Mar 2014 11:15:34 +0100 In-Reply-To: (Ben Laurie's message of "Mon, 17 Mar 2014 07:43:42 +0000") Message-ID: <87wqftuo55.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: http://mailarchive.ietf.org/arch/msg/openpgp/9Ihk0T_FgqQ1V03ZRVL0ydknOJY Cc: openpgp@ietf.org, Vincent Yu , Daniel Kahn Gillmor Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 17 Mar 2014 10:26:56 -0000 On Mon, 17 Mar 2014 08:43, ben@links.org said: >>> make sure I only use the new s/w for ring signatures. Then probability >>> says its not me, according to you. >> >> Right, you would decrease the probability that you created it. > > Clearly not. I concur and you then disagree? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Mar 17 03:53:22 2014 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 DDAD01A03D7 for ; Mon, 17 Mar 2014 03:53:19 -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 ZAxRTjgWfC8V for ; Mon, 17 Mar 2014 03:53:19 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D17611A03C8 for ; Mon, 17 Mar 2014 03:53:18 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id x13so5668653qcv.33 for ; Mon, 17 Mar 2014 03:53: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=FLkg4F+UxoW5IyVBKaAQq4Cfc0z6lAvIw30P6OKbZSQ=; b=TZWONCG/KO+7oHCDHZG5xjw2I+g0ujNqJrXHIJSdX1/XutEd9p/g3ttXCWQ8MiC2+8 uDIX1pfBYNiJ5C1spFzl1KViRsPoMSfwFqke4wbNYckV2bNA8pTQvGj7JiVUhn0eeUi0 XQWf9/LjcmA9uqjpr2XdIQh1KCQ/ZX5O6lMaoXsD+h+5rZM5LtYvfiJu5hCkupcpYK3/ K8y+KZXbMGZzfAeimlw8AbyrjDOCwKo2jzeOVte6cm42ucabVCKJINMyOTFBgKtJqpkv M2BJhcZ6Wh/5gsHew344M5WJR2A0gxvcVVes2EUlmCKhd/3gPdt4tQ0uK5CwFxLcdrUh iHww== MIME-Version: 1.0 X-Received: by 10.224.147.77 with SMTP id k13mr27219013qav.64.1395053590812; Mon, 17 Mar 2014 03:53:10 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.96.157.137 with HTTP; Mon, 17 Mar 2014 03:53:10 -0700 (PDT) In-Reply-To: <87wqftuo55.fsf@vigenere.g10code.de> References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <87y50cybh3.fsf@vigenere.g10code.de> <53233BD4.4020804@fifthhorseman.net> <87lhwcy93w.fsf@vigenere.g10code.de> <87iordwakp.fsf@vigenere.g10code.de> <87wqftuo55.fsf@vigenere.g10code.de> Date: Mon, 17 Mar 2014 10:53:10 +0000 X-Google-Sender-Auth: _M3ozQasHDtB66cfadSumzSV0wk Message-ID: From: Ben Laurie To: Werner Koch Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/EVEneom9BJ-wvaNTuFBHHn60Lbg Cc: openpgp@ietf.org, Vincent Yu , Daniel Kahn Gillmor Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys 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, 17 Mar 2014 10:53:20 -0000 On 17 March 2014 10:15, Werner Koch wrote: > On Mon, 17 Mar 2014 08:43, ben@links.org said: > >>>> make sure I only use the new s/w for ring signatures. Then probability >>>> says its not me, according to you. >>> >>> Right, you would decrease the probability that you created it. >> >> Clearly not. > > I concur and you then disagree? The probability I created it is 100%, right? That's exactly my point. However, you propose a calculation that makes it _less_ likely that I created than others did. Clearly this calculation is wrong. From nobody Mon Mar 17 08:39:45 2014 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 8E50B1A02FD for ; Mon, 17 Mar 2014 08:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 i-NzTK8TL2wI for ; Mon, 17 Mar 2014 08:39:42 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10.hushmail.com [65.39.178.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4941A02F5 for ; Mon, 17 Mar 2014 08:39:42 -0700 (PDT) Received: from smtp10.hushmail.com (localhost [127.0.0.1]) by smtp10.hushmail.com (Postfix) with SMTP id A4611C014A for ; Mon, 17 Mar 2014 15:39:34 +0000 (UTC) Received: from smtp.hushmail.com (w7.hushmail.com [65.39.178.32]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp10.hushmail.com (Postfix) with ESMTPS for ; Mon, 17 Mar 2014 15:39:34 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 69A37206F2; Mon, 17 Mar 2014 15:39:34 +0000 (UTC) MIME-Version: 1.0 Date: Mon, 17 Mar 2014 11:39:33 -0400 To: openpgp@ietf.org From: vedaal@nym.hush.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20140317153934.69A37206F2@smtp.hushmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/FtZeHRXbfGX_ntLjtpPHNrwVTS4 Subject: [openpgp] signer-agnostic signatures 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, 17 Mar 2014 15:39:43 -0000 Instead of multiple users sharing a key, what if they just shared the passphrase, and the signature done with a passphrase string-to key as in conventional encryption, rather than with an actual key? The passphrase could be changed regularly and put up as a webpage or post, that was simultaneously encrypted to different users' public keys. This way, there would be no revocation issues, as a revoked key could still be used for decryption, and so, some form of repudiable signatures could be achieved. vedaal From nobody Tue Mar 18 09:00:50 2014 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 EA4081A06FB for ; Tue, 18 Mar 2014 09:00:43 -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, 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 6wAUZyiFZ0Yn for ; Tue, 18 Mar 2014 09:00:41 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCF41A0703 for ; Tue, 18 Mar 2014 09:00:37 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id h16so1940096oag.36 for ; Tue, 18 Mar 2014 09:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=RTz0701QpKItpjaZA3L4XiWeW+NQsX82gyidlNBBsPo=; b=KYvxg0cbvH85Wl6DBzSEgXxaulpXOqoIQtdLMXOo7gE3nodEv1uicbUUaQWXThKTHX 4iE8hyJNlD++jGbs4umfNCzPAXssIGrJXZCwdLF0CFvQqALXIge+AFN34mQmCZ/ntbhr cvNWoHClKEYIIcQZVALvK9grZotoTaOQ1evhc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=RTz0701QpKItpjaZA3L4XiWeW+NQsX82gyidlNBBsPo=; b=Tq67Z6cKM8XIzkXvCscnBoK6cNWiFKOKGAJZkZPT4p763mTwsj/B7jQTKITsROGGzO JHzC7ovNggpfmsEfeKLsUjr8viuMHJbqU3acONBKi1L/BQaCKDNiswZ8Kp4cx0yqbBE5 bR8hPYbfEMSReG9Vtrk9JVTRV0Xgoew4xeEJdLQRQloZVrmhL4yIF2uZPeTCvYD4Lfer Ym+J6JCsXOxkiDJn82pBTPojNqh8SkBZ21n9O9mjxqdELx96BSGvfv2q3ioxwplRezA4 q7cuyrlhlky6BPcSmdz7ZF3FycZFBwQFCHAwe33en/JoYfESKd7MYGcjrSDMnZQHBjgf ru3w== X-Gm-Message-State: ALoCoQkNLHMLEUbpqeu6vt7WneZQRksQ6HlJ9duxiSbZcjveoC3xAarK04jo8evU0N2pNCeGCf1i MIME-Version: 1.0 X-Received: by 10.182.28.7 with SMTP id x7mr854609obg.43.1395158429381; Tue, 18 Mar 2014 09:00:29 -0700 (PDT) Sender: alfredo@pironti.eu Received: by 10.76.151.35 with HTTP; Tue, 18 Mar 2014 09:00:29 -0700 (PDT) X-Originating-IP: [128.93.161.197] Date: Tue, 18 Mar 2014 17:00:29 +0100 X-Google-Sender-Auth: xadhrMVvtuCDzhbuVteSy6-fMWw Message-ID: From: Alfredo Pironti To: openpgp@ietf.org Content-Type: multipart/alternative; boundary=089e015380ba96ccf304f4e3a23d Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/34SnYliCeRUml8yaBuAn7MHMV84 Subject: [openpgp] Disabling compression in OpenPGP 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, 18 Mar 2014 16:00:44 -0000 --089e015380ba96ccf304f4e3a23d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear list, It is well known that compressing data before encrypting them leaks much about the plaintext [1]. Recently, this has been exploited against the TLS protocol in the so-called CRIME attack [2]. Looking at RFC 4880, section 2.3, I read =E2=80=9COpenPGP implementations SHOULD compress the message after applying= the signature but before encryption.=E2=80=9D And indeed, gpg faithfully follows the spec by enabling compression by default. I have done some preliminary work on password managers that rely on OpenPGP (gpg, in fact) to encrypt the passwords. Unsurprisingly, it turns out that compressing the password before encrypting it leaks much of the password entropy, making dictionary attacks significantly easier to mount. (In my preliminary experiments I used a password dictionary containing about 4 million passwords. If the attacker knows the original password length and its compressed length, then for some combinations of the two the candidate dictionary entries can reduce to as few as some hundreds.) I believe similar attacks can be mounted in different contexts where OpenPGP is used. Hence, I propose to start discussion to amend RFC 4880 to at least discourage (if not forbid) the use of compression. I welcome comments and suggestions. Alfredo Pironti [1] Kelsey, J.: Compression and information leakage of plaintext. In: Fast Software Encryption. pp. 263=E2=80=93276 (2002) [2] See, e.g.: http://en.wikipedia.org/wiki/CRIME_%28security_exploit%29 --089e015380ba96ccf304f4e3a23d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear list,

It is well known that compressing data b= efore encrypting them leaks much about the plaintext [1]. Recently, this ha= s been exploited against the TLS protocol in the so-called CRIME attack [2]= .

Looking at RFC 4880, section 2.3, I read
=E2=80=9COpenPGP implementa= tions SHOULD compress the message after applying the signature but before e= ncryption.=E2=80=9D
And indeed, gpg faithfully follows the spec by enabl= ing compression by default.

I have done some preliminary work on password managers that rely on Ope= nPGP (gpg, in fact) to encrypt the passwords. Unsurprisingly, it turns out = that compressing the password before encrypting it leaks much of the passwo= rd entropy, making dictionary attacks significantly easier to mount. (In my= preliminary experiments I used a password dictionary containing about 4 mi= llion passwords. If the attacker knows the original password length and its= compressed length, then for some combinations of the two the candidate dic= tionary entries can reduce to as few as some hundreds.)

I believe similar attacks can be mounted in different contexts where Op= enPGP is used. Hence, I propose to start discussion to amend RFC 4880 to at= least discourage (if not forbid) the use of compression.

I welcome = comments and suggestions.
Alfredo Pironti

[1] Kelsey, J.: Compression and information leakage = of plaintext. In: Fast Software Encryption. pp. 263=E2=80=93276 (2002)
[= 2] See, e.g.: http://en.wikipedia.org/wiki/CRIME_%28security_exploit%29
--089e015380ba96ccf304f4e3a23d-- From nobody Tue Mar 18 09:08:14 2014 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 E70011A041D for ; Tue, 18 Mar 2014 09:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPjuv0KZEkKP for ; Tue, 18 Mar 2014 09:08:07 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9FC1A02F5 for ; Tue, 18 Mar 2014 09:07:53 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id c11so4986685lbj.12 for ; Tue, 18 Mar 2014 09:07:44 -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=v+jUwAUkhxNsJ44hg7EDBJeI+XTaY8O3e9rOUWvoNc8=; b=WnYMBjgAtWeFUYiKDlHlxtRW6NhWrqr5sDPWEslNq6AEk6VQQHyYez7MqweGix2aC0 7RjazUEsL+mIEy5x4xSIKpfMTLTg1Loel2JJ1UnVBKsa57UpH3FBOGJE+GmofIT4Owe9 P/38PfGGH8kVvNZXrPbwctQJqz3lgkt1DPDsyG/WUqH9jTTjM3NOhJBhyqIS1B4kBoQD g686tXQPCgYUo/FCyqAUI8AL/kWMpLW5JrBgugU7sq5IrenDWH9VCPlxKOOE3JoQKx6N UWnb177hZM+eXXsifImyQsu+gWX3Um71ab6EEsan29frW51XdlYlXYcoQeQ0brDsJs8a IFQQ== MIME-Version: 1.0 X-Received: by 10.112.254.163 with SMTP id aj3mr20752591lbd.20.1395158864415; Tue, 18 Mar 2014 09:07:44 -0700 (PDT) Received: by 10.112.184.226 with HTTP; Tue, 18 Mar 2014 09:07:44 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Mar 2014 09:07:44 -0700 Message-ID: From: Gregory Maxwell To: Alfredo Pironti Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/rG-X9rp2jlbyACoosnbxRXjCeys Cc: openpgp@ietf.org Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 18 Mar 2014 16:08:10 -0000 On Tue, Mar 18, 2014 at 9:00 AM, Alfredo Pironti wrote: > I believe similar attacks can be mounted in different contexts where OpenPGP > is used. Hence, I propose to start discussion to amend RFC 4880 to at least > discourage (if not forbid) the use of compression. OpenPGP compression (well, the unawareness there-of) compromised the privacy of the Wikimedia Foundation board election a couple years ago. Users publically submitted ballots encrypted to the election officials, the ballots were constant length but the compression trivially revealed information about their content. If it isn't disabled it may be useful to quantize the size somewhat for a minor overhead in order to reduce the information leak somewhat. From nobody Tue Mar 18 09:52:37 2014 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 5E5FA1A0724 for ; Tue, 18 Mar 2014 09:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Cbi1W9tXmbi for ; Tue, 18 Mar 2014 09:48:39 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 112F91A06FC for ; Tue, 18 Mar 2014 09:48:38 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id s2IGmOqB018989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Mar 2014 17:48:27 +0100 From: Simon Josefsson To: Gregory Maxwell References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:140318:openpgp@ietf.org::CTzSLGsHz4L1+D5t:H5+1 X-Hashcash: 1:22:140318:gmaxwell@gmail.com::oR87WCpcUHlWNjxH:Jnyn X-Hashcash: 1:22:140318:alfredo.pironti@inria.fr::V11ems8i1JtQz3uB:sP44 Date: Tue, 18 Mar 2014 17:48:24 +0100 In-Reply-To: (Gregory Maxwell's message of "Tue, 18 Mar 2014 09:07:44 -0700") Message-ID: <87wqfre9lz.fsf@latte.josefsson.org> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.98.1 at duva.sjd.se X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/mxsOENo_yPOseLbHwBteT_c8QKs X-Mailman-Approved-At: Tue, 18 Mar 2014 09:52:29 -0700 Cc: openpgp@ietf.org, Alfredo Pironti Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 18 Mar 2014 16:48:41 -0000 Gregory Maxwell writes: > On Tue, Mar 18, 2014 at 9:00 AM, Alfredo Pironti > wrote: >> I believe similar attacks can be mounted in different contexts where OpenPGP >> is used. Hence, I propose to start discussion to amend RFC 4880 to at least >> discourage (if not forbid) the use of compression. > > OpenPGP compression (well, the unawareness there-of) compromised the privacy > of the Wikimedia Foundation board election a couple years ago. Users publically > submitted ballots encrypted to the election officials, the ballots > were constant length > but the compression trivially revealed information about their content. > > If it isn't disabled it may be useful to quantize the size somewhat > for a minor overhead > in order to reduce the information leak somewhat. TLS allow implementations to randomly pad messages to mitigate these attacks, could something similar be what OpenPGP needs? /Simon From nobody Tue Mar 18 11:10:04 2014 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 9CF911A074D for ; Tue, 18 Mar 2014 11:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 NyA4g64LAqZu for ; Tue, 18 Mar 2014 11:08:50 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A2EEA1A0757 for ; Tue, 18 Mar 2014 11:08:03 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id wo20so7243379obc.19 for ; Tue, 18 Mar 2014 11:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=g1lvzgqcRo0UoZkceWoV4LgQJ5zmkepKk+isQAtyaCY=; b=hCOBH4TXt1gb2oBoKedGQvRFL3j28ORbwufrC8f2AYOWkzLEHrgNKXQz4/ieH1Qj0N H28lgTpAv0G7sNjSCnCJoBci9sM1h+LEVsJovbE+k9/O7FmUE2OBNaGsgg58yDcy9xW1 IIdWWZDmG3J+1gAlWejTLpPc4jsb843GJhgq4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=g1lvzgqcRo0UoZkceWoV4LgQJ5zmkepKk+isQAtyaCY=; b=QRkiWC7QLgRICIJPUDp7QnIKvafhmGueM9deIZRa/dpY5vdWpf9W/pV10kIsyESKhk 5i+TNommboPP5muRnBoQnHPTcVwpYvsUuO3QqYKcHK4KW0lIOARI+4dAmH2BZM3S22a4 ZZqLeK4uGcPu+TDreKAJ/KNjnLZVLG0i/jOsYmKGmXvMrw5RUnE+VxGZQzx0xr1Sd7h8 vGeRxHE1aOHJQk8Thdy2LCRePK2pXRcb/LAhBdEg+c3VliWXaNqSfOtZgF7kuf9Yrkgz g0bzCxyFl/peKZE973elomRWTeyxpXWZGtKwFmYy7Okz6OUfxKt2zXyRRwylbyG8r428 d68Q== X-Gm-Message-State: ALoCoQmA7wZCWQPMdoNfHI8m9ZNokeabdFt9qz8jzXTNU8l887q94+kn88dOhBEzotMzJmsRd0ca MIME-Version: 1.0 X-Received: by 10.182.102.134 with SMTP id fo6mr25298019obb.10.1395166075008; Tue, 18 Mar 2014 11:07:55 -0700 (PDT) Sender: alfredo@pironti.eu Received: by 10.76.151.35 with HTTP; Tue, 18 Mar 2014 11:07:54 -0700 (PDT) X-Originating-IP: [128.93.161.197] In-Reply-To: <87wqfre9lz.fsf@latte.josefsson.org> References: <87wqfre9lz.fsf@latte.josefsson.org> Date: Tue, 18 Mar 2014 19:07:54 +0100 X-Google-Sender-Auth: 2JCrMSnNF-ckJBsTn_CidDec6ws Message-ID: From: Alfredo Pironti To: Simon Josefsson Content-Type: multipart/alternative; boundary=089e0149c3804dced004f4e56a17 Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/cfOAhtkt0hB2gfEMsDlHsJczT9Q Cc: Gregory Maxwell , openpgp@ietf.org Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 18 Mar 2014 18:09:19 -0000 --089e0149c3804dced004f4e56a17 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 18, 2014 at 5:48 PM, Simon Josefsson wrote: > Gregory Maxwell writes: > > > On Tue, Mar 18, 2014 at 9:00 AM, Alfredo Pironti > > wrote: > >> I believe similar attacks can be mounted in different contexts where > OpenPGP > >> is used. Hence, I propose to start discussion to amend RFC 4880 to at > least > >> discourage (if not forbid) the use of compression. > > > > OpenPGP compression (well, the unawareness there-of) compromised the > privacy > > of the Wikimedia Foundation board election a couple years ago. Users > publically > > submitted ballots encrypted to the election officials, the ballots > > were constant length > > but the compression trivially revealed information about their content. > > > > If it isn't disabled it may be useful to quantize the size somewhat > > for a minor overhead > > in order to reduce the information leak somewhat. > Deterministic quantization may do in principle, but it seems to me harder to deploy than just disabling compression, because of backward compatibility issues and unpredictable compression ratio. Looking at TLS, in practice compression has been disabled everywhere (with a proposal of completely removing it in TLS 1.3), and it seems not have had particularly negative effects. > > TLS allow implementations to randomly pad messages to mitigate these > attacks, could something similar be what OpenPGP needs? > I'd refrain to use random padding, because it does not protect against repeated sampling: if you encrypt the same plaintext (say, a password) over and over, the shortest encrypted message will soon give you a hint of the plaintext length [1]. Alfredo > > /Simon > [1] http://hal.inria.fr/hal-00732449 --089e0149c3804dced004f4e56a17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 18, 2014 at 5:48 PM, Simon Josefsson <simon@josefsson.org> wrote:
Gregory Maxwell= <gmaxwell@gmail= .com> writes:

> On Tue, Mar 18, 2014 at 9:00 AM, Alfredo Pironti
> <alfr= edo.pironti@inria.fr> wrote:
>> I believe similar attacks can be mounted in different contexts whe= re OpenPGP
>> is used. Hence, I propose to start discussion to amend RFC 4880 to= at least
>> discourage (if not forbid) the use of compression.
>
> OpenPGP compression (well, the unawareness there-of) compromised the p= rivacy
> of the Wikimedia Foundation board election a couple years ago. =C2=A0U= sers publically
> submitted ballots encrypted to the election officials, the ballots
> were constant length
> but the compression trivially revealed information about their content= .
>
> If it isn't disabled it may be useful to quantize the size somewha= t
> for a minor overhead
> in order to reduce the information leak somewhat.

Deterministic quantization may do in principle,= but it seems to me harder to deploy than just disabling compression, becau= se of backward compatibility issues and unpredictable compression ratio.
Looking at TLS, in practice compression has been disabled ev= erywhere (with a proposal of completely removing it in TLS 1.3), and it see= ms not have had particularly negative effects.
=C2=A0

TLS allow implementations to randomly pad messages to mitigate = these
attacks, could something similar be what OpenPGP needs?

I'd refrain to use random padding, because it does not= protect against repeated sampling: if you encrypt the same plaintext (say,= a password) over and over, the shortest encrypted message will soon give y= ou a hint of the plaintext length [1].

Alfredo
=C2=A0

/Simon

[1] http://hal.inria.fr/hal-00732449
= --089e0149c3804dced004f4e56a17-- From nobody Tue Mar 18 11:19:54 2014 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 BF38C1A044F for ; Tue, 18 Mar 2014 11:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ooGreNcuRXew for ; Tue, 18 Mar 2014 11:19:40 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 6994B1A0453 for ; Tue, 18 Mar 2014 11:15:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id E97044F84D50; Tue, 18 Mar 2014 11:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ct4JlXyTHqSF; Tue, 18 Mar 2014 11:15:14 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id D5FB64F84D3E; Tue, 18 Mar 2014 11:15:12 -0700 (PDT) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Tue, 18 Mar 2014 11:15:14 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 18 Mar 2014 11:15:14 -0700 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Jon Callas In-Reply-To: Date: Tue, 18 Mar 2014 11:15:11 -0700 Message-Id: <0AB5C684-6F51-48BD-9FF3-8810981F8C31@callas.org> References: To: Alfredo Pironti X-Mailer: Apple Mail (2.1874) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/Vf-Pl9XQ5V_pSPujfNyVWFaymsU Cc: openpgp@ietf.org, Jon Callas Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 18 Mar 2014 18:19:48 -0000 On Mar 18, 2014, at 9:00 AM, Alfredo Pironti = wrote: > Dear list, >=20 > It is well known that compressing data before encrypting them leaks = much about the plaintext [1]. Recently, this has been exploited against = the TLS protocol in the so-called CRIME attack [2]. >=20 > Looking at RFC 4880, section 2.3, I read > =93OpenPGP implementations SHOULD compress the message after applying = the signature but before encryption.=94 > And indeed, gpg faithfully follows the spec by enabling compression by = default. >=20 > I have done some preliminary work on password managers that rely on = OpenPGP (gpg, in fact) to encrypt the passwords. Unsurprisingly, it = turns out that compressing the password before encrypting it leaks much = of the password entropy, making dictionary attacks significantly easier = to mount. (In my preliminary experiments I used a password dictionary = containing about 4 million passwords. If the attacker knows the original = password length and its compressed length, then for some combinations of = the two the candidate dictionary entries can reduce to as few as some = hundreds.) >=20 > I believe similar attacks can be mounted in different contexts where = OpenPGP is used. Hence, I propose to start discussion to amend RFC 4880 = to at least discourage (if not forbid) the use of compression. >=20 > I welcome comments and suggestions. > Alfredo Pironti I think you're confusing a number of things, as well as cherry picking = your data. On the other side, there's the Katz-Schneier attack (which is more of a = CFB attack than OpenPGP per se) that is essentially thwarted by = compression. There are other attacks where compressing helps because it = obscures plaintext. I'm eliding much, so go look at it. OpenPGP is in general not an interactive or on-line protocol, and there = are all sorts of attacks that are easy against interactive or on-line = attacks and not against off-line. CRIME is one of them -- it exploits = the interactive nature of TLS and makes repeated connections to learn = something about the plaintext. It isn't the *compression* that does it, = it's deltas between similar requests. You don't get to do that with = OpenPGP. Note also that there are two easy mitigations against CRIME -- = one is to disable compression and other other is to restrict the = interactivity of the attack. Similarly, most side-channel attacks aren't possible when all you have = is ciphertext and you're attacking it yourself. TLS is an on-line = protocol and there are many, many attacks against it that simply don't = apply to blob encryption, which is what OpenPGP is. There are a number of compression oracles that exist because of = carelessness. Kelsey's paper that you quote is a fantastic paper because = it flew in the face of the naive belief that compression was always good = (on the grounds that it makes the plaintext less predictable). = Compression is *often* good for that very reason. Compression is = sometimes bad. Asserting that because compression is sometimes bad, it = must always be bad is stretching the point, in my opinion. If you believe that there are attacks that can be mounted OpenPGP = because of, find one. You'll have a great paper. Even better, come up with a generalized attack. Here's a framework that = you can use: OpenPGP is mostly bulk CFB encryption of a data blob. There are headers = and stuff (which could make it easier or harder depending on data = leaks), but at the core of the protocol, it's just CFB. OpenPGP = compression is mostly ZIP or GZIP compression. Again, there are details = with headers. In this case, the header issue might be significant, as = OpenPGP often deletes some normal ZIP headers which could be used as = known plaintext. Nonetheless, here's where you should put your efforts: * Take a file or other data blob. Call it P (for plaintext).=20 * Compress P with ZIP or GZIP or even BZIP. Call that Z (for zip). * Encrypt that with a simple CFB encryptor using some key K and some = suitable cipher; I'd pick AES. Call that C (for ciphertext). * Use comparisons between P, Z, and C to mount an attack on K -- giving = a key-recovery attack. Or bypass the key and cipher and use knowledge = about fragments of P and Z to undo pieces of C -- which would be some = form of known plaintext attack. etc. This gives a simplified model of what's going on inside OpenPGP, and = might be easier to work with. Note, however, that OpenPGP typically = throws away Z -- it's computed as an intermediate value and discarded. = So it's conceivable that there's an attack that's possible but hard to = mount. Alternatively, you could use compression options in the gpg command line = to get ciphertext of compressed and uncompressed outputs and do the same = thing. You describe an interesting case where there's a structured file of = passwords. You could look at cases where the attacker would have = knowledge of the plaintext or parts of it in varying ways. For example, = it could be a sorted file, or it could contain all N-character passwords = in a group (that might be itself sorted) and so on.=20 You could also devise interactive and non-interactive versions of your = attack. Note that the non-interactive ones are more interesting, of = course.=20 I hope this helps. Jon From nobody Tue Mar 18 11:29:38 2014 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 B82A71A03F6 for ; Tue, 18 Mar 2014 11:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 wxuRogPvMUfz for ; Tue, 18 Mar 2014 11:29:33 -0700 (PDT) Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2211A0401 for ; Tue, 18 Mar 2014 11:29:33 -0700 (PDT) Received: from dshaw.nasuni.net (vpn.nasuni.com [173.166.63.186]) (authenticated bits=0) by walrus.jabberwocky.com (8.14.4/8.14.4) with ESMTP id s2IITN37020372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Mar 2014 14:29:24 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: David Shaw In-Reply-To: Date: Tue, 18 Mar 2014 14:29:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> References: To: Alfredo Pironti X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/CCEGnIr6kpVRkdkNSKAUU5Bo4z8 Cc: openpgp@ietf.org Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 18 Mar 2014 18:29:37 -0000 On Mar 18, 2014, at 12:00 PM, Alfredo Pironti = wrote: > Dear list, >=20 > It is well known that compressing data before encrypting them leaks = much about the plaintext [1]. Recently, this has been exploited against = the TLS protocol in the so-called CRIME attack [2]. >=20 > Looking at RFC 4880, section 2.3, I read > =93OpenPGP implementations SHOULD compress the message after applying = the signature but before encryption.=94 > And indeed, gpg faithfully follows the spec by enabling compression by = default. >=20 > I have done some preliminary work on password managers that rely on = OpenPGP (gpg, in fact) to encrypt the passwords. Unsurprisingly, it = turns out that compressing the password before encrypting it leaks much = of the password entropy, making dictionary attacks significantly easier = to mount. (In my preliminary experiments I used a password dictionary = containing about 4 million passwords. If the attacker knows the original = password length and its compressed length, then for some combinations of = the two the candidate dictionary entries can reduce to as few as some = hundreds.) >=20 > I believe similar attacks can be mounted in different contexts where = OpenPGP is used. Hence, I propose to start discussion to amend RFC 4880 = to at least discourage (if not forbid) the use of compression. It is not my intent to make light of your email, but I'm somewhat amused = as a few years ago there was an attack that could be *avoided* by = compression. See https://www.schneier.com/paper-pgp.pdf for the = details. Damned if you do, damned if you don't? Note that the use of compression in OpenPGP (at least in the public key = context) is under the control of the recipient. If a given recipient = doesn't want compression used on messages to their key, they can set a = preference reflecting that, and all OpenPGP implementations will not = compress when encrypting a message to that key. David From nobody Tue Mar 18 12:10:09 2014 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 00E5B1A0455 for ; Tue, 18 Mar 2014 12:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 o4OH6BOXSpq1 for ; Tue, 18 Mar 2014 12:10:06 -0700 (PDT) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:243]) by ietfa.amsl.com (Postfix) with ESMTP id 984E11A044C for ; Tue, 18 Mar 2014 12:10:06 -0700 (PDT) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta13.emeryville.ca.mail.comcast.net with comcast id f1dj1n0031vN32cAD79ywb; Tue, 18 Mar 2014 19:09:58 +0000 Received: from [127.0.0.1] ([71.202.164.227]) by omta22.emeryville.ca.mail.comcast.net with comcast id f79t1n00Y4uhcbK8i79vLw; Tue, 18 Mar 2014 19:09:58 +0000 Message-ID: <532899EA.6070006@brainhub.org> Date: Tue, 18 Mar 2014 12:09:30 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: openpgp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1395169798; bh=mAOvqeZFOaLfhPdpatxTcr07Ub/3bYVhkuydjmUTfc4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gCvdXXLv0tj6TYN378p5/0YIXITyREsMf6ubN6rhnxuLM9uRaEsdnHxKObzExi/TQ rxdOL0eVHzSoPSYM7j9MdQGisLN2WxiSKnPocVCnW5cg1G2GERAU7Dc9OOPOyXjHFM iotl5Ti7mz76icrH2TcxvPdC+hav/hV9WgWng0wOq0lAwgekrWC4R4pyT5zunvn75N AaBnMjMLE3TPZ/sBdGZPqpMjyKFtaNRN3z0JgCvXE9WSCFDNOxy/Z67OTkJaLPr+h0 WJn8PLVfJfhc9w4h60pL/8Bxfwo8VkChX2NYWC76hxV11XjdtxAdqf7V6Zg2Im95h+ c4W1xXsrjUEJQ== Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/U2mYovSEZUbB83K-V7hPgZtHhFk Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 18 Mar 2014 19:10:08 -0000 On 03/18/2014 09:00 AM, Alfredo Pironti wrote: > > I have done some preliminary work on password managers that rely on > OpenPGP (gpg, in fact) to encrypt the passwords. Unsurprisingly, it > turns out that compressing the password before encrypting it leaks much > of the password entropy, making dictionary attacks significantly easier > to mount. (In my preliminary experiments I used a password dictionary > containing about 4 million passwords. If the attacker knows the original > password length and its compressed length, then for some combinations of > the two the candidate dictionary entries can reduce to as few as some > hundreds.) I wonder why the additional piece of information is available, which is that both the length of the original password and the length of the compressed one is available from a ciphertext that is an encrypted password. Wouldn't only one of these sizes be provided through the size of the ciphertext? When you build a dictionary with 4 million passwords, you can index it by the password length or by password's compressed length. It's true that OpenPGP CFB format will leak the size either of the plaintext or of the compressed plaintext (so perhaps higher-level padding is the right thing to do in cases like these). Narrowing down the choices by the size of the password v.s. the size of the compressed password seems equivalent regarding the password recovery attack. I do see that if we can narrow down the choices by two sizes simultaneously, this will indeed narrow down the possibilities further. However, it's unclear how both sizes are obtained from a single ciphertext. From nobody Wed Mar 19 08:26:18 2014 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 DE3F31A0781 for ; Wed, 19 Mar 2014 08:26:16 -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, 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 5EUWXdUjCnUT for ; Wed, 19 Mar 2014 08:26:14 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF041A077B for ; Wed, 19 Mar 2014 08:26:14 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id wn1so8303918obc.16 for ; Wed, 19 Mar 2014 08:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=eypmjrWyRGu6cWHdJw1ODTQJFlAM1WH6VKYAC2SYJXw=; b=YUcykEyyP2W9I+NSDNLTMIe/pe/h80LQN6Hqy87saMOqyd1poVXH0Q0AdZvuUGUWYc /19VJpksFY9tGr6LW3bkeOFEmfQ//SNKSACY+oiWLTavOeXO8IdxHnfNh5LKVBHVONLs 14t1nODhLKTiWPwyj996vfkGKb1L2bMOFrf/A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eypmjrWyRGu6cWHdJw1ODTQJFlAM1WH6VKYAC2SYJXw=; b=BH4Uf6dJGpFMMNyrSUJN473BCOURYB2zUf6FxE1jI9At1IznVu4dBtvmj+g0IcNXrm zpztGgxIuk7FxPK9z1DHdxBJFBD2iS1ZU+9NQ3rTjEZSIs8Bts63x/1NhOThA34YearN VoHy2INmJZwGfcAnv3hccgZWRBH18e/PWcbL7BrO3gsnTIYdWCZDiYUIdfWb5H2yA+6+ GluAoG5QUlNEvxpLpzf8k19S3TFqtEp+FoG9l6rbNLkKOGauj+w2YMVZ/MZ/T4nxdG/T SqeNhYxvjm06CtPJ+cv3OsQbWey+TMiz1QBupkOKGqyaB51Xw/TUbBa/XA5Vc0lWdxQT sW4Q== X-Gm-Message-State: ALoCoQnFRcprapnBLERfwYQCJtfVSvtHCmlqpA3R0SpQ0xsGFkIyqyWjDWbByYHYbOmcO/61TNxW MIME-Version: 1.0 X-Received: by 10.60.246.165 with SMTP id xx5mr618546oec.84.1395242765189; Wed, 19 Mar 2014 08:26:05 -0700 (PDT) Sender: alfredo@pironti.eu Received: by 10.76.151.35 with HTTP; Wed, 19 Mar 2014 08:26:05 -0700 (PDT) X-Originating-IP: [128.93.188.195] In-Reply-To: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> References: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> Date: Wed, 19 Mar 2014 16:26:05 +0100 X-Google-Sender-Auth: rHo3xdJLmUJkCg-HBm6aR1gj3pM Message-ID: From: Alfredo Pironti To: David Shaw Content-Type: multipart/alternative; boundary=001a1136989865ce8704f4f74524 Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/Q0qWHBGm6Qt85PSkDupC6ZyEVeQ Cc: openpgp@ietf.org Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 19 Mar 2014 15:26:17 -0000 --001a1136989865ce8704f4f74524 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 18, 2014 at 7:29 PM, David Shaw wrote: > On Mar 18, 2014, at 12:00 PM, Alfredo Pironti > wrote: > > > Dear list, > > > > It is well known that compressing data before encrypting them leaks muc= h > about the plaintext [1]. Recently, this has been exploited against the TL= S > protocol in the so-called CRIME attack [2]. > > > > Looking at RFC 4880, section 2.3, I read > > =E2=80=9COpenPGP implementations SHOULD compress the message after appl= ying the > signature but before encryption.=E2=80=9D > > And indeed, gpg faithfully follows the spec by enabling compression by > default. > > > > I have done some preliminary work on password managers that rely on > OpenPGP (gpg, in fact) to encrypt the passwords. Unsurprisingly, it turns > out that compressing the password before encrypting it leaks much of the > password entropy, making dictionary attacks significantly easier to mount= . > (In my preliminary experiments I used a password dictionary containing > about 4 million passwords. If the attacker knows the original password > length and its compressed length, then for some combinations of the two t= he > candidate dictionary entries can reduce to as few as some hundreds.) > > > > I believe similar attacks can be mounted in different contexts where > OpenPGP is used. Hence, I propose to start discussion to amend RFC 4880 t= o > at least discourage (if not forbid) the use of compression. > > It is not my intent to make light of your email, but I'm somewhat amused > as a few years ago there was an attack that could be *avoided* by > compression. See https://www.schneier.com/paper-pgp.pdf for the details. > Damned if you do, damned if you don't? > In that case, compression incidentally thwarted the attack, by inserting additional packet headers in the encrypted packets, hence letting some parsing fail when decrypting a chosen ciphertext. In general, I see two patterns: - Compression incidentally thwarts some attacks - Compression fundamentally breaks privacy by leaking plaintext entropy (see the Wikimedia Foundation case for a quite convincing example) I would not want to rely on the obfuscation provided by an optional feature of OpenPGP to ensure secrecy. If a decryption oracle is found, it should be systematically fixed -- also for users who decide not to use compression. On the other hand, at least making compression disabled by default would protect those users who are unaware of the interaction between compression and encryption. Those who are aware of it could always explicitly enable compression. Cheers, Alfredo > > Note that the use of compression in OpenPGP (at least in the public key > context) is under the control of the recipient. If a given recipient > doesn't want compression used on messages to their key, they can set a > preference reflecting that, and all OpenPGP implementations will not > compress when encrypting a message to that key. > > David > > --001a1136989865ce8704f4f74524 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Mar 18, 2014 at 7:29 PM, David Shaw <<= a href=3D"mailto:dshaw@jabberwocky.com" target=3D"_blank">dshaw@jabberwocky= .com> wrote:
On Mar 18, 2014, at 12:00 PM= , Alfredo Pironti <alfredo.p= ironti@inria.fr> wrote:

> Dear list,
>
> It is well known that compressing data before encrypting them leaks mu= ch about the plaintext [1]. Recently, this has been exploited against the T= LS protocol in the so-called CRIME attack [2].
>
> Looking at RFC 4880, section 2.3, I read
> =E2=80=9COpenPGP implementations SHOULD compress the message after app= lying the signature but before encryption.=E2=80=9D
> And indeed, gpg faithfully follows the spec by enabling compression by= default.
>
> I have done some preliminary work on password managers that rely on Op= enPGP (gpg, in fact) to encrypt the passwords. Unsurprisingly, it turns out= that compressing the password before encrypting it leaks much of the passw= ord entropy, making dictionary attacks significantly easier to mount. (In m= y preliminary experiments I used a password dictionary containing about 4 m= illion passwords. If the attacker knows the original password length and it= s compressed length, then for some combinations of the two the candidate di= ctionary entries can reduce to as few as some hundreds.)
>
> I believe similar attacks can be mounted in different contexts where O= penPGP is used. Hence, I propose to start discussion to amend RFC 4880 to a= t least discourage (if not forbid) the use of compression.

It is not my intent to make light of your email, but I'm somewhat= amused as a few years ago there was an attack that could be *avoided* by c= ompression. =C2=A0See https://www.schneier.com/paper-pgp.pdf for the details.= =C2=A0Damned if you do, damned if you don't?

In that case, compression incidentally thw= arted the attack, by inserting additional packet headers in the encrypted p= ackets, hence letting some parsing fail when decrypting a chosen ciphertext= .

In general, I see two patterns:
- Compression = incidentally thwarts some attacks
- Compression fundamentally= breaks privacy by leaking plaintext entropy (see the Wikimedia Foundation = case for a quite convincing example)

I would not want to rely on the obfuscation provided by an o= ptional feature of OpenPGP to ensure secrecy. If a decryption oracle is fou= nd, it should be systematically fixed -- also for users who decide not to u= se compression.

On the other hand, at least making compression disabled by d= efault would protect those users who are unaware of the interaction between= compression and encryption. Those who are aware of it could always explici= tly enable compression.

Cheers,
Alfredo
=C2=A0

Note that the use of compression in OpenPGP (at least in the public key con= text) is under the control of the recipient. =C2=A0If a given recipient doe= sn't want compression used on messages to their key, they can set a pre= ference reflecting that, and all OpenPGP implementations will not compress = when encrypting a message to that key.

David


--001a1136989865ce8704f4f74524-- From nobody Wed Mar 19 09:43:34 2014 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 F210C1A07DF for ; Wed, 19 Mar 2014 09:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 o-PqdoGsnIwF for ; Wed, 19 Mar 2014 09:43:29 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id BD2A81A07DC for ; Wed, 19 Mar 2014 09:43:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id EC5CF4F97386; Wed, 19 Mar 2014 09:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frznN44Jp4ph; Wed, 19 Mar 2014 09:43:11 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id B18B24F9736A; Wed, 19 Mar 2014 09:43:09 -0700 (PDT) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Wed, 19 Mar 2014 09:43:11 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 19 Mar 2014 09:43:11 -0700 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Jon Callas In-Reply-To: Date: Wed, 19 Mar 2014 09:43:07 -0700 Message-Id: <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> References: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> To: Alfredo Pironti X-Mailer: Apple Mail (2.1874) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/2MMgwfP59K6lt6w01agCjEG0Ovw Cc: David Shaw , openpgp@ietf.org, Jon Callas Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 19 Mar 2014 16:43:32 -0000 >=20 > In general, I see two patterns: > - Compression incidentally thwarts some attacks > - Compression fundamentally breaks privacy by leaking plaintext = entropy (see the Wikimedia Foundation case for a quite convincing = example) In general, compression does the opposite of your second bullet. It = *protects* privacy by taking things that are typically not pseudo-random = (what you're calling entropic) -- e.g. text -- into something that is = highly pseudo-random. In specific cases, *flaws* in this conversion when combined with an = interactive protocol can lead to an attack that is in general, not = applicable to a non-interactive protocol with large amounts of = compressed data. But in general, this benefits the defender, as the attacker has no idea = what the *actual* plaintext is (the compressed data) unless they know = the base plaintext is, and small inaccuracies in the attackers guess = lead to large differences. Of course, I could be wrong. I offered an outline for research where you = could come up with some results that would be impressive. Why not do = some work on it? Jon From nobody Wed Mar 19 09:57:03 2014 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 09B6A1A0429 for ; Wed, 19 Mar 2014 09:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] 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 fqFZdGDJlOJ5 for ; Wed, 19 Mar 2014 09:56:54 -0700 (PDT) Received: from albireo.enyo.de (albireo.enyo.de [46.237.207.196]) by ietfa.amsl.com (Postfix) with ESMTP id DD8851A040A for ; Wed, 19 Mar 2014 09:56:53 -0700 (PDT) Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) id 1WQJnI-0002v5-97; Wed, 19 Mar 2014 17:56:44 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1WQJnD-0005Mp-Ta; Wed, 19 Mar 2014 17:56:39 +0100 From: Florian Weimer To: Jon Callas References: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> Date: Wed, 19 Mar 2014 17:56:39 +0100 In-Reply-To: <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> (Jon Callas's message of "Wed, 19 Mar 2014 09:43:07 -0700") Message-ID: <874n2uazzs.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/4uJnGxj8A-cL1a7zJjZxoCvlBu8 Cc: David Shaw , openpgp@ietf.org, Alfredo Pironti Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 19 Mar 2014 16:56:56 -0000 * Jon Callas: > In specific cases, *flaws* in this conversion when combined with an > interactive protocol can lead to an attack that is in general, not > applicable to a non-interactive protocol with large amounts of > compressed data. It doesn't have to be interactive (in the sense of chosen-something attacks). For example, lossy voice compression tends to produce length differences for different phonemes. And the Wikimedia example wasn't something interactive, either. > But in general, this benefits the defender, as the attacker has no > idea what the *actual* plaintext is (the compressed data) unless > they know the base plaintext is, and small inaccuracies in the > attackers guess lead to large differences. But this doesn't matter if the encryption is sound, does it? From nobody Wed Mar 19 10:19:41 2014 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 E8B571A070D for ; Wed, 19 Mar 2014 10:19:37 -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, 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 6ClzXXuIGVMu for ; Wed, 19 Mar 2014 10:19:34 -0700 (PDT) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 536E21A073B for ; Wed, 19 Mar 2014 10:19:33 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id n16so8616458oag.41 for ; Wed, 19 Mar 2014 10:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=luNKqtypSVtyVBR7O29ojxzaKczgvfrAYeavK0EJQgI=; b=UiC0PRCrIE3ot31Ch+27iBO2guwZ6w+IQ356sySSYu98jojvw5LNi7JUbOSvNp1KNl YDTvadlPsSMqOfm4jvr9YZONDTQJmt8kieDeGJWVA0IDmPGXmT2Ah06e+ZVhIwjrRNvw XKecUcoOqSmvyKlfG4uQOHhrX/tRTI8+bN9yE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=luNKqtypSVtyVBR7O29ojxzaKczgvfrAYeavK0EJQgI=; b=Z7gV4e94xLImtxxmf30AsWUlLOSFIeSleIi503cZHl4M4uXpWgX+nZ5CK75cAdyh7Z D+HWfE4/Co9YrfIde7Lz4c2guodIaXpSph0GRR9v1iKZmuj1UbZ1DWS4Elz9zkKz26/q p/hQ1A9c9dBdg12WvbGL+sQeOCYagDUjlLhEHKrs4TuWbd+SZxBarClQ4mg+gbKSgnV7 ldBzVfa6oYE+VGshfkLkIkDZ20QCBvIFyyYpXZ2/YkkHW87B/CFJ1kpMb6+3EhtpZxzi Yx30xpmMVPqEpMSAUTEvBFFXZfUXHCx9GZfqX8LylPqs8eJ/onMTpQkdK2PAZ16maCzD Jm1g== X-Gm-Message-State: ALoCoQnqcLxtwRTtCE5bW2toTIEvUkxJKCT8otT5pTKS/p13Z8GOtpxoxDK5BcLEpwqD2aC17Ejq MIME-Version: 1.0 X-Received: by 10.182.28.7 with SMTP id x7mr3012976obg.43.1395249565042; Wed, 19 Mar 2014 10:19:25 -0700 (PDT) Sender: alfredo@pironti.eu Received: by 10.76.151.35 with HTTP; Wed, 19 Mar 2014 10:19:24 -0700 (PDT) X-Originating-IP: [128.93.188.195] In-Reply-To: <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> References: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> Date: Wed, 19 Mar 2014 18:19:24 +0100 X-Google-Sender-Auth: dS5U-mreaYNFe2suWe5zWa7b8aw Message-ID: From: Alfredo Pironti To: Jon Callas Content-Type: multipart/alternative; boundary=089e015380bab3a6c904f4f8da0f Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/nXvj2947Y0VsqAUpcB6NVTaMqhs Cc: David Shaw , openpgp@ietf.org Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 19 Mar 2014 17:19:38 -0000 --089e015380bab3a6c904f4f8da0f Content-Type: text/plain; charset=UTF-8 On Wed, Mar 19, 2014 at 5:43 PM, Jon Callas wrote: > > > > In general, I see two patterns: > > - Compression incidentally thwarts some attacks > > - Compression fundamentally breaks privacy by leaking plaintext entropy > (see the Wikimedia Foundation case for a quite convincing example) > > > In general, compression does the opposite of your second bullet. It > *protects* privacy by taking things that are typically not pseudo-random > (what you're calling entropic) -- e.g. text -- into something that is > highly pseudo-random. > Just to clarify, I was talking in terms of the length side-channel entailed by compression. If the attacker knows the uncompressed plaintext length, and can measure the compressed ciphertext length, then some information about the uncompressed plaintext content is leaked. It may be not common, but it seems to me that this attacker model is well within the scope of OpenPGP. > > In specific cases, *flaws* in this conversion when combined with an > interactive protocol can lead to an attack that is in general, not > applicable to a non-interactive protocol with large amounts of compressed > data. > > But in general, this benefits the defender, as the attacker has no idea > what the *actual* plaintext is (the compressed data) unless they know the > base plaintext is, and small inaccuracies in the attackers guess lead to > large differences. > > Of course, I could be wrong. I offered an outline for research where you > could come up with some results that would be impressive. Why not do some > work on it? > > Jon > > > --089e015380bab3a6c904f4f8da0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Mar 19, 2014 at 5:43 PM, Jon Callas <<= a href=3D"mailto:jon@callas.org" target=3D"_blank">jon@callas.org> wrote:
>
> In general, I see two patterns:
> - Compression incidentally thwarts some attacks
> - Compression fundamentally breaks privacy by leaking plaintext entrop= y (see the Wikimedia Foundation case for a quite convincing example)


In general, compression does the opposite of your second bullet. It *= protects* privacy by taking things that are typically not pseudo-random (wh= at you're calling entropic) -- e.g. text -- into something that is high= ly pseudo-random.

Just to clarify, I was talking in terms of= the length side-channel entailed by compression. If the attacker knows the= uncompressed plaintext length, and can measure the compressed ciphertext l= ength, then some information about the uncompressed plaintext content is le= aked.

It may be not common, but it seems to me that this attacker model is we= ll within the scope of OpenPGP.
=C2=A0

In specific cases, *flaws* in this conversion when combined with an interac= tive protocol can lead to an attack that is in general, not applicable to a= non-interactive protocol with large amounts of compressed data.

But in general, this benefits the defender, as the attacker has no idea wha= t the *actual* plaintext is (the compressed data) unless they know the base= plaintext is, and small inaccuracies in the attackers guess lead to large = differences.

Of course, I could be wrong. I offered an outline for research where you co= uld come up with some results that would be impressive. Why not do some wor= k on it?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jon



--089e015380bab3a6c904f4f8da0f-- From nobody Wed Mar 19 13:40:44 2014 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 86EB01A07FF for ; Wed, 19 Mar 2014 13:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 lO_yrLkl7zvs for ; Wed, 19 Mar 2014 13:40:41 -0700 (PDT) Received: from outmail149095.authsmtp.com (outmail149095.authsmtp.com [62.13.149.95]) by ietfa.amsl.com (Postfix) with ESMTP id 919871A0803 for ; Wed, 19 Mar 2014 13:40:41 -0700 (PDT) Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s2JKeUW3090938; Wed, 19 Mar 2014 20:40:30 GMT Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s2JKePor060984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 19 Mar 2014 20:40:27 GMT Date: Wed, 19 Mar 2014 16:40:47 -0400 From: Peter Todd To: Jon Callas Message-ID: <20140319204047.GC30999@savin> References: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Clx92ZfkiYIKRjnr" Content-Disposition: inline In-Reply-To: <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: b4b415f6-afa6-11e3-94fa-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR bgdMdwsUFVQGAgsB AmIbWVReVF17W2s7 bAxPbAVDY01GQQRq WVdMSlVNFUsrA2Z6 U35BEBl0dwxOfDBx YUFnWz4JWBZ+dEMr RFMFQzwAeGZhPWMC WUQOJh5UcAFPdx8U a1N6AHBDAzANdhE/ BwI1Jz8pCH1zKT9c SAUMK11aSkEOBiQx XAsDGjNnHEtNYD0+ KSQJEjYB X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/7hTCGVtx8RY3uJ_TVilv5dGmMF8 Cc: David Shaw , openpgp@ietf.org, Alfredo Pironti Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 19 Mar 2014 20:40:43 -0000 --Clx92ZfkiYIKRjnr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 19, 2014 at 09:43:07AM -0700, Jon Callas wrote: > >=20 > > In general, I see two patterns: > > - Compression incidentally thwarts some attacks > > - Compression fundamentally breaks privacy by leaking plaintext entropy= (see the Wikimedia Foundation case for a quite convincing example) >=20 >=20 > In general, compression does the opposite of your second bullet. It *prot= ects* privacy by taking things that are typically not pseudo-random (what y= ou're calling entropic) -- e.g. text -- into something that is highly pseud= o-random. That's the job of encryption, and modern encryption does that job very well. I strongly support turning off compression by default. That the length of the data being encrypted is leaked is pretty easy for a non-advanced user to figure out - just compare the encrypted and unencrypted file lengths, or for that matter, just think about it rationally. But the fact that information on the contents of the file is being leaked too - exactly what encryption is supposed to prevent - is not at all obvious. --=20 'peter'[:-1]@petertodd.org 0000000000000000bb8e8e215734f2855ab6da93a8e1caf12392231696f01f83 --Clx92ZfkiYIKRjnr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQGrBAEBCACVBQJTKgDKXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDA2N2M0YzQ2YTVmYTJkMjY4NjU1OTYwN2QxNDQ1MDQ5N2Vm YjI4MjYyMzRiMThkODcvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfv57AgAkbzKfb+0NFCd9vvpJ6ZtF4L3 fYAEKpC1sZ4pkuZ8TY6ded3z9jPD9ZhIBYfyPt/0jUIZbjfabWcEhBlJ5h9wEf48 On05F9pmDOdWex/eZmH4igqV7r7fKdbtG37D+rF3mAWvJJtNA0ktYebTB7Q6ZO50 BsisxsbTcBvDaGLsnXhW+dAT1DqxY2ZG6P2sZhwldiKUYHpXDKPGItLg8dPsVUvf 13i1JPKuFC9/ZE1Ejy0EBBEO/s3mVM0EgPlahpyFJh2UHwMB/qnfwTZG7sguwxIa augUsOcCw5VK3x9cnsEHgIM8N3U9WI22Df6kZwe7iOXue4oaXGEtA5hRjQGWGg== =Nlp3 -----END PGP SIGNATURE----- --Clx92ZfkiYIKRjnr-- From nobody Wed Mar 19 13:47:18 2014 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 EDD0D1A0808 for ; Wed, 19 Mar 2014 13:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GSK5NTaMcRBz for ; Wed, 19 Mar 2014 13:47:14 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 377141A07FB for ; Wed, 19 Mar 2014 13:47:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 7C5CD4F9ABB9; Wed, 19 Mar 2014 13:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTxgscCdsWJg; Wed, 19 Mar 2014 13:47:04 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id C7EC34F9ABA4; Wed, 19 Mar 2014 13:47:04 -0700 (PDT) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Wed, 19 Mar 2014 13:47:04 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 19 Mar 2014 13:47:04 -0700 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Jon Callas In-Reply-To: <20140319204047.GC30999@savin> Date: Wed, 19 Mar 2014 13:47:01 -0700 Message-Id: References: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> <20140319204047.GC30999@savin> To: Peter Todd X-Mailer: Apple Mail (2.1874) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/splf_bwdQ3M81iw56h4HU9-FWO8 Cc: David Shaw , "openpgp@ietf.org OpenPGP" , Jon Callas , Alfredo Pironti Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 19 Mar 2014 20:47:17 -0000 > That's the job of encryption, and modern encryption does that job very > well. >=20 > I strongly support turning off compression by default. That the length > of the data being encrypted is leaked is pretty easy for a = non-advanced > user to figure out - just compare the encrypted and unencrypted file > lengths, or for that matter, just think about it rationally. But the > fact that information on the contents of the file is being leaked too = - > exactly what encryption is supposed to prevent - is not at all = obvious. What's being leaked by compression? Really, I don't get it. Consider an OpenPGP blob that is compressed and encrypted. Consider that = it is intercepted by whatever means. What's the leak? Here's an example, where an unknown plaintext is encrypted both to a = key, and to a passphrase: -----BEGIN PGP MESSAGE----- Comment: GPGTools - http://gpgtools.org hQEOA2EbpgyFsrXlEAQAs63hznff9WCrq9xpT5s8dbmoabOQpfV/Crzaqn5diiCp x1kyqqTCpSJQ648O3bF3GYq0KfqWhzc3S+rK7yrSpSA8UDWWifVfSBKmVDvYUD/g GPURwlTKtUp00MzlKrT083oq/aQEotO/7botgihpEbWPrEO3ZZIFwwxmNfwUUtED /jyNjMfPTmeLYvPdMLFiy+AuMbGnE3L0M9+iTLJZHW6Hb/hn0TLJk69RdDkmyiql VaZNYE+9l1AiZpEVddmoKOTPPV0EtzeNqVZtVr3yCH0rBrN54GjHoWAnD8/IhuX8 T11kixGJhs1228xlhK+3UTp15VGrKNQsLoGpUd45iewPjCYEAwMCe35rGZQc7xjR gk41KuP8CsROH0ulK1pzm/zH2gZbzhY068np63ZvnfxTQyaYBV+MRAhN2NOF1XkW 4QtFr2bfJCYiCzS6vuwxjRicfU9kwHaI+G3XfJGXVB/qtcgEV7JWG81VDnU2zKSh h1KATe/zU5zJ7RM6mwrL37Ve4SY5tLPvpxSahu8fRffeU8/pBeQCcZyKa7ZGxiFB xjFLBB2a3N77Bf0VZ+nRS9nE6SpTEx8tF8b8l3qMa+lzJKVZk7cP2Yc0POHtBCT6 F2TlnMDEvRvFmbz+3Z592OCXaZoBG6fU7VKALzZ/kl6usm6mvKAtrbNQfTk5MM38 fqwUrcLOHpxWVNKcDvmOGdsODq5lX2coHfsix8aBoRBz/q1HiOGV3F0C9hudag01 P199G1PCYuxzX9OvJPKEZnzf6+jEZ3vE8dhkRZPrhs/Xo7A7ryj++GSKFCSyVaHk PryGNgJnAp82uimr9FYT8Wmwoy42o1pPCAyVoquowHxpXAgADhmwpk0wbbE5vaD/ 81uh1843VRySOpuQCkIkI7PhIy3HBbs349FVLKnC07VF0vMHzW3QeY9JVZJH6RlJ DQP0G2TjBaneHRPhdoNKzWLhTfKuaDo9FkJaaTzeB/gVKnPfovcdDjZefmflCQXR PvtYDsms4m5slCo/MTToM4oGuBBZqqcLIv5ZSRWYr/Gu2w9ZLkysb92dtfJe4+nw y2Bqk9UKInw3WAbAs0rCUlPBpAOFxNHdjkzjthGx6P3W5ZI+nG9aXyB1XNeHaTYL /Sx0SEFU1fmlKaIynY4reM3qJjjXi/PAWn5piTrH/G0LI3CUEgXa3Mw3sG3ArbAw PleXVP3QWt8jf418bDA4BLH4DFhYLQk2Ayss1M/snoRip/iUqKEu0OsUJtaspHDY Xt2bksh35paCav0rEtGfhxC0ks7UTdRQDP4l9tX24unQZfWAEfZkPhQPh+mkDA+H 3u6VfmN+5QXqph8//Qk7LSTsiBgG+EswRpqDRhNjV2ibCWjMmggtJZyKq/oOsQpS oCQqkpgjrv+GSGCgEwIKeUZfnTtVTpKX0EiDjUTQ5Cuq1VR+NsIfHdo2ZSVQ0+mS D9sGjILD87c80Pcfd3i9NtZoZqX46p4CVOReaFEvll1X9YqEaX4uDPCPoubSHsqR EfqIT2AYRegF1Grjr16YTzqiqkfL/4lOKQHyRwGLjq8pag888IXdbKIxWbXtMESs =3DUqr6 -----END PGP MESSAGE----- What's the leak? What's the vuln? Jon From nobody Wed Mar 19 13:55:19 2014 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 B9E921A0464 for ; Wed, 19 Mar 2014 13:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTNDRG_L2tiH for ; Wed, 19 Mar 2014 13:55:15 -0700 (PDT) Received: from outmail148161.authsmtp.com (outmail148161.authsmtp.com [62.13.148.161]) by ietfa.amsl.com (Postfix) with ESMTP id 83D281A07FE for ; Wed, 19 Mar 2014 13:55:15 -0700 (PDT) Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s2JKt4xY040854; Wed, 19 Mar 2014 20:55:04 GMT Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s2JKstCO004582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 19 Mar 2014 20:54:57 GMT Date: Wed, 19 Mar 2014 16:55:17 -0400 From: Peter Todd To: Jon Callas Message-ID: <20140319205517.GA6566@savin> References: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> <20140319204047.GC30999@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: bb48ee20-afa8-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR bgdMdwsUFVQGAgsB AmIbWVReVVl7XGs7 bAxPbAVDY01GQQRq WVdMSlVNFUsrA2Z6 RVptLRlycwBOejBy Y0VqWz4JDkByIBN/ QlMFQzwOeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhE/ BwI1Jz8pCH1zKT9c SAUMK11aSkEOBiQx XAsDGjNnHEtNYD0+ KSQJEjYB X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/AHDIP0rJg3TmV4kafPrPtZOovVM Cc: David Shaw , "openpgp@ietf.org OpenPGP" , Alfredo Pironti Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 19 Mar 2014 20:55:17 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 19, 2014 at 01:47:01PM -0700, Jon Callas wrote: > > That's the job of encryption, and modern encryption does that job very > > well. > >=20 > > I strongly support turning off compression by default. That the length > > of the data being encrypted is leaked is pretty easy for a non-advanced > > user to figure out - just compare the encrypted and unencrypted file > > lengths, or for that matter, just think about it rationally. But the > > fact that information on the contents of the file is being leaked too - > > exactly what encryption is supposed to prevent - is not at all obvious. >=20 > What's being leaked by compression? Really, I don't get it. >=20 > Consider an OpenPGP blob that is compressed and encrypted. Consider that = it is intercepted by whatever means. What's the leak? >=20 > Here's an example, where an unknown plaintext is encrypted both to a key,= and to a passphrase: >=20 > -----BEGIN PGP MESSAGE----- > Comment: GPGTools - http://gpgtools.org >=20 > hQEOA2EbpgyFsrXlEAQAs63hznff9WCrq9xpT5s8dbmoabOQpfV/Crzaqn5diiCp > x1kyqqTCpSJQ648O3bF3GYq0KfqWhzc3S+rK7yrSpSA8UDWWifVfSBKmVDvYUD/g > GPURwlTKtUp00MzlKrT083oq/aQEotO/7botgihpEbWPrEO3ZZIFwwxmNfwUUtED > /jyNjMfPTmeLYvPdMLFiy+AuMbGnE3L0M9+iTLJZHW6Hb/hn0TLJk69RdDkmyiql > VaZNYE+9l1AiZpEVddmoKOTPPV0EtzeNqVZtVr3yCH0rBrN54GjHoWAnD8/IhuX8 > T11kixGJhs1228xlhK+3UTp15VGrKNQsLoGpUd45iewPjCYEAwMCe35rGZQc7xjR > gk41KuP8CsROH0ulK1pzm/zH2gZbzhY068np63ZvnfxTQyaYBV+MRAhN2NOF1XkW > 4QtFr2bfJCYiCzS6vuwxjRicfU9kwHaI+G3XfJGXVB/qtcgEV7JWG81VDnU2zKSh > h1KATe/zU5zJ7RM6mwrL37Ve4SY5tLPvpxSahu8fRffeU8/pBeQCcZyKa7ZGxiFB > xjFLBB2a3N77Bf0VZ+nRS9nE6SpTEx8tF8b8l3qMa+lzJKVZk7cP2Yc0POHtBCT6 > F2TlnMDEvRvFmbz+3Z592OCXaZoBG6fU7VKALzZ/kl6usm6mvKAtrbNQfTk5MM38 > fqwUrcLOHpxWVNKcDvmOGdsODq5lX2coHfsix8aBoRBz/q1HiOGV3F0C9hudag01 > P199G1PCYuxzX9OvJPKEZnzf6+jEZ3vE8dhkRZPrhs/Xo7A7ryj++GSKFCSyVaHk > PryGNgJnAp82uimr9FYT8Wmwoy42o1pPCAyVoquowHxpXAgADhmwpk0wbbE5vaD/ > 81uh1843VRySOpuQCkIkI7PhIy3HBbs349FVLKnC07VF0vMHzW3QeY9JVZJH6RlJ > DQP0G2TjBaneHRPhdoNKzWLhTfKuaDo9FkJaaTzeB/gVKnPfovcdDjZefmflCQXR > PvtYDsms4m5slCo/MTToM4oGuBBZqqcLIv5ZSRWYr/Gu2w9ZLkysb92dtfJe4+nw > y2Bqk9UKInw3WAbAs0rCUlPBpAOFxNHdjkzjthGx6P3W5ZI+nG9aXyB1XNeHaTYL > /Sx0SEFU1fmlKaIynY4reM3qJjjXi/PAWn5piTrH/G0LI3CUEgXa3Mw3sG3ArbAw > PleXVP3QWt8jf418bDA4BLH4DFhYLQk2Ayss1M/snoRip/iUqKEu0OsUJtaspHDY > Xt2bksh35paCav0rEtGfhxC0ks7UTdRQDP4l9tX24unQZfWAEfZkPhQPh+mkDA+H > 3u6VfmN+5QXqph8//Qk7LSTsiBgG+EswRpqDRhNjV2ibCWjMmggtJZyKq/oOsQpS > oCQqkpgjrv+GSGCgEwIKeUZfnTtVTpKX0EiDjUTQ5Cuq1VR+NsIfHdo2ZSVQ0+mS > D9sGjILD87c80Pcfd3i9NtZoZqX46p4CVOReaFEvll1X9YqEaX4uDPCPoubSHsqR > EfqIT2AYRegF1Grjr16YTzqiqkfL/4lOKQHyRwGLjq8pag888IXdbKIxWbXtMESs > =3DUqr6 > -----END PGP MESSAGE----- >=20 > What's the leak? What's the vuln? Having a completely unknown plaintext is the best case; having plaintexts that are not completely unknown to the attacker is both common, and reasonable to defend against. If I knew that the plaintext was either 1KB worth of uncompressable binary = garbage, or 1KB worth of text, it'd be pretty easy for me to figure out if I was looking at garbage or text. Gregory Maxwell's example of the Wikipedia vote's privacy being broken by compression-by-default shows this is a real world risk that users are not thinking about. --=20 'peter'[:-1]@petertodd.org 000000000000000067c4c46a5fa2d2686559607d14450497efb2826234b18d87 --jI8keyz6grp/JLjh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQGrBAEBCACVBQJTKgQvXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDBiMTg3MmJkMDZmNzQxMGU1OThhZmFmMzgyMmFkYjBjZjNh MDljZmJhZTljOGZmOTgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsfpwf+NdN4MBGCy1OWYhsXnrWiaeCQ npFNbjNOyiJdDPJqNIFmCTpn1l7mJV8PQiawSwFUOzCffTsqmt6Hwa6pOStFeddt VAwk32ZAZQm8TmCbqGUpyVGRs6CtctgJiD5HvhaSoXUSopw9Oc3eYtmpM3Ydj5yd httL2nKec9fKihkA1MFUCqxvBzj/Qq7+cZCIBnaEQQ7zMeUQ3aLykgU7zYYUhiov 4BY1rNBEG6evVzxoxv6wM9GC+RQGA496Pa9kRv+oFoWGKGuidUxqH2nN9LLZ7Cvj e6UDik+coBL5Wc7qAecIKOrx40CscmPUyUyNowNH6uMCxYnwnIXGFob0m6pvgQ== =ID5g -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From nobody Wed Mar 19 14:16:36 2014 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 67C671A0304 for ; Wed, 19 Mar 2014 14:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AE_8WTjK9w8x for ; Wed, 19 Mar 2014 14:16:26 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 00BC01A0335 for ; Wed, 19 Mar 2014 14:16:25 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id y1so6366034lam.37 for ; Wed, 19 Mar 2014 14:16:16 -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=Bd4e35TfQPYM0khgwXHWk/m8rnoagTMo3nCleNBkbjU=; b=FpK8y+Lc91OBEPf55Z+eYt0oKfkoCWzWcN+U632grspUCcGE25tntsHisTK1K/dj3I q/zO+1Ze4ThrNF78zo2Byf0FMmMux3H9DYWD7fEdfVF4YwF9WpqZlHCwxLHj6LZ0BuVw lTMILdKKqd6yisEgfWjA4VCZbacDNMUUfzBHQjSEuoi4ndE9kgT2TErubq2wWU43GkG6 a5mgWUHL2in9t0tnSdsgJQ5E2FlCOzZKOzFprho+IMr2QjgxwP8ZNqv2JHG1k30yLgaH Yk/RSKRvblOICicC6PY/3ovrBhJaFVWHY2fJQvcFQuqNaAxsHuAVcATGwX4/3lVUfEYd TYrQ== MIME-Version: 1.0 X-Received: by 10.152.26.66 with SMTP id j2mr27440068lag.25.1395263776621; Wed, 19 Mar 2014 14:16:16 -0700 (PDT) Received: by 10.112.184.226 with HTTP; Wed, 19 Mar 2014 14:16:16 -0700 (PDT) In-Reply-To: References: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> <20140319204047.GC30999@savin> Date: Wed, 19 Mar 2014 14:16:16 -0700 Message-ID: From: Gregory Maxwell To: Jon Callas Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/R2c3gxhc7HlxeUF1B2HWjr3RpBw Cc: David Shaw , Peter Todd , Alfredo Pironti , "openpgp@ietf.org OpenPGP" Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 19 Mar 2014 21:16:31 -0000 On Wed, Mar 19, 2014 at 1:47 PM, Jon Callas wrote: > What's being leaked by compression? Really, I don't get it. Some people like a demonstration. Consider that I'm going to cast one of two ballots in a secret ballot election. The ballots are just permutations of eachother so they are the same size. https://people.xiph.org/~greg/ballot.1 https://people.xiph.org/~greg/ballot.2 I encrypt my secret ballot to the election officials with the public key at https://people.xiph.org/~greg/openpgp_testpubkey.asc using the command: gpg -ear 9C28FC94 --compress-algo ZIP --compress-level 9 ballot.X (just being explicit for consistency sake, using GPG 1.4.16 in Fedora 19) And I get the encrypted result of https://people.xiph.org/~greg/ballot.secret.asc Which ballot did I cast? Anyone? From nobody Wed Mar 19 14:38:08 2014 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 CC49F1A0724 for ; Wed, 19 Mar 2014 14:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lzYFXI5-mKVl for ; Wed, 19 Mar 2014 14:38:03 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id B8E611A07A1 for ; Wed, 19 Mar 2014 14:38:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 478AD4F9B94F; Wed, 19 Mar 2014 14:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5O5RzytekUM; Wed, 19 Mar 2014 14:37:52 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 20DCC4F9B938; Wed, 19 Mar 2014 14:37:52 -0700 (PDT) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Wed, 19 Mar 2014 14:37:52 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 19 Mar 2014 14:37:52 -0700 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Jon Callas In-Reply-To: <20140319205517.GA6566@savin> Date: Wed, 19 Mar 2014 14:37:50 -0700 Message-Id: References: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> <20140319204047.GC30999@savin> <20140319205517.GA6566@savin> To: Peter Todd X-Mailer: Apple Mail (2.1874) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/-TiAQhg1DjlbchMknnjYVVVJK1Y Cc: David Shaw , "openpgp@ietf.org OpenPGP" , Jon Callas , Alfredo Pironti Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 19 Mar 2014 21:38:06 -0000 > Having a completely unknown plaintext is the best case; having > plaintexts that are not completely unknown to the attacker is both > common, and reasonable to defend against. >=20 > If I knew that the plaintext was either 1KB worth of uncompressable = binary garbage, > or 1KB worth of text, it'd be pretty easy for me to figure out if I = was > looking at garbage or text. >=20 > Gregory Maxwell's example of the Wikipedia vote's privacy being broken > by compression-by-default shows this is a real world risk that users = are > not thinking about. But it proves nothing here. It's a really, really interesting exception = case. We're talking about a default. We're also talking about the = protocol definition, and not implementation software. Compression is on by default because it improves security. It meets that = goal. It is, however, a default. Defaults can be changed. Moreover, = there's a way to work around the issue in the existing standard. Make = the vote-submission key not support compression. Poof, it works. There are many, many other cases where it is *assumed* that compression = is on by default, and that's the desired behavior for both security = reasons and non-security reasons (like you want the object compressed as = well as encrypted!) When you design systems and software, one of the things you need to = consider is defaults. Another is exceptions. But there's also installed = base.=20 Changing a standard is hard, and that's a feature, not a bug. The weaker = that a standard is about something, the harder it is to change. Changing = an implementation is easier, because it's just software. But there's = also the issue of not only the defaults but the installed base. If you went, for example, to someone who did an email plugin that did = not expose compression and argue that they should not compress by = default, you have an interesting case. I think it's still unproven, but = it's interesting. I can even see the worth of turning compression off in = a lot of cases. However, there are still many people who consider = default compression a feature and *rely* on it for their system. If you went to the gpg people and asked for "-z 0" (which turns off = compression) to be the default, it would be a very bad idea because = there's 20+ years of presumption that compression is on. Moreover, it's very easy for anyone to opt out of compression. Put no = compression in the key as a pref.=20 Making a change to the standard requires a really good reason. Let's = face it, even if it were easy to do, and we changed it from a SHOULD to = a MAY, that would almost certainly result in no change to software = because there's an expectation that it's the default across the user = base and has been for twenty-some years. Changing the default in = software is a really bad idea, absent a really big reason. If it went = all the way from SHOULD to MUST NOT, you'd end up with lots of software = even ignoring the new standard -- again, absent some compelling case. Remember, the word SHOULD in a standard is guidance to an implementer = that to do X unless there's a good reason. Any time there's a good = reason, the implementation can do whatever it wants. That's it, it's = merely guidance. I'm going to repeat what I said and say that you need some actual = security analysis that goes beyond finding a cool exception case. But = I'll add that you might be better served by going to the people who make = software and systems. It's very easy for them to do what you want. Heck, = I've even made a system that does what you want, myself. (It wasn't for = your reasons, though. It was because implementation constraints made it = drop compression.) Jon From nobody Wed Mar 19 14:41:21 2014 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 397901A07D8 for ; Wed, 19 Mar 2014 14:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiHE2u3Xfvh3 for ; Wed, 19 Mar 2014 14:41:16 -0700 (PDT) Received: from outmail149058.authsmtp.co.uk (outmail149058.authsmtp.co.uk [62.13.149.58]) by ietfa.amsl.com (Postfix) with ESMTP id B33491A0724 for ; Wed, 19 Mar 2014 14:41:15 -0700 (PDT) Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt14.authsmtp.com (8.14.2/8.14.2) with ESMTP id s2JLf2j1080211; Wed, 19 Mar 2014 21:41:02 GMT Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s2JLeuLg030476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 19 Mar 2014 21:40:58 GMT Date: Wed, 19 Mar 2014 17:41:18 -0400 From: Peter Todd To: Gregory Maxwell Message-ID: <20140319214118.GA17419@savin> References: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> <20140319204047.GC30999@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 29143fb2-afaf-11e3-94fa-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR bwdMdwsUFVQGAgsB AmIbWVVeVF17XGo7 bAxPbAVDY01GQQRq WVdMSlVNFUsrA2Z9 U1tiBRlxdwFBfjBx bENhXj5ZVUV+dhAv QFMFQzxQeGZhPWMC WUQOJh5UcAFPdx8U a1N6AHBDAzANdhE/ BwI1Jz8pCH1zKT9c SAUMK11aSkEOBiQx XAsDGjNnHEtNYD0+ KSQJEjYB X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/g8mPYFCPZp0B4kmCsqumsD5aPEY Cc: David Shaw , "openpgp@ietf.org OpenPGP" , Jon Callas , Alfredo Pironti Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 19 Mar 2014 21:41:20 -0000 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 19, 2014 at 02:16:16PM -0700, Gregory Maxwell wrote: > On Wed, Mar 19, 2014 at 1:47 PM, Jon Callas wrote: > > What's being leaked by compression? Really, I don't get it. >=20 > Some people like a demonstration. >=20 > Consider that I'm going to cast one of two ballots in a secret ballot > election. The ballots are just permutations of eachother so they are > the same size. >=20 > https://people.xiph.org/~greg/ballot.1 > https://people.xiph.org/~greg/ballot.2 >=20 > I encrypt my secret ballot to the election officials with the public > key at https://people.xiph.org/~greg/openpgp_testpubkey.asc >=20 > using the command: > gpg -ear 9C28FC94 --compress-algo ZIP --compress-level 9 ballot.X > (just being explicit for consistency sake, using GPG 1.4.16 in Fedora > 19) >=20 > And I get the encrypted result of > https://people.xiph.org/~greg/ballot.secret.asc >=20 > Which ballot did I cast? Anyone? After realizing that I needed to account for the size of the "Version:" string I got the exact same size as your secret for ballot.1, so I'm guessing that was your vote. Am I right? --=20 'peter'[:-1]@petertodd.org 0000000000000000c7cb0567f1dddff05db43f9d2c32acdb26e89e69eb80c492 --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQGrBAEBCACVBQJTKg75XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDBjN2NiMDU2N2YxZGRkZmYwNWRiNDNmOWQyYzMyYWNkYjI2 ZTg5ZTY5ZWI4MGM0OTIvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsvJQf+JrQepRlLYHqkLJ7cPRt9eD9p Ubg+zZrSKf5QDArRagNP3q/i4AJM9PeC+R9wYwZ4bXiL5Vd8E5pb8sCo4gs345OE ejiD6Ol0cEXBF7Ns8r5cuEqmti+NuaC0DJvKTo69q8TGr3kzEwlp4Qfe9s+LgcsQ OH+1lwu+y3FHC4XtqakzLogMmxWmZD72eSTIFL/6vGYsd8/vvwhZ23pTRAfncL+H CH6nfMktJjDUkrsUNWOuIqYnkYK14evSF4Br8KDYa0Ff+F+43vdK8p5j/r70dCkN yDz4ZY6Pk7Ai/H1W3hpRN9VFbuug3xEjcQBJi6p6R5N+jehe+f5eQnjs4pUhFw== =5B3g -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- From nobody Wed Mar 19 15:04:56 2014 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 30B951A07E2 for ; Wed, 19 Mar 2014 15:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aGoONFXdfl6 for ; Wed, 19 Mar 2014 15:04:48 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3A51A07A1 for ; Wed, 19 Mar 2014 15:04:47 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id hr17so6431893lab.18 for ; Wed, 19 Mar 2014 15:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GiJtGgrVO3cmhRqO31Nv2iaI6cYxdVrL+WKBn6Jh5+Q=; b=n76XLTQN2AjoJz3Jb2/alnoL7DIZSY/NiC/YYBqO8M+Ot/CTkr6He8gHDcqCjIvshb HxE4F3PtEOspR8CF6K8dGnyQfgHlMp/lZ8a6Z9MkPxeWiUmKL5/8cplPe1UjN96WH/1K MlyeitQ7ZXhAUBarH17iJlDGRZZlEnxvaFPeZTRfO6DlYUCmM0ATurpNQu+1BfZXMsmj W2u4RMInebgzXnWMQbWJK3cVMOba6SE555Vi7dHS0eeoqEHDRtQgFF0Ts4o+ZlRQagTZ UpsbwXeEn1sHNIVakl1KilWg+70jv4HdINXEcZqPxp/cNvqnkKim+fCIrAKNzHJy2BPO iq7Q== MIME-Version: 1.0 X-Received: by 10.112.254.163 with SMTP id aj3mr26023174lbd.20.1395266678721; Wed, 19 Mar 2014 15:04:38 -0700 (PDT) Received: by 10.112.184.226 with HTTP; Wed, 19 Mar 2014 15:04:38 -0700 (PDT) In-Reply-To: <20140319214118.GA17419@savin> References: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> <20140319204047.GC30999@savin> <20140319214118.GA17419@savin> Date: Wed, 19 Mar 2014 15:04:38 -0700 Message-ID: From: Gregory Maxwell To: Peter Todd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/ND6XSjzQIkIZCci2aPMzDnIQq9o Cc: David Shaw , "openpgp@ietf.org OpenPGP" , Jon Callas , Alfredo Pironti Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 19 Mar 2014 22:04:53 -0000 On Wed, Mar 19, 2014 at 2:41 PM, Peter Todd wrote: > After realizing that I needed to account for the size of the "Version:" > string I got the exact same size as your secret for ballot.1, so I'm > guessing that was your vote. > > Am I right? Indeed, you are. https://people.xiph.org/~greg/openpgp_testpubkey.secret.asc password: qwertyqwerty On Wed, Mar 19, 2014 at 2:37 PM, Jon Callas wrote: > But it proves nothing here. It's a really, really interesting exception c= ase. We're talking about a default. We're also talking about the protocol d= efinition, and not implementation software. It's a very highly surprising failure mode which leaks information about the plaintext by encoding it into the size, one which baffels otherwise expert users of the sort who would post to the openpgp list to exclaim "What's being leaked by compression? Really, I don't get it." Even thoughtful users who take care to make their messages constant length will have the implicit compression sneak up and bite them. Of course, you could compress and pad up to the original size=E2=80=A6 Voting isn't the only case where compression leaks data about the plain-text, it's just one where I know that it cause and actual compromise, with actual expert users, in actual practice. There are a great many people who use gpg to encrypt a small number of control messages (e.g. for updating route registries and such) where compression can leak information about the content. > Compression is on by default because it improves security. It meets that = goal. It is, however, a default. Defaults can be changed. It does not improve security in any practical sense. The presence of compression harms security severely and in a very practical way in at least some applications. No cipher should be used where the entropy of the input is believed to be security relevant, and if one were used, the compression in gpg still leaves non-trivial known plaintext in cases where the input begins with known plaintext (in addition to additional compression headers giving more known plaintext even when the message is otherwise completely unknown). (It's possible to design compression systems where the output is indistinguishable, e.g. arithmetic coders bijective termination, but none of the supported compressors are designed this way... they will allow you to detect an incorrect symmetric key with overwhelming probability with just a dozen bytes of decrypted output or less) > Moreover, there's a way to work around the issue in the existing standard= . Make the vote-submission key not support compression. Poof, it works. Yea, sure, don't aim the gun at your foot and your foot will not be shot. It's true, but it's not always useful. What do you care about a specification and software? real engineers encrypt their messages by hand with pen and paper. Part of the purpose of the specification and software is that doing everything 'manually' is too costly and difficult, the specification hopefully embodies the collected wisdom of careful consideration by the best available experts. > However, there are still many people who consider default compression a f= eature and *rely* on it for their system. Care to elaborate on how they rely on it? That seems highly suspect to me. Compression is a useful feature, it's nice that often the base64 encoded encrypted versions are not a ton longer than ascii text... but if we're going through the trouble of encrypting something then the encryption really ought to not invisibly leak data about the plaintext. When something is a general tool used for many applications then we ought to be assuming a sum-of-all-attacks and not just a very narrow threat model. Obviously a size side channel still exists, and might be worth reducing (e.g. by quantizing message size to a multiple of 512 bytes) but at least that side channel is highly visible to technical users. From nobody Wed Mar 19 15:59:10 2014 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 DB49B1A07DB for ; Wed, 19 Mar 2014 15:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 m95UfpOwlpLo for ; Wed, 19 Mar 2014 15:59:03 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 886561A023C for ; Wed, 19 Mar 2014 15:59:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 9F1354F9CBFA for ; Wed, 19 Mar 2014 15:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVYdkTPGnmmK for ; Wed, 19 Mar 2014 15:58:53 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 565834F9CBE6 for ; Wed, 19 Mar 2014 15:58:53 -0700 (PDT) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Wed, 19 Mar 2014 15:58:53 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 19 Mar 2014 15:58:53 -0700 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Jon Callas In-Reply-To: Date: Wed, 19 Mar 2014 15:58:50 -0700 Message-Id: References: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> <20140319204047.GC30999@savin> <20140319214118.GA17419@savin> To: Gregory Maxwell X-Mailer: Apple Mail (2.1874) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/a-NtIlYXAXl7q9KXjnquKRwnhSY Cc: "openpgp@ietf.org OpenPGP" Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 19 Mar 2014 22:59:07 -0000 On Mar 19, 2014, at 3:04 PM, Gregory Maxwell wrote: > It's a very highly surprising failure mode which leaks information > about the plaintext by encoding it into the size, one which baffels > otherwise expert users of the sort who would post to the openpgp list > to exclaim "What's being leaked by compression? Really, I don't get > it." It is! It's a really cool failure mode, and I think you should write it = up and submit it to some security conference. However, as I said, it's an exception case. It's also an exception case = that you didn't explain very well. Let me try to help: Zelda is collecting some ballots. The ballots are all text and constant = length. The voters, Vernon_i, will each edit the text ballots with their = votes, but the resultant ballots will remain constant length. If the ballots are encrypted with compression, there may be information = leaks because the different patterns of voting in the ballot. In the = simplest case where there is only one item on the ballot, it is possible = that vote can be discerned despite the raw plaintext being constant = length. I think I got that more or less right. However, there are two workarounds for this: 1. Zelda adds a no-compression preference to her key. 2. The voting system uses the "-z 0" option in a gpg command. > Voting isn't the only case where compression leaks data about the > plain-text, it's just one where I know that it cause and actual > compromise, with actual expert users, in actual practice. Please give other cases. In the usual case, Alice sends a free-form message to a set of = recipients. There's no leak in this case. >=20 > There are a great many people who use gpg to encrypt a small number of > control messages (e.g. for updating route registries and such) where > compression can leak information about the content. You're stretching it here. If those messages vary in length, there's not = much of a leak. In many cases, the real thing you're doing is *signing* = the control messages; in the specific example you give (route = registries) the actual content of the message may not even be secret. = But I know I'm quibbling. The workarounds here are: 1. Add a no-compression flag to the receiving key. 2. Add "-z 0" to the command line that generates those messages. >> However, there are still many people who consider default compression = a feature and *rely* on it for their system. >=20 > Care to elaborate on how they rely on it? That seems highly suspect to = me. >=20 tar -c source-tree | gpg key >source-tree.pgp.gz This is also what at PGP Corp we called a "PGP Zip" file, which was = implemented as a PGP encrypted tarball. It's done all the time in = back-end systems, and very likely the second largest use of PGP, where = signing files is the most. It's a really useful idiom. You're asking for a change to the standard. You're not really doing = that, even. You're asking for a change to the default behavior to = software that's been around for 20+ years because you have a wonderful = edge condition, for which there are not only per-message but per-key = workarounds. I'm really sorry your ballots got spoiled. But you can fix that with = zero changes to software nor protocol.=20 Jon From nobody Wed Mar 19 16:08:45 2014 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 CED2D1A07E2 for ; Wed, 19 Mar 2014 16:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XBNUV1dSIBH for ; Wed, 19 Mar 2014 16:08:38 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id C12B51A07DF for ; Wed, 19 Mar 2014 16:08:37 -0700 (PDT) Received: from tormenta.local (www2.futureware.at [78.41.115.142]) by virulha.pair.com (Postfix) with ESMTPSA id D11136D575; Wed, 19 Mar 2014 19:08:24 -0400 (EDT) Message-ID: <532A2363.3090800@iang.org> Date: Wed, 19 Mar 2014 23:08:19 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> <20140319204047.GC30999@savin> <20140319214118.GA17419@savin> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/oyYM6CDqJLKGKbu8LXPw0gZBGls Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 19 Mar 2014 23:08:43 -0000 On 19/03/2014 22:04 pm, Gregory Maxwell wrote: > On Wed, Mar 19, 2014 at 2:41 PM, Peter Todd wrote: >> After realizing that I needed to account for the size of the "Version:" >> string I got the exact same size as your secret for ballot.1, so I'm >> guessing that was your vote. >> >> Am I right? > > Indeed, you are. > https://people.xiph.org/~greg/openpgp_testpubkey.secret.asc password: > qwertyqwerty > > On Wed, Mar 19, 2014 at 2:37 PM, Jon Callas wrote: >> But it proves nothing here. It's a really, really interesting exception case. We're talking about a default. We're also talking about the protocol definition, and not implementation software. > > It's a very highly surprising failure mode which leaks information > about the plaintext by encoding it into the size, one which baffels > otherwise expert users of the sort who would post to the openpgp list > to exclaim "What's being leaked by compression? Really, I don't get > it." Clearly, compression leaks info if there is some understanding of the structure of the message. Sure. But OpenPGP is typically used to ship lots of large documents around, and people are accustomed to getting the compression bounty for free. So there is a sense that in order to protect the very few who might fall for this case, we'll end up disadvantaging a wider population who might actually suffer more. > Even thoughtful users who take care to make their messages constant > length will have the implicit compression sneak up and bite them. Of > course, you could compress and pad up to the original size… The assumption here is that constant length is somehow more secure than inconstancy. If for example the voting procedure were this: Send N messages, 1 for each candidate, with 0 for the ones you do not vote for (we need reliability here...) and 1 + the name for the one person you vote for (redundancy is good...) ... Then you get the same problem; *length leaks some info*. This seems to be with or without compression, so is this just a case of choosing ones pathology? There is no fundamental way to overcome the flaw of length in a packet protocol, which is what OpenPGP is. (In a stream protocol one can overcome it by insisting on transmitting X bps forever; this is what ZKS did, and setting it at some ridiculously high number like 256kbps lead the mode to be rather unpopular.) > Voting isn't the only case where compression leaks data about the > plain-text, it's just one where I know that it cause and actual > compromise, with actual expert users, in actual practice. > > There are a great many people who use gpg to encrypt a small number of > control messages (e.g. for updating route registries and such) where > compression can leak information about the content. I see this in my work all the time. Error packets are 10 bytes long, success is like 500 bytes. This is leaking info ... my only solution is to make all packets like 1024 bytes, but some of my packets are longer. How far do I go? Answer: I've got better things to worry about right now. YMMV. >> Compression is on by default because it improves security. It meets that goal. It is, however, a default. Defaults can be changed. > > It does not improve security in any practical sense. The presence of > compression harms security severely and in a very practical way in at > least some applications. No cipher should be used where the entropy of > the input is believed to be security relevant, and if one were used, > the compression in gpg still leaves non-trivial known plaintext in > cases where the input begins with known plaintext (in addition to > additional compression headers giving more known plaintext even when > the message is otherwise completely unknown). > > (It's possible to design compression systems where the output is > indistinguishable, e.g. arithmetic coders bijective termination, but > none of the supported compressors are designed this way... they will > allow you to detect an incorrect symmetric key with overwhelming > probability with just a dozen bytes of decrypted output or less) That;s interesting. Maybe what we need to do is look at more pathological cases and come up with a sort of survey of with/without? >> Moreover, there's a way to work around the issue in the existing standard. Make the vote-submission key not support compression. Poof, it works. > > Yea, sure, don't aim the gun at your foot and your foot will not be > shot. It's true, but it's not always useful. What do you care about > a specification and software? real engineers encrypt their messages by > hand with pen and paper. > > Part of the purpose of the specification and software is that doing > everything 'manually' is too costly and difficult, the specification > hopefully embodies the collected wisdom of careful consideration by > the best available experts. Well, it is true that PGP was conceived in a different world to today, and carries those traditions which are now 20 years old. But poking at just one of those assumptions may not reward, because there are 10 others sitting and wobbling. >> However, there are still many people who consider default compression a feature and *rely* on it for their system. > > Care to elaborate on how they rely on it? That seems highly suspect to me. > > Compression is a useful feature, it's nice that often the base64 > encoded encrypted versions are not a ton longer than ascii text... but > if we're going through the trouble of encrypting something then the > encryption really ought to not invisibly leak data about the > plaintext. When something is a general tool used for many applications > then we ought to be assuming a sum-of-all-attacks and not just a very > narrow threat model. > > Obviously a size side channel still exists, and might be worth > reducing (e.g. by quantizing message size to a multiple of 512 bytes) > but at least that side channel is highly visible to technical users. So one of those traditions was that every byte saved was important, as back in those days people still had 9600 baud to worry about. These days less so. But if we're going to look at that, there are a whole bunch of other things that also merit attention. iang From nobody Wed Mar 19 16:12:57 2014 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 EEE991A07DF for ; Wed, 19 Mar 2014 16:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJDUgAExlxIQ for ; Wed, 19 Mar 2014 16:12:55 -0700 (PDT) Received: from outmail149101.authsmtp.com (outmail149101.authsmtp.com [62.13.149.101]) by ietfa.amsl.com (Postfix) with ESMTP id A10551A07DB for ; Wed, 19 Mar 2014 16:12:54 -0700 (PDT) Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s2JNCCQt044083; Wed, 19 Mar 2014 23:12:12 GMT Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s2JNC8tQ041662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 19 Mar 2014 23:12:10 GMT Date: Wed, 19 Mar 2014 19:12:30 -0400 From: Peter Todd To: Jon Callas Message-ID: <20140319231230.GA10573@savin> References: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> <20140319204047.GC30999@savin> <20140319214118.GA17419@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: e671c915-afbb-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdwsUFVQGAgsB AmIbWVdeUV97WGI7 bAxPbAVDY01GQQRq WVdMSlVNFUsrA2Z/ dRZaMxl2dgNAejBx bUBhXD4OWkN7Jk98 R1MFQz9UeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhE/ BwI1Jz8pCH1zKT9c SAUMK11aSkEOBiQx XAsDGjNnHEtNYD0+ KSQJEjYB X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/ZWZADxXnNz6dVAFRU7Ik1FRQOQg Cc: Gregory Maxwell , "openpgp@ietf.org OpenPGP" Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 19 Mar 2014 23:12:57 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 19, 2014 at 03:58:50PM -0700, Jon Callas wrote: >> It is! It's a really cool failure mode, and I think you should write it = up and submit it to some security conference. >=20 > However, as I said, it's an exception case. It's also an exception case t= hat you didn't explain very well. Let me try to help: >=20 > Zelda is collecting some ballots. The ballots are all text and constant l= ength. The voters, Vernon_i, will each edit the text ballots with their vot= es, but the resultant ballots will remain constant length. >=20 > If the ballots are encrypted with compression, there may be information l= eaks because the different patterns of voting in the ballot. In the simples= t case where there is only one item on the ballot, it is possible that vote= can be discerned despite the raw plaintext being constant length. >=20 > I think I got that more or less right. >=20 > However, there are two workarounds for this: >=20 > 1. Zelda adds a no-compression preference to her key. > 2. The voting system uses the "-z 0" option in a gpg command. I don't want a workaround; I want default behavior that is reasonably safe for users. Removing default compression is a step forward in that regard. > >> However, there are still many people who consider default compression = a feature and *rely* on it for their system. > >=20 > > Care to elaborate on how they rely on it? That seems highly suspect to = me. > >=20 >=20 > tar -c source-tree | gpg key >source-tree.pgp.gz >=20 > This is also what at PGP Corp we called a "PGP Zip" file, which was imple= mented as a PGP encrypted tarball. It's done all the time in back-end syste= ms, and very likely the second largest use of PGP, where signing files is t= he most. It's a really useful idiom. >=20 > You're asking for a change to the standard. You're not really doing that,= even. You're asking for a change to the default behavior to software that'= s been around for 20+ years because you have a wonderful edge condition, fo= r which there are not only per-message but per-key workarounds. >=20 > I'm really sorry your ballots got spoiled. But you can fix that with zero= changes to software nor protocol.=20 Your example isn't much of a failure; the tarball will end up maybe 2x larger than it should have been, someone might investigate, and they'll change the command to: tar -c source-tree | gzip | gpg key >source-tree.pgp.gz or something. This is a *very* low-consequence failure mode. --=20 'peter'[:-1]@petertodd.org 00000000000000004ec562299f1cd08a38fdea8f0d612fce3923203df379c0b3 --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQGrBAEBCACVBQJTKiRZXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAxMjUzNjg2MjUxYzVmODNlYTI3ZTdmM2UxMTBjZmM0NjQ3 NDYxMDdkYTU2ZWFmMDQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfvShAf/XL6qV/quShhpT1e2sxbFySoh 2ebxN51dWbfuJTDw4om5A+fKscBmrqCY411tWthk4FKiYGfaenZuDYBa2SX6pbHm 60umIdI3vujtQ3ykCSvFC+xxqyiOO8FIgS7RTr6EmRdPfXSQn4+8SnvT11xSvdEk bk/QCaFdDO07rUoReJErPGJyXHJXeN0VAvmjsaHGzFfOErrU1cuqQHAFuttv3i6o kFH7itpNxcaUB4gsDb+NQjuIqF3WwoKFzuYwVY1W6AMJnBDEGKk48c06tZAeyCkK EbJ07wkx0+0nfz6TsxFf5XaomtG1fvC+aaIm3wfyjTSA5cMJ/JLlbEUkVQadZA== =ihML -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From nobody Wed Mar 19 16:41:14 2014 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 2BB661A0803 for ; Wed, 19 Mar 2014 16:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8crpm0SFpdEy for ; Wed, 19 Mar 2014 16:41:07 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 08CFF1A044D for ; Wed, 19 Mar 2014 16:41:06 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id gl10so43322lab.14 for ; Wed, 19 Mar 2014 16:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=r+C/RDU6/5gHm8LKd1mNpOyM9vLBGxvZLKwhiLN5Tmg=; b=hSqj67UT08mJRiiGiQnoEIOz5m+9NamBl5+k8IRsisn5CNhTnqqlk4AIDYahPiqWGg yu4f5rX6Q8jCWi7XJhtGlNGMmVJWAGhwQTIn5XGn3S3NZg6u1KqQNxrcRIh5fgPwdUPT 57uRn3suKgF5VR4xWGh4QWVaHAoP36EsmYnWZguV1KYhVaFk0Lh8DAqgQAY5arpGn9Jn Q6QQQAOFVT3U0Vz93mmgM2N2K36SM2GI+fKu4kGcDSp2VPRiaRe/9DLrW6i2CR2TVNUg XkiWZwOlu4e/EiJRNh7AlM7heLlPppzd16Ojz3s8yiynMFZgaK+UFOaGEWdsrfdJIoiM WHoQ== MIME-Version: 1.0 X-Received: by 10.152.246.43 with SMTP id xt11mr3838166lac.34.1395272457661; Wed, 19 Mar 2014 16:40:57 -0700 (PDT) Received: by 10.112.184.226 with HTTP; Wed, 19 Mar 2014 16:40:57 -0700 (PDT) In-Reply-To: References: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> <20140319204047.GC30999@savin> <20140319214118.GA17419@savin> Date: Wed, 19 Mar 2014 16:40:57 -0700 Message-ID: From: Gregory Maxwell To: Jon Callas Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/uhylrefC0gXpY--75hVWzBnLGZ4 Cc: "openpgp@ietf.org OpenPGP" Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 19 Mar 2014 23:41:10 -0000 On Wed, Mar 19, 2014 at 3:58 PM, Jon Callas wrote: > It is! It's a really cool failure mode, and I think you should write it u= p and submit it to some security conference. Its old and well known and unsurprising to people who actually work on cryptographic software. No amount of presentations at security conferences will actually protect users, however, unless the default and recommended behavior changes. > Please give other cases. The original post in this thread gave another case, I was adding another example case where security was compromised in practice. In the original post PGP is used to encrypt messages containing a password to access some service, just a password management use=E2=80=94 (t= his is something that I also happen to do, so I'm doubtful that it's that fringe an application). The poster points out that knoweldge of the size leaks a considerable amount of information about the password. > In the usual case, Alice sends a free-form message to a set of recipients= . There's no leak in this case. I think its debatable if free form messages are actually the most common usage of PGP in practice. But thats not here or there, while working on security the worst cases are usually more important. In the usual case no one cares to sniff your email at all and even if they do you're not saying anything important, not using encryption saves cpu cycles and avoids compatibility problems. ... but it isn't the usual cases that we need to protect against. > The workarounds here are: > 1. Add a no-compression flag to the receiving key. > 2. Add "-z 0" to the command line that generates those messages. These aren't actual workarounds because they do not address the problem that an otherwise highly conscious user would be unaware that they need to take these steps. Would you also respond with "Add --cipher aes" if I were complaining that ROT13 was not a good default cipher? :) >> Care to elaborate on how they rely on it? That seems highly suspect to m= e. > tar -c source-tree | gpg key >source-tree.pgp.gz > This is also what at PGP Corp we called a "PGP Zip" file, which was imple= mented as a PGP encrypted tarball. It's done all the time in back-end syste= ms, and very likely the second largest use of PGP, where signing files is t= he most. It's a really useful idiom. Okay, I think you're using a different definition of rely. Obviously if you don't upgrade software nothing changes. Its not unusual that upgrading software changes behavior. If you upgraded to a version that didn't compress by default, the end result would be those backups would be larger. You'd either not notice and care or you would, and then after some hunting for the release notes you'd twilddle a knob and nothing irreparable happens. > I'm really sorry your ballots got spoiled. This was years ago (IIRC 2006), I don't care about the event anymore. I brought it up as a real world example of where this behavior compromised the security the users reasonably expected. Not just a theoretical weakness to counter the claims that the compression harms nothing, but an actual example of where it happened. Can you show anything as remotely strong for the assertion that compression improves security? On Wed, Mar 19, 2014 at 4:08 PM, ianG wrote: > Clearly, compression leaks info if there is some understanding of the > structure of the message. Sure. But OpenPGP is typically used to ship > lots of large documents around, and people are accustomed to getting the > compression bounty for free. > > So there is a sense that in order to protect the very few who might fall > for this case, we'll end up disadvantaging a wider population who might > actually suffer more. Well, there are compromises such as padding the post-compression size to a common interval. I'm not a super big fan of that because you still may be invisibly doomed by compression, but I assume (eek) that the cases where the leaks are really fatal are ones where the messages tend to be quite small. > The assumption here is that constant length is somehow more secure than > inconstancy. It's generally fairly intuitive to users who are being thoughtful that the length of the message is a side-channel. In the case of the Wikimedia ballots the people who set it up thought of that, and arranged it so that ballots were permutations. > Then you get the same problem; *length leaks some info*. This seems to > be with or without compression, so is this just a case of choosing ones > pathology? The distinction being that the leak happens at a level which is immediately visible to the thoughtful user vs in a way which is pretty thoroughly hidden and ... > There is no fundamental way to overcome the flaw of length in a packet which can't be completely fixed without unreasonable costs, as you note. One shouldn't decline to make improvements in some things because other things cannot be improved. One point here is that it's non-deterministic too in that you could test and confirm that your ballots all showed up the same size but the users system has a different compression preference or library (deflate is not deterministic, the encoder has freedom) and they're no longer the same size when the users use them. > I see this in my work all the time. Error packets are 10 bytes long, > success is like 500 bytes. This is leaking info ... my only solution is > to make all packets like 1024 bytes, but some of my packets are longer. > How far do I go? Answer: I've got better things to worry about right > now. YMMV. Padding to reduce the leakage is interesting even if it doesn't eliminate it entirely because its cheap, and obscures the least significant bits which often (ahem, assumptions) are the greatest entropy leak. At some point it's indeed too costly to fix and not worth it. But I argue that getting the details as right as possible is why people should be using standards and popular software and not just encrypting everything on their own. From nobody Thu Mar 20 00:53:35 2014 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 C36BF1A0674 for ; Thu, 20 Mar 2014 00:53:33 -0700 (PDT) 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, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, 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 3wXQNX5HAJw4 for ; Thu, 20 Mar 2014 00:53:32 -0700 (PDT) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 493C11A066E for ; Thu, 20 Mar 2014 00:53:32 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id d49so314484eek.27 for ; Thu, 20 Mar 2014 00:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=CtqTsObcUbqp/4pPiC04vCgYY2oFgrrbxMSjRSwts48=; b=r7L4oqufLwaCsc93nkWVhCG/94F0zm6zZ+kgI+N2dUwlqu2xWuxYfn83Frz0G9QL/U CRcowyG+5YXP/Fcd1jFLGMr50zfB4fN2wbFDofxuYTZYfOjqQOu5vhDOtibG91C7sBmN +Qu01BJh/lcmeNa74aGE7WPXurQlysQG3EHhMxgypVVqwvU83IA6/fT2BK874x844w/0 r3BDrWXeO2tg7evbT5iuGe7ZnbdV/08LtbNlfZf9PzpKfcv2RuIIrYjbAWeOAgsf2vQ1 9ud2115IKa6Vu57FTc8HAADe45W9WxamMQMmslE0sqJ2dFljOLhhunz0Ud9e7ZRveVNa qrrA== MIME-Version: 1.0 X-Received: by 10.15.31.137 with SMTP id y9mr40306798eeu.12.1395302002826; Thu, 20 Mar 2014 00:53:22 -0700 (PDT) Received: by 10.14.80.135 with HTTP; Thu, 20 Mar 2014 00:53:22 -0700 (PDT) In-Reply-To: References: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> <20140319204047.GC30999@savin> <20140319214118.GA17419@savin> Date: Thu, 20 Mar 2014 07:53:22 +0000 Message-ID: From: Nicholas Cole To: "openpgp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/RlkgZtqvd6K1wGBi2Qqnhh9Jjhs Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 20 Mar 2014 07:53:34 -0000 On Wed, Mar 19, 2014 at 10:58 PM, Jon Callas wrote: > > On Mar 19, 2014, at 3:04 PM, Gregory Maxwell wrote: > >> It's a very highly surprising failure mode which leaks information >> about the plaintext by encoding it into the size, one which baffels >> otherwise expert users of the sort who would post to the openpgp list >> to exclaim "What's being leaked by compression? Really, I don't get >> it." > > It is! It's a really cool failure mode, and I think you should write it u= p and submit it to some security conference. > > However, as I said, it's an exception case. It's also an exception case t= hat you didn't explain very well. Let me try to help: > > Zelda is collecting some ballots. The ballots are all text and constant l= ength. The voters, Vernon_i, will each edit the text ballots with their vot= es, but the resultant ballots will remain constant length. > > If the ballots are encrypted with compression, there may be information l= eaks because the different patterns of voting in the ballot. In the simples= t case where there is only one item on the ballot, it is possible that vote= can be discerned despite the raw plaintext being constant length. > > I think I got that more or less right. > > However, there are two workarounds for this: > > 1. Zelda adds a no-compression preference to her key. > 2. The voting system uses the "-z 0" option in a gpg command. > > >> Voting isn't the only case where compression leaks data about the >> plain-text, it's just one where I know that it cause and actual >> compromise, with actual expert users, in actual practice. > > Please give other cases. This discussion reminds me (trivially) of the example of university or job acceptance or rejection letters. In most cases the size of the envelope usually reveals the content of the message, since an acceptance letter will come with all sorts of additional forms etc. There are many cases where the size of the message reveals something about the content, compression or no compression. Less trivially - voting systems online are really hard. I remember that _Applied Cryptography_ devoted a whole chapter to the issue. In this case compression unexpectedly (for the users) added to the message frustrated efforts at secrecy that were based on assumptions about message length. It is worth someone writing up this experience (I can't find any documentation of it online). I think it is a bit of a stretch to say that compression itself is bad. It just happened to be unhelpful in this case. As you note above, Jon, the key used for voting could have had no compression preference and all would have been well. N. From nobody Thu Mar 20 04:37:00 2014 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 2697C1A0732 for ; Thu, 20 Mar 2014 04:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 m0zbMfrhFDRa for ; Thu, 20 Mar 2014 04:36:57 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id D58911A06CF for ; Thu, 20 Mar 2014 04:36:56 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1WQbHD-0006ts-3m for ; Thu, 20 Mar 2014 12:36:47 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1WQb62-0006qR-FJ; Thu, 20 Mar 2014 12:25:14 +0100 From: Werner Koch To: Jon Callas References: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> <20140319204047.GC30999@savin> <20140319214118.GA17419@savin> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Thu, 20 Mar 2014 12:25:14 +0100 In-Reply-To: (Jon Callas's message of "Wed, 19 Mar 2014 15:58:50 -0700") Message-ID: <87ior9ru1x.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: http://mailarchive.ietf.org/arch/msg/openpgp/rPGhyFiZplRPkixcCVzqK3a6bqU Cc: Gregory Maxwell , "openpgp@ietf.org OpenPGP" Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 20 Mar 2014 11:36:59 -0000 On Wed, 19 Mar 2014 23:58, jon@callas.org said: > I'm really sorry your ballots got spoiled. But you can fix that with > zero changes to software nor protocol. Yep. However, this a problem of the voting protocol. You would run into the same problems if you use a ZIP file with encryption or require to send an ODF document. Both compress stuff; even text editors may do that by replacing runs of white space by tabs. There are a lot of possible failure modes to be investigated which is the reason why getting electronic voting right is so hard. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Thu Mar 20 04:55:25 2014 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 66FEC1A06C3 for ; Thu, 20 Mar 2014 04:55:23 -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, 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 exbaZC9yLkeS for ; Thu, 20 Mar 2014 04:55:22 -0700 (PDT) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 33E401A06AF for ; Thu, 20 Mar 2014 04:55:22 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id i11so748965oag.34 for ; Thu, 20 Mar 2014 04:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3HfvT2JOjlqNNP8hePTbejHLv9NNY4rIFSS5XS4ip9U=; b=DoOfLndkUp51f1JdGTopt5mFXszQUGVxZbRwvDA58SP6sxYfHZGMrpBvSsZ7NlPqbr 56JZwW3atjkmzmQ588FKOJ/ad2CJJh7hqThdTmcr5UMsBkYljNAtirxFC7nuUvf5znpw 2dPKQVBtqkn2LUixe7PE9orqSkTyPagAcy76o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3HfvT2JOjlqNNP8hePTbejHLv9NNY4rIFSS5XS4ip9U=; b=R3vUTu6IxgyJWwzV61K/eMF7xDeSOVD1GP2x8ZeZhBEbbDFlLNQ7Q2O5E9E1ri+3uA uNWLUHj+WxTbY9iD8ZXxU+1oDtdesvgGdTERFevNmVhiXNFBE3dMnyxNEj7Rc1EfXe4j El0yldAhZqyv81neqfASaitYVgvI8lT4w9sQ1NhiMCOnpP2sPNkGxvH+kRRWzVnM0K1t 9CxbKakfLfn2df36Rx2S8U3eYJAAWRjsoaB5XR+EsyRt4r2Yrk9Eropjfklnirn3sMPP 5LRFekzDztfVrEKkfwjDz/KEoZTtyPGlYw42dQtvf6UqK4OZ42/pKO8lpXiwmnMSsv5S JADA== X-Gm-Message-State: ALoCoQl8GQjMOvNeuO1fqbDcjhysJhdyMV+EIwXXK1cDJ5c/RRy+VTYcQHYuAqW1JvnRjNj7mcLS MIME-Version: 1.0 X-Received: by 10.182.33.73 with SMTP id p9mr6552353obi.37.1395316513207; Thu, 20 Mar 2014 04:55:13 -0700 (PDT) Sender: alfredo@pironti.eu Received: by 10.76.151.35 with HTTP; Thu, 20 Mar 2014 04:55:13 -0700 (PDT) X-Originating-IP: [128.93.188.195] In-Reply-To: <87ior9ru1x.fsf@vigenere.g10code.de> References: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> <20140319204047.GC30999@savin> <20140319214118.GA17419@savin> <87ior9ru1x.fsf@vigenere.g10code.de> Date: Thu, 20 Mar 2014 12:55:13 +0100 X-Google-Sender-Auth: 0dVloOABOvocVG5unK-SjJGi00Y Message-ID: From: Alfredo Pironti To: Werner Koch Content-Type: multipart/alternative; boundary=047d7b5d58b41e8ff404f508714a Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/BMJxofCGRKtd3BeOxtzOsRlIOkM Cc: Gregory Maxwell , "openpgp@ietf.org OpenPGP" , Jon Callas Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 20 Mar 2014 11:55:23 -0000 --047d7b5d58b41e8ff404f508714a Content-Type: text/plain; charset=UTF-8 On Thu, Mar 20, 2014 at 12:25 PM, Werner Koch wrote: > On Wed, 19 Mar 2014 23:58, jon@callas.org said: > > > I'm really sorry your ballots got spoiled. But you can fix that with > > zero changes to software nor protocol. > > Yep. > > However, this a problem of the voting protocol. It would be, if the voting protocol was prescribing compression, or was using ballots of different lengths. Instead, here OpenPGP is to blame because it silently slips in compression. > You would run into the > same problems if you use a ZIP file with encryption or require to send > an ODF document. Both compress stuff; even text editors may do that by > replacing runs of white space by tabs. > > There are a lot of possible failure modes to be investigated which is > the reason why getting electronic voting right is so hard. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --047d7b5d58b41e8ff404f508714a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 20, 2014 at 12:25 PM, Werner Koch <= ;wk@gnupg.org> wrote:
On Wed, 1= 9 Mar 2014 23:58, jon@callas.org said= :

> I'm really sorry your ballots got spoiled. But you can fix that wi= th
> zero changes to software nor protocol.

Yep.

However, this a problem of the voting protocol.

= It would be, if the voting protocol was prescribing compression, or was usi= ng ballots of different lengths.

Instead, here OpenPGP is to b= lame because it silently slips in compression.

=C2=A0

--
Die Gedanken sind frei. =C2=A0Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
openpgp mailing list
openpgp@ietf.org
https://www.ietf.org/mailman/listinfo/openpgp

--047d7b5d58b41e8ff404f508714a-- From nobody Thu Mar 20 06:12:03 2014 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 B2B3A1A03CE for ; Thu, 20 Mar 2014 06:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 2t50zW8Gux-8 for ; Thu, 20 Mar 2014 06:11:58 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7741A06CF for ; Thu, 20 Mar 2014 06:11:57 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1WQcl9-00082j-3Z for ; Thu, 20 Mar 2014 14:11:47 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1WQce2-00078F-Qg; Thu, 20 Mar 2014 14:04:26 +0100 From: Werner Koch To: Alfredo Pironti References: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> <20140319204047.GC30999@savin> <20140319214118.GA17419@savin> <87ior9ru1x.fsf@vigenere.g10code.de> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Thu, 20 Mar 2014 14:04:26 +0100 In-Reply-To: (Alfredo Pironti's message of "Thu, 20 Mar 2014 12:55:13 +0100") Message-ID: <8761n9rpgl.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: http://mailarchive.ietf.org/arch/msg/openpgp/YHu8IP9jKsLeHmSeEku5Mpe4Tlc Cc: Gregory Maxwell , "openpgp@ietf.org OpenPGP" , Jon Callas Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 20 Mar 2014 13:12:00 -0000 On Thu, 20 Mar 2014 12:55, alfredo.pironti@inria.fr said: > It would be, if the voting protocol was prescribing compression, or was > using ballots of different lengths. I already mentioned that there are many factors which need to be consider when creating a voting protocol. All parts involved in running the protocol need to be considered - not just the length of the ballots and the encryption protocol. The described fault was made possible by a non-well defined voting protocol. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Thu Mar 20 06:51:32 2014 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 BECE61A06CF for ; Thu, 20 Mar 2014 06:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gsbbtfowbnm3 for ; Thu, 20 Mar 2014 06:51:27 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id B24761A069C for ; Thu, 20 Mar 2014 06:51:27 -0700 (PDT) Received: from tormenta.local (www2.futureware.at [78.41.115.142]) by virulha.pair.com (Postfix) with ESMTPSA id 1424C6D4AD; Thu, 20 Mar 2014 09:51:14 -0400 (EDT) Message-ID: <532AF250.3040506@iang.org> Date: Thu, 20 Mar 2014 13:51:12 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> <20140319204047.GC30999@savin> <20140319214118.GA17419@savin> <87ior9ru1x.fsf@vigenere.g10code.de> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/R-cDrybEGBcO9-CU4a5LUQ3eC88 Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 20 Mar 2014 13:51:31 -0000 On 20/03/2014 11:55 am, Alfredo Pironti wrote: > On Thu, Mar 20, 2014 at 12:25 PM, Werner Koch wrote: > >> On Wed, 19 Mar 2014 23:58, jon@callas.org said: >> >>> I'm really sorry your ballots got spoiled. But you can fix that with >>> zero changes to software nor protocol. >> >> Yep. >> >> However, this a problem of the voting protocol. > > > It would be, if the voting protocol was prescribing compression, or was > using ballots of different lengths. > > Instead, here OpenPGP is to blame because it silently slips in compression. OpenPGP doesn't make any statement about whether it preserves the length, up or down. Typically crypto can enlarge a packet, or it can shrink the packet. It's complicated, we slap on some MACs and headers and padding and stuff, so the packet ends up growing. Then some of that might be clawed back by compression or ratcheting or packet slicing or whatever. So we don't typically promise much about packet lengths. This becomes a bit more germane with say disk encryption, where for some reason people insist on not losing much space, and it becomes convenient to encrypt block for block. It *also* becomes an analogous issue when emailing from one person to another, as the trackability of names and times is an issue. As soon as you start putting some attention on what the users are doing, a generic broad protocol such as OpenPGP and also SSH and TLS and Skype and etc start to show edge cases where they might not be quite perfect for the task. Which is why there is a continuous war going on between the folks who say "use TLS and you're secure" and the folks who have to protect real value. It seems general-meets-specific brittleness has become an issue when people have a single byte protocol such as the voting protocol in use. It could be that OpenPGP could be improved for that protocol failure case, at the expense of harming all the other people who love the compression. But actually, there is a wider question here. Is the voting protocol properly thought out, and is OpenPGP really the answer? I doubt. Voting is one of the really hard problems. Most of the old-timers I know here will be able to go in and rip the guts out of any simple slapped-together voting protocol. Most of the old-timers know that voting protocols are very hard, and they don't get involved because it's so darn depressing. So I'd say, no. OpenPGP isn't to blame at all, that I see. Voting is hard, and I expect the people who put it together didn't do nearly enough thinking, or perhaps they assumed to much. I for one would not use OpenPGP to do voting. Or if I did, and it f**ked up, I'd say darn, my fault, should have known better :) iang From nobody Thu Mar 20 06:56:21 2014 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 57B821A074E for ; Thu, 20 Mar 2014 06:56:19 -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, 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 UdtXebkjN8iI for ; Thu, 20 Mar 2014 06:56:18 -0700 (PDT) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id E37A71A06D2 for ; Thu, 20 Mar 2014 06:56:17 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id n16so932829oag.27 for ; Thu, 20 Mar 2014 06:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=DnKTLDCaU0U1lP5JWMbFSC8rmYBF6lViHbwZGGvcGPU=; b=RLPLaTQ3xtDzCC2PGvu/apbXq63mepLUwTngmos1bDpMf/0KGMoAnpNl099U85IEOr Mbw62xwafBrcDOyjEa2puhTJaxhR0BGyI/mtAXMCzNcBq4OjXVt+M3YT+bnONzCzxITQ vwF3YO/mOh9FPPT69v1cMoPcBgKY5hC2vkKq8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DnKTLDCaU0U1lP5JWMbFSC8rmYBF6lViHbwZGGvcGPU=; b=YZxBE1AZ2n8n5Bz3sN3jaAZraytGfxYY2gSeE+lbVbd6GMPEdWbnGLwoL1MDvFpa6m F6SCzmwAlTxwjoWsgqWxeDFzELtLobAurqvcUvKPs2UoT8GCmdD4zpawuaN1YmE3a2Gb rdtTDF9V0n00URPBk0alxTkoGSb6ddFXyXwviNp5G8e1iPHYv/MccwQsSbmM1hZxHIBs jeKEDJxS5Y3iTWU3uVmv++63qyPY9rPvkKvzQYFVQk+zQSqyJqHzFP5TbHJEJpykF8CS qqn92ZNTurlFGjnyvVnK0cfzkfNLMHvHZVVx/oelfoGMxD0ehavP+Fq7i6QHsHrSeXGz naLg== X-Gm-Message-State: ALoCoQnjr5lQ5Z+fw4XTG9i9igwYxtEazcQSGIbkykaKJLEqiG2DIdVvevZwJjmp/hYuTZTE5M2w MIME-Version: 1.0 X-Received: by 10.60.246.165 with SMTP id xx5mr704935oec.84.1395323768395; Thu, 20 Mar 2014 06:56:08 -0700 (PDT) Sender: alfredo@pironti.eu Received: by 10.76.151.35 with HTTP; Thu, 20 Mar 2014 06:56:08 -0700 (PDT) X-Originating-IP: [128.93.188.195] In-Reply-To: References: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> <20140319204047.GC30999@savin> <20140319205517.GA6566@savin> Date: Thu, 20 Mar 2014 14:56:08 +0100 X-Google-Sender-Auth: 0bZfsehPFQm8eRNWbdLDcsEjKc0 Message-ID: From: Alfredo Pironti To: Jon Callas Content-Type: multipart/alternative; boundary=001a1136989890fcc304f50a21f1 Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/RPu0PYTgDBJJSd1JhyNrv7r62jU Cc: David Shaw , Peter Todd , "openpgp@ietf.org OpenPGP" Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 20 Mar 2014 13:56:19 -0000 --001a1136989890fcc304f50a21f1 Content-Type: text/plain; charset=UTF-8 > Compression is on by default because it improves security. I disagree. Compression is not a tool designed to build secure systems. Can you be more precise in what improvement to security compression would bring? In this discussion, the "input distribution" argument has already been debunked: a good crypto scheme works equally well regardless of the input distribution. Also attacks that seemed to be thwarted by compression turned out to be actually thwarted by the different message format that compression implies. What other security arguments would remain in favor of compression? Applications that rely on compression for functionality (not security) are another matter. If your application relies on gpg compression so crucially that a system crash would occur otherwise, then you may want to set an explicit -z X flag to gpg anyway. > It meets that goal. It is, however, a default. Defaults can be changed. > Moreover, there's a way to work around the issue in the existing standard. > Make the vote-submission key not support compression. Poof, it works. > --001a1136989890fcc304f50a21f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



Compression is on by default because it improves security.

I disagree. Compression is not a tool designed to build sec= ure systems. Can you be more precise in what improvement to security compre= ssion would bring?

In this discussion, the "input distribution" argum= ent has already been debunked: a good crypto scheme works equally well rega= rdless of the input distribution.

Also attacks that seemed to be thw= arted by compression turned out to be actually thwarted by the different me= ssage format that compression implies.

What other security arguments would remain in favor of compression?
=
Applications that rely on compression for functionality (not= security) are another matter. If your application relies on gpg compressio= n so crucially that a system crash would occur otherwise, then you may want= to set an explicit -z X flag to gpg anyway.
=C2=A0
It meets that go= al. It is, however, a default. Defaults can be changed. Moreover, there'= ;s a way to work around the issue in the existing standard. Make the vote-s= ubmission key not support compression. Poof, it works.
--001a1136989890fcc304f50a21f1-- From nobody Thu Mar 20 06:58:01 2014 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 317601A068F for ; Thu, 20 Mar 2014 06:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmEipDT7xr_1 for ; Thu, 20 Mar 2014 06:57:59 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id E71D51A03FA for ; Thu, 20 Mar 2014 06:57:58 -0700 (PDT) Received: from tormenta.local (www2.futureware.at [78.41.115.142]) by virulha.pair.com (Postfix) with ESMTPSA id 420F16D4AD; Thu, 20 Mar 2014 09:57:49 -0400 (EDT) Message-ID: <532AF3DA.6080702@iang.org> Date: Thu, 20 Mar 2014 13:57:46 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> <20140319204047.GC30999@savin> <20140319214118.GA17419@savin> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/Q3_0z7Mf1SfPbnH-ROP8YeT1BpM Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 20 Mar 2014 13:58:00 -0000 On 19/03/2014 22:58 pm, Jon Callas wrote: > > On Mar 19, 2014, at 3:04 PM, Gregory Maxwell wrote: > >> It's a very highly surprising failure mode which leaks information >> about the plaintext by encoding it into the size, one which baffels >> otherwise expert users of the sort who would post to the openpgp list >> to exclaim "What's being leaked by compression? Really, I don't get >> it." > > It is! It's a really cool failure mode, and I think you should write it up and submit it to some security conference. > > However, as I said, it's an exception case. Is there a sense that this could be more traumatic at small packets? Could we set a limit say 100b under which packets aren't compressed? Actually I think not because the attack is about comparison amongst results of different packets. The encrypting/compressing agent only knows about its one packet, it knows nothing about the other packets. So it cannot know about the effect of compression on the other packet, and how one ends up being markedly different to another. If I get it right, it all comes back to the (hidden? agreed?) assumption of length. What is our preference, to meet some assumption about length? Or to not meet it? Perhaps a comment needs to be put in the document "We make no claims as to the preservation of length. Compression can result in leaking information which can be illuminating in known-plaintext and multi-packet scenarios." iang From nobody Thu Mar 20 07:09:41 2014 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 878711A075C for ; Thu, 20 Mar 2014 07:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVLAoeCjb1Yw for ; Thu, 20 Mar 2014 07:09:37 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1601A08DA for ; Thu, 20 Mar 2014 07:09:37 -0700 (PDT) Received: from tormenta.local (www2.futureware.at [78.41.115.142]) by virulha.pair.com (Postfix) with ESMTPSA id 711A26D4AD; Thu, 20 Mar 2014 10:09:27 -0400 (EDT) Message-ID: <532AF695.5050109@iang.org> Date: Thu, 20 Mar 2014 14:09:25 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <95BD0817-D762-41DD-8444-A0C4F7AF1003@jabberwocky.com> <849778F8-1C16-4FF8-A039-6363C158BD1F@callas.org> <20140319204047.GC30999@savin> <20140319205517.GA6566@savin> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/1lWOLW8s8E_drdQ7pwscFRVkgw8 Subject: Re: [openpgp] Disabling compression in OpenPGP 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, 20 Mar 2014 14:09:38 -0000 On 20/03/2014 13:56 pm, Alfredo Pironti wrote: > In this discussion, the "input distribution" argument has already been > debunked: a good crypto scheme works equally well regardless of the input > distribution. > > Also attacks that seemed to be thwarted by compression turned out to be > actually thwarted by the different message format that compression implies. > > What other security arguments would remain in favor of compression? At the margin, if a protocol finds itself finding 2x sized messages, it may simply fail. This leads to a security failure if the result is that the user switches away or does something else like cleartext message delivery (the failure known as S/MIME). This is a very meta-argument, in that usability over time is more important than anything else. It's not a particularly good theoretical argument because it lacks context, it's more like one of those unforeseen consequences you can only find out by trying it. We may find on trying it that we lose half our user base because all their backups break; or we may not. It's also the case that we tend to prefer to protect our existing users and their apps more than we tend to help people who aren't as yet firmly in that set and dependent. This is a tendency that I argue against vociferously in any other context except an IETF WG ;) Or in simpler terms, if it ain't broke, don't fix it. iang, amused that I find myself defending the old, crusty ways!