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.
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.
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