secure sign & encrypt
Adrian 'Dagurashibanipal' von Bidder
avbidder at fortytwo.ch
Wed May 22 10:50:02 CEST 2002
On Tue, 2002-05-21 at 18:32, Robert J. Hansen wrote:
> > not be the case. The open question is basically if the user should be
> > educated that the software does not work the way they think (hard, I
> > think), or if the software should be modified to match the users
> > (reasonable, imho) expectations.
> "To every sociological problem there exists a technological solution which
> is cheap, easy, and wrong."
Why do locks exist, then? The existence of thieves is a purely
sociological problem, after all, and so one should not try to solve it
with technological means.
I agree it'd be breaking (I'd call it extending, but call it what you
want). But I argue that it's just automating a task the user presently
has to do manually.
Currently, to get secure, authenticated end-to-end encryption with gpg,
the sender has to sign/encrypt/sign, which presently requires at least 2
gpg invocations, and the recipient has to manually verify that the inner
and the outer signature match.
What I propose does basically just automate this task. It might do so by
literally sign/encrypt/sign, or by encrypt/sign[intended ecryption
keys|msg] (cf my proposal) - it's not the issue which of the two is
happening, though I believe the latter to be more elegant.
And I want to stress again that having an end-to-end encrypted channel
is imho a fairly basic requirement of a cryptosystem and is what the
average user is probably expecting to have if he is at the receiving end
of an encrypted channel.
secure email with gpg avbidder at fortytwo.ch: key id
avbidder at acter.ch: key id
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: This is a digitally signed message part
Url : /pipermail/attachments/20020522/777bf6c8/attachment.bin
More information about the Gnupg-devel