General remarks on uses of OpenPGP
nagydani@epointsystem.org (Daniel A. Nagy) Tue, 28 March 2006 09:57 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOAx4-0007n2-CG for openpgp-archive@lists.ietf.org; Tue, 28 Mar 2006 04:57:26 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOAx4-0001y4-0m for openpgp-archive@lists.ietf.org; Tue, 28 Mar 2006 04:57:26 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S9bHW9053310; Tue, 28 Mar 2006 02:37:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2S9bHpa053309; Tue, 28 Mar 2006 02:37:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2S9bFLF053303 for <ietf-openpgp@imc.org>; Tue, 28 Mar 2006 02:37:16 -0700 (MST) (envelope-from nagydani@epointsystem.org)
Received: by mail.epointsystem.org (Postfix, from userid 1001) id 20BD05447; Tue, 28 Mar 2006 11:37:15 +0200 (CEST)
Date: Tue, 28 Mar 2006 11:37:15 +0200
To: ietf-openpgp@imc.org
Subject: General remarks on uses of OpenPGP
Message-ID: <20060328093715.GA20426@epointsystem.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.9i
From: nagydani@epointsystem.org
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
This message is not directly relevant for the ongoing discussions, just a few thoughts inspired by them. The short summary is that I am advocating a conservative approach, and arguing against changing anything in the minimal requirements. Historically OpenPGP (and PGP) has been designed with the hypotetical NSA as an adversary in mind. As long as being secure against extremely well-funded adversaries does not put unnecessary burden on those of us, who only have less powerful enemies to worry about, this approach is more than welcome. It is great marketing, a safe bet, etc., etc., etc. The low cost of OpenPGP-based encryption of email has made it the solution of choice for the majority of those who care at all, even in the face of the fact that S/MIME is supported out-of-the-box on all popular email clients, while adding OpenPGP support requires non-trivial effort. This feat alone justifies the general approach of OpenPGP. I am extremely greatful to this WG of IETF for your choice of MUST algorithms, as it allowed me to implement the standard on the J2SE 1.4 platform without implementing any cryptography. Even on the somewhat crypto-crippled versions of Java, it is a full-strength, interoperable implementation. It allowed me to implement java applets weighing a few dozen kilobytes(!) that perform various PGP-operations and run on the vast majority of java-enabled browsers. A full-fledged GUI-client that does everything except key management fits into 140 kilobytes, including the gui. It is precisely the 3DES, SHA1, MD5, RSA-s, DSA-s, RSA-e and ELG-e choice of alrogithms that made this possible. Requiring AES or IDEA would have made it much more difficult, although I understand that letting go of IDEA and excluding Rijndael were both controversial choices at the time. If the standard's requirements exceed the bare minimum that one can count on in all sorts of legacy systems still in wide use, just to keep everybody secure against the hypotetical NSA (not the real one, by the way -- cryptography alone cannot achieve that), it would put an unnecessary burden on all sorts of practical applications where this is not a requirement. I think, that the standard should definitely allow building heavy-duty super-secure and super-efficient cryptosystems, if someone feels like that, but _requiring_ excessive strength and efficiency would be, well, excessive. -- Daniel
- General remarks on uses of OpenPGP Daniel A. Nagy