rpaul@dolphin.omni.co (Rodian Paul) (03/06/91)
Say, with all the embellishments SGI has been adding to BSD Mail, how about some form of encrypted mail in the future? Unless of course I've missed the boat and it's allready incorporated. We tend to send a fair amount of confidential stuff between these sushi-shores and the real world, but it's a pain to have to crypt/uuencode and uudecode/crypt time and time again. Anyway could this stuff be incorporated in a future release? Cheers. ------------------------------------------------------------------------------- crow!rpaul@ccut.cc.u-tokyo.ac.jp phone: +81 (3) 5706-8357 ccut.cc.u-tokyo.ac.jp!crow!rpaul FAX: +81 (3) 5706-8437
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (03/07/91)
In article <9103061407.AA17329@dolphin.omni.co>, rpaul@dolphin.omni.co (Rodian Paul) writes: > > Say, with all the embellishments SGI has been adding to BSD Mail, how > about some form of encrypted mail in the future? Unless of course I've > missed the boat and it's allready incorporated. > > We tend to send a fair amount of confidential stuff between these > sushi-shores and the real world, but it's a pain to have to crypt/uuencode > and uudecode/crypt time and time again. Anyway could this stuff be > incorporated in a future release? Would you (or others) like a proprietary mechanism that would work only between IRIS's? Are you interested in the Internet Secure Mail project? Is the cost of "tickets" a consideration? (That uses patented RSA crypto stuff, and involves something like $25 for the right to send things. I haven't figured out if the right is for a company or for an individual, or for how many From: addresses. I don't know how many messages the ticket is lasts, nor how many months or years. There has been some recent controversy on these issues, so exact answers many not yet be knowable.) How important are "multimedia" or other non-text inclusions? What about 8-bit text? Would you rather have X.400 or other, esp. non-UNIX gateways or mechanisms? Again, do you want a standard or something proprietary? There is a lot of technical activity in the Internet and UNIX communities related to these subjects. However, it seems many of the people concerned are implementors and designers. Feel free to post answers so that the people working at other workstations companies that read this newsgroup/mailing list can see them. A consensus would benefit everyone. Vernon Schryver, vjs@sgi.com
architec@cutmcvax.cs.curtin.edu.au (Phil Dench) (03/07/91)
rpaul@dolphin.omni.co (Rodian Paul) writes: >We tend to send a fair amount of confidential stuff between these >sushi-shores and the real world, but it's a pain to have to crypt/uuencode >and uudecode/crypt time and time again. ... If you are really serious about your files secrecy, you shouldn't just be using 'crypt'. There are freely available tools around that allow anyone to get plain text within a few minutes if they can read your file and have some idea of its likely contents. As far as I know, compress before crypting gives a better level of protection (thats what I do anyway). Phil
rpaul@crow.UUCP (Rodian Paul) (03/08/91)
> Would you (or others) like a proprietary mechanism that would work only > between IRIS's? > Initially yes, as I suppose that's gunna be the easiest to incorporate and the people we tend to send encrypted mail to use IRIS's as their platforms. > Are you interested in the Internet Secure Mail project? Is the cost of > "tickets" a consideration? (That uses patented RSA crypto stuff, and > involves something like $25 for the right to send things. I haven't > figured out if the right is for a company or for an individual, or for how > many From: addresses. I don't know how many messages the ticket is lasts, > nor how many months or years. There has been some recent controversy on > these issues, so exact answers many not yet be knowable.) > I'm not familiar with the above project, but as a possible end user I'd prefer just to pay a one time fee bundled in the price of the software purchase and updates. Why not handle it like the AT&T Documenters Work Bench Package? > How important are "multimedia" or other non-text inclusions? What about > 8-bit text? Would you rather have X.400 or other, esp. non-UNIX gateways > or mechanisms? Again, do you want a standard or something proprietary? > With (I hope) SGI's continuing slant towards full ANSI C implementation (i.e. wide characters and string libraries) I would like 8bit+ handling of text. The Japanese staff here would at times like to be able to use Kanji text editors, but none of them want to bother dicking around learning kanji-emacs and stick to vi. "multimedia"? for that I don't mind sticking to encrypt/compress/uucp. I assume that when image and voice xfer's become more prevelant they will use a different transport method from good ol' Mail. As I don't deal with non-UNIX mechanisms (except the slightly mundane Mac OS) it isn't an issue with me. However, I would rather forgo the wait for a standard package at first and would happily make use of an SGI proprietary product. Anybody else out there got any comments they feel worth voicing on this subject? Post away. ------------------------------------------------------------------------------- crow!rpaul@ccut.cc.u-tokyo.ac.jp phone: +81 (3) 5706-8357 ccut.cc.u-tokyo.ac.jp!crow!rpaul FAX: +81 (3) 5706-8437
jeffg@sgi.com (Jeff C. Glover) (03/09/91)
In article <architec.668336357@cutmcvax.cs.curtin.edu.au> architec@cutmcvax.cs.curtin.edu.au (Phil Dench) writes: >As far as I know, compress before crypting gives a better level of >protection (thats what I do anyway). Wouldn't the "compress" magic number (first longword of the file) give a crypt-breaker a fairly good headstart on the rest of the contents? Jeff jeffg@loki.asd.sgi.com
rpw3@rigden.wpd.sgi.com (Rob Warnock) (03/09/91)
In article <1991Mar9.014207.16178@odin.corp.sgi.com> jeffg@sgi.com (Jeff C. Glover) writes: +--------------- | Wouldn't the "compress" magic number (first longword of the file) give | a crypt-breaker a fairly good headstart on the rest of the contents? +--------------- Yes, indeed. But it's a constant, so remove it after compressing (with "dd"?) and put it back at the other end after transmission and before decompressing. The fact that what follows the header is a permutation of the "strings" for the single characters you most often use might possibly give some aid to a perpetrator, but much less help than the fixed header. But in any case, don't use "crypt". -Rob ----- Rob Warnock, MS-1L/515 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311
architec@cutmcvax.cs.curtin.edu.au (Phil Dench) (03/10/91)
Has anyone an opinion on whether using a double crypt with diff keys gives even better protection? eg crypt < file | crypt > file.crypt There are not the problems with magics/headers that compress suffers from. And its still pretty easy to do. And secure enough to stop your average crypt breaker. Or does it just give as much encryption as a single crypt. (ie is there a key that will give you the original with just one crypt? ) Phil