AW: Efail or OpenPGP is safer than S/MIME

[Fiedler Roman]

> Von: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] Im Auftrag von
>
> > On 14 May 2018, at 18:32, Werner Koch <wk at gnupg.org> wrote:
> >
> > On Mon, 14 May 2018 15:44, andrewg at andrewg.com said:
> >
> >> This all exposes one of the difficulties with trying to manage security
> >> software in a decentralised ecosystem. We end up in arguments over
> whose
> >
> > That is actually easy compared to a system which is also designed to
> > protect data at rest.  Some users may want to restore their 2 year old
> > backup to fix a problem with garbled tapes; some may want to read the
> > real documents about WMD from 2003; some may even want to be able to
> > decrypt their old love letters at the time of their silver wedding.
>
> Indeed. This is why data must be treated as a living object. If tape drive
> technology moves on, the data must be moved on. Same with file formats,
> encryption systems and dying raid arrays. Librarians and archaeologists
> understand the process of care and feeding for physical artefacts. Digital
> artefacts are no exception.

So true. By applying such procedures, the long-term costs for providing data access would not only be on the gnupg developers' side (for providing loads of backward compatibility switches in highly security critical context) but also on those users wanting to keep the data for a long time. To improve awareness on user side and also reduce their archival costs, might a "gnupg --archive" function help? It decrypts a message the same way a normal "--decrypt" would do but then reencrypts the old encrypted message plus the decrypted content and a full decryption process audit log using an "archive key".

With such a function, gnupg might have it easier to argue running a more rigid scheme for retiring old features, e.g. that first normal decryption will fail (warning about deprecation, recommending sender upgrade or --archive use) and then after some years grace period removing the code completely?