5 ms·
Wouldn't including a constant block at the beginning of every message of the plaintext help to break any ciphertext generated from the plaintext?
by jsprogrammer 11y ago
Wouldn't including a constant block at the beginning of every message of the plaintext help to break any ciphertext generated from the plaintext?
- bascule 11y agoNo, secure ciphers like AES are not vulnerable to known plaintext attacks
- tptacek 11y agoHold on. AES is not intrinsically vulnerable to known-plaintext, like every modern cipher probably going back all the way to DES, but that doesn't mean AES constructions can't be attacked through known plaintext runs. This particular text isn't a vulnerability (after all, HTTP is full of known plaintext), but I think you've overplayed your argument. :)
- logicallee 11y agoyeah, if knowing the leading 192 bits of the plaintext (24 octets, per article) lets an attacker break a session encrypted with 256-bit AES, you've got bigger problems than a known-plaintext attack, methinks. :)
- jsprogrammer 11y agoThis may be true for a single session, but it would seem that having every session begin with the same long text could allow correlations to be drawn on large data sets, potentially leading to full recovery of the sessions. Do you know of the proof that rules out such a possibility?
- logicallee 11y agono of course I don't know such a proof. But I wouldn't say 192 bits is long, in any case! It's absolutely tiny.
- tptacek 11y agoNo, that is not a realistic vulnerability. I am now regretting nerding out about AES upthread, since I seem to have created the impression that there is some risk to having every HTTP request start with a fixed string. There is not.
- jsprogrammer 11y ago>I seem to have created the impression that there is some risk to having every HTTP request start with a fixed string Every HTTP request does not start with a fixed string. Every HTTP2 request apparently does (if I have read correctly). >There is not. Why not? What allows AES to escape such an attack?
- tptacek 11y agoThere is not. This is something the first few lectures in Boneh's Coursera class should address for you.
- minitech 11y ago> Why not? What allows AES to escape such an attack? What attack? A known plaintext attack is just a type of attack. There aren’t any such known attacks against AES currently. http://crypto.stackexchange.com/a/10837/7264 http://crypto.stackexchange.com/a/10837/7264 is related.
- jsprogrammer 11y agoFair enough. Maybe there is some disagreement between the participants of this thread in what "known-known" means. I would say that without a proof that a known-plaintext attack cannot exist, one cannot say "There is not (a known-plaintext attack)." One could say, however, "I do not know of a known-plaintext attack against AES, however I do not know of a proof that rules one out." Also, HTTP/2 traffic may be encrypted using another scheme (which may be vulnerable to large constant blocks in known locations). I don't think HTTP refers or deals at all with encryption. I'm not sure about HTTP2. My understanding is that they are application protocols only and that message integrity protocols occur at a different layer.
- AnimalMuppet 11y agoWell, it eliminates most of the possible keys. Out of 2^256 possible keys, only 2^64 are now possible. This would be serious if someone found a way to easily identify which keys were still possible. From there, you could find the real key simply by a process of elimination. It would be somewhat lengthy, but not unreasonably so. But so far as I know, nobody yet knows how to easily identify which keys are still possible. Note: I'm ignoring IVs here, partly because I don't know if HTTP2 uses them. They may make the process of elimination impossible (at least in realistic amounts of time).
- tptacek 11y agoThis looks like exactly the kind of vulnerability that Tony Arcieri is, correctly, saying doesn't happen with modern ciphers. HTTP2 doesn't "use IVs" at all, in that encryption in HTTP2 is provided by TLS. TLS does use random IVs, and modern TLS uses them correctly.
- maaku 11y agoIsn't supposed to happen. It would be a break of AES if it were to be shown to be possible. However it would mean that such a break would be instantly exploitable, rather than having defense in depth by requiring multiple independent failures. Our crypto systems should not be so fragile...
- tptacek 11y agoNo. As has been repeatedly pointed out: HTTP is positively loaded with much longer runs of known plaintext.
- jsprogrammer 11y ago>This particular text isn't a vulnerability (after all, HTTP is full of known plaintext). This isn't quite a proof. You'd need to show that HTTP is not vulnerable to such an attack. I don't think HTTP requires a starting block. HTTP2 apparently requires a client's first message to be/start with: 0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a I'd guess that is much longer than any block that HTTP mandates. Maybe I am reading things wrong?
- danielhlockard 11y agodoesn't HTTP require "VERB URL HTTP/VERSION" ?
- jsprogrammer 11y agoYes, but there are many VERBs and URLs.
- danielhlockard 11y agobut "GET / HTTP/1.1" is likely the most common.
- jsprogrammer 11y agoI'd believe it might be the most common (though, I'd guess "GET /favicon.ico HTTP/1.1" to be a real contender). I highly doubt either are anywhere more than a small fraction of the total HTTP requests though.
- arcatek 11y agoNot actually requiring something to start with a fixed string doesn't really mean anything when every message begins with a fixed string because it's just the way to do.
- Ar-Curunir 11y agoIf you use randomness (like in say CBC mode) that should suffice to give you IND-CPA security, no? And I believe GCM mode gives you IND-CCA2 security as well.
- hackcasual 11y agoActually CBC is a great mode for demonstrating how constructions built on secure primitives can introduce vulnerabilities. We can prepend a specific block to one with known plaintext in CBC mode to end up with garbage + plaintext we control.
- yuhong 11y agoThere is a reason HTTP/2 requires GCM or other AEAD. TLS's MAC-before-encrypt is flawed because of these kinds of attacks.
- venning 11y agoWhat is it about this particular text that makes it not vulnerable? That it is short?
- deleted 11y ago[deleted]
- magicalist 11y agoAs shown in the commit itself[1] (and implied by the original article), the connection header always started with a constant text block. It was just changed to include "PRISM" instead of "START". [1] https://github.com/http2/http2-spec/commit/ac468f3fab9f7092a430eedfd69ee1fb2e23c944 https://github.com/http2/http2-spec/commit/ac468f3fab9f7092a... (as linked by others below)
- jsprogrammer 11y agoThe particular constant block may not matter much. The curious thing here (for me at least) is all sessions beginning with a constant block of some length.