Ah, I see what you mean. Thanks for explaining. So, if I understand correctly, your threat model is that you want to prevent an attacker who obtains the traffic keys from injecting new traffic during the plausible lifetime of the connection (once close_notify has been exchanged, the traffic keys are useless).
Whether this is possible or not with a given AEAD transform seems to depend on the transform. FWIW, in the specific case of HMAC, because the key \xor pad fills an entire digest block, you might imagine storing the state of the outer compression function after the first block in the hardware module. I am not aware of any analysis that shows that this is safe and it very likely is not as strong as having the entire HMAC key in the module, but it might (or might not) be better than nothing. -Ekr On Mon, Nov 30, 2015 at 7:17 PM, Bill Cox <waywardg...@google.com> wrote: > On Mon, Nov 30, 2015 at 7:06 PM, Eric Rescorla <e...@rtfm.com> wrote: > >> Hi Bill, >> >> I am sorry, but I do not understand what you are proposing. Do you think >> you could try restating the computation you have in mind, perhaps by >> providing an equation that explains the construct? >> > > Sure. I'll stick to HMAC, which is more widely understood. We do > encrypt-them-mac using the write key. The inner SHA-256 consumes the > entire ciphertext, and at the end, the outer SHA-256 is applied. > > This hack would use a different key for the outer SHA-256. This way, it > is only used to hash a single block. > > Quite a hack, right :) > > Bill >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
