garyp@cognos.UUCP (Gary Puckering) (02/25/87)
I see Crypt as a tool similar to compress in it's usage. Therefore, I suggest that crypt should work like compress. That is, it's syntax should be something like this: crypt [ -k key ] file ... In this form, any file which is encrypted would be replaced with a file of the same name but with a suffix to indicate such. Compress uses ".Z" as it's suffix -- perhaps crypt could use ".X". If the key were not provided in thhe command line, then crypt (or decrypt) would prompt for it (once) just as it does now. Any comments? -- Gary Puckering 3755 Riverside Dr. Cognos Incorporated Ottawa, Ontario decvax!utzoo!dciem! (613) 738-1440 CANADA K1G 3N3 nrcaer!cognos!garyp
woods@gpu.utcs.toronto.edu (02/28/87)
I agree, a crypt which used a compress style command line would make more sense. However, how do we convince AT&T of this, and then get them to distribute fixes for everyone? Not to worry, there has been published, in source code form, an implimentation of the Unix crypt algorithm. It could be easily be modified and distributed on the net. See the February 1987 issue of Computer Language, in an article by Alan Filipski. Greg Woods.
janm@runx.ips.oz (Jan Mikkelsen) (03/06/87)
The only problem with entering the key on the command line is that it
can be seen with the 'ps' or the 'w' commands, giving away the key. This
is mentioned in one of the manuals. Which one escapes me now, however.
Jan Mikkelsen
---
ACSnet: janm@runx.ips.oz JANET: runx.ips.oz!janm@ukc
ARPA: janm%runx.ips.oz@seismo.css.gov CSNET: janm@runx.ips.oz
UUCP: {enea,hplabs,mcvax,prlb2,seismo,ubc-vision,ukc}!munnari!runx.ips.oz!janmpdg@ihdev.ATT.COM (P. D. Guthrie) (03/09/87)
In article <707@runx.ips.oz> janm@runx.OZ (Jan Mikkelsen) writes: >The only problem with entering the key on the command line is that it >can be seen with the 'ps' or the 'w' commands, giving away the key. This >is mentioned in one of the manuals. Which one escapes me now, however. Nope, both system V and Bezerkeley versions of crypt immediately destroy (by writing nulls over the argument) any indication of the arg (after copying it into another internal buffer). This way, it is *not* visible on the command line, unless you hit it at exactly the right spot. So it's not too much of a security glitch. -- Paul Guthrie ihnp4!ihdev!pdg This Brain left intentionally blank.
shipley@miro.Berkeley.EDU (Peter Shipley) (03/10/87)
In article <1274@ihdev.ATT.COM> pdg@ihdev.UUCP (55224-P. D. Guthrie) writes: >In article <707@runx.ips.oz> janm@runx.OZ (Jan Mikkelsen) writes: >>The only problem with entering the key on the command line is that it >>can be seen with the 'ps' or the 'w' commands, giving away the key. This >>is mentioned in one of the manuals. Which one escapes me now, however. > >Nope, both system V and Bezerkeley versions of crypt immediately >destroy (by writing nulls over the argument) any indication of the arg >(after copying it into another internal buffer). This way, it is >*not* visible on the command line, unless you hit it at exactly the >right spot. So it's not too much of a security glitch. > What if someone looks in your ".savehist" file? +-----------------------------------------------------------------------------+ John O'Conner email: shipley@miro.berkeley.edu Flames: cc-29@cory.berkeley.edu ucbvax!miro!shipley ucbvax!cory!cc-29 Spelling Quote: "Then one night I saw the corections: /dev/null light and now there is nothing more to see" +-----------------------------------------------------------------------------+
charles@hpcvcd.UUCP (03/11/87)
>Nope, both system V and Bezerkeley versions of crypt immediately >destroy (by writing nulls over the argument) any indication of the arg > So it's not too much of a security glitch. Ah, but if you are using ksh or csh, it is visible in your .history file. Is your .history readable? Charles Brown
zeta@runx.UUCP (03/21/87)
Please post sources - leave crypt discussions to comp.unix.wizards Flame to: /dev/null