somehow you understood the opposite of what i ment. the point is that using encrypted/signed s/mime with upas should be transparent. i would think the easiest way to do that would be to do the translation as close to the edges of the system as possible. those edges would be upas/fs -- which presents a mail box as a filesystem and upas/marshal which builds an rfc-2822 message for sending.
i had not thought of using s/mime for general encrypted storage. mime is not a particularly friendly or easy-to-parse format. i would think that using, say, blowfish in cbc mode would be plenty compatable. mcrypt/mhash (http://(mcrypt|mhash).sourceforge.net/), for example, could decrypt this on a unix-like machine. (not that either is svelt.) what would be the advantage of using s/mime outside of email? - erik On Tue Mar 28 09:00:28 EST 2006, [EMAIL PROTECTED] wrote: > Erik Quanstrom wrote: > // i think a better route would be to build s/mime compatable signatures > // and encryption into upas/fs and upas/marshal so applications without > // a need to know would not have to know. > > i'm not really sure what you mean by that. certainly we shouldn't > require the content-producing programs (like, say, 'cat') to know > anything about encryption, but that idea's already totally foreign to > plan 9 (cat --enable-encryption-with-aes-cbc?). > > having s/mime in upas would be wonderful, but doesn't fully address > the needs being discussed. i want to be able to store files on disk > securely, including across platforms. for that, i want a stand-alone > program (hopefully, one which could then be used in upas).
