[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Moving files from lisp/gnus/ to lisp/net/?

From: Simon Josefsson
Subject: Re: Moving files from lisp/gnus/ to lisp/net/?
Date: Mon, 01 Nov 2004 21:31:47 +0100
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)

Ted Zlatanov <address@hidden> writes:

> On Fri, 29 Oct 2004, address@hidden wrote:
>> It was added later on, not by me.  I suppose he who added it might
>> argue that it is useful, though.  I tend to think that there should
>> only be one worked out interface.  (I'm not saying the current API,
>> without p-r-a-a is the best interface, only that it would be better
>> with only one interface.)
> I added it for the purpose of decrypting a file, which is a one-shot
> deal.  If it fails, it fails - you don't try to reopen the file as you
> would a network connection, and you don't necessarily know that it
> failed (for example, the encrypt.el XOR cipher produces garbage with a
> bad password but otherwise there's no indication that there was an
> error).  The only problem is that the password is then memorized, so
> if it was bad it will stay around.
> Either I should add an option to ask y/n if the decryption was OK
> after the first time a password is entered, or I will give the user a
> way to clear a bad password.  Any other suggestions are welcome.
> Please note again that we don't necessarily know the decryption
> failed.  Maybe we should not memorize encryption passwords at all?
> That would be tedious, though, if you encrypt a lot of files with the
> same cipher...

I understand the problem.  One solution is to simply not use
encryption methods that doesn't provide integrity?  Then the
decryption process would know if the password worked or not.  I
believe that, in general, encryption mechanisms that do not offer
integrity protection are questionable.  The XOR key derivation from
password seem a bit fragile, too.  On the other hand, I realize that
only using GnuPG may create more work for the user.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]