|
Standards on the way for encrypting data on tape, disk by Decius at 1:14 pm EST, Jan 10, 2006 |
While some storage-product companies already support one sort of encryption or another, having standard implementations could make it easier for customers to safeguard data across heterogeneous storage environments, standards supporters say. The proposed standards define three encryption algorithms and a method of key management designed to ensure the compatibility and interoperability of different storage gear. For encryption on disk, the specification proposes using the new Liskov, Rivest, Wagner-Advanced Encryption Standard (LRW-AES) cryptographic algorithm. For tape encryption, it proposes using the National Institutes of Standards and Technologies' (NIST) AES Galois/Counter Mode (AES-GCM) and AES Counter with CBC-MAC Mode (AES-CCM) standards.
Galois/Counter Mode? BTW this article's comments about CBC are wrong. You cannot do arbirary data mangling in CBC. He is thinking of ECB. The problem with CBC is its slow... |
|
RE: Standards on the way for encrypting data on tape, disk by bucy at 1:50 pm EST, Jan 10, 2006 |
Decius wrote: While some storage-product companies already support one sort of encryption or another, having standard implementations could make it easier for customers to safeguard data across heterogeneous storage environments, standards supporters say. The proposed standards define three encryption algorithms and a method of key management designed to ensure the compatibility and interoperability of different storage gear. For encryption on disk, the specification proposes using the new Liskov, Rivest, Wagner-Advanced Encryption Standard (LRW-AES) cryptographic algorithm. For tape encryption, it proposes using the National Institutes of Standards and Technologies' (NIST) AES Galois/Counter Mode (AES-GCM) and AES Counter with CBC-MAC Mode (AES-CCM) standards.
Galois/Counter Mode? BTW this article's comments about CBC are wrong. You cannot do arbirary data mangling in CBC. He is thinking of ECB. The problem with CBC is its slow...
Until relatively recently, many folks didn't really understand the gravity of chosen ciphertext attacks on the standard modes of encryption. The common attitude has been that the ciphertext is opaque somehow and tamper-resistent because if anyone changes it, it will just decrypt to "garbage." In fact there are practical attacks on some implementations of CBC (e.g. Vaudenay's "padding oracle" attack (Vaudenay02)) that can completely unravel it. Standard cipher modes tend to have the characteristic that every ciphertext will decrypt to "something" so if your adversary has an opportunity to submit arbitrary ciphertexts to you for decryption, you absolutely must authenticate the ciphertext somehow. The obvious thing to do here is to run some MAC over your CT but there have been some efforts recently (e.g. Rogaway's patent-encumbered OFB mode) to devise authenticated encryption modes with marginal overhead above and beyond that of encrypting the data. Black and Uturbia's Usenix Security 02 paper on this. |
|
|
|