secure sign & encrypt

[Adrian 'Dagurashibanipal' von Bidder]

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.

cheers
-- vbi

-- 
secure email with gpg                 avbidder at fortytwo.ch: key id
0x92082481
                                      avbidder at acter.ch:    key id
0x5E4B731F

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : /pipermail/attachments/20020522/777bf6c8/attachment.bin