# IEEE P1619

Institute of Electrical and Electronics Engineers (IEEE) standardization project for encryption of stored data, but more generically refers to the Security in Storage Working Group (SISWG), which includes a family of standards for protection of stored data and for the corresponding cryptographic key management.

## Standards

SISWG oversees work on the following standards:
The base IEEE 1619 Standard Architecture for Encrypted Shared Storage Media uses the XTS-Advanced Encryption Standard (XEX-based Tweaked CodeBook mode (TCB) with ciphertext stealing (CTS); the proper name should be XTC (XEX TCB CTS), but that acronym is already used to denote the drug ecstasy).
The P1619.1 Authenticated Encryption with Length Expansion for Storage Devices uses the following algorithms:
* Counter mode with CBC-MAC (CCM)
* Galois/Counter Mode (GCM)
* Cipher Block Chaining (CBC) with HMAC-Secure Hash Algorithm
* XTS-HMAC-Secure Hash Algorithm
The P1619.2 Standard for Wide-Block Encryption for Shared Storage Media has proposed algorithms including:
* Extended Codebook (XCB)
* Encrypt Mix Encrypt V2 (EME2)
The P1619.3 Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data defines a system for managing encryption data at rest security objects which includes architecture, namespaces, operations, messaging and transport.
P1619 also standardized the key backup in the XML format.

### Narrow-block vs. wide-block encryption

An encryption algorithm used for data storage has to support independent encryption and decryption of portions of data. So-called narrow-block algorithms operate on relatively small portions of data, while the wide-block algorithms encrypt or decrypt a whole sector. Narrow-block algorithms have the advantage of more efficient hardware implementation. On the other hand, smaller block size provides finer granularity for data modification attacks. There is no standardized "acceptable granularity"; however, for example, the possibility of data modification with the granularity of one bit (bit-flipping attack) is generally considered unacceptable.
For these reasons, the working group selected the narrow-block (128 bits) encryption with no authentication in the standard P1619, assuming that the added efficiency warrants the additional risk. But recognizing that wide-block encryption might be useful in some cases, another project P1619.2 has been started to study the usage of wide-block encryption.
The project is maintained by the IEEE Security in Storage Working Group (SISWG). Both the disk storage standard P1619 (sometimes called P1619.0) and the tape storage standard P1619.1 were standardized in December 2007.
A discussion was ongoing on standardization of the wide-block encryption for disk drives, like CMC and EME as P1619.2, and on key management as P1619.3.

### LRW issue

From 2004 to 2006, drafts of the P1619 standards used the Advanced Encryption Standard (AES) in LRW mode. In the 30 Aug 2006 Archived 11 March 2007 at the Wayback Machine meeting of the SISWG, a straw poll showed that most members would not approve P1619 as it was. Consequently, LRW-AES has been replaced by the XEX-AES tweakable block cipher in P1619.0 Draft 7 (and renamed to XTS-AES in Draft 11). Some members of the group found it non-trivial to abandon LRW, because it had been available for public peer-review for many years (unlike most of the newly suggested variants). The issues of LRW were:
* An attacker can derive the LRW tweak key K2 from the ciphertext if the plaintext contains K2||0$^n$ or 0$^n$||K2. Here || is the concatenation operator and 0$^n$ is a zero block. This may be an issue for software that encrypts the partition of an operating system under which this encryption software is running (at the same time). The operating system could write the LRW tweak key to an encrypted swap/hibernation file.
* If the tweak key K2 is known, LRW does not offer indistinguishability under chosen plaintext attack (IND-CPA) anymore, and the same input block permutation attacks of ECB mode are possible. Leak of the tweak key does not affect the confidentiality of the plaintext.