Re: [openpgp] Expiration impending: <draft-ietf-openpgp-rfc4880bis-01.txt> Mon, 03 July 2017 20:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 53A53127137 for <>; Mon, 3 Jul 2017 13:34:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oKdI2_wS_P97 for <>; Mon, 3 Jul 2017 13:34:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9BC4A13147C for <>; Mon, 3 Jul 2017 13:34:47 -0700 (PDT)
Received: from [IPv6:2001:8e0:1084:de02:e9f8:f772:64a7:84e0] (unknown [IPv6:2001:8e0:1084:de02:e9f8:f772:64a7:84e0]) by (Postfix) with ESMTPSA id BEA3FFFC55 for <>; Mon, 3 Jul 2017 22:34:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1499114080; bh=gwRUPCq+bfPduZaLtryz78GKOHch07vKcPICQm4xX68=; h=Subject:To:References:From:Date:In-Reply-To; z=Subject:=20Re:=20[openpgp]=20Expiration=20impending:=0D=0A=20<dra ft-ietf-openpgp-rfc4880bis-01.txt>||Referenc es:=20<149847732613.7086.8580563657011849337.idtracker@ietfa.amsl. com>=0D=0A=20<CALaySJKxWevOZYv1hOBFV-+3T=3D2x43vmie50t6ko2A+a-gTS_>=0D=0A=20<a3a82aab-a0d9-f044-21c0-26de346bf6b3@si>=0D=0A=20<20170702232541.t25v6mf36qnrxkex@genre.crus>=0D=0A=20<1b5da7bf-d43b-fde5-f6b6-28d9c6fd6edb@gm>=0D=0A=20<94a05934-4b5c-4fb6-d127-beb0eacb47cf@sixdemonbag.o rg>=0D=0A=20<679411c5b2de4c308cbfbb3733c4fe54@usma1ex-dag1mb1.msg.>=0D=0A=20<9fbed93a-e4a7-3d00-1c53-ee587c2dface@o.b>=0D=0A=20<f3e7ad3f-4ce1-d3fc-f2a3-2981382d6a8e@sixdemonbag .org>||Date:=20Mon,=203=20Jul=20201 7=2022:34:42=20+0200|In-Reply-To:=20<f3e7ad3f-4ce1-d3fc-f2a3-29813>; b=BcF+zucsgRtvyYepYx4h+8Ti5LR4rJnKDIidBdqBAq4SejhmVHuw+c54oMLWFz/G+ VxME6Gr+e2rhV8uZXGrdlPV0cfuL+y2wLynEJg8eDdJENUTKd1XTXU7DeJKNgMz6kR NF8igGhDF/fNWdDdO3LNQTQk16wG+SoAQygG0wSI=
References: <> <> <> <> <> <> <> <> <>
Message-ID: <>
Date: Mon, 3 Jul 2017 22:34:42 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <>
Subject: Re: [openpgp] Expiration impending: <draft-ietf-openpgp-rfc4880bis-01.txt>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Jul 2017 20:34:52 -0000

On 03.07.2017 21:51, Robert J. Hansen wrote:
> The latest draft minimizes (but does not eliminate) SHA-1.  3DES is
> still a MUST-implement algorithm, and will likely be so for the ongoing
> future.  3DES has been a MUST algorithm since RFC2440, way back when;
> there's a lot of data encrypted with it and the RFC will continue to
> require 3DES be supported in order to help interoperate with old traffic.

Not being a  crypto devoloper I fully agree to keep the 3DES key for
backward compatbility.
My interest ist simply that new keys will not use 3DES by default (but
if user wishes it could be added).

>> I expierence in private an buisness live extra efforts to ensure pgp
>> communication is not using 3DES for example which
>> costs percious time in our projects.
> Why?  What problem is presented by using 3DES for your work, which is so
> severe that you have to ensure 3DES isn't used?
I work in the Payment Industry. Next to 3DES usage in EMV Cards we use
file encryption based on PCI, VISA, MC ... regulations. (PGP)
I experienced several projects where we had to again and again request
clients(not necessarily crypto professionals) to regenerate keys because
3DES was still enabled.
I asked our key manager why exactly this is a problem. He pointed me to
some regulations where a concrete do not use 3DES for file crypto is not

But he also mentioned that in the professional community within PCI it
is more or less clear to base on also rock solid more modern an more
long living ciphers like AES Family and remove 3DES for every new key.
As well it is expected that one or more regulators would disapprove 3DES
in near future.
I give you that is hear/say but It seems to me time to say slowly good
bye to old technology and base on new also proofen algorithms. Therefore
3DES for backward compatibility and opt in if wanted.
But not any more as a default.
> Seriously: it's still believed to be a strong cipher, there are no
> practical attacks on it, and no new attacks are looming on the horizon.
> 3DES is slow and it only has a 64-bit block size, but for the vast
> majority of OpenPGP usage that's not a problem.
I'm also very fund of my old Diesel VW. Great car - never had a problem
(touch on wood). But if I look at the news here where I live it is clear
my next cars will be another motor technology.
Saying if something suitable new is here and you can choose - then
choose new and proofen over old and proofen.

best regards