From nobody Sun Apr 13 15:30:51 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 4FF2B1A02D7 for ; Sun, 13 Apr 2014 15:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.749 X-Spam-Level: * X-Spam-Status: No, score=1.749 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5L6p1wpInoq for ; Sun, 13 Apr 2014 15:30:46 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.13]) by ietfa.amsl.com (Postfix) with ESMTP id 77CD61A0241 for ; Sun, 13 Apr 2014 15:30:46 -0700 (PDT) Received: from inno.localnet (e178138207.adsl.alicedsl.de [85.178.138.207]) by mrelayeu.kundenserver.de (node=mreue105) with ESMTP (Nemesis) id 0MXovv-1WVR0G1Qnv-00WpTc; Mon, 14 Apr 2014 00:30:43 +0200 From: Hauke Laging To: openpgp@ietf.org Date: Mon, 14 Apr 2014 00:30:35 +0200 Message-ID: <1581476.osxlhUbTDj@inno> User-Agent: KMail/4.11.5 (Linux/3.11.10-7-desktop; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1597516.AQKeoBsODp"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Provags-ID: V02:K0:KJsgE8lxHgSluydVbQwt4pFr1lQKNtfdBl4Ac2WayhJ fCvwyBKqFuNSeyDUZlW0wCkBMDsgkCgWGMNjHguOddTdu2NJ8S wiDjDjJ51bG4iGs1oPKsyCnYitWGv+71Ct9pqT6oY1rb0iIGHL jayP25WxiOBakg/tthrWZefsInUUkLGJ/XOXCd7ojjGTrraytO RQpd6sOUuO5oz4ews1FIfintzhftwBIZ1FOvwJ//5y+TNk+8Fp 2Xs+ZiPj1IPIlDdv9/KvssmKIahLZ4aaPAjTIK5X9fWs1ppC9x TQPbPIT+sZZ9+17669z4fDL7TMvRtRzxaOucHU4HmIoaRZWi+1 tUveg3junNjS2BkmuBoI= Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/OJpvzwV_4fzUpost8YQNNGvZe5E 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: Sun, 13 Apr 2014 22:30:48 -0000 --nextPart1597516.AQKeoBsODp Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Am Do 20.03.2014, 07:53:22 schrieb Nicholas Cole: > There are many cases where the size of the message reveals something > about the content, compression or no compression. Would it help to have to possibility to add a certain amount of=20 (ignored) random data to an encrypted packet? In that case an OpenPGP application could =E2=80=93 regardless of compr= ession =E2=80=93=20 be configured (in appropriate situations) to create packets which e.g. a) have a certain minimum length b) have a length which is a multiple of a block size (e.g. 1K, 2K but=20= not 1234 bytes) Hauke =2D-=20 Crypto f=C3=BCr alle: http://www.openpgp-schulungen.de/fuer/unterstuetz= er/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 --nextPart1597516.AQKeoBsODp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAABCAAGBQJTSxARAAoJEEhrF6s/lq2O7bQH/2BwLRFSG9Pu0GUU525iqXXf 7ZlJKr6zRkeeFCAAEeJQR765I5ySgWoFMRLTqnwYXxoCtyBJZHxJmvb6InPcdcbN WQ/7sUGASn45wUQqfS1qtlFykF0TdGq8YSXp30kAGTikWf/PWWKFGJYMsosGP8wb uTc67NXlLT+Y+ShsL9jjpJqUtWbR1lqQURYbhC95Yg/r/xZjZrDoxv6efXlfBimN 6pxgfutqaJ9ASMCYZeTxKRCONAnYxDgrTgeLbZe/zyWGtHln46imHj9nErcZquBA f534QXhHooFZPwqgdCEUSr0oYfY0SP+lB9Xa+u7GSQElSxqMsTMpEfsbrGVA6Ts= =5Mzl -----END PGP SIGNATURE----- --nextPart1597516.AQKeoBsODp-- From nobody Sun Apr 13 15:53: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 E5F0C1A0251 for ; Sun, 13 Apr 2014 15:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 09EtpCzq-Nvv for ; Sun, 13 Apr 2014 15:52:57 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id CAE311A0241 for ; Sun, 13 Apr 2014 15:52:56 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id pn19so5047654lab.6 for ; Sun, 13 Apr 2014 15:52:54 -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=DfUavmWG9CBXWcGKKj6szfazrVkduEJs2xpXoimyzhw=; b=G5daFlAs2xpO3zHF8fGbjyXQxywxHldng6kxwYnJzRRl4Mlr0LaK8WrvAob5ZNd0Lu Ue32H4DhKPq8J/7cq3LS8HRsapHwmWTGhbYZILyojQrY5BqaXbtnaGgxnWJvZsSJnGLH tNAKP6obcVQLJf3vakjepKJ37rhZk/tw/rwidHLmcokx2OOlJKh/ZRhjUdtttp4RRDb7 unxehxF2Jpcwkisr5yD3QWaw3VNGAzzBW2ETRRDFvD/rWxbljtitrWl8tFV/SaurLU8f HKHA1RZJPPC5texrPs2KZPZXyVETI+gfa4q4CQClNT13llLVgm/le/TZDqQncMxG6poL wslw== MIME-Version: 1.0 X-Received: by 10.152.203.129 with SMTP id kq1mr27173891lac.6.1397429573989; Sun, 13 Apr 2014 15:52:53 -0700 (PDT) Received: by 10.112.89.68 with HTTP; Sun, 13 Apr 2014 15:52:53 -0700 (PDT) In-Reply-To: <1581476.osxlhUbTDj@inno> References: <1581476.osxlhUbTDj@inno> Date: Sun, 13 Apr 2014 15:52:53 -0700 Message-ID: From: Gregory Maxwell To: Hauke Laging Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/z7FYZPtnEAKz9VSVdXvAKpLmKfY 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: Sun, 13 Apr 2014 22:52:59 -0000 On Sun, Apr 13, 2014 at 3:30 PM, Hauke Laging wrote: >> There are many cases where the size of the message reveals something >> about the content, compression or no compression. > Would it help to have to possibility to add a certain amount of > (ignored) random data to an encrypted packet? > In that case an OpenPGP application could =E2=80=93 regardless of compres= sion =E2=80=93 > be configured (in appropriate situations) to create packets which e.g. > > a) have a certain minimum length > b) have a length which is a multiple of a block size (e.g. 1K, 2K but > not 1234 bytes) Yes, I believe many of the most devastating cases would be addressed by quantizing the sizes. There may still be cases where the user is compromised=E2=80=94 where the revealing data is only a single bit and wher= e the sizes put it near a quantization threshold, but the number of cases where the user's privacy is quietly compromised would be fewer. I continue to hold the view that an implementation which expects perfectly informed users to be aware of and avoid subtle, unadvertised, and format specific information leaks will (and, as I pointed out, has) fail to produce real users with the advertised and expected level of security. The great challenge of a general tool is that you cannot assume a narrow threat model or a sophisticated user. In some cases the attacker may even be the party specifying the protocol, relying on subtle behavior the underlying trusted components (like openpgp) to compromise the system. As a result perfect security is almost certantly impossible, but there are implementation optimizations like disabling compression for small messages, where it is never very useful and sometimes actively harmful, and quantizing sizes which can provide a practical improvement in a world where users aren't perfect and attackers don't play nice. I think these optimizations should be well specified and recommended at the SHOULD level. As an aside, I note that RFC6562 SHOULD NOTs variable rate compression for the application of secure VoIP for highly sensitive information. From nobody Sat Apr 26 00:47: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 88E5A1A0455 for ; Sat, 26 Apr 2014 00:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 wSDDV_01zr5g for ; Sat, 26 Apr 2014 00:47:45 -0700 (PDT) Received: from atom.fsij.org (atom.fsij.org [211.14.6.125]) by ietfa.amsl.com (Postfix) with ESMTP id 57FDD1A030D for ; Sat, 26 Apr 2014 00:47:45 -0700 (PDT) Received: from c203214.dynamic.ppp.asahi-net.or.jp ([210.155.203.214] helo=[192.168.1.10]) by atom.fsij.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1WdxKi-0007yo-1F; Sat, 26 Apr 2014 16:47:36 +0900 Message-ID: <1398498450.5174.1.camel@latx1.gniibe.org> From: NIIBE Yutaka To: openpgp@ietf.org Date: Sat, 26 Apr 2014 16:47:30 +0900 Organization: Free Software Initiative of Japan Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 210.155.203.214 X-SA-Exim-Mail-From: gniibe@fsij.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on atom.fsij.org) Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/zi7pzv83IvPk-zTlRyLcb8LtyZs Subject: [openpgp] Curve25519 for public key encryption 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, 26 Apr 2014 07:47:47 -0000 Hello, I am doing some experiment with GnuPG to support Curve25519 for public key encryption. When we apply draft-jivsov-ecc-compact-05 (that is, using x-coordinate only), I think that we could extend the specification of RFC6637 for Curve25519 naturally. RFC6637 assumes that the cofactor is 1, while Curve25519's is 8. But this is no problem. Since Curve25519's private key is defined as multiple of 8 (= its cofactor), we don't need to change any computation of ECDH. Thus, I think that all that we need is OID of Curve25519, if it is OK for us to keep using MPI format (in the original implementation of Curve25519, representation is little endian). If this support of Curve25519 in OpenPGP has no conflict to RFC6637 + draft-jivsov-ecc-compact-05, I'm going to work enhancement of OpenPGPcard (the smartcard specification) for Curve25519, too. Any suggestions or comments? --