4 ms·
I also don’t understand how padding oracle attack corresponds to this if all IDs are under 128 bits.
by heavenlyblue 7y ago
I also don’t understand how padding oracle attack corresponds to this if all IDs are under 128 bits.
- blattimwind 7y agoWhile AES(0||id) is subject to a padding oracle, it's not immediately obvious why this would be a useful capability to an attacker, since you can't tweak your input based on the oracle's output (unlike e.g. AES-CBC).
- tptacek 7y agoHow is AES(0||id) subject to a padding oracle? Am I misunderstanding the notation?
- blattimwind 7y agoYeah, that's not a padding oracle, but it's similar in concept, because the prefix check after decryption will likely leak whether the app considers the ciphertext valid, ala: pk = decrypt(params.id) if pk[0:8] != EIGHT_ZEROS: return Http404 id = int(pk[8:16]) object = db.query(id) Also stuff like this isn't really specific to using this particular construction. Even if systems are designed to return "does not exist" instead of "forbidden", it's hard to make authorization checks constant time and I've never seen code to even try that.
- tptacek 7y agoSure, but you can't adaptively choose a new ciphertext to iterate with. Which is the core of the concept.
- blattimwind 7y agoYeah, exactly. I don't think we disagree, I just abused the name a little bit - not a good idea in this field!
- deleted 7y ago[deleted]
- heavenlyblue 7y agoI don’t think you have any idea of what you’re talking about. The attack you mention doesn’t help you retrieve any part of the encrypted text, it only leaks the upper bound of cardinality of the set of all IDs. While the padding oracle attack would allow you to retrieve parts of the actual ID.