Re: On-Disk Encryption and Data Integrity

jeffrey.w.walton@xxxxxxxxx writes:

Even though Enrypt then Authenticate does provide what I need (again,
I consider it stronger), what concerns me is programmic cost. If I
blindly select Encrypt then Authenticate because it is the generally
accepted solution in Secure Channels, I might be wasting CPU cycles (I
know, I know).

Easy: use a very fast MAC such as D. J. Bernstein's poly1305
(http://cr.yp.to/mac.html#poly1305-paper). Authenticating ciphertexts
with a fast MAC allows you to reject forged ciphertexts faster than you
can decrypt them, which may help resist denial-of-service attacks.

Hmmm. That wants floating-point hardware if it's to go screamingly
fast: your environment may not have it. Plan B...

Authenticated encryption modes such as GCM might be also be interesting;
if you're willing to pay licence fees, there are patented modes such as
OCB which offer better performance.

Finally, if implementation complexity is concerning you, then something
like CMAC

http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf

might be a good bet: it makes good use the block cipher you've already
implemented.

All of these ought to be faster than a collision-resistant hash
function. (HMAC wouldn't be, but I'm not recommending that.)

The reason CPU cycles are important is because I am working with an
embedded device which suffers a processing power imbalance from their
desktop cousins. This disparity will most likely adversly affect the
user experience.

This is a good reason to authenticate the ciphertext rather than the
other way around: you can reject forgeries before having to decrypt.

Part of my problem was my penchant for the HAC: I did not want
to completely discard the section on Confidentiality and Integrity.
I also do not like to take liberties in Cryptography, so if E( m || h
(m) ) does not apply to the Secure Channel, I did not want to extend
this to File Encryption without due dilligence.

I'm not sure what you're referring to here.

I don't compromise Cryptography for User Experience. However, I would
be performing a dis-service to the user if I blatantly wasted
processing power because I did not do my homework.

Absolutely. I sincerely believe the MACs and authenticated-encryption
modes will offer a speed /advantage/ over an encrypted hash function in
all cases.

-- [mdw]
.

Relevant Pages

  • [UNIX] Vulnerability in Encrypted Loop Device for Linux
    ... Encrypting a disk device aims to protect against an off-line attacker who ... The encryption mode used by encrypted loop device is CBC. ... We propose 2 types of fixes: one that authenticate at mount time (see ...
    (Securiteam)
  • Vulnerability in encrypted loop device for linux
    ... An attacker is able to modify the content of the encrypted device ... considered a aim of the encryption mode, so most modes (e.g. ECB, CFB, ... As we need to authenticate the device across mounts and not while it is ... It slows down mount operations but they are ...
    (Bugtraq)
  • Re: On-Disk Encryption and Data Integrity
    ... with a fast MAC allows you to reject forged ciphertexts faster than you ... Authenticated encryption modes such as GCM might be also be interesting; ... This is a good reason to authenticate the ciphertext rather than the ...
    (sci.crypt)
  • Re: Unix Password Encryption Procedures
    ... I know that most Unix machines either use the DES encryption algorithm ... such thing as the "MD5 encryption algorithm". ... Some administrators have also been known to setup systems to authenticate ...
    (comp.unix.admin)
Quantcast