fun thought of the day: for IND-CCA2 security, it theoretically doesn't matter what the cryptosystem does when you do "encrypt(key, key)" (iow, encrypt the key using the key), right? since in the IND-CCA2 game, you can only hit that case with negligible probability?
-
-
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
yeah, here's a contrived encrypt-and-mac scheme that will break completely with encrypt(key, key): E(k, m) = iv || AES-CBC(HMAC(k, k), iv, m) || HMAC(k, m) E(k, k) will reveal HMAC(k, k), and from there you can find k
-
Well there are many other fishy things in this construction on its own....
End of conversation
New conversation -
-
-
it's quite unnerving but in protocols where this might happen there seems to be a preference for not exposing actual key material but only allowing export (for channel binding, that sorta stuff) of secrets derived from it with some kind of PRF/hash in between:pic.twitter.com/xtWZpWckwz
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
In practice most schemes are actually fine if you make very strong assumptions about the security of the encryption primitives. The gap between theory and practice here is large.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.