pnakada@oracle.com (Paul Nakada) (10/17/90)
A question concerning eexec decryption. The font I have is from Macintosh ATM. I have moved the font data from the resource fork of the font file to a plain text file. The question I have concerns the eexec encrypted portion. 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 encryption of eexec portions on different platforms (i.e. are fonts aimed at Windows ATM different from fonts aimed at Mac ATM.. Are c1/c2/key constant accross *all* fonts/platforms? The ultimate goal of this exercise is to give GhostScript true outline fonts as opposed to the bitmap outlines which it currently uses. thanks in advance for any info.. -Paul Nakada -- Paul Nakada | Oracle Corporation | pnakada@oracle.com
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (10/18/90)
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
kevina@apple.com (This space for rent) (10/18/90)
In article <PNAKADA.90Oct16140333@pnakada.oracle.com> pnakada@oracle.com (Paul Nakada) writes: > A question concerning eexec decryption. > The font I have is from Macintosh ATM. I have moved the font data > from the resource fork of the font file to a plain text file. The > question I have concerns the eexec encrypted portion. > > 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 > encryption of eexec portions on different platforms (i.e. are fonts > aimed at Windows ATM different from fonts aimed at Mac ATM.. > There are two separate issues here: 1) the format of Type 1 font data on the Mac, and 2) eexec decryption of binary data. Type 1 fonts on the Mac are stored as POST resources. The first byte of a POST resource tells how it is to be interpreted. If the first byte is 2, then the data is stored as binary but is intended to be converted to hex as it is transmitted to the PostScript interpreter. (This info from "Supporting Downloadable PostScript Fonts" by our friend Glenn Reid, available on the Adobe file server.) When you converted the resource fork to an ordinary text file, you should have done the binary-to-hex conversion to emulate what happens on the Mac. BUT, eexec decryption *does* work on binary data! None of the public algorithms which I have seen in this group take that into account. (The relevant portion of the Type 1 spec is section 7.2.) If any of the first 8 bytes are not valid hex characters, then the encrypted data is treated as binary (i.e. one encrypted byte = one "ciphertext" byte.) Otherwise, two hex bytes are consumed for each ciphertext byte. > Are c1/c2/key constant accross *all* fonts/platforms? > They are a documented part of PostScript via the Adobe Type 1 Font Format. (But note that a different key is used for charstring encryption than for eexec encryption.) Disclaimer: I'm not on TV, but I play doctor. --Kevin Andresen [kevina@apple.com] "Orange whip? Orange whip? Three orange whips."