Re: netrc.el now supports encoded files

[Simon Josefsson <jas@extundo.com>]

Ted Zlatanov <tzz@lifelogs.com> writes:

>> The AES specification limit the key lengths and block lengths, if
>> you need arbitrary data lengths or password-to-key derivation, you
>> must invent your own -- or preferably, use something prepackaged,
>> like CMS or OpenPGP.
>
> OK, so we're back to external utilities...  Maybe I'll prepend a
> number to the string, so I know the length of the data, and then pad
> it to the multiple that rijndael.el likes.  I'd really like a
> built-in cipher so we don't depend on any external utilities, even if
> it's less secure.

I agree built-in is good.  What we need is a password-to-key function.
PBKDF2 from PKCS#5 is simple to implement.  IIRC, both arbitrary data
lengths and integrity protection of data could be solved by using CCM
mode (RFC 3610).  Perhaps even a limited OpenPGP implementation is
realistic, PGG contains an OpenPGP parser now.

> Let's be realistic, most people want some security but a minimum of
> hassle.  I think that netrc.el should actually complain if the netrc
> file is plain text in future Gnus versions, *unless* the user says
> it's OK.  Whatever scheme we use, it's better than nothing.

Depends somewhat on if .authinfo is considered a Gnus file.  Perhaps
someone is symlinking it to .netrc, which is a standard file used by
other applications.

>> If the reason people want obfuscation is that real security is too
>> costly to set up, using GnuPG for .netrc is probably a good idea --
>> it is as easy to use as the current nerc.el appear to be, and at
>> least it aspires to be secure.
>
> I don't think there's Gnus support for any sort of encryption of netrc
> files using GnuPG right now.  How would one set that up?  It was the
> lack of such support that made me sit down and modify netrc.el.

Right, I was talking about the hypothetical GnuPG support in netrc.el.