[comp.unix.microport] Decrypting Files Encrypted on Another Machine

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