(v13) Encryption using filters

This page applies to Harlequin v13.1r0 and later; both Harlequin Core and Harlequin MultiRIP.

Where a resource is proprietary or particularly valuable, it may be necessary to manage it so that it is only accessible to particular copies of the Harlequin RIP. Every license for the Harlequin RIP has a serial number (sometimes called a security number), which is usually associated with a particular security device (dongle) but sometimes with a network licensing daemon.

It is then possible to encrypt a PostScript language file containing sensitive definitions, such as the outlines for a composite font, according to a particular serial number, or to a particular OEM number so that it can only be run on a system with that serial number or OEM number. Encryption software is available from Harlequin by special arrangement.

The operator _hqxrun (in internaldict ; note the underscore) is used to decrypt a file and execute the contents (if a data file is required, the first part of the contents is a small stub of PostScript language, which determines what is to happen to the rest of it when the file is run). For fonts, this happens automatically if the file cannot be run in the usual way from a plain text file.

The technique can be applied to any file, not just fonts. However, to be of significant value, the results of interpreting it must not be stored in PostScript VM; otherwise a simple PostScript language program can easily inspect the contents in memory after decryption. Fonts in the Harlequin RIP’s DLD format can be successfully protected because the outlines are interpreted internally and never stored in generally accessible PostScript-language memory. Another possibility is a proprietary image, but you would have to ensure that the image operator could not be redefined or shadowed (see (v13) Shadowop and operator redefinition) to catch the data produced by the encryption.

For protection from casual inspection, the eexec operator (see [TYPE1]) will usually be sufficient.