* netrc.el now supports encoded files @ 2004-01-05 23:22 Ted Zlatanov 2004-01-05 23:34 ` Jesper Harder ` (3 more replies) 0 siblings, 4 replies; 27+ messages in thread From: Ted Zlatanov @ 2004-01-05 23:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-05 23:22 netrc.el now supports encoded files Ted Zlatanov @ 2004-01-05 23:34 ` Jesper Harder 2004-01-06 1:02 ` Ted Zlatanov 2004-01-06 0:13 ` Steven E. Harris ` (2 subsequent siblings) 3 siblings, 1 reply; 27+ messages in thread From: Jesper Harder @ 2004-01-05 23:34 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-05 23:34 ` Jesper Harder @ 2004-01-06 1:02 ` Ted Zlatanov 0 siblings, 0 replies; 27+ messages in thread From: Ted Zlatanov @ 2004-01-06 1:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-05 23:22 netrc.el now supports encoded files Ted Zlatanov 2004-01-05 23:34 ` Jesper Harder @ 2004-01-06 0:13 ` Steven E. Harris 2004-01-06 1:01 ` Ted Zlatanov 2004-01-06 13:28 ` Simon Josefsson 2004-01-06 23:19 ` Richard Hoskins 3 siblings, 1 reply; 27+ messages in thread From: Steven E. Harris @ 2004-01-06 0:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-06 0:13 ` Steven E. Harris @ 2004-01-06 1:01 ` Ted Zlatanov 2004-01-06 21:57 ` Chris Green 0 siblings, 1 reply; 27+ messages in thread From: Ted Zlatanov @ 2004-01-06 1:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-06 1:01 ` Ted Zlatanov @ 2004-01-06 21:57 ` Chris Green 2004-01-06 23:00 ` Ted Zlatanov 0 siblings, 1 reply; 27+ messages in thread From: Chris Green @ 2004-01-06 21:57 UTC (permalink / raw) 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' ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-06 21:57 ` Chris Green @ 2004-01-06 23:00 ` Ted Zlatanov 2004-01-06 23:25 ` Simon Josefsson 0 siblings, 1 reply; 27+ messages in thread From: Ted Zlatanov @ 2004-01-06 23:00 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-06 23:00 ` Ted Zlatanov @ 2004-01-06 23:25 ` Simon Josefsson 2004-01-06 23:58 ` Ted Zlatanov 2004-01-07 14:47 ` Chris Green 0 siblings, 2 replies; 27+ messages in thread From: Simon Josefsson @ 2004-01-06 23:25 UTC (permalink / raw) Cc: ding 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-06 23:25 ` Simon Josefsson @ 2004-01-06 23:58 ` Ted Zlatanov 2004-01-07 0:09 ` Simon Josefsson 2004-01-07 2:53 ` Lars Magne Ingebrigtsen 2004-01-07 14:47 ` Chris Green 1 sibling, 2 replies; 27+ messages in thread From: Ted Zlatanov @ 2004-01-06 23:58 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-06 23:58 ` Ted Zlatanov @ 2004-01-07 0:09 ` Simon Josefsson 2004-01-07 2:53 ` Lars Magne Ingebrigtsen 1 sibling, 0 replies; 27+ messages in thread From: Simon Josefsson @ 2004-01-07 0:09 UTC (permalink / raw) Cc: ding 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-06 23:58 ` Ted Zlatanov 2004-01-07 0:09 ` Simon Josefsson @ 2004-01-07 2:53 ` Lars Magne Ingebrigtsen 2004-01-08 22:03 ` Ted Zlatanov 1 sibling, 1 reply; 27+ messages in thread From: Lars Magne Ingebrigtsen @ 2004-01-07 2:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-07 2:53 ` Lars Magne Ingebrigtsen @ 2004-01-08 22:03 ` Ted Zlatanov 2004-01-27 19:44 ` Ted Zlatanov 0 siblings, 1 reply; 27+ messages in thread From: Ted Zlatanov @ 2004-01-08 22:03 UTC (permalink / raw) Cc: Karl Berry, kyle_jones 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-08 22:03 ` Ted Zlatanov @ 2004-01-27 19:44 ` Ted Zlatanov 0 siblings, 0 replies; 27+ messages in thread From: Ted Zlatanov @ 2004-01-27 19:44 UTC (permalink / raw) Cc: Karl Berry, kyle_jones [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-06 23:25 ` Simon Josefsson 2004-01-06 23:58 ` Ted Zlatanov @ 2004-01-07 14:47 ` Chris Green 2004-01-08 20:48 ` Ted Zlatanov 1 sibling, 1 reply; 27+ messages in thread From: Chris Green @ 2004-01-07 14:47 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-07 14:47 ` Chris Green @ 2004-01-08 20:48 ` Ted Zlatanov 0 siblings, 0 replies; 27+ messages in thread From: Ted Zlatanov @ 2004-01-08 20:48 UTC (permalink / raw) Cc: ding 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-05 23:22 netrc.el now supports encoded files Ted Zlatanov 2004-01-05 23:34 ` Jesper Harder 2004-01-06 0:13 ` Steven E. Harris @ 2004-01-06 13:28 ` Simon Josefsson 2004-01-06 19:58 ` Ted Zlatanov 2004-01-06 23:19 ` Richard Hoskins 3 siblings, 1 reply; 27+ messages in thread From: Simon Josefsson @ 2004-01-06 13:28 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-06 13:28 ` Simon Josefsson @ 2004-01-06 19:58 ` Ted Zlatanov 2004-01-06 20:24 ` Simon Josefsson 2004-01-06 20:33 ` Simon Josefsson 0 siblings, 2 replies; 27+ messages in thread From: Ted Zlatanov @ 2004-01-06 19:58 UTC (permalink / raw) Cc: Ding Mailing List 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-06 19:58 ` Ted Zlatanov @ 2004-01-06 20:24 ` Simon Josefsson 2004-01-06 20:59 ` Steven E. Harris 2004-01-06 23:13 ` Ted Zlatanov 2004-01-06 20:33 ` Simon Josefsson 1 sibling, 2 replies; 27+ messages in thread From: Simon Josefsson @ 2004-01-06 20:24 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-06 20:24 ` Simon Josefsson @ 2004-01-06 20:59 ` Steven E. Harris 2004-01-06 22:00 ` Simon Josefsson 2004-01-06 23:13 ` Ted Zlatanov 1 sibling, 1 reply; 27+ messages in thread From: Steven E. Harris @ 2004-01-06 20:59 UTC (permalink / raw) Cc: Ding Mailing List 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-06 20:59 ` Steven E. Harris @ 2004-01-06 22:00 ` Simon Josefsson 2004-01-06 22:24 ` Simon Josefsson 0 siblings, 1 reply; 27+ messages in thread From: Simon Josefsson @ 2004-01-06 22:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-06 22:00 ` Simon Josefsson @ 2004-01-06 22:24 ` Simon Josefsson 2004-01-06 22:56 ` Ted Zlatanov 0 siblings, 1 reply; 27+ messages in thread From: Simon Josefsson @ 2004-01-06 22:24 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-06 22:24 ` Simon Josefsson @ 2004-01-06 22:56 ` Ted Zlatanov 0 siblings, 0 replies; 27+ messages in thread From: Ted Zlatanov @ 2004-01-06 22:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-06 20:24 ` Simon Josefsson 2004-01-06 20:59 ` Steven E. Harris @ 2004-01-06 23:13 ` Ted Zlatanov 2004-01-06 23:35 ` Simon Josefsson 1 sibling, 1 reply; 27+ messages in thread From: Ted Zlatanov @ 2004-01-06 23:13 UTC (permalink / raw) Cc: Ding Mailing List 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-06 23:13 ` Ted Zlatanov @ 2004-01-06 23:35 ` Simon Josefsson 0 siblings, 0 replies; 27+ messages in thread From: Simon Josefsson @ 2004-01-06 23:35 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-06 19:58 ` Ted Zlatanov 2004-01-06 20:24 ` Simon Josefsson @ 2004-01-06 20:33 ` Simon Josefsson 2004-01-06 23:14 ` Ted Zlatanov 1 sibling, 1 reply; 27+ messages in thread From: Simon Josefsson @ 2004-01-06 20:33 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-06 20:33 ` Simon Josefsson @ 2004-01-06 23:14 ` Ted Zlatanov 0 siblings, 0 replies; 27+ messages in thread From: Ted Zlatanov @ 2004-01-06 23:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: netrc.el now supports encoded files 2004-01-05 23:22 netrc.el now supports encoded files Ted Zlatanov ` (2 preceding siblings ...) 2004-01-06 13:28 ` Simon Josefsson @ 2004-01-06 23:19 ` Richard Hoskins 3 siblings, 0 replies; 27+ messages in thread From: Richard Hoskins @ 2004-01-06 23:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2004-01-27 19:44 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-01-05 23:22 netrc.el now supports encoded files Ted Zlatanov 2004-01-05 23:34 ` Jesper Harder 2004-01-06 1:02 ` Ted Zlatanov 2004-01-06 0:13 ` Steven E. Harris 2004-01-06 1:01 ` Ted Zlatanov 2004-01-06 21:57 ` Chris Green 2004-01-06 23:00 ` Ted Zlatanov 2004-01-06 23:25 ` Simon Josefsson 2004-01-06 23:58 ` Ted Zlatanov 2004-01-07 0:09 ` Simon Josefsson 2004-01-07 2:53 ` Lars Magne Ingebrigtsen 2004-01-08 22:03 ` Ted Zlatanov 2004-01-27 19:44 ` Ted Zlatanov 2004-01-07 14:47 ` Chris Green 2004-01-08 20:48 ` Ted Zlatanov 2004-01-06 13:28 ` Simon Josefsson 2004-01-06 19:58 ` Ted Zlatanov 2004-01-06 20:24 ` Simon Josefsson 2004-01-06 20:59 ` Steven E. Harris 2004-01-06 22:00 ` Simon Josefsson 2004-01-06 22:24 ` Simon Josefsson 2004-01-06 22:56 ` Ted Zlatanov 2004-01-06 23:13 ` Ted Zlatanov 2004-01-06 23:35 ` Simon Josefsson 2004-01-06 20:33 ` Simon Josefsson 2004-01-06 23:14 ` Ted Zlatanov 2004-01-06 23:19 ` Richard Hoskins
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).