[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.