netrc.el now supports encoded files

netrc.el now supports encoded files

[Ted Zlatanov]

I used the very timely password.el to add password support to
netrc.el, and it can now decode symmetric ciphers with OpenSSL.  The
OpenSSL binary is required, so it would be nice if someone implemented
a built-in cipher.  A helper netrc-encode function is also provided.

I have not updated the docs, please test and/or see the code if you
are interested.  It works for me, both without encodind and with it.
I'll update the docs later, but it's likely that the interface will
change before then.

Ted

Re: netrc.el now supports encoded files

[Jesper Harder]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I used the very timely password.el to add password support to
> netrc.el, and it can now decode symmetric ciphers with OpenSSL.  The
> OpenSSL binary is required, so it would be nice if someone implemented
> a built-in cipher.  A helper netrc-encode function is also provided.

I'd like to suggest a different term than »encode«.  In Gnus encode
usually doesn't imply encryption, but stuff like base64 or QP.

Re: netrc.el now supports encoded files

[Steven E. Harris]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I used the very timely password.el to add password support to
> netrc.el, and it can now decode symmetric ciphers with OpenSSL.  The
> OpenSSL binary is required, so it would be nice if someone
> implemented a built-in cipher.

This is to support an encrypted .authinfo, right?

I would also like to see GPG as an option (using symmetric ciphers as
well). Perhaps once I get your update in hand, I can look into
implementing that. I assume it's just a matter of swapping some
command-line arguments to call on gpg rather than openssl.

-- 
Steven E. Harris

Re: netrc.el now supports encoded files

[Ted Zlatanov]

On Mon, 05 Jan 2004, seh@panix.com wrote:

> This is to support an encrypted .authinfo, right?

Yes, and I just made another CVS commit to s/encode/encrypt/
everywhere as per Jesper's suggestion.

> I would also like to see GPG as an option (using symmetric ciphers
> as well). Perhaps once I get your update in hand, I can look into
> implementing that. I assume it's just a matter of swapping some
> command-line arguments to call on gpg rather than openssl.

Yes, I can add it too if you need it.  What would be really nice is a
built-in ELisp cipher, for Windows users for example.  A simple XOR or
ROT-13 based cipher would not be hard - does anyone want those or
should I (or someone else) implement a more complex one?

Ted

Re: netrc.el now supports encoded files

[Ted Zlatanov]

On Tue, 06 Jan 2004, harder@ifa.au.dk wrote:

> I'd like to suggest a different term than »encode«.  In Gnus encode
> usually doesn't imply encryption, but stuff like base64 or QP.

You're right, I've s/encode/encrypt/ now.

Thanks
Ted

Re: netrc.el now supports encoded files

[Simon Josefsson]

> I used the very timely password.el to add password support to
> netrc.el, and it can now decode symmetric ciphers with OpenSSL.  The
> OpenSSL binary is required, so it would be nice if someone implemented
> a built-in cipher.  A helper netrc-encode function is also provided.

IMHO, use GnuPG instead of OpenSSL.  I'm trying to remove the last OpenSSL
dependencies from Gnus (ssl.el and sha1-el.el are done, I'm working on
starttls.el, smime.el is the next step).  Perhaps supporting OpenSSL as
well is OK, but I think the defaults should be to use GNU tools where
available.

I wrote an elisp AES implementation some time ago
(<http://josefsson.org/aes/>) but I'm not sure using it is a good idea,
password based file encryption is more complicated than the block cipher
primitive.

Re: netrc.el now supports encoded files

[Ted Zlatanov]

On Tue, 6 Jan 2004, jas@extundo.com wrote:

> IMHO, use GnuPG instead of OpenSSL.  I'm trying to remove the last
> OpenSSL dependencies from Gnus (ssl.el and sha1-el.el are done, I'm
> working on starttls.el, smime.el is the next step).  Perhaps
> supporting OpenSSL as well is OK, but I think the defaults should be
> to use GNU tools where available.

Sure.  I don't use GnuPG, so if someone who does could give me the
command lines I'll be glad to add the Lisp code to netrc.el.
Actually I may move it all to gnus-encrypt.el or something like that.

> I wrote an elisp AES implementation some time ago
> (<http://josefsson.org/aes/>) but I'm not sure using it is a good
> idea, password based file encryption is more complicated than the
> block cipher primitive.

That looks useful in theory, but it's very slow.  I was hoping for a
faster cipher.  Should I just turn down rijndael-monte-carlo-limit
and rijndael-monte-carlo-loop or would that make the cipher
significantly less secure?  I don't know AES so I can't judge that.

The interface is pretty complicated (the string and key lengths are
limited).  Can we have a simple encrypt/decrypt function?

rijndael.el is not (currently) part of Gnus or Emacs, is that a
problem?  How should I connect it to gnus-encrypt.el, with autoloads?

Sorry for the many questions :)

Thanks
Ted

Re: netrc.el now supports encoded files

[Simon Josefsson]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Tue, 6 Jan 2004, jas@extundo.com wrote:
>
>> IMHO, use GnuPG instead of OpenSSL.  I'm trying to remove the last
>> OpenSSL dependencies from Gnus (ssl.el and sha1-el.el are done, I'm
>> working on starttls.el, smime.el is the next step).  Perhaps
>> supporting OpenSSL as well is OK, but I think the defaults should be
>> to use GNU tools where available.
>
> Sure.  I don't use GnuPG, so if someone who does could give me the
> command lines I'll be glad to add the Lisp code to netrc.el.
> Actually I may move it all to gnus-encrypt.el or something like that.

Or a crypt+++.el.  It is a generally useful feature, so perhaps it is
worth the effort to separate it from Gnus.

>> I wrote an elisp AES implementation some time ago
>> (<http://josefsson.org/aes/>) but I'm not sure using it is a good
>> idea, password based file encryption is more complicated than the
>> block cipher primitive.
>
> That looks useful in theory, but it's very slow.  I was hoping for a
> faster cipher.  Should I just turn down rijndael-monte-carlo-limit
> and rijndael-monte-carlo-loop or would that make the cipher
> significantly less secure?  I don't know AES so I can't judge that.

The monte carlo stuff is only for the self-tests.  The self tests are
very slow, but encrypting a few kilobytes of a .netrc should not be a
problem speed-wise.

> The interface is pretty complicated (the string and key lengths are
> limited).  Can we have a simple encrypt/decrypt function?

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.

I'm not sure the current netrc.el approach should be advertised as
secure, there is more to file encryption than using some block cipher
in CBC mode, and deriving the key and iv from a password.  It is more
like obfuscation.  OTOH, obfuscation is what people seem to want.  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.

Re: netrc.el now supports encoded files

[Simon Josefsson]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Sure.  I don't use GnuPG, so if someone who does could give me the
> command lines I'll be glad to add the Lisp code to netrc.el.

Encryption:

gpg --armor --symmetric < P > C

Decryption:

gpg < C

For password handling, and general IO, look at
`pgg-gpg-process-region' in pgg-gpg.el.

Perhaps supporting asymmetric methods would be useful too, but that
can be added later.

Re: netrc.el now supports encoded files

[Steven E. Harris]

Simon Josefsson <jas@extundo.com> writes:

> I'm not sure the current netrc.el approach should be advertised as
> secure, there is more to file encryption than using some block
> cipher in CBC mode, and deriving the key and iv from a password. It
> is more like obfuscation. OTOH, obfuscation is what people seem to
> want.

Now I'm confused. If encrypting the file with a symmetric cipher
doesn't count as "secure," what more would it take to make this system
secure? What's the difference between obfuscation and security in this
case?

-- 
Steven E. Harris

Re: netrc.el now supports encoded files

[Chris Green]

Ted Zlatanov <tzz@lifelogs.com> writes:

>
> Yes, I can add it too if you need it.  What would be really nice is a
> built-in ELisp cipher, for Windows users for example.  A simple XOR or
> ROT-13 based cipher would not be hard - does anyone want those or
> should I (or someone else) implement a more complex one?

base64-encode-{region,string} is what mozilla uses by default if you
don't use the passphrase stuff.

That's a plus for those times when you can open up
.mozilla/user/*/\d+.s and actually get your passwords back out of
silly webforms :>
-- 
Chris Green <cmg@dok.org>
Chicken's thinkin'

Re: netrc.el now supports encoded files

[Simon Josefsson]

"Steven E. Harris" <seh@panix.com> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> I'm not sure the current netrc.el approach should be advertised as
>> secure, there is more to file encryption than using some block
>> cipher in CBC mode, and deriving the key and iv from a password. It
>> is more like obfuscation. OTOH, obfuscation is what people seem to
>> want.
>
> Now I'm confused. If encrypting the file with a symmetric cipher
> doesn't count as "secure," what more would it take to make this system
> secure? What's the difference between obfuscation and security in this
> case?

I think one attack the current approach doesn't cover for is a
chosen-ciphertext attack.  In other words, the encrypted data is not
integrity protected.  So the attacker can replace, e.g., the final
encrypted block without being detected.  Incidentally, in the authinfo
format, the password is often the last data, so the corruption caused
in CBC mode by replacing a block doesn't have to occur.  To finish the
attack, the decrypted (garbage) password has to be leaked somehow, but
this isn't completely unlikely.  Another attack is cut'n'paste of
cipher blocks.  Consider if the user has two accounts, with a 8
character password (i.e., one block length), one on a secure server
(i.e., SSL) and one insecure (i.e., cleartext LOGIN), and the insecure
one is listed first in the .authinfo file -- the attacker can replace
the last block with the one read for the first server, thus causing
the user to send the password for the secure server to the insecure
server.  When Gnus is about to contact the secure server, it will only
read garbage in the file (because CBC mode propagate errors), but then
it may be too late.

I believe gnupg uses integrity protection, that counter these
problems.

Re: netrc.el now supports encoded files

[Simon Josefsson]

On second thought, my examples are somewhat flawed.  But I hope my
main point, that home-grown file encryption schemes are not as good as
using something standard, like OpenPGP, still stands.  Even when the
home-grown encryption is vetted by an OpenSSL command line interface.

Re: netrc.el now supports encoded files

[Ted Zlatanov]

On Tue, 06 Jan 2004, jas@extundo.com wrote:

> On second thought, my examples are somewhat flawed.  But I hope my
> main point, that home-grown file encryption schemes are not as good
> as using something standard, like OpenPGP, still stands.  Even when
> the home-grown encryption is vetted by an OpenSSL command line
> interface.

I understand your concern that we don't consider home-grown
encryption to be secure.  I want to provide something better than
plain-text passwords in the ~/.authinfo file for the average user.

The examples you give are true, but as long as a casual attacker can't
read the ~/.authinfo passwords, we've already made a big step in the
right direction.

Ted

Re: netrc.el now supports encoded files

[Ted Zlatanov]

On Tue, 06 Jan 2004, cmg@dok.org wrote:

> Ted Zlatanov <tzz@lifelogs.com> writes:
> 
>>
>> Yes, I can add it too if you need it.  What would be really nice is
>> a built-in ELisp cipher, for Windows users for example.  A simple
>> XOR or ROT-13 based cipher would not be hard - does anyone want
>> those or should I (or someone else) implement a more complex one?
> 
> base64-encode-{region,string} is what mozilla uses by default if you
> don't use the passphrase stuff.
> 
> That's a plus for those times when you can open up
> .mozilla/user/*/\d+.s and actually get your passwords back out of
> silly webforms :>

Would it be good to provide security that's very easily broken?
Simon's rijndael.el seems much better - but I'll implement something
that's easily reversed if you or someone else actually want it.

Ted

Re: netrc.el now supports encoded files

[Ted Zlatanov]

On Tue, 06 Jan 2004, jas@extundo.com wrote:

> Or a crypt+++.el.  It is a generally useful feature, so perhaps it
> is worth the effort to separate it from Gnus.

I saw crypt++.el, and it goes too far in my opinion.  There's just too
much work to use it, and it interferes with file hooks.  I'd rather
provide a simple interface to symmetric decoding of a file into a
buffer and decoding back, using external utilities or extensible
ciphers.  I'll inquire on the emacs-devel list.

> 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'm not sure the current netrc.el approach should be advertised as
> secure, there is more to file encryption than using some block
> cipher in CBC mode, and deriving the key and iv from a password.  It
> is more like obfuscation.  OTOH, obfuscation is what people seem to
> want.  

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.

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

Ted

Re: netrc.el now supports encoded files

[Ted Zlatanov]

On Tue, 06 Jan 2004, jas@extundo.com wrote:

> Ted Zlatanov <tzz@lifelogs.com> writes:
> 
>> Sure.  I don't use GnuPG, so if someone who does could give me the
>> command lines I'll be glad to add the Lisp code to netrc.el.
> 
> Encryption:
> 
> gpg --armor --symmetric < P > C
> 
> Decryption:
> 
> gpg < C

OK, thanks.

> For password handling, and general IO, look at
> `pgg-gpg-process-region' in pgg-gpg.el.

Do you want me to abstract the pgg-gpg-* functions into
gnus-encrypt.el, since they'll be used by me too and I'd rather not
duplicate code?

Ted

Re: netrc.el now supports encoded files

[Richard Hoskins]

Ted Zlatanov <tzz@lifelogs.com> writes:

> The OpenSSL binary is required, so it would be nice if someone
> implemented a built-in cipher.  A helper netrc-encode function is
> also provided.

Graham Hughes has implemented RC4 in emacs lisp.  it is available at 
http://www.xs4all.nl/~cg/ciphersaber/comp/emacs-lisp.txt

-- 
Lift me down, so I can make the Earth tremble.
                                --Bucky Katt

Re: netrc.el now supports encoded files

[Simon Josefsson]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Tue, 06 Jan 2004, cmg@dok.org wrote:
>
>> Ted Zlatanov <tzz@lifelogs.com> writes:
>> 
>>>
>>> Yes, I can add it too if you need it.  What would be really nice is
>>> a built-in ELisp cipher, for Windows users for example.  A simple
>>> XOR or ROT-13 based cipher would not be hard - does anyone want
>>> those or should I (or someone else) implement a more complex one?
>> 
>> base64-encode-{region,string} is what mozilla uses by default if you
>> don't use the passphrase stuff.
>> 
>> That's a plus for those times when you can open up
>> .mozilla/user/*/\d+.s and actually get your passwords back out of
>> silly webforms :>
>
> Would it be good to provide security that's very easily broken?
> Simon's rijndael.el seems much better - but I'll implement something
> that's easily reversed if you or someone else actually want it.

Perhaps several levels are useful.  But none of this is enabled by
default, is it?  I mean, users have to request encryption of .authinfo
for it to happen, right?

But I'm not sure I see the advantage of b64 over plain-text.

Anyway, it sounds more and more like this could be a separate package.
"encrypt.el" is available, AFAICT.  Using various hooks, such a
package might be able to work without the cooperation of Gnus at all.
Then you could request automatic encryption/decrypt of ~/.newsrc.eld
by saying (add-to-list 'encrypt-file-alist '("~/.newsrc.eld."
gpg-symmetric)) or something like that.

But that sounds like work, so simply adding gpg support to netrc.el
might be sufficient.

Re: netrc.el now supports encoded files

[Simon Josefsson]

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.

Re: netrc.el now supports encoded files

[Ted Zlatanov]

On Wed, 07 Jan 2004, jas@extundo.com wrote:

> Perhaps several levels are useful.  But none of this is enabled by
> default, is it?  I mean, users have to request encryption of
> .authinfo for it to happen, right?

Right, netrc-encrypting-method has to be set to something right now.

> But I'm not sure I see the advantage of b64 over plain-text.

grep -i password /home/*/.??*

would not work, for instance, if trivial obfuscation is applied.
It's better that the user makes the file unreadable to outsiders, but
in reality users don't realize this if it happens.

> Anyway, it sounds more and more like this could be a separate
> package.  "encrypt.el" is available, AFAICT.  Using various hooks,
> such a package might be able to work without the cooperation of Gnus
> at all.  Then you could request automatic encryption/decrypt of
> ~/.newsrc.eld by saying (add-to-list 'encrypt-file-alist
> '("~/.newsrc.eld."  gpg-symmetric)) or something like that.

I think cooperation is good.  Trying to hide the reality of the
situation - that we're encoding files with external utilities or
internal functions - is sure to cause problems in the long run.  I see
it in crypt++.el, and it's not pretty.  It interferes with many
packages.

I'd prefer that Gnus use the functions below, which will revert to the
regular Emacs functions unless they see the file in
gnus-encrypt-file-alist as you suggest above.  It's sort of a
compromise, but I think trying to be too clever won't work :)

> But that sounds like work, so simply adding gpg support to netrc.el
> might be sufficient.

I think I'd like to start on gnus-encrypt.el.  These functions will
be available:

gnus-encrypt-insert-file-contents
gnus-encrypt-write-file-contents

and these variables:

gnus-encrypt-file-alist

The format of that variable: list of filenames or regular expressions
matched with an encrypting/decrypting method.  Methods:

'(gpg PUBKEY) ; RSA, RSA-E, RSA-S, ELG-E, DSA, ELG
'(gpg CIPHER) ; 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH
'(openssl CIPHER) ; too many to list
'(internal CIPHER) ; rijndael, RC4, XOR, Base64 etc.

What do you think?  Any comments before I start coding?

Thanks
Ted

Re: netrc.el now supports encoded files

[Simon Josefsson]

Ted Zlatanov <tzz@lifelogs.com> writes:

>> Anyway, it sounds more and more like this could be a separate
>> package.  "encrypt.el" is available, AFAICT.  Using various hooks,
>> such a package might be able to work without the cooperation of Gnus
>> at all.  Then you could request automatic encryption/decrypt of
>> ~/.newsrc.eld by saying (add-to-list 'encrypt-file-alist
>> '("~/.newsrc.eld."  gpg-symmetric)) or something like that.
>
> I think cooperation is good.  Trying to hide the reality of the
> situation - that we're encoding files with external utilities or
> internal functions - is sure to cause problems in the long run.  I see
> it in crypt++.el, and it's not pretty.  It interferes with many
> packages.

Yes.  OTOH, in some (non-Gnus) situations it might useful to be able
to "advice" a package to encrypt its files, without changing the
package.

> I think I'd like to start on gnus-encrypt.el.  These functions will
> be available:
>
> gnus-encrypt-insert-file-contents
> gnus-encrypt-write-file-contents
>
> and these variables:
>
> gnus-encrypt-file-alist
>
> The format of that variable: list of filenames or regular expressions
> matched with an encrypting/decrypting method.  Methods:
>
> '(gpg PUBKEY) ; RSA, RSA-E, RSA-S, ELG-E, DSA, ELG
> '(gpg CIPHER) ; 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH
> '(openssl CIPHER) ; too many to list
> '(internal CIPHER) ; rijndael, RC4, XOR, Base64 etc.
>
> What do you think?  Any comments before I start coding?

This sounds good to me.  And probably more reliable than any crypt++
approach.

Btw, the "ecrypto" XEmacs package contain (3)DES and Blowfish in elisp
as well.

Re: netrc.el now supports encoded files

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I think I'd like to start on gnus-encrypt.el.  These functions will
> be available:
>
> gnus-encrypt-insert-file-contents
> gnus-encrypt-write-file-contents

These sound so generic and useful that I think it would make sense to
just create encrypt.el and call them `encrypt-insert-file-contents',
etc. 

> and these variables:
>
> gnus-encrypt-file-alist

That definitely sounds like a Gnus, thing, though.

> The format of that variable: list of filenames or regular expressions
> matched with an encrypting/decrypting method.  Methods:
>
> '(gpg PUBKEY) ; RSA, RSA-E, RSA-S, ELG-E, DSA, ELG
> '(gpg CIPHER) ; 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH
> '(openssl CIPHER) ; too many to list
> '(internal CIPHER) ; rijndael, RC4, XOR, Base64 etc.
>
> What do you think?  Any comments before I start coding?

Sounds good.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: netrc.el now supports encoded files

[Chris Green]

Simon Josefsson <jas@extundo.com> writes:

> Perhaps several levels are useful.  But none of this is enabled by
> default, is it?  I mean, users have to request encryption of .authinfo
> for it to happen, right?
>
> But I'm not sure I see the advantage of b64 over plain-text.

If it's only obfuscation, base64 does the trick and its good enough in
mozilla that I can edit a domain name and be pretty confident that
someone over my shoulder isn't doing the transform in their head.

It's not secure but IMO it's better than rot13 ( which is what I was
replying to ).

My vote for what I would want for gnus is gpg.  The base64 is perhaps
an easy obfuscation if there is no gpg binary available or people
don't want to bother with passphrases.
-- 
Chris Green <cmg@dok.org>
You now have 14 minutes to reach minimum safe distance.

Re: netrc.el now supports encoded files

[Ted Zlatanov]

On Wed, 07 Jan 2004, cmg@dok.org wrote:

> My vote for what I would want for gnus is gpg.  The base64 is
> perhaps an easy obfuscation if there is no gpg binary available or
> people don't want to bother with passphrases.

GPG will be an option.  I'll follow up to Lars' comment with more details.

Ted

Re: netrc.el now supports encoded files

[Ted Zlatanov]

On Wed, 07 Jan 2004, larsi@gnus.org wrote:

> Ted Zlatanov <tzz@lifelogs.com> writes:
> 
>> I think I'd like to start on gnus-encrypt.el.  These functions will
>> be available:
>>
>> gnus-encrypt-insert-file-contents
>> gnus-encrypt-write-file-contents
> 
> These sound so generic and useful that I think it would make sense
> to just create encrypt.el and call them
> `encrypt-insert-file-contents', etc.

OK, here's the plan.

The crypt++.el package, which does a lot of what I need to do, will
be the starting point.  I'll call my package gencrypt.el.  I talked
to Karl Berry, the current crypt++.el maintainer, and he's OK with
this.

Gnus will get gnus-encrypt.el which will use

gencrypt-insert-file-contents (+ arguments)
gencrypt-write-file-contents (+ arguments)

to provide

gnus-encrypt-insert-file-contents (no arguments if possible)
gnus-encrypt-write-file-contents (no arguments if possible)

using the gnus-encrypt-file-alist association list we discussed.
This will let Gnus internals move to using the gnus-encrypt.el
functions without modifications.

Without gencrypt.el, gnus-encrypt.el will provide four options:
OpenSSL encoding (I'll just copy what I have in netrc.el), GPG
encoding (simple command-line invocation with --armor), base64
encoding, and no encoding.

Ted

Re: netrc.el now supports encoded files

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]

On Thu, 08 Jan 2004, tzz@lifelogs.com wrote:

> Without gencrypt.el, gnus-encrypt.el will provide four options:
> OpenSSL encoding (I'll just copy what I have in netrc.el), GPG
> encoding (simple command-line invocation with --armor), base64
> encoding, and no encoding.

I've finished the GPG and one built-in cipher for gnus-encrypt.el.
Attached is the code.  I need a few people to test it, and any
feedback is appreciated of course.  OpenSSL and base64 encodings were
not implemented because I didn't think they were really necessary.
OpenSSL support will probably come through gencrypt.el when that's
released.

If the *encoding* fails, the file is saved in plain text.

If the *decoding* fails, we load the encoded file.  Tough break.

The built-in XOR filter is actually pretty nice.  It's not good
encryption, but it's definitely a step up from base64, and it had
decent speed when I tried it.

The major issue is that, for simplicity, gnus-encrypt.el only works
with whole buffers.  I don't think more will be necessary for Gnus
development, although the gencrypt.el code will definitely support
encoding of regions and such.

If and when gnus-encrypt.el goes into the Gnus CVS, I will start
adding support for it everywhere in Gnus.  Without setting
gnus-encrypt-file-alist, users will see absolutely no effect from the
gnus-encrypt functions.

Ted


[-- Attachment #2: gnus-encrypt.el --]
[-- Type: application/emacs-lisp, Size: 8436 bytes --]