Patent Publication Number: US-2003231767-A1

Title: Efficient encryption of image data

Description:
CROSS-REFERENCE TO RELATED PATENT APPLICATIONS  
       [0001] EPO Priority Application 02008424.0, filed Apr. 12, 2002 including the specification, drawings, claims and abstract, is incorporated herein by reference in its entirety.  
       FIELD OF THE INVENTION  
       [0002] The present invention relates to encryption of data, and particularly, although not exclusively to encryption of image data files having relatively large size, for example image posters and the like.  
       BACKGROUND OF THE INVENTION  
       [0003] It is known in the prior art to download image files over the internet to a users computer via a web-browser. Typically, such image files are relatively small in data size, however there are still significant delays due to the limited bit-rate capacity of local loop internet connections, and data processing capacity of legacy computers connected to the internet. Content owners may wish to apply levels of encryption protection to image content, since there is value in such image content, which may also be legally protected by copyright. For relatively small images, such as thumbnail images or VDU screen sized images which will print on A4 size paper, and contained for example in JPEG files, delivery of encrypted JPEG files is known in the prior art. Download and processing times are of the order of a few seconds to a few minutes depending on the age of and processing capability of the receiving computer, and the bit rate capacity of the local loop internet connection.  
       [0004] For e-service applications, where an image data is being delivered as a product or service, it is known to encrypt an entire image file which is delivered to a receiving device, for example operated by a customer. The image file needs to be decrypted by the receiving device.  
       [0005] In U.S. Pat. No. 5,703,951, there is disclosed a system for delivering encrypted data on a portable data storage media which may be physically delivered, and in which an access code is transmitted electronically from a location to enable a person receiving the portable data storage media to decrypt the received encrypted data, when in possession of both of the access code, and the encrypted data. The method in U.S. Pat. No. 5,703,951 relies upon full encryption of data stored on the data storage media, which has to be decrypted at a destination device.  
       [0006] Prior art methods for encrypting JPEG image data involve applying a symmetric cipher over an entire image data. Whilst symmetric ciphers may be efficient compared to asymmetric ciphers, the fact that the entire image must be passed through a cipher incurs a further data processing delay in encrypting a file and requires data processing capacity at a receiving device. Consequently it is inefficient to encrypt large JPEG files or other image data files for transmission over a medium such as the Internet, where download and print times for files should be low. To make the medium practically usable for files having data sizes of 5 megabytes to 100 megabytes or above, the data processing capability required to decrypt a file at a receiving device significantly slows down the efficient receipt and processing of image data at the receiving device.  
       [0007] In WO 00/31964, there is disclosed a method of partial encryption of an image file, in which different levels of quality of image data are transmitted, where successively higher levels of quality image data are protected by successive levels of encryption. A low quality image data is left unencrypted, whereas a next level of medium quality image data is encrypted by a first encryption method and a high quality image data is encrypted by a second encryption method. In the system disclosed in WO 00/31964, where encryption is applied, this relies upon encryption of a whole image data.  
       [0008] Efficient coding techniques have been applied to streaming media such as those in MPEG format. Whilst the end goal may be the same as for JPEG encryption, i.e. efficient decryption, the motivations for MPEG format encryption is different. In MPEG systems, streaming media has to be rendered in real time and must meet quality of service constraints.  
       [0009] In contrast, JPEG files containing large still images have no such real time streaming restriction, and consequently in the prior art less effort has been placed in optimizing the encryption and decryption methods used for JPEG format files, compared with MPEG format files.  
       SUMMARY OF THE INVENTION  
       [0010] One object of specific implementations herein is to decrease the time required, and the computing power required to decrypt an image file.  
       [0011] The inventors have realized that, whilst prior art encryption techniques provide high levels of security for data, there are certain types of data where absolute secrecy and security are not necessarily essential, and where a level of security below full encryption of a whole data file can be applied such that some parts of the data file can be left unencrypted, whilst still for all practical purposes, making that data file useless to a person misappropriating the data file.  
       [0012] Since decrypting a complete image data file is computationally expensive, encryption and decryption delays can be reduced by leaving parts of the image data file unencrypted, but encrypting enough of the image data file that the unencrypted parts of the file are practically of little or no use to an unauthorised person acquiring those unencrypted parts or the whole file including encrypted and unencrypted parts.  
       [0013] The computing power required to apply encryption to a relatively large size image data file, to the extent that a person acquiring the encrypted image data file cannot practically make use of the image data file, can be reduced by encrypting only the parts of the file which are critical for rendering an image.  
       [0014] Specific implementations aim to reduce the computing time and computing power required to decrypt an encrypted image, and thereby allow for incorporation of a decryption phase at a point of image rendering, without significantly decreasing performance or cost of an apparatus which renders an image data, for example a printer.  
       [0015] An authorised receiving device in receipt of a partially encrypted image data file may only need to apply decryption to the encrypted parts of the file, which requires less data processing power than if the same image data file were fully encrypted, and the whole of that image data file needed to be decrypted.  
       [0016] In one specific method, a data file contains a content data portion, and optionally a header portion. The content data portion comprises a data payload of the file, for example a poster image data. Part of the content data is encrypted, so that a person misappropriating the content data cannot make full use of the content data, since parts of the data are protected by encryption. An authorized recipient of the data can decrypt the encrypted content data portions, where an encryption method and key length are agreed beforehand between a sender of the data file and an receiver of the data file. A header portion may contain data describing the type of file, and other known parameters according to a particular file format selected.  
       [0017] In a variation of the first specific method, a header portion describes an encryption type used and a key length.  
       [0018] In the first specific method, the header portion only is encrypted. A person acquiring the file will not be able to read the header portion, and therefore will not be able to tell which encryption method is applied to the content data portion of the file, nor a file format which the content data is stored in.  
       [0019] In a second specific method, a file comprises a header data comprising information describing one or more encryption methods used to protect the file and one or more key lengths and optionally describing a file type, as well as data block lengths and positions, and a content data portion containing a content data payload. The header portion is encrypted, as well individual blocks selected from the content data. A person acquiring the file, needs to decrypt both the header portion and the encrypted data blocks from the content data in order to have full access to the content data.  
       [0020] In implementations in which a header is encrypted, it is necessary to be able to identify where the header begins and where the header ends. Some headers may be fixed in length, whereas some headers may be of a variable length. In the case of a variable length header, data describing the length of the encrypted header can be located in a predetermined position within a file, and the encrypted data of a described number of bytes forms the header data. Alternatively, the encrypted header can be identified by a begin header marker and an end header marker, in which case a receiving device needs to search for the begin and end markers, and decrypt the data between those markers to recover the header data.  
       [0021] Encrypted header bytes can be identified,by a begin marker and an end marker.  
       [0022] According to a first aspect of the present invention, there is provided a method for applying security to a data file comprising a content data portion, said method comprising:  
       [0023] selecting at least one section of said content data portion from anywhere within said content data portion;  
       [0024] applying at least one encryption algorithm to said at least one selected data section to obtain at least one encrypted data section, and at least one remaining unencrypted data section;  
       [0025] sending said at least one encrypted data section; and  
       [0026] sending said at least one remaining unencrypted data section.  
       [0027] Further features of the invention are as recited in the claims herein. 
     
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
     [0028] For a better understanding of the invention and to show how the same may be carried into effect, there will now be described with reference to the accompanying drawings by way of example only, specific embodiments, methods and processes according to the present invention in which:  
     [0029]FIG. 1 illustrates schematically a distributed printing system, in which image data files are transferred between computer entities;  
     [0030]FIG. 2 illustrates schematically a first encrypted file format according to a first specific implementation of the present invention;  
     [0031]FIG. 3 illustrates schematically a second encrypted file format according to a second specific implementation of the present invention;  
     [0032]FIG. 4 illustrates schematically a header data of the second file format.  
     [0033]FIG. 5 illustrates schematically individual computer entities within the system of FIG. 1, and illustrating components of the computer entities required for handling the file formats with reference to FIGS. 2 and 3 herein;  
     [0034]FIG. 6 illustrates schematically components of a printer device adapted for receiving a partially encrypted file according to the first and second file formats.  
     [0035]FIG. 7 illustrates schematically process steps carried out by a sending computer entity for sending a file according to the first file format;  
     [0036]FIG. 8 illustrates schematically process steps carried out by a sending computer entity for sending a file according to the second file format;  
     [0037]FIG. 9 illustrates schematically a file transfer method according to a third specific implementation of the present invention, for transferring files between computer entities;  
     [0038]FIG. 10 illustrates schematically process steps carried out at a receiving entity, for example a printer device, for reconstituting and printing an image data content of a received data file. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
     [0039] There will now be described by way of example the best mode contemplated by the inventors for carrying out the invention. In the following description numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent however, to one skilled in the art, that the present invention may be practiced without limitation to these specific details. In other instances, well known methods and structures have not been described in detail so as not to unnecessarily obscure the description.  
     [0040] In this specification, specific implementations are described in which an image data file is partially encrypted.  
     [0041] A common representation of JPEG images is the prior art JPEG file interchange format. This file format consists of a header which is located at the beginning of a file, followed by actual values which are used to decompress and render an image data, subject of the file.  
     [0042] Whilst in the following implementations, there is described the specific example of the JPEG file, the processes and implementations described herein are applicable to a wide variety of file types including video, or audio, and in principle, any object file can be subjected to treatment according to the specific methods disclosed herein.  
     [0043] For large data sizes, for example poster images, which have a relatively high amount of data to be sent across a communications net work such as the internet, content owners may wish to protect that image data against misappropriation, particularly within an e-services environment.  
     [0044] It will be appreciative that a JPEG file constitutes one example of an image data file, and in the following example, various types of image date file such as GIF, or PDF files or other like types of image data file may be substituted.  
     [0045] Referring to FIG. 1 herein, there is illustrated schematically a physical architecture of an on-line distributed printing system in which transfer of poster images by JPEG file may be made, according to a novel partially encrypted file format.  
     [0046] The system provides printing services to a plurality of customer terminals  104 , in response to a plurality of orders from customers, who may also be the end users. The network comprises a plurality of internet-enabled print service providers  105 - 107  each capable of providing physical prints in response to orders for printed images; an internet-enabled print merchant computer entity  100  for matching a plurality of orders for print services to the plurality of print service providers  105 - 107 ; one or a plurality of internet-enabled content provider computer entities  101  capable of providing image data; a plurality of content retailer computer entities  102 ,  103 , each capable of receiving orders from subscribers, e.g. the general public, for printed images; and one or a plurality of courier service providers  117 - 119  acting to deliver physical prints to specified end users.  
     [0047] Individual internet-enabled computer entities may be characterized by the function which they provide, as follows:  
     [0048] A content retailer computer entity  102 ,  103  provides image content on-line to customers by offering such content via a website. The customers, using personal computers having web browsers may view web pages made available at the content retailer computer entity, and may order online prints of those images.  
     [0049] A content provider computer entity  101 , stores a plurality of image data, of interest to individuals and businesses and deliverable on-line. For example, a content provider business may provide a library of pictures, in JPEG data format, stored in a database and made accessible over the internet by a content provider computer entity  101 . Content provider computer entity  101  comprises a database storing a plurality of digital image content data representing a plurality of images, and an internet compatible communications interface, making available the digital image content data over a communications link.  
     [0050] A print merchant computer entity  100 , provides a service to business customers, direct retail customers, content retailer websites and content providers, as well as to one or more print service providers. The print merchant computer allows conversion of orders from subscribers to those content retailer businesses into high quality prints which can be sold by the content retailer websites, with print and delivery to end users. The print merchant business handles the printing and delivery service for poster provided by the content retailers. Print service providers are connected to print merchant  100  by their print manager computers, which act as e-servers  108 - 110 . Each e-server allows a plurality of printing devices  111 - 116  to be connected to the print merchant.  
     [0051] A print service provider comprises an on-line enabled print manager computer entity  108 - 110 , and one or a plurality of printer devices  111 - 116 , the print manager computer entity capable of receiving orders from the print merchant computer entity on-line, e.g. over the internet, and capable of receiving on-line image data direct from the content provider computer entity, content retailer entity, or print merchant entity.  
     [0052] The means of communication between entities may make use of any suitable communications network or a mixture of network links, including, but not limited to, virtual private networks (VPN&#39;s), local area networks (LAN&#39;s), wide area networks (WAN&#39;s), using any suitable routing and/or transport protocols.  
     [0053] In the environment shown in FIG. 1, files having a large image data content, for example posters, are transferred between entities within the system, and consequently data processing times at receiving computer entities are significant. There is a need to protect the image content data, whilst at the same time minimizing computing resources for applying data protection, throughout the whole system.  
     [0054] In the printing system of FIG. 1, to enhance security of image content throughout the system, a content owner  601  may wish to encrypt or partially encrypt a content data for transmission over in the system. Decryption of the content data preferably occurs as close to the point of actual printing as possible so as to maximize security, and ideally within a printer device  111  to  115 . Typically, the printer device has a fixed amount of data processing power, which is primarily used for processing of image data in real time in order to provide a print of an image onto a print media. Therefore, an amount of data processing power available for decryption is limited. Any reallocation of data processing power away from the processing of image data, and to a decryption function, risks slowing down the printing process.  
     [0055] According to specific implementations of the present invention, by encrypting selected portions of the files, the time required to encrypt or decrypt an image file can be greatly reduced, whilst at the same time effectively maintain for practical purposes of a person who may misappropriate an image file, a similar level of security as offered by encrypting an entire image data file.  
     [0056] Three approaches may be taken to encrypting the file.  
     [0057] In a first approach, parts of a data file may be encrypted. In particular, parts of a content data file such as an image data. An encryption algorithm and key length may be set up beforehand between a sending entity and one or more receiving entities. This may be carried out “out of band” that is, not as part of the transmission of the data file. For example, two parties may agree beforehand that all documents will be sent using the prior art Rivest, Shamir, Adleman (RSA) algorithm, or any other known algorithm, with a 2 k byte key length. In another example, at a development stage of a system, engineering teams may agree a key length and encryption type.  
     [0058] Alternatively, there may be an out of band agreement on how a key will be acquired. Once this is agreed, then using a prior art standard way of packaging keys, will inform the parties which encryption method is being used.  
     [0059] No header information concerning file type or encryption method needs to be included in the first approach. A receiver of a partially encrypted file needs to recognize or determine that the file is partially encrypted, and apply a predetermined decryption algorithm and key exchange method to decrypt the encrypted parts of the data file, to recover the full unencrypted content data.  
     [0060] In the second approach, only a header data is encrypted. The encrypted header data, in a minimum case would describe:  
     [0061] an encryption algorithm used, for example RSA; and  
     [0062] A key length used for example 1024 or 2048 bytes.  
     [0063] Optionally, the encrypted header data may also include data specifying a file or file format, for example a JPEG file header in the case of a JPEG image file.  
     [0064] In a third approach, randomly selected blocks of image data from a file may be encrypted, in addition to encrypting the file header. The selection of the portions of the image data to be encrypted may be based on a randomly generated byte pattern, which can be used to index to specific blocks of the image data. The block size for encryption is predetermined, and is the same for each block.  
     [0065] In a variation of the third approach implementation, rather than having a predetermined block size for encryption, the block size can be made to vary. In this implementation, the encryption header includes a map of which blocks have been encrypted, and corresponding block links. A format for such a block map may include details of:  
     [0066] Block off set  
     [0067] Block links.  
     [0068] The header data and image data need not be encrypted using the same encryption algorithm, nor the same encryption keys. In this case, a portion of the header describing the blocks which have been encrypted may carry its own information regarding an encryption format used for encryption of the image data blocks.  
     [0069] Referring to FIG. 2 herein, there is illustrated schematically a first image data file format according to a first specific implementation of the present invention. The image data file comprises a header portion  200  and content data portion  201  containing image data. Typically, the header portion  200  has a much lower data size, i.e. much lower number of bytes, than the content data portion  201 . The header data  200  is encrypted according to a known encryption algorithm, whereas the image content portion  201  remains unencrypted.  
     [0070] Typically, the image content data may be in the range 1 megabyte to 100 megabytes or greater.  
     [0071] A person receiving the image data file of FIG. 2, in order to access the image data, needs to read the header data. Because the header data is encrypted, this requires a decryption algorithm at a receiving computer entity, in order to decrypt the header data. Operation of the decryption algorithm requires a finite data processing capability at the receiving computer entity. However, because only the header data has been encrypted, and the header data is relatively small in size compared to the number of bytes of the content data, the amount of data processing capacity required at the receiving end is low, relative to that which would be required if the whole data file including the content data were encrypted. By encrypting the header data, access to the unencrypted content data is protected, since the receiving computer entity cannot determine the format in which the image data is encrypted.  
     [0072] The implementation as illustrated in FIG. 2 herein, represents a relatively low level of security for the content data, since a person misappropriating the file has access to unencrypted content data. It may be possible for a person to remove the encrypted header data, and work out by a brute force computing approach, which type of file format, from a number of known file formats, for example PDF, JPEG, GIF and the like, the content image data is provided in. Therefore, the solution described in FIG. 2 provides an intermediate level of protection between full encryption, and between no encryption at all of a large content image data file.  
     [0073] The encryption algorithm used may be a known encryption algorithm, for example the known RSA, or known defense encryption standard (DES) encryption algorithms. A wide range of encryption algorithms are known in the art, and can be obtained from the American National Standards Institute (ANSI), the Institution of Electrical and Electronic Engineers (IEEE), and the published conference proceedings of Crypto and Eurocrypt, published by Springer-Verlag.  
     [0074] The header data comprises data identifying an encryption algorithm or encryption method used, and a key length used for encryption, for example 1024 or 2048 bytes. Optionally, and depending upon the format of the image data file, the header may also comprise a header of the particular file format for example a JPEG header including details of values which are used for decompression of the image data.  
     [0075] Referring to FIG. 3 herein, there is illustrated schematically a second file format according to a second specific implementation of the present invention. The second file format comprises a header data  300  and a content data  301 . The content data  301  typically comprises image data content of a size 1 megabyte to 100 megabytes, but may be larger. In the second file format, header data  300  is encrypted using a known encryption algorithm. The content data  301  comprises image data in a standard or proprietary format, e.g. GIF, JPEG, PDF or the like. A plurality of blocks of the content data  301  are encrypted as shown by shaded regions  302 - 307  in FIG. 3.  
     [0076] The size, number and encryption method applied to data blocks in the content data and the header data can be varied as follows:  
     [0077] Each encrypted block in the content data may be encrypted using a same algorithm.  
     [0078] Alternatively, different encryption methods each having a corresponding encryption key may be used to encrypt a plurality of different selected data blocks within the content data.  
     [0079] One or more encrypted blocks of the content data may be encrypted using a same encryption algorithm and same encryption key as that used for the header data  300 .  
     [0080] One or more encrypted blocks  302  in the content data may be encrypted using a different encryption algorithms and different decryption key to those used to encrypt the header data  300 .  
     [0081] In the general case, any number n of encryption algorithms may be used to encrypt any number n of encrypted blocks within the content data portion  301 , and one or more of those encrypted content blocks may use a same encryption algorithm and/or same encryption key as an encryption algorithm and encryption key used to encrypt the header portion  300 , or all encryption algorithms and encryption keys used to encrypt the encrypted content sections in the content data may be different to an encryption algorithm and/or encryption key used to encrypt the header data  300 .  
     [0082] The size of the blocks selected for encryption may be predetermined, or may be randomly selected each time a different file is encrypted.  
     [0083] Contained within the encrypted headed data, a map of the data blocks which have been encrypted may be provided, giving the location of those data blocks as a data section off set from a start of the content data, and a data block size for each encrypted data block.  
     [0084] A person or computer entity misappropriating a partially encrypted file as disclosed in FIG. 3 is faced with several barriers in order to obtain a full image content data. Firstly, they must decrypt the header  300  in order to find out the file format. Secondly, they must identify which portions of the content data are unencrypted image portions and which portions are encrypted image portions. Thirdly, they must identify an encryption method and key for each encrypted section, in order to decrypt the content data within that encrypted block in order to obtain a full-unencrypted image data.  
     [0085] Persons misappropriating the file may be able to strip off the encrypted header  300 , and identify the type of image file, by a brute force computing solution, which may enable them to access the unencrypted portion of the image data, minus the encrypted sections. However, the image data obtained by such an exercise will still leave large gaps in the image data, which as a practical matter, where the image comprises for example a poster, will mean that the usefulness of that acquired image data is severely degraded, in particular, to the point where it is commercially useless to the person misappropriating the image data, because large areas of the image are blurred and unintelligible. Since blocks of data are encrypted, access to a complete poster image is prohibited by virtue of the encrypted blocks contained within the image data.  
     [0086] Selection of particular blocks of image data may be made randomly, or according to a predetermined pattern. Whether selection of random blocks or a pattern of blocks is made, may be a user configurable option, at the point of encryption.  
     [0087] The particular parts of the file which are encrypted may be selectable by a content owner, depending upon the sensitivity of the file, and the content owners preference for security level applied to the file. For example, where the file is a JPEG file, the JPEG header may be selected so as to be encrypted, so that a potential hacker would not even be able to tell that the file is a JPEG file. However, in other instances, the JPEG header may be left unencrypted, in cases where it is irrelevant whether a person misappropriating the file knows that the file is a JPEG file, as long as there is part of the file that is encrypted, i.e. part of the content data, which makes that file practically useless to the acquirer.  
     [0088] Referring to FIG. 4 herein, there is illustrated schematically a data table, comprising the header portion of the second file format. The data table comprises data types include a block identifier  400  for example a numbering scheme for encrypted data blocks; a size in megabytes of each data block; position information for each encrypted data block, in the form of a number of bytes offset from the start of the content data section; an encryption type identifier data used to identify a type of encryption used for each data block; and a key length data for identifying a key length used for each encryption type.  
     [0089] Referring to FIG. 5 herein, there is illustrated schematically components of individual computer entities illustrated in FIG. 1, for encrypting and decrypting image content files according to a second specific implementation of the present invention.  
     [0090] The computer entities comprise a content provider computer  500 , a print manager computer entity  501 ; and a printer  502 .  
     [0091] Content provider computer  500  comprises communications port  503 , a processor  504 , with associated memory  505 , a conventional operating system  506 , a data storage device  507  and user interface  508  including a visual display unit, keyboard and pointing device, and a content provider application  509 , which includes an encryption algorithm for encrypting data files as described herein.  
     [0092] Print manager computer entity  501  comprises a communications port  510  for communicating with other computer entities on-line; a processor  511 ; memory  512 , including random access memory and read only memory; an operating system  513 , e.g. Linux®, Unix®, Windows NT/Windows 2000®; a data storage media port  514 , such as a DDS tape port, CDRom player or DVD player enabling the print manager computer to receive a file data on physical data storage media input into the physical media port of the print manager computer, a data storage device  515  e.g. hard disk drive, RAID array or the like; a user interface  515  enabling a human operator to interact with the print manager computer, the user interface comprising a visual display unit, keyboard and a pointing device, e.g. a mouse, trackball or similar; and a print manager application  517  acting as a e-server for communicating with print merchant computer entity and for controlling locally one or a plurality of printer devices  502  and other resources within a print service provider facility.  
     [0093] Referring to FIG. 6 herein, there is illustrated schematically components of a printer, adapted for receiving a partially encrypted file in a format as described herein before. The printer device  600  comprises a local area network interface  601  for receiving encrypted and unencrypted data from a print manager computer; one or more decryption algorithms  602  for decrypting encrypted sections of a received file; a memory device  603  for locally storing and constituting an unencrypted data file from the encrypted and unencrypted received section; a control component  604 , for controlling a printer and a print mechanism  605  for printing an image to a physical print media.  
     [0094] The interface, decryption component, memory component and control component  604  may be provided as discreet components in firm ware, or may be provided as a conventional data processor and memory, adapted by means of computer program to perform interface, decryption and control functions.  
     [0095] Since encryption of parts of the content data requires a corresponding amount of data processing power at a receiving computer entity or at a printer device, there is a trade off between the level of security applied to the content data, and the data processing power required at the receiving end in order to apply decryption. For a particular file size, the higher the proportion of the content data which is encrypted, the higher the security, but also, the receiving entity data processing power requirement increases correspondingly. Conversely, for the same file size and decryption time, reduction in the data processing power requirement in millions of instructions per second (MIPS) at the receiving computer entity is achievable by reducing the proportion of content data which is encrypted. Trade offs between the absolute amount of content data encrypted, the amount of content data encrypted relative to the total content data size; the encryption time at a sending computer entity; a decryption time at a receiving computer entity, a data processing power available at the sending computer, and a data processing power available at one or more receiving computer entities can be traded off and optimized against one another within a system. For a fixed amount of computing resource at the receiving end, the trade off is of security against utilization of computing resources, with the consequences of the trade off being increase or decrease in security, and increase or decrease in encryption and decryption times.  
     [0096] In the system of FIG. 1, considering the relatively large file sizes of typically 1 to 100 megabytes, such files can experience delays in traversing the communications network between a content provider entity and other entities in the network, culminating in delivery at the print service provider. Encrypting the large file does not significantly reduce the overall file size, particularly where the JPEG format is used, since this already includes a level of compression in any case. Therefore, as an alternative to electronic transmission over a communications network, a file or part of a file can be loaded onto a data storage media, such as a CD-ROM or DVD, and be physically delivered to a print service provider instead of being delivered by electronic transmission over a communications network.  
     [0097] Therefore, in one variation an unencrypted part of the data image could be delivered by physical data storage media such as DVD, and an encrypted part of the image could be delivered over a communications network, the full image being recoverable only by combining the unencrypted portion with a decrypted version of the encrypted file received over the communications network.  
     [0098] This variation may be useful where transmission times are not critical and a delay in receiving a physical data storage media through the post can be tolerated, but where data processing power at the receiving computer is limited, and time taken to print an image needs to be minimised, and utilisation of data processing power at a printer device for the purpose of decryption needs to be minimised, for example in a print service provider where many print jobs are being carried out, and utilisation of printer devices needs to be optimised.  
     [0099] Referring to FIG. 7 herein, there is illustrated schematically process steps carried out by a sending computer entity for sending a data file according to a format disclosed herein. In process  700 , the sending entity creates a header data for the file, the header data comprising data describing a type of encryption method used, for example specifying an encryption algorithm, and specifying a key length. In process  701  the header portion is encrypted, and in process  702  the encrypted-headed portion is sent to a destination computer entity. A remaining unencrypted content data portion of the file is also sent to the destination computer. Sending of the encrypted header portion and unencrypted content data portion preferably occur in this example as a same transmission made electronically.  
     [0100] Referring to FIG. 8 herein, there is illustrated schematically process steps for creating and sending a partially encrypted data file according to the second file format disclosed herein. In process  800  one or more sections of the content data portion are selected for encryption. In process  801 , each of the selected blocks are encrypted. Encryption may be applied using a same encryption process for each section or using different encryption methods for each section. In process  802  a header portion is generated. The header portion comprises a list of selected data blocks, together with encryption keys for those data blocks, and encryption methods used for each data block, preferably together with data describing a position of an encrypted data block within the content data. Additionally, the header portion may be assembled to include an existing header portion of an existing file type, for example a JPEG file. In process  803  the header portion is encrypted. In process  804  the encrypted header portion is sent to a destination entity, together with the encrypted blocks of content data, and an unencrypted section of the content data.  
     [0101] Referring to FIG. 9 herein, there is illustrated schematically a second specific method of file delivery according to a second specific implementation of the present invention. A data image file  900  is partially encrypted, by encrypting a first header portion  901  and optionally, one or more data blocks  902  of an image content data  903 . The unencrypted image content data  703  is stored on a physical data storage medium  904 , for example a CD-ROM or DVD. The encrypted file portions, including the header data and, optionally one or more encrypted data blocks  902  from the image content data are transmitted as an electronic file  905 , to a receiving computer entity. The unencrypted physical image content data arriving on the physical data storage media by surface mail may be sent to the location of the receiving computer entity at some time before delivery of the electronic encrypted data file  905 .  
     [0102] At the receiving computer entity, the unencrypted image content data  903  is stored locally on a data storage device, and the encrypted portion is decrypted at a printer device, and reconstituted with the unencrypted image content data, to give a fully decrypted file  906  having a decrypted header data  907  and decrypted image content data  708  in a form ready for raster image processing and physical printing at a printer device.  
     [0103] Decryption of the encrypted header portion  901  and, if present, encrypted blocks  902  of the image content data is carried out as close a possible to the point of final printing, ideally within the printer device itself.  
     [0104] Referring to FIG. 10 herein, there is illustrated schematically processes carried out at a receiving printer device for printing a physical image to a print media, where the image is received as unencrypted data on a physical data storage media and as an encrypted file over a communications network. In process  1000 , an unencrypted file content, typically an image data or a part image data is loaded from a received physical data storage carrier, for example a DVD carrier. The unencrypted data may be input in real time, as required by an algorithm within the printer, or may be loaded into a data storage device comprising or attached to the printer device. In process  1001 , the printer device receives an encrypted data file, comprising an encrypted header and optionally one or more encrypted image data blocks. In process  802  the printer applies a decryption algorithm to the encrypted header and one or more encrypted data blocks from the image content data by a prior art decryption algorithm. In process  1003 , the unencrypted image data portion, and the decrypted file portions resulting from decryption of the header data and optionally one or more encrypted image data blocks are reconstituted, resulting in a fully unencrypted reconstituted file having a header data and an image content data, for example in the JPEG format. This file is then raster image processed in process  1005  as is known in the prior art, resulting in a printed physical poster  1006 .  
     [0105] Specific implementations may have an advantage of reducing the time required and hence the computing power required to apply decryption security to an image file, for example a JPEG file by focussing solely on the parts of the file which are critical for rendering an image.  
     [0106] For relatively large image files, reduction of the time delay and computing power required to decrypt the image may allow for incorporation of a decryption phase at the actual point of rendering, for example inside a printer, without un-necessarily decreasing printer performance or increasing the printer costs.  
     [0107] In the foregoing examples, in some implementations a header data is encrypted whereas in others it is not. There are cases where the header data may be of a fixed length, and other cases where the header data may be of a variable length, according to a variable length format. Where the header data is encrypted, the encrypted bytes comprising the header data need to be identified, so that they can be decrypted by a receiving device.  
     [0108] Encrypting a first number N bytes of data may result in a second number M bytes of encrypted data, where either M can be equal to N, M can be less than N, or M can be greater than N. In order to properly decrypt an encrypted header data block, it needs to be determined which bytes comprise the encrypted block, so that at the receiving end, the encrypted block can be identified and then decrypted. This may cause problems in the case where the number of bytes of encrypted data M is not equal to the number of bytes of unencrypted header block data N.  
     [0109] To identify the encrypted header block, there are various options as follows.  
     [0110] In the case of a variable length header data, a data describing the header length can form part of the header itself, the header length data being located in a pre-determined position according to a file transfer format or protocol.  
     [0111] Alternatively, the header can be identified by means of a “begin header” marker data and an “end header” marker data. This approach is used with known JPEG files.  
     [0112] When a header data is encrypted, its length may be changed, and in order to decrypt it properly, it is necessary to identify the encrypted bytes. According to a further implementation of the present invention, a header data is provided which at minimum identifies the encrypted header bytes. A specific example comprises a begin marker data, and an end marker data. This may be implemented as shown in the following example of pseudo code:  
     [0113] &lt;EncryptedHeader&gt; 
     [0114] encrypted data  
     [0115] &lt;/Encrypted Header&gt; 
     [0116] &lt;Data&gt; 
     [0117] . . . &lt;/Data&gt; 
     [0118] Where the &lt;data&gt; block may or may not contain encrypted data depending on the specific mode employed. This format for sending a data file comprises an encrypted header data, a begin header data marker identifying a beginning of said encrypted header data; an end header data marker identifying an end of said encrypted header data; a portion of encrypted content data; and a portion of unencrypted content data.  
     [0119] In a further implementation, it may be indicated a number of bytes to be decrypted, where the starting point is well identified. For example:  
     [0120] &lt;NewHeader&gt; 
     [0121] &lt;ByteCount&gt;200&lt;/ByteCount&gt; 
     [0122] &lt;/EndHeader&gt; 
     [0123] &lt;Fild Data&gt; 
     [0124] . . .  
     [0125] &lt;/FileData&gt; 
     [0126] This format for sending a data file comprises an encrypted header data; a begin marker data, identifying a beginning of said encrypted header data; a byte count data identifying a number of bytes of said encrypted data; an encrypted data content portion; and an unencrypted data content portion.