Xref: utzoo comp.lang.postscript:6414 comp.fonts:1528
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!chinacat!woody
From: woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal)
Newsgroups: comp.lang.postscript,comp.fonts
Subject: Re: Type1 eexec decryption
Summary: There are 2 of them
Message-ID: <1648@chinacat.Unicom.COM>
Date: 18 Oct 90 03:40:28 GMT
References: <PNAKADA.90Oct16140333@pnakada.oracle.com>
Followup-To: comp.lang.postscript
Distribution: na
Organization: a guest of Unicom Systems Development, Austin
Lines: 14

In article <PNAKADA.90Oct16140333@pnakada.oracle.com>, pnakada@oracle.com (Paul Nakada) writes:
> 
> 
> This particular file contains binary data (not hexstring data) after
> the eexec call.  Following the Type1 spec for decryption yields
> garbage.  What I need to know is if there is any extra or different

Once you have decrypted the initial layer of encryption, there is an
additional layer to be dealt with.  It uses a diffrent key, and I
don't have it handy at the momement.  It does use the same algo though.


Cheers
Woody