5 ms·

What you said makes no sense. The assumption is that a block cipher is secure to differential cryptanalysis. CBC mode requires unpredictable IV, and as the BEAS

by wbl 13y ago

What you said makes no sense. The assumption is that a block cipher is secure to differential cryptanalysis. CBC mode requires unpredictable IV, and as the BEAST attack shows, chaining is a bad idea. RFC 3602 specifies using a random IV. Could you please cite minutes and an RFC, and maybe some more information so we can judge for ourselves?

marshray 13y ago
> The assumption is that a block cipher is secure to differential cryptanalysis. That assumption was not taken for granted back in the 90's. It was only with years of cryptanalysis of AES (which had had resistance to known plaintext an explicit design goal) that designers felt comfortable with things like CTR mode. In practice, we've learned that the block ciphers are by far the strongest part of the system, and it's the block cipher modes that provide the weakness for attackers. IMHO this is the type of poisoned knowledge that the US spies should be blamed for.
- diminish 13y ago
  ..isn't a good place to be paranoid the core of AES, namely substitution-permutation network hocus-pocus. (Joan Daemen' and Vincent Rijmen's). A backdoor transformation would suffice to make all other paranoia superfluous.
  - marshray 13y ago
    I'm not saying its impossible, but decades of public cryptanalysis have failed to produce a significant dent in the security of 3DES or AES. On the other hand, we've seen a total discrediting of LFSR-based schemes and a steady flow of issues resulting from the block modes (padding and timing oracles). We should be paranoid, but mostly that we might be not worrying about the right things.
    - diminish 13y ago
      You are right that padding/timing attacks on block modes and weaknesses in PRGs form the bulk of contemporary cryptanalysis. Nonetheless, if there is one single backdoor transform with a unique key on AES substitution-permutation network which would make further attacks possible, it would be nearly impossible to devise a adversary/challenge to reveal it using current cryptanalysis techniques. The standardization history for AES, and the organizations involved does not give much hope neither.
      - marshray 13y ago
        There are a couple of reasons I have some hope for the security of AES: 1. There's this proof that a trapdoored symmetric cipher is equivalent to a public key system (there's a link in the metzdowd thread somewhere). No one seems to have figured out how to build a public key system with anything close to the efficiency of AES. 2. The specification of AES itself isn't that large. It's not minimal, but neither does it seem to have large arbitrary-looking constants. https://en.wikipedia.org/wiki/Kolmogorov_complexity https://en.wikipedia.org/wiki/Kolmogorov_complexity https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number The NIST Dual-EC DRBG fails on both counts: 1. it is based on an obvious public key system, and 2. it recommends the use of large arbitrary constants that could easily be a trapdoor. Now is it possible that NSA occasionally intentionally fails to backdoor a NIST standard in order to help us underestimate how often they succeed? Can we ever develop a coherent threat model with the possibility of this kind of adversary?
    - tptacek 13y ago
      I think if you're going to be a paranoid, Marsh, you might as well be an equal-opportunity paranoid and not exempt the algorithms you happen to like (or need, professionally). I think you're obligated to provide a real rationale for why we shouldn't all switch to Camellia.
      - marshray 13y ago
        How about RC4 -> GOST -> AES -> Camellia, all with unrelated keys?
- wbl 13y ago
  Now I am genuinely curious: at what point did the standard game definitions of security become widespread/presented? Because given those it is obvious that CTR is secure given a PRP, which any block cipher should be to be semantically secure when encrypting a single block.
  - marshray 13y ago
    My impression is that it was NSA/NIST's AES specification process that made it "officially OK" to stop worrying about known plaintext. But really we need to ask some the folks older than I am. It would be a good question for the randombit or metzdowd crypography lists. Also, I'll tweet at Bellovin. Edit: https://twitter.com/marshray/status/376600321637638144 https://twitter.com/marshray/status/376600321637638144
tytso 13y ago
Um, so you realize that the BEAST attack is pretty TLS (and heck, pretty implementation specific --- it only works against certain websockets implementation). That's because it is a chosen-plaintext attack, so it is dependent on TLS being used to encrypt Javascript, where the Javascript libraries are hosted on a server under the attacker's control. Also, remember in the early 90's, when IPSEC was still going through its indeterminable standardization process, this was pre-AES, and most of us were still using DES (or if we could afford the CPU --- CPU's were much slower back then) 3DES. Heck, some of this work was going on before Javascript was even invented! :-) BTW, I was wrong, the comments about not using a counter did make it into an RFC. See RFC 2405, which does state that using a counter or some other low-hamming distance is preferred. Note that there are dangers with using a random IV --- if you do this, the RNG used to generate your IV's had better be independent of the RNG used to generate your session keys, or else you might potentially leak information about your RNG state that might be yet another wedge into attacking the crypto. (In particular, I would NOT recommend using RDRAND in bare fashion --- see comments on my G+ post #ThinkLikeTheNSA --- about what fun and games you might have if you could compromise the RDRAND instructuction.) If you really want to be paranoid, generate a separate key (different from the key used for encryption and for generation of the MAC) and use that key as the basis of a Cyptographic RNG, and then use the output of that CRNG for your IV.
- caf 13y ago
  BEAST does not require encrypting of Javascript. It uses Javascript, which can just as well be delivered unencrypted, to induce the browser to make separate requests to the HTTPS site, which include the chosen plaintext. In the context of network stacks rather than browsers, inducing the target to encrypt chosen plaintext is often possible - ICMP ECHO, for example. Of course it seems rather difficult to arrange for your chosen plaintext to be right at the start of an IPSEC packet, since there will usually be a TCP or UDP header - but perhaps it is possible (and even if it isn't, that looks like rather flimsy protection).
  - tptacek 13y ago
    He is right about how specific the circumstances are that give rise to Bard's CBC IV attack. Not only that, but BEAST itself was the product of a former NSA cryptologist, now a Wisconsin university math professor; it is vanishingly unlikely that it was common knowledge inside of NSA, since the guy PUBLISHED it just a year or two after leaving the agency. Either way, IPSEC was formulated in the dark ages of crypto. Almost nobody (except Phil Rogaway) knew this stuff about CBC back when the standard was being drafted.

by wbl 13y ago

marshray 13y ago

> The assumption is that a block cipher is secure to differential cryptanalysis. That assumption was not taken for granted back in the 90's. It was only with years of cryptanalysis of AES (which had had resistance to known plaintext an explicit design goal) that designers felt comfortable with things like CTR mode. In practice, we've learned that the block ciphers are by far the strongest part of the system, and it's the block cipher modes that provide the weakness for attackers. IMHO this is the type of poisoned knowledge that the US spies should be blamed for.

diminish 13y ago
..isn't a good place to be paranoid the core of AES, namely substitution-permutation network hocus-pocus. (Joan Daemen' and Vincent Rijmen's). A backdoor transformation would suffice to make all other paranoia superfluous.
- marshray 13y ago
  I'm not saying its impossible, but decades of public cryptanalysis have failed to produce a significant dent in the security of 3DES or AES. On the other hand, we've seen a total discrediting of LFSR-based schemes and a steady flow of issues resulting from the block modes (padding and timing oracles). We should be paranoid, but mostly that we might be not worrying about the right things.
  - diminish 13y ago
    You are right that padding/timing attacks on block modes and weaknesses in PRGs form the bulk of contemporary cryptanalysis. Nonetheless, if there is one single backdoor transform with a unique key on AES substitution-permutation network which would make further attacks possible, it would be nearly impossible to devise a adversary/challenge to reveal it using current cryptanalysis techniques. The standardization history for AES, and the organizations involved does not give much hope neither.
    - marshray 13y ago
      There are a couple of reasons I have some hope for the security of AES: 1. There's this proof that a trapdoored symmetric cipher is equivalent to a public key system (there's a link in the metzdowd thread somewhere). No one seems to have figured out how to build a public key system with anything close to the efficiency of AES. 2. The specification of AES itself isn't that large. It's not minimal, but neither does it seem to have large arbitrary-looking constants. https://en.wikipedia.org/wiki/Kolmogorov_complexity https://en.wikipedia.org/wiki/Kolmogorov_complexity https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number The NIST Dual-EC DRBG fails on both counts: 1. it is based on an obvious public key system, and 2. it recommends the use of large arbitrary constants that could easily be a trapdoor. Now is it possible that NSA occasionally intentionally fails to backdoor a NIST standard in order to help us underestimate how often they succeed? Can we ever develop a coherent threat model with the possibility of this kind of adversary?
  - tptacek 13y ago
    I think if you're going to be a paranoid, Marsh, you might as well be an equal-opportunity paranoid and not exempt the algorithms you happen to like (or need, professionally). I think you're obligated to provide a real rationale for why we shouldn't all switch to Camellia.
    - marshray 13y ago
      How about RC4 -> GOST -> AES -> Camellia, all with unrelated keys?
wbl 13y ago
Now I am genuinely curious: at what point did the standard game definitions of security become widespread/presented? Because given those it is obvious that CTR is secure given a PRP, which any block cipher should be to be semantically secure when encrypting a single block.
- marshray 13y ago
  My impression is that it was NSA/NIST's AES specification process that made it "officially OK" to stop worrying about known plaintext. But really we need to ask some the folks older than I am. It would be a good question for the randombit or metzdowd crypography lists. Also, I'll tweet at Bellovin. Edit: https://twitter.com/marshray/status/376600321637638144 https://twitter.com/marshray/status/376600321637638144

tytso 13y ago

Um, so you realize that the BEAST attack is pretty TLS (and heck, pretty implementation specific --- it only works against certain websockets implementation). That's because it is a chosen-plaintext attack, so it is dependent on TLS being used to encrypt Javascript, where the Javascript libraries are hosted on a server under the attacker's control. Also, remember in the early 90's, when IPSEC was still going through its indeterminable standardization process, this was pre-AES, and most of us were still using DES (or if we could afford the CPU --- CPU's were much slower back then) 3DES. Heck, some of this work was going on before Javascript was even invented! :-) BTW, I was wrong, the comments about not using a counter did make it into an RFC. See RFC 2405, which does state that using a counter or some other low-hamming distance is preferred. Note that there are dangers with using a random IV --- if you do this, the RNG used to generate your IV's had better be independent of the RNG used to generate your session keys, or else you might potentially leak information about your RNG state that might be yet another wedge into attacking the crypto. (In particular, I would NOT recommend using RDRAND in bare fashion --- see comments on my G+ post #ThinkLikeTheNSA --- about what fun and games you might have if you could compromise the RDRAND instructuction.) If you really want to be paranoid, generate a separate key (different from the key used for encryption and for generation of the MAC) and use that key as the basis of a Cyptographic RNG, and then use the output of that CRNG for your IV.

caf 13y ago
BEAST does not require encrypting of Javascript. It uses Javascript, which can just as well be delivered unencrypted, to induce the browser to make separate requests to the HTTPS site, which include the chosen plaintext. In the context of network stacks rather than browsers, inducing the target to encrypt chosen plaintext is often possible - ICMP ECHO, for example. Of course it seems rather difficult to arrange for your chosen plaintext to be right at the start of an IPSEC packet, since there will usually be a TCP or UDP header - but perhaps it is possible (and even if it isn't, that looks like rather flimsy protection).
- tptacek 13y ago
  He is right about how specific the circumstances are that give rise to Bard's CBC IV attack. Not only that, but BEAST itself was the product of a former NSA cryptologist, now a Wisconsin university math professor; it is vanishingly unlikely that it was common knowledge inside of NSA, since the guy PUBLISHED it just a year or two after leaving the agency. Either way, IPSEC was formulated in the dark ages of crypto. Almost nobody (except Phil Rogaway) knew this stuff about CBC back when the standard was being drafted.