GB2353191A - Packet data encryption/decryption - Google Patents

Abstract

Plaintext data packets to be encrypted, transmitted and decrypted comprise data elements P<SB>1</SB>, P<SB>2</SB>...P<SB>n</SB>, the number n of elements in each packet being variable between successive packets. Each plaintext packet is converted to a ciphertext packet comprising the same number n of elements C<SB>1</SB>, C<SB>2</SB>...C<SB>n</SB> as the number of elements in the plaintext packet from which it is converted. The element conversion is achieved by combining each of the plaintext elements in turn with a respective element of the first n data elements K<SB>1</SB>, K<SB>2</SB>...K<SB>n</SB> of a key stream segment comprising N data elements K<SB>1</SB>, K<SB>2</SB>...K<SB>N</SB>, N being a constant which is at least as great as n. Each ciphertext packet is transmitted from a transmitter to a receiver, and the received ciphertext packet is converted to the plaintext packet from which it was converted. Reconversion is achieved by combining each of the ciphertext data elements in turn with a respective element of the first n elements of a key stream segment identical to that used to convert the plaintext packet to the ciphertext packet. The key stream segments are generated by cipher apparatus operating on an initialisation vector which is updated each time an element is converted and further updated after conversion of the last element in a packet such that the vector is always updated N times each time a packet is converted. Thus regardless of the number of elements in a packet to be converted, the vector is always updated the same number of times as a result of conversion of that packet.

Description

2353191 DATA ENCRYPTION AND TRANSMISSION The present invention relates to

a method and apparatus for encrypting, transmitting and decrypting a series of plaintext data packets.

Data encryption systems are required which can provide end-to-end synchronisation of a stream of data which has been encrypted by for example a block cipher apparatus. In particular, there is an increasing need for systems capable of transmitting multimedia data over different types of communications networks with highly secure end-to-end encryption. The term "end-to-end" is used to indicate where encryption is performed at a signal source and decryption is performed at a signal destination to distinguish from systems in which encryption takes place at intermediate points along a communications channel between a signal source and a signal destination, for example "air-interface" encryption systems.

Secure end-to-end encryption is particularly required by military, commercial and public safety users of radio and PSTN networks. Communication over timevarying channels inevitably results in discrepancies between the transmitted data and the received data and accordingly, if an encryption system is being used in which synchronisation between decryption apparatus at the receiver and incoming ciphertext must be maintained, steps must be taken to avoid loss of synchronisation which would otherwise result in an erroneously deciphered data stream. This means that the information used as the basis for encryption at the transmitter must be communicated in some manner to the receiver.

This synchronisation problem has been addressed in a known system referred to as the Terrestrial Trunked Radio system (TETRA). The TETRA system uses a frame-stealing technique to provide end-to-end synchronisation of encrypted data. With this technique, portions of the encrypted data stream are periodically replaced by synchronisation data packets or frames. Those portions of the encrypted data stream which are replaced by the synchronisation data packets are inevitably lost and as a result some of the original data is missing from the decrypted data stream. In some applications this is not a problem, but for certain systems in which continuous media is transmitted loss of even one frame of data can result in errors propagating through successive frames. For example, it is conventional practice to differentially encode 2 video frames such that data representing a particular frame does not fully describe that frame but merely characterises differences between that frame and the immediately preceding frame. Where data compression techniques of this type are used framestealing cannot be applied without substantial degradation of the decrypted data.

It is an object of the present invention to obviate or mitigate the problems outlined above.

According to the present invention, there is provided a method for encrypting, transmitting and decrypting a series of plaintext data packets each of which comprises data elements P I, P2... Pn, the number n of data elements in each packet being variable between successive data packets, wherein each plaintext data packet is converted to a ciphertext data packet comprising the same number n of data elements C I, C2...C,, as the number of data elements in the plaintext data packet from which it is converted, the data element conversion being achieved by combining each of the plaintext data elements in turn with a respective data element of the first n data elements KI, K2...K,, of a key stream segment comprising N data elements K1, K2... KN, N being a constant which is at least as great as n, each ciphertext data packet is transmitted from a transmitter to a receiver, and the received ciphertext data packet is converted to the plaintext data packet from which it was converted by combining each of the ciphertext data elements in turn with a respective data element of the first n data elements of a key stream segment identical to that used to convert the plaintext data packet to the ciphertext data packet, the key stream segments being generated by cipher apparatus operating on an initialisation vector, and the initialisation vector being updated each time a data element is converted and fialher updated after conversion of the last data element in a data packet such that the initialisation vector is always updated N times each time a data packet is converted, whereby regardless of the number of data elements in a data packet to be converted the initialisation vector is always updated the same number of times as a result of conversion of that data packet.

The present invention also provides an apparatus for encrypting, transmitting and decrypting a series of plaintext data packets each of which comprises data elements P 1, P2 - Pn, the number n of data elements in each data packet being variable between successive data packets, comprising means for converting each plaintext data 3 packet to a ciphertext data packet comprising the same number n of data elements C C2... C. as the number of data elements in the plaintext data packet ftom which it is converted, the data element conversion means combining each of the plaintext data elements in turn with a respective data element of the first n data elements KI, K2 - K, of a key stream segment comprising N data elements KI, K2...KN, N being a constant which is at least as great as n, means for transmitting each ciphertext data packet from a transmitter to a receiver, and means for converting the received ciphertext data packet to the plaintext data packet from which it was converted by combining each of the ciphertext data elements in turn with a respective data element of the first n data elements of a key stream segment identical to that used to convert the plaintext data packet to the ciphertext data packet, the key stream segments being generated by cipher apparatus operating on an initialisation vector, and the cipher apparatus updating the initialisation vector each time a data element is converted and after conversion of the last data element in a data packet such that the initialisation vector is always updated N times each time a data packet is converted, whereby regardless of the number of data elements in a data packet to be converted the initialisation vector is always updated the same number of times as a result of conversion of that data packet.

The invention further provides a method for operating a data encryption and transmission system using a cryptographic mode which relies at a transmitter upon an initialisation vector to convert plaintext to ciphertext for transmission and the same initialisation vector at a receiver to convert received transmitted ciphertext to plaintext, the initialisation vector used for text conversion at the transmitter varying during the course of signal transmission, and frames of synchronisation data being transmitted with the ciphertext to enable the generation at the receiver of the initialisation vector required to convert transmitted ciphertext to plaintext, wherein the ciphertext is transmitted as a stream of successive packets of ciphertext each made up from a series of ciphertext data elements, and each synchronisation frame is inserted into the transmitter signal between successive ciphertext data packets or between successive ciphertext data elements in a ciphertext data packet.

4 Transmitting synchronisation data within rather than in place of ciphertext means that synchronisation data is transmitted without any loss of the ciphertext as occurs with prior art systems, for example the TETRA system.

Embodiments of the present invention will now be described, by way of example, with reference to the accompanying drawings, in which:

Figure I is a schematic representation of a conventional block cipher system which operates in output feedback mode; Figure 2 is a schematic representation of an apparatus provided at a transmitter in a system in accordance with the present invention; Figure 3 schematically represents the structure of a synchronisation packet or frame which is generated in the apparatus of Figure 2; Figure 4 is a schematic representation of apparatus provided at a receiver in a system in accordance with the present invention embodying the transmission apparatus of Figure 2; Figure 5 illustrates the output of a block cipher apparatus incorporated in the transmitter apparatus of Figure 2; Figures 6 and 7 illustrate the response of the receiver apparatus of Figure 4 to variable length and dropped data packets; Figure 8 illustrates a conventional encryption system which operates in counter mode; and Figures 9 and 10 illustrate alternative embodiments of the invention.

Referring to Figure 1, in the illustrated conventional arrangement, a series of plaintext data packets each of which comprises n data elements P1, P2... P, is converted into a ciphertext data packet comprising the same number n of data elements C1, C2... C,, by combining each data element of the plaintext data packet with a respective data element of a key stream segment comprising N data elements KI, K2... K, The plaintext data packets could be video data to be transmitted by radio. In a block cipher system, each data element would be in the form of a block of data, for example 8 bytes. Alternatively in a stream cipher arrangement, each data element would be a single bit of data. Each data packet will also include a header of appropriate form to identify the start of each data packet. Similarly, each data element in the key stream segment will be in an appropriate form to convert one plaintext data element to one ciphertext data element.

As shown in Figure 1, a block cipher apparatus 1 is responsive to two inputs 2 and 3, that is a session key delivered to input 2 and data fed back to input 3 from the output of the apparatus 1 though a register 4. Thus the output of the block cipher apparatus 1 is fed back to the input to the block cipher apparatus through the register 4, and each successive plaintext data element Pn is XORed with the output of the block cipher apparatus I to obtain a corresponding ciphertext data element C, The current content of the register 4 is referred to hereinafter as the initialisation vector (IV). A starting value Wo of the initialisation vector can be loaded from an external source. The content of the register 4 is thus a function of the session key, an algorithm which is operated by the block cipher apparatus 1, and the starting value IVO of the initialisation vector. Therefore the IV is not a constant value but is updated each time a new data element of the key stream segment appears at the output of the block cipher apparatus 1, that is each time a plaintext data element P,' is converted to a ciphertext data element C,,.

At the receiver, the ciphertext data element C,, is XORed with the key stream segment output K,, of a block cipher apparatus 5 to reproduce the original plaintext data element P, Clearly for each received block of the ciphertext data element C,,, a process must be performed which reverses the process performed at the transmitter to convert the original plaintext data element P,, to the transmitted ciphertext data element Cn. Accordingly, the block cipher apparatus 5 at the receiver is identical to that at the transmitter, and the block cipher apparatus 5 is responsive to the same session key and the same IV which again is stored in a register 6. If the transmitter and receiver apparatus are not synchronised so that identical values are contained in the registers 4 and 6, the recovered plaintext will be gibberish because the IV and/or session key used to convert the plaintext to ciphertext will not be the same as the IV and/or session key used to convert the ciphertext to plaintext. Any fault on the transmission channel between the transmitting and receiving apparatus which results in the loss of data may result in a loss of synchronisation, and accordingly some mechanism must be put in place to communicate the current IV and the current 6 session key to the receiver to enable the receiver to maintain synchronisation with the transmitter.

In prior art systems, synchronisation frames were transmitted periodically in place of one or more of the ciphertext data packet. As a result data incorporated in a replaced ciphertext data packet was lost. Such data loss results in some systems in serious degradation of the recovered plaintext data packets. This problem can be overcome in accordance with the present invention by adopting a system such as that described below.

Figure 2 illustrates apparatus provided at a transmitter in a system in accordance with the present invention. As shown in Figure 2, input data elements Pn are XORed with key stream data elements K,, to produce ciphertext data elements C, A block cipher apparatus 7 produces key stream segment data element K, in response to a session key k on input 8 and an initialisation vector IV on input 9, the initialisation vector being derived from a register 10. As in the case of the conventional apparatus shown in Figure 1, the content of the register 10 is updated by feeding back the output K,, of the block cipher apparatus 7. The output of the register 10 is also delivered to a further block cipher apparatus 11 which is responsive to a key k' on input 12 which may be the same as the session key k on input 8 or may be a different key and produces an encrypted version E(IV) of the IV which is delivered to a synchronous data frame buffer 13. Block cipher apparatus 11 may be the same as block cipher apparatus 7 or it may operate using a different algorithm.

As illustrated in greater detail in Figure 3, the frame buffer 13 stores a synchronisation frame comprising a frame marker (FM), a key number (K. No.), an algorithm number (A.No.), an encrypted initialisation vector (E(IV)) and a check sum (CRQ. If the system was using a session key which did not vary, and an encryption/decryption algorithm which did not vary, it would not be necessary to transmit a key number or an algorithm number, but in the illustrated system it will be assumed that the session key and the algorithm number changed periodically. The frame marker identifies the beginning of each synchronisation frame and may be for example an 8 bit code word such as "0 1111110", or a sequence chosen for its impulsive autocorrelation properties, such as I 110000 10 100 110 1 (a pseudo random sequence, for example Barker and Willard sequences). If required, the uniqueness of 7 the frame marker may be ensured by bit or byte stuffing in the data, but in a preferred implementation, the frame marker may be validated by the use of a known length and the check sum (for example CRC 16) for the synchronisation frame.

The key number corresponds to the current session key which is used as an input to the block cipher apparatus at both the transmitter and receiver. Transmission of the key number enables late entry into a group call that is currently in progress. For example if two parties are in communication and a third party wishes to enter into that communication, it is necessary for that third party to be given the current key. It may also be noted that this key information is useful to the second party in the call in establishing initial synchronisation data which must be transmitted ahead of ihe first packet of data. An identical format may be used for the initial synchronisation.

The algorithm number identifies the algorithm which is currently in use in the block cipher apparatus at the transmitter and receiver. Once again the algorithm number is required to facilitate late entry into a group call that is currently in progress.

The check sum, for example CRC-16, is provided for error detection. Preferably, the check sum is summed over the entire synchronisation frame including the frame marker.

The output 14 of the synchronisation frame buffer 13 is applied to multiplexer 15 which also receives on an input 16 the ciphertext data elements Cn. The multiplexer 15 is controlled by a control unit 17 which in turn is responsive to a timer 18. At intervals determined by the timer 18, the synchronisation frame stored in the frame buffer is inserted between successive ciphertext data elements Cn or between successive ciphertext data packets. Thus the output of the multiplexer incorporates all of the ciphertext elements Cn delivered to the multiplexer 15 and each of the synchronisation frames delivered from the synchronisation buffer 13.

Figure 4 illustrates apparatus provided at the receiver. When a ciphertext data packet is received at the receiver it is stored in a buffer 19 and an encryption synchronisation unit 20 checks whether a synchronisation frame has been received. This involves a process of checking to determine whether or not the received packet is equal in length to the synchronisation packet size, and if so, checking that the first byte of the received packet is equal to the synchronisation frame marker, and, if so, checking the check sum. Alternatively, it would be possible to check for the 8 synchronisation marker first, and only to test that the length is correct after the synchronisation marker has been found.

When a synchronisation frame has been detected, an output is delivered to a control unit 21 which in turn controls a demultiplexer 22 and IV register 23. The detected synchronisation packet is routed from the demultiplexer 22 to a synch frame buffer 24 whereas the ciphertext data packets are combined with the output of a block cipher apparatus 25 to generate a series of plaintext data element outputs P, When a synchronisation frame is received, the contents of the synchronisation frame buffer 24 are updated if necessary by changing the current session key to the key indicated by the key number in the received synchronisation frame, and if necessary changing the algorithm to correspond to the algorithm number of the received synchronisation frame. In addition, the encrypted IV of the received synchronisation frame is delivered to the synchronisation frame buffer 24. The encrypted IV is converted back to plaintext by a block cipher apparatus 26 which must use the same algorithm as the apparatus I I and the same key k'. The output of the block cipher apparatus 26 is applied to the IV register 23 such that the content of the IV register is updated when this function is enabled by the input to the IV register derived from the control unit 21. The block cipher apparatus 25 generates the appropriate key stream segment made up of data elements Kn to be XORed with the ciphertext data element C,, to produce the plaintext data elements P, The block cipher apparatus 25 operates on the basis of the key k and algorithm determined by the key and algorithm numbers stored in the synchronisation frame buffer 24.

The header of each encrypted data packet will include a sequence number, successively encrypted data packets having consecutive sequence numbers. Thus, at the receiver, if successively received data packets do not have consecutive sequence numbers the loss of a data packet can be detected. Similarly, if a received data packet has a corrupted header, that data packet is discarded. It is vital to maintain the receiver in synchronisation with the accepted received data packets, even if data packets are dropped. Given a system which operates with data packets of variable size, there is no way of determining the size of a dropped packet. Figure 5 illustrates how synchronisation is maintained even if data packets of unknown size are dropped.

9 Referring to Figure 5, the output of the block cipher apparatus of Figure 2 is in the form of a series of key stream segments KSI, KS2... with each key stream segment being made of a series of N key stream data elements KI, K2.... KN. Each key stream segment KSI, KS2... is used to encrypt a respective one of a series of variable length data packets DP I, DP2.... The key stream segments are all of the same length, that length being completely independent of the size of the associated data packet except that the key stream segment length is at least equal to the maximum allowed or maximum possible length of any data packet. After encryption of a data packet the size of which is n (where n is less than the key stream segment size N) the remaining portion of the key stream segment is in effect discarded. As a data packet made up n data elements is converted to ciphertext, the IV is updated once as each data element is converted such that for a data packet made up of n elements the IV is updated n times. After the conversion of a data packet, the IV is then further updated by N-n times. Essentially, N-n is the additional number of rounds that the block cipher apparatus must operate to ensure that regardless of the number n of data elements in a converted data packet the IV is always updated by the same number of times N each time any data packet is converted. For example, if the maximum data packet size is 20, 000 bytes arranged in 2,500 blocks each of 8 bytes, and the curTent data packet size is 16,000, then during processing of the current data packet the IV will be updated n times where n equals 16,000/8 = 2,000 times and after processing of the current data packet the IV will be further updated (N-n) times where (N-n) equals (20,000-16,000)/8 = 500 times.

Thus, after each data packet of n data elements is encrypted, the IV is updated N-n times. This "flywheeling" process makes it possible for variable length data packets such as video frames to be accommodated. As a result of obtaining constant length key stream segments, the initial IV value stored in the block cipher apparatus register when the first data element of a data packet is to be processed is independent of the size of the previous data packet. This means that at the receiver the initial IV value to be used in the cipher apparatus to decrypt the next data packet can be determined with certainty. Accordingly the receiver can keep the key stream segments synchronised to the incoming encrypted data packet stream in the intervals between successive synchronisation frames regardless of variations in the number of data elements in the data packets. Thus synchronisation can be maintained in systems with variable data rates such as systems in which data from multiple applications or sources are multiplexed on a single data channel.

If a ciphertext data package is received out of sequence, the IV of the decryption unit must be updated to take account of the loss of one or more packets before the out of sequence packet is decrypted. For example, consider a scenario as illustrated in Figure 6 where a block cipher with block size equal to 8 bytes is used in a system with a maximum data packet size of 20,000 bytes. If the packet M+l is received immediately after the packet M- 1, this means that the packet M (which is of unknown length) has been dropped. The IV must therefore be updated 2,500 times (that is the packet size divided by the block size) before the packet M+I is decrypted. Similarly, if the packet M+2 is received immediately after the packet M-1, then the IV should be updated 2 x 20,000 - 8 which equals 5,000 times before the packet M+2 is decrypted. In circumstances in which packet M is dropped, it will be noted that all of key stream segment KSM is discarded. Figure 7 is a flowchart illustrating the process, where "m" represents the number of consecutive data packets dropped.

Simple mechanisms can be provided to update the IV as necessary both with regard to discarding that portion of a key stream segment which is not required as the result of the difference in length of the key stream segment and the associated processed data packet, and with regard to updating the IV as required to take account of a dropped data packet or packets. Simple counting mechanisms are all that is required, the counting mechanisms needing to do no more than to monitor the number of data elements in each data packet and the sequence number of each data packet, and to update the IV generator to take account of differences between the lengths of data packets and the fixed length key stream segments and the dropping of data packets.

It will be appreciated that in the system described with reference to Figures 2 to 7, the data packets are encrypted in output feedback mode. The present invention is however applicable to other modes, for example a counter mode. Figure 8 illustrates a conventional block cipher system operating in counter mode. In the case illustrated in Figure 8, the IV would be in effect the output of a counter 27 at the transmitter and a counter 28 at the receiver. Accordingly to convert a conventional arrangement such as that shown in Figure 8 to a system in accordance with the present invention it would be necessary to insert the IV value of the counter 27 at the transmitter into a synchronisation frame for transmission between successive or within cipher text packets. Encrypting in counter mode in this manner would ensure a maximum cycle length of the key stream. In addition, such a procedure requires less processing that when updating the IV as described with reference to Figures 2 to 7 after each encryption of the data packets. This is because it is a very much simpler process to update a counter a predetermined number of times to take account of variable length or dropped data packets than operating a block cipher apparatus such as that illustrated in Figure 2 the same number of times.

Whenever a synchronisation frame is sent or received, the sequence number counters of the transmitter and the receiver may be reset to zero. This could cause problems however because the receiver will make a synchronisation error if a corrupted synchronisation frame is dropped. Therefore, preferably the counters will be reset only when they reach their maximum count.

When a synchronisation frame is received, the IV value of the synchronisation frame is used as the starting IV of the data packet received immediately after the synchronisation frame, assuming the received data packet has the correct sequence number. If the sequence number is wrong, the flywheeling mechanism will be used to correctly resynchronise In the case illustrated in Figures 2 to 7, the current IV value of the encryption apparatus is encrypted in the ECB mode using the key k'. In a stream-cipher system, this step would not be applicable as the IV would be included in the synchronisation frame without encrypting it. It is however advantageous to encrypt the IV as this will further enhance the security of the system. The ability to encrypt the IV would be particularly useful in a stream cipher system, in which the starting state of the key stream segment generator (that is the starting IV value) is used as a cipher key instead of an actual cipher key. Figure 9 illustrates in simplified form the structure of a block cipher system in which the IV is encrypted, such a system being the same in general terms to that described with reference to Figures 2 to 7. Figure 10 illustrates IV encryption in a stream cipher system.

12 Referring to Figure 9, in a block cipher system where the OFB mode is used to encrypt the data, as previously described with reference to Figure 2 the current IV value of the block encryption apparatus can be encrypted in the ECB mode using the current session key to secure the IV within the synchronisation frame. It will be seen in Figure 9 that there are two identical block cipher units 29 receiving session keys on inputs 30 and 31 and the same IV value on inputs 32, the IV value being derived from the common register 32 to which a starting IV valve IVO is delivered. Here, key I (input 30) and key 2 (input 3 1) should be different as the two block ciphers 29 are the same. Key 2 can be derived from key 1, for example by hashing. In alternative arrangements, the two block ciphers could be different, or the two block ciphers could be the same but the second could operate in decrypt mode so that to obtain the IV the receiver has to operate in encrypt mode.

In a key based stream cipher system as illustrated in Figure 10, the key and the IV will determine the ciphertext generated from a given plaintext data packet. Unlike block ciphers, stream ciphers do not have a mode equivalent to the ECB mode where an IV is not used. In order to encryptthe IV therefore, as shown in Figure 10 it is possible to use a block cipher 34 in a system in which stream cipher 35 is used to encrypt data.

It may be desirable to include a key number and an algorithm number for the IV encryption in the synchronisation frame.

If replay protection is required, it is necessary to include some form of time stamp in the encryption mechanism, for example by combining the time with the IV in an XOR process, or to provide a time indication as an additional item in synchronisation frames, possibly protected by a cryptographic check sum.

With the "flywheeling" mechanism described with reference Figures 5, 6 and 7, it is possible for the receiver to determine the starting IV of the expected packet in advance. This means that the starting IV of each received packet is known to the receiver. Therefore, the transmitter does not have to send the IV to the receiver in order to resynchronise, as the sequence numbering scheme can compensate for dropped packets. Thus, providing there is initial synchronisation, and end-to-end encryption synchronisation scheme can be implemented without either insertion or frame stealing.

13 Initially a random IV (IVR) can be sent to the receiver in encrypted form. This will be the starting IV for the first packet. Alternatively, the IVR can be hashed and the hashed value H(IVR) used as the starting IV of the first packet. After that, the system can "flywheel" a predetermined number of times to obtain the starting IV of subsequent received packets. Therefore, this method can be used to synchronise encrypted real time data, providing late entry is not required. Such a scheme could be implemented using a block cipher operating in counter mode. The counter can be incremented a predetermined number (N) times for each packet. The starting IV for the first packet will be IVR or H(IVR). The starting IV for the subsequent packets can be calculated by multiplying the packet number M by N and adding to the IVR or H(IVR).

Therefore, the starting IV of packet M in the series of packets 0,1,2,3,.. .MI,M,M+l... is:

IVSM= IVR+NxM or ivsm=H(IVR)+NxM The value IVsM can be calculated and loaded to the counter, so that it does not have to operate N times for each packet, thus saving processing.

The packet numbers do not have to be sequential. They can vary randomly, and a random number generator can be used to assign numbers to the packets. In this case M will be the random number assigned to the packet. This would require the generation of the IV directly from the randomly generated packet number M, as successive packets would not have successive packet numbers. The two above equations for IVsm will however still be applicable.

Since the packet number field (e.g. 16 bits) will not generally be as large as the IV field (e.g. 64 bits), a new IVR should be assigned when the packet count wraps around if the packet number is used to generate the IV. This can be done by either the transmitter generating and sending a new IVR to the receiver or deriving a new IVR from the old IVR (for example new IVR = hash(old IVR)).

It will be appreciated that the invention may be implemented in any convenient manner relying upon software or hardware.

14

Claims (12)

1. A method for encrypting, transmitting and decrypting a series of plaintext data packets each of which comprises data elements PI, P2-..P,,, the number n of data elements in each packet being variable between successive data packets, wherein each plaintext data packet is converted to a ciphertext data packet comprising the same number n of data elements C1, C2... C,, as the number of data elements in the plaintext data packet from which it is converted, the data element conversion being achieved by combining each of the plaintext data elements in turn with a respective data element of the first n data elements KI, K2... Kn of a key stream segment comprising N data elements KI, K2... KN, N being a constant which is at least as great as n, each ciphertext data packet is transmitted from a transmitter to a receiver, and the received ciphertext data packet is converted to the plaintext data packet from which it was converted by combining each of the ciphertext data elements in turn with a respective data element of the first n data elements of a key stream segment identical to that used to convert the plaintext data packet to the ciphertext data packet, the key stream segments being generated by cipher apparatus operating on an initialisation vector, and the initialisation vector being updated each time a data element is converted and further updated after conversion of the last data element in a data packet such that the initialisation vector is always updated N times each time a data packet is converted, whereby regardless of the number of data elements in a data packet to be converted the initialisation vector is always updated the same number of times as a result of conversion of that data packet.

2. A method according to claim 1, wherein the initialisation vector is generated at the transmitter and periodically or from time to time transmitted to the receiver in a synchronisation frame.

3. A method according to claim 2, wherein the initialisation vector is transmitted in encrypted form.

4. A method according to claim 2 or 3, wherein the synchronisation frame is inserted between successive ciphertext data packets or between successive ciphertext data elements in a ciphertext data packet.

5. A method according to claim 4, wherein synchronisation frames are inserted at intervals determined by a timer.

6. A method according to claim 1, 2, 3, 4 or 5, wherein successive data packets incorporate data packet sequence numbers, the sequence numbers of received ciphertext data packets are detected at the receiver to detect dropped data packets, and the initialisation vector is updated at the receiver N times each time a data packet is dropped before the next ciphertext data packet in the series is converted to plaintext.

7. A method according to any preceding claim, wherein data packets are converted by stream cipher apparatus.

8. A method according to claim 7, wherein the stream cipher apparatus is derived from block cipher apparatus operating in output feedback mode.

9. An apparatus for encrypting, transmitting and decrypting a series of plaintext data packets each of which comprises data elements P I, P2... Pn, the number n of data elements in each data packet being variable between successive data packets, comprising means for converting each plaintext data packet to a ciphertext data packet comprising the same number n of data elements C 1, C2-- - Cn as the number of data elements in the plaintext data packet from which it is converted, the data element conversion means combining each of the plaintext data elements in turn with a respective data element of the first n data elements KI, K2...K,, of a key stream segment comprising N data elements K1, K2... KN, N being a constant which is at least as great as n, means for transmitting each ciphertext data packet from a transmitter to a receiver, and means for converting the received ciphertext data packet to the plaintext data packet from which it was converted by combining each of the ciphertext data elements in turn with a respective data element of the first n data 16 elements of a key stream segment identical to that used to convert the plaintext data packet to the ciphertext data packet, the key stream segments being generated by cipher apparatus operating on an initialisation vector, and the cipher apparatus updating the initialisation vector each time a data element is converted and after conversion of the last data element in a data packet such that the initialisation vector is always updated N times each time a data packet is converted, whereby regardless of the number of data elements in a data packet to be converted the initialisation vector is always updated the same number of times as a result of conversion of that data packet.

10. A method for operating a data encryption and transmission system using a cryptographic mechanism or mode which relies at a transmitter upon an initialisation vector to convert plaintext to ciphertext for transmission and the same initialisation vector at a receiver to convert received transmitted ciphertext to plaintext, the initialisation vector used for text conversion at the transmitter varying during the course of signal transmission, and frames of synchronisation data being transmitted with the ciphertext to enable the generation at the receiver of the initialisation vector required to convert transmitted ciphertext to plaintext, wherein the ciphertext is transmitted as a stream of successive packets of ciphertext each made up from a series of ciphertext data elements, and each synchronisation frame is inserted into the transmitter signal between successive ciphertext data packets or between successive ciphertext data elements in a ciphertext data packet.

11. A method for encrypting, transmitting and decrypting a series of plaintext data packets substantially as hereinbefore described with reference to Figures 2 to 7, Figure 9 or Figure 10 of the accompanying drawings.

12. An apparatus for encrypting, transmitting and decrypting a series of plaintext data packets substantially as hereinbefore described with reference to Figures 2 to 7, Figure 9 or Figure 10 of the accompanying drawings.