On Tuesday 21 June 2005 23:00, Jerrold Leichter wrote: > It's much > harder to see how one could attack a session key in a properly implemented > system the same way. You would have to inject a message into the ongoing > session. However, if the protocol authenticates its messages, you'll never > get any response to an injected message. At best, you might be able to > observe some kind of reaction to the injected message. But that's a channel > that can be made very noisy, since it shouldn't occur often. (BTW, if you > use > encrypt-then-authenticate, you're completely immune to this attack, since the > implementation won't ever decrypt the injected message. Of course, there may > be a timing attack against the *authentication*!)
I agree with your comments about the injection, but I don't see why the attack doesn't work on the session passively. Are you assuming that because it is a session, it's in some way not plausible to match the inbound packets with outbound packets? I would have thought that was possible with things like keep alives and so forth. The only drawback I can see is that there might not be enough data (hence desire to tickle things along with an injection). When I was thinking about "use a mode" I was more thinking about how a mode could be the cover needed to hide the decrypt time. A straight CBC mode would probably make matters worse because it is a known length and the key doesn't change, so plausibly the longer the total packet, the better the time estimate. But if the key were to change for each block in a decrypt-dependent fashion, this would presumably render the total time as an average over many decrypts of many block keys. The longer the packets, the more the cover, and no key gets used more than once anyway. So, hypothetically a mode that XOR'd the previous output with the key before encryption (heaven knows whether that would be cryptographically sound, but something along those lines, anyway). Alternatively, if one is in the unfortunate position of being an oracle for a single block encryption then the packet could be augmented with a cleartext random block to be xor'd with the key each request. iang -- Advances in Financial Cryptography, Issue 1: https://www.financialcryptography.com/mt/archives/000458.html Daniel Nagy, On Secure Knowledge-Based Authentication Adam Shostack, Avoiding Liability: An Alternative Route to More Secure Products Ian Grigg, Pareto-Secure --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
