From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/55755 Path: main.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: netrc.el now supports encoded files Date: Tue, 06 Jan 2004 18:13:04 -0500 Organization: =?koi8-r?q?=F4=C5=CF=C4=CF=D2=20=FA=CC=C1=D4=C1=CE=CF=D7?= @ Cienfuegos Sender: ding-owner@lists.math.uh.edu Message-ID: <4nsmisy8lb.fsf@collins.bwh.harvard.edu> References: <4n3caut1yy.fsf@collins.bwh.harvard.edu> <2268.217.208.174.213.1073395735.squirrel@217.208.174.213> <4n8ykkzw59.fsf@collins.bwh.harvard.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1073430887 20620 80.91.224.253 (6 Jan 2004 23:14:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 6 Jan 2004 23:14:47 +0000 (UTC) Cc: "Ding Mailing List" Original-X-From: ding-owner+M4295@lists.math.uh.edu Wed Jan 07 00:14:39 2004 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Ae0PG-0005t9-00 for ; Wed, 07 Jan 2004 00:14:39 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1Ae0P6-0001ww-00; Tue, 06 Jan 2004 17:14:28 -0600 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1Ae0P2-0001wr-00 for ding@lists.math.uh.edu; Tue, 06 Jan 2004 17:14:24 -0600 Original-Received: from clifford.bwh.harvard.edu (clifford.bwh.harvard.edu [134.174.9.41]) by justine.libertine.org (Postfix) with ESMTP id BE4BF3A0026 for ; Tue, 6 Jan 2004 17:14:23 -0600 (CST) Original-Received: from collins.bwh.harvard.edu (collins [134.174.9.80]) by clifford.bwh.harvard.edu (8.10.2+Sun/8.11.0) with ESMTP id i06ND9726892; Tue, 6 Jan 2004 18:13:10 -0500 (EST) Original-Received: from collins.bwh.harvard.edu (localhost [127.0.0.1]) by collins.bwh.harvard.edu (8.12.9+Sun/8.11.0) with ESMTP id i06ND5uB021354; Tue, 6 Jan 2004 18:13:05 -0500 (EST) Original-Received: (from tzz@localhost) by collins.bwh.harvard.edu (8.12.9+Sun/8.12.9/Submit) id i06ND4Kf021351; Tue, 6 Jan 2004 18:13:04 -0500 (EST) Original-To: Simon Josefsson X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6;d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Followup-To: Simon Josefsson , "Ding Mailing List" In-Reply-To: (Simon Josefsson's message of "Tue, 06 Jan 2004 21:24:28 +0100") User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (usg-unix-v) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:55755 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:55755 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