rock@rancho.uucp (Rock Kent) (04/07/89)
I have been unsuccessful in taking files which have been encrypted on
an NCR Tower using crypt(1) and decrypting them on a microport Sys
V/386 system. I have successfully decrypted the files on the Tower
which were originally encrypted on the Tower. I have successfully
decrypted the files on the V/386 machine which were originally
encrypted on the V/386 machine. I believe that one of the following
may be true:
- something's getting munged up in the transfer . . . not highly
likely since I'm successfully receiving a compressed batch news
feed from the same host.
- I've some critical parameter erroneously set . . . possible, since
I'm unaware of any parameters.
- The system V release 3 crypt is different from the release 2 crypt.
- Microport's crypt is nonstandard.
I would appreciate your comments on the validity of any of the above
or comments on the portability of crypt(1).
***************************************************************************
*Rock Kent rock@rancho.uucp POB 8964, Rancho Sante Fe, CA. 92067*
***************************************************************************todd@stiatl.UUCP (Todd Merriman) (04/07/89)
In article <198@rancho.uucp> rock@rancho.uucp (Rock Kent) writes: >I have been unsuccessful in taking files which have been encrypted on >an NCR Tower using crypt(1) and decrypting them on a microport Sys >V/386 system. More than likely, integers are being stored in the encrypted file if the encrypting program is not treating the input and output files as byte streams. Due to differences in architectures between the Tower (68000, I think) and the 386, integers are stored with a different byte ordering. You need a crypt/decrypt that is specifically non-architecture dependent. ...!gatech!stiatl!todd Todd Merriman * 404-377-TOFU * Atlanta, GA Note: I have no idea what my employer's views on the subject are.
mchamp@wpi.wpi.edu (Marc J. Champagne) (04/07/89)
Assuming you try to copy the stuff over again and the 2 copies you then have are identical, the problem is probably that one machine uses a crypt routine with a SALT variation, and the other doesn't. Consult the man pages on crypt on each system. If you find that this is the problem, then let me know and I'll send you more specific instructions. Hope this helps. (NOTE: it's unlikely that the DES implementation on either machine is non-standard, but some DES programs have been modified with the SALT routines ; these can usually be disabled in a call to crypt on such a machine, if need be.)
wescott@ncrcae.Columbia.NCR.COM (Mike Wescott) (04/08/89)
In article <198@rancho.uucp> rock@rancho.uucp (Rock Kent) writes: [ about problems with NCR Tower's crypt and Microport's crypt ] > - something's getting munged up in the transfer . . . possible - check the byte order on each machine or the encrypted file > - I've some critical parameter erroneously set . . . possible, since > I'm unaware of any parameters. I don't know of any either. > - The system V release 3 crypt is different from the release 2 crypt. Nope. > - Microport's crypt is nonstandard. Possible. I don't have Microport to test against but I have checked some small files on Towers and on 4.3 Vax with no problems.
dave@pmafire.UUCP (Dave Remien) (04/08/89)
In article <4119@stiatl.UUCP= todd@stiatl.UUCP (Todd Merriman) writes: =In article <198@rancho.uucp= rock@rancho.uucp (Rock Kent) writes: ==I have been unsuccessful in taking files which have been encrypted on ==an NCR Tower using crypt(1) and decrypting them on a microport Sys ==V/386 system. = = =More than likely, integers are being stored in the encrypted file if =the encrypting program is not treating the input and output files as =byte streams. Due to differences in architectures between the Tower =(68000, I think) and the 386, integers are stored with a different =byte ordering. You need a crypt/decrypt that is specifically =non-architecture dependent. It's a cheap shot, but you could try dd'ing the file to swap bytes (dd conv=swab), then try crypt on it again.
guy@auspex.auspex.com (Guy Harris) (04/09/89)
>Possible. I don't have Microport to test against but I have checked >some small files on Towers and on 4.3 Vax with no problems. If you mean you've encrypted files on one of those machines, transferred it to the other, and decrypted them successfully, the byte order is *NOT* the problem - the VAX, like the 80386, is little-endian.
guy@auspex.auspex.com (Guy Harris) (04/09/89)
>(NOTE: it's unlikely that the DES implementation on either machine is >non-standard, but some DES programs have been modified with the SALT >routines ; these can usually be disabled in a call to crypt on such a >machine, if need be.) Huh? He was talking about CRYPT(1), not CRYPT(3); to quote the SunOS 4.0 CRYPT(1) man page, crypt implements a one-rotor machine designed along the lines of the German Enigma, but with a 256-element rotor. Methods of attack on such machines are widely known, thus crypt provides minimal security. This is also correct for "crypt" in other UNIX systems. It doesn't use DES.
dipto@umbc3.UMBC.EDU (Dipto Chakravarty) (04/14/89)
>In article <198@rancho.uucp= rock@rancho.uucp (Rock Kent) writes: >=I have been unsuccessful in taking files which have been encrypted on >=an NCR Tower using crypt(1) and decrypting them on a microport Sys >=V/386 system. > Two things come into my mind immediately. First issue is about the nature in which integers are handled in crypt.c ; it could be a problem. Second point is about the 'dd' utility with its conv=swab i.e. swap bytes option. -- dipto@umbc.bitnet ------\ /------ !uunet!umbc3!dipto dipto@umbc3.umbc.edu -------> In-real-life: <------- dipto@umbc2.umbc.edu nerwin!dipto@umbc3.umbc.edu/ Dipto Chakravarty \------ CMSC, U.of Md, 21228