3 ms·

AES CBC + Elephant != XTS Elephant 'mixes' the blocks on a sector level to limit CBC block modification attacks. It does not limit the maximum size to align to

by xnull 12y ago

AES CBC + Elephant != XTS Elephant 'mixes' the blocks on a sector level to limit CBC block modification attacks. It does not limit the maximum size to align to sectors. It is not XTS. Nor is my claim that Elephant is what you want or need. Merely that it was removed, that Ferguson designed it, and that FIPS compliance was the underlying justification.

tptacek 12y ago
I didn't say Elephant was XTS. I said that neither XTS --- the industry standard sector-level construction --- nor Elephant actually authenticated sectors. All three of AES-CBC, Elephant, and XTS fail to authenticate data. This isn't my point; it's Rogaway's, and the opinion of several other people during the XTS standardization process, including Ferguson. So it's a stretch to talk about how Microsoft "weakened" Bitlocker by removing the idiosyncratic Elephant construction. None of the design alternatives Microsoft had available provided real authentication, and all of them provide adequate confidentiality (to the extent that's possible with sector-level crypto, which is itself just a bad idea).
- xnull 12y ago
  Couldn't it both be true that Microsoft weakened Bitlocker by removing Elephant AND that AES-CBC + Elephant isn't good enough (e.g. lack of integrity)? We might discuss how to best design FDE, or whether FDE is what we want. But that conversation is orthogonal to the fact that AES-CBC is weaker than AES-CBC + Elephant, which is what we are talking about here. Your criticism comes down to: "CBC + Elephant may be stronger than CBC, but neither are strong enough for me". I agree with this.
  - tptacek 12y ago
    Not quite. My high level response to this thread, which opened with a subtextual claim that Microsoft removed Elephant in yet another example of a big vendor being coerced by NSA into weakening end-user crypto, is twofold: * First, that Elephant does not provide meaningful (and certainly not provable) security improvements, and, put in the context of FDE in general, does not give/remove a Bitlocker capability that other mainstream FDE systems actually have. * Second, that the clunky feature Elephant tries to provide (Ferguson calls it "poor man's authentication") is in fact not at all relevant to the NSA threat model; to wit: if your adversary has an (a) continuous and (b) active vantage point to hit you from, no FDE solution can help you. FDE is exclusively valuable in the case where your disk is irrevocably and totally compromised, despite the folklore that says otherwise. Popping up a level further on the stack: I'm rebutting the claim that NSA coerced MSFT into removing Elephant. It was a marginal implementation of a marginal countermeasure that wasn't relevant to NSA. Popping up a level further on the stack: I do not believe that NSA has within the last decade coerced Microsoft into doing anything cryptographic.
    - xnull 12y ago
      The security improvements due to Elephant certainly are not proveable (what in crypto truly is?). I argue that there is meaningful security added by Elephant, clunky though it certainly is - because it does make block modification attacks (which could be used to thwart "Secure Boot") and in that 'poor man's authentication' is better than no man's authentication. Here the perfect very well may be the enemy of the good. Of course I would be happier with something even better. > Popping up a level further on the stack: I'm rebutting the claim that NSA coerced MSFT into removing Elephant. It was a marginal implementation of a marginal countermeasure that wasn't relevant to NSA. Not sure whether this is strong enough evidence to be considered a rebuttal. I do not know and will not claim that it was the NSA (or other) coercing MSFT. > Popping up a level further on the stack: I do not believe that NSA has within the last decade coerced Microsoft into doing anything cryptographic. Not the NSA key? Not the removal of end-to-end crypto from Skype and then onboarding of Skype to PRISM? Not the SEA hacking of FBI request documents? Not bitlocker keys automatically uploaded to OneDrive, and OneDrive onboarded to PRISM? Not TPM 2.0 support - not Germany's leak of TPM backdoors - not China's following ban of TPM 2.0 and Windows 8.1 - not Microsoft's then downport of TPM 2.0 support to Windows 8?Not the cloud key escrow patent? "Once a request comes in from a third party (e.g. a user, a business, a legal entity or governmental entity, etc.) to access user's data, the data storage system may send..." https://www.google.com/patents/US20120321086 https://www.google.com/patents/US20120321086 "MS, working with the FBI, developed a surveillance capability to deal with the new SSL... went live Dec 2012" - Snowden docs http://hbpub.vo.llnwd.net/o16/video/olmk/holt/greenwald/NoPlaceToHide-Documents-Uncompressed.pdf http://hbpub.vo.llnwd.net/o16/video/olmk/holt/greenwald/NoPl... (30) You probably think Microsoft did these things without NSA/TLA coercion.
      - tptacek 12y ago
        "What in crypto truly is provable" is where I get off this train.
        xnull 12y ago
        Hey I love (and defend) crypto but ultimately it relies on (sometimes standard) assumptions like the one-way hardness of discrete logarithms. Symmetric systems hardly have underlying information theoretic garuntees - usually symmetric constructs are based on reductions under random oracle models (which have has its own methodological problems). Furthermore implementations are hardly the same as mathematical constructs, which gives rise to side channels. These are not controversial views - they are common knowledge among cryptographers. It is thus an injustice to knock Elephant on 'provability' grounds. The papers for Elephant (and Lion before it) follow standards for peer reviewed work in cryptography. It is a shame you will not reply to any of the examples in the remainder of the comment. But other HN readers will see them.

by xnull 12y ago

tptacek 12y ago

I didn't say Elephant was XTS. I said that neither XTS --- the industry standard sector-level construction --- nor Elephant actually authenticated sectors. All three of AES-CBC, Elephant, and XTS fail to authenticate data. This isn't my point; it's Rogaway's, and the opinion of several other people during the XTS standardization process, including Ferguson. So it's a stretch to talk about how Microsoft "weakened" Bitlocker by removing the idiosyncratic Elephant construction. None of the design alternatives Microsoft had available provided real authentication, and all of them provide adequate confidentiality (to the extent that's possible with sector-level crypto, which is itself just a bad idea).

xnull 12y ago
Couldn't it both be true that Microsoft weakened Bitlocker by removing Elephant AND that AES-CBC + Elephant isn't good enough (e.g. lack of integrity)? We might discuss how to best design FDE, or whether FDE is what we want. But that conversation is orthogonal to the fact that AES-CBC is weaker than AES-CBC + Elephant, which is what we are talking about here. Your criticism comes down to: "CBC + Elephant may be stronger than CBC, but neither are strong enough for me". I agree with this.
- tptacek 12y ago
  Not quite. My high level response to this thread, which opened with a subtextual claim that Microsoft removed Elephant in yet another example of a big vendor being coerced by NSA into weakening end-user crypto, is twofold: * First, that Elephant does not provide meaningful (and certainly not provable) security improvements, and, put in the context of FDE in general, does not give/remove a Bitlocker capability that other mainstream FDE systems actually have. * Second, that the clunky feature Elephant tries to provide (Ferguson calls it "poor man's authentication") is in fact not at all relevant to the NSA threat model; to wit: if your adversary has an (a) continuous and (b) active vantage point to hit you from, no FDE solution can help you. FDE is exclusively valuable in the case where your disk is irrevocably and totally compromised, despite the folklore that says otherwise. Popping up a level further on the stack: I'm rebutting the claim that NSA coerced MSFT into removing Elephant. It was a marginal implementation of a marginal countermeasure that wasn't relevant to NSA. Popping up a level further on the stack: I do not believe that NSA has within the last decade coerced Microsoft into doing anything cryptographic.
  - xnull 12y ago
    The security improvements due to Elephant certainly are not proveable (what in crypto truly is?). I argue that there is meaningful security added by Elephant, clunky though it certainly is - because it does make block modification attacks (which could be used to thwart "Secure Boot") and in that 'poor man's authentication' is better than no man's authentication. Here the perfect very well may be the enemy of the good. Of course I would be happier with something even better. > Popping up a level further on the stack: I'm rebutting the claim that NSA coerced MSFT into removing Elephant. It was a marginal implementation of a marginal countermeasure that wasn't relevant to NSA. Not sure whether this is strong enough evidence to be considered a rebuttal. I do not know and will not claim that it was the NSA (or other) coercing MSFT. > Popping up a level further on the stack: I do not believe that NSA has within the last decade coerced Microsoft into doing anything cryptographic. Not the NSA key? Not the removal of end-to-end crypto from Skype and then onboarding of Skype to PRISM? Not the SEA hacking of FBI request documents? Not bitlocker keys automatically uploaded to OneDrive, and OneDrive onboarded to PRISM? Not TPM 2.0 support - not Germany's leak of TPM backdoors - not China's following ban of TPM 2.0 and Windows 8.1 - not Microsoft's then downport of TPM 2.0 support to Windows 8?Not the cloud key escrow patent? "Once a request comes in from a third party (e.g. a user, a business, a legal entity or governmental entity, etc.) to access user's data, the data storage system may send..." https://www.google.com/patents/US20120321086 https://www.google.com/patents/US20120321086 "MS, working with the FBI, developed a surveillance capability to deal with the new SSL... went live Dec 2012" - Snowden docs http://hbpub.vo.llnwd.net/o16/video/olmk/holt/greenwald/NoPlaceToHide-Documents-Uncompressed.pdf http://hbpub.vo.llnwd.net/o16/video/olmk/holt/greenwald/NoPl... (30) You probably think Microsoft did these things without NSA/TLA coercion.
    - tptacek 12y ago
      "What in crypto truly is provable" is where I get off this train.
      - xnull 12y ago
        Hey I love (and defend) crypto but ultimately it relies on (sometimes standard) assumptions like the one-way hardness of discrete logarithms. Symmetric systems hardly have underlying information theoretic garuntees - usually symmetric constructs are based on reductions under random oracle models (which have has its own methodological problems). Furthermore implementations are hardly the same as mathematical constructs, which gives rise to side channels. These are not controversial views - they are common knowledge among cryptographers. It is thus an injustice to knock Elephant on 'provability' grounds. The papers for Elephant (and Lion before it) follow standards for peer reviewed work in cryptography. It is a shame you will not reply to any of the examples in the remainder of the comment. But other HN readers will see them.