Re: [PATCH] Delete cryptoloop

From: David Wagner (daw_at_cs.berkeley.edu)
Date: 07/31/04

  • Next message: Jeff Garzik: "Re: [PATCH] Configure IDE probe delays" 
    To: linux-kernel@vger.kernel.org
Date:	Fri, 30 Jul 2004 17:44:24 -0700 (PDT)

    > But we identified more problems (I don't if these are all real issues).
    > Assuming the attacker has access to both plaintext and the encrypted
    > disk. (shared storage, user account on the machine or something)
    [...]

    Yes, there are a host of potential attacks in this scenario. That's why I
    wrote that, if you find yourself in this threat model, it would be prudent
    to assume that the current disk encryption scheme can potentially be
    defeated. Does anyone care about these threat models? From the design,
    I had assumed that no one cared, but if they are relevant in practice,
    then it might make sense to investigate additional defenses.

    The natural defense against these attacks would be to add a MAC, but this
    has the disadvantage of increasing ciphertext lengths and thus may be
    unsuitable for disk encryption. Also, a MAC might still be susceptible
    to some attacks based on cutting and splicing old ciphertext sectors
    with new ciphertext sectors, or somesuch. In other words, a vanilla MAC
    does not ensure freshness (it doesn't stop replaying old ciphertexts),
    unless it is augmented with additional mechanisms. It is not clear to
    me whether this would matter in practice.

    An alternative possibility would be to use a tweakable block cipher.
    The block width would be the size of the sector, and the sector number
    would be used as the tweak. This doesn't prevent the attacker from
    fooling around with ciphertexts; it just ensures that if the attacker
    changes what is on disk to some new value, then its decryption will be
    randomized and unpredictable to the attacker. One would have to spend
    a little time thinking about whether this is good enough in practice.
    Note that a tweakable block cipher retains the potential for replaying
    old ciphertexts just like a MAC would.

    Also, I haven't said anything about traffic analysis threats. If the
    attacker can observe the encrypted data on your hard disk at multiple
    times, he may be able to identify some partial information about which
    sectors or blocks of data have changed at which times. There may be
    some things one could do about this, if it matters to anyone.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Jeff Garzik: "Re: [PATCH] Configure IDE probe delays"

    Relevant Pages

    • Re: reasons for the algorithm
      ... but i can't call the first variable keystream because it only ... That has gigs of known plaintext (all the operating system ... You really think you can prevent the attacker from knowing ... different attacks in different classes such as plaintext ciphertext side ...
      (sci.crypt)
    • Re: encryption using a block cipher // ? size limit of plaintext
      ... The attacker finds two ciphertext blocks C_and C_that are the same. ... two plaintext blocks whose ciphertext matches. ... encrypt one file with a key you will only need to use one nonce, ...
      (sci.crypt)
    • Re: Faster way to use RSA...
      ... public exponent and d to be the private exponent. ... then what is the advantage of RSA over a symmetric key ... > ciphertext without knowledge of the public key, ... validity of this attack assumes that the attacker can reconstruct ...
      (sci.crypt)
    • Re: [PROPOSAL/PATCH] Fortuna PRNG in /dev/random
      ... > plaintext that's not one of the two. ... > which plaintext of the two goes with which ciphertext, ... > attacker has to mount their attack is limited. ... > and propose a comment patch. ...
      (Linux-Kernel)
    • Re: Re-encrypt and decrypt
      ... > Here you may be thinking of Pohlig-Hellman encryption (encryption by ... The old ciphertext is S1+P and the new ciphertext will ... One has to assume the attacker has access to all the ... Bryan Olson's suggestion of attaching session keys to the data and ...
      (sci.crypt)