[Cryptography] Literature on reusing same key for AES / HMAC?

[Max Kington]

On Wed, Nov 4, 2015 at 7:09 PM, Will Sargent <will.sargent at gmail.com> wrote:

> Hi there,
>
> I'm looking at a very specific issue, where the same secret key is used
> with AES-CTR for encryption, and then later that same key is used for
> signing the ciphertext with HMAC-SHA1.  I know that generally it's unsafe
> for CBC-MAC (which I'm not familiar with) and RSA keys: I want to be able
> to say AES / HMAC is a safe or unsafe construction, and so far I'm not sure
> which.
>

Ultimately you could only be *sure *it's an unsafe construction but only
have some confidence in it being a safe construction.

I guess the real question is to what end?

As Ian says, are you reviewing an existing system?  If so are you trying to
assert that the application *needs* changing to better apply a separation
of use principle for the purpose of a key (namely that your encryption and
integrity keys should be different for all the key management reasons
that's a good idea)?  Or is is that you want to assert that in this case,
the risk is low and doesn't *have* to be changed but could be?


>
> I've got two different sources, one saying that this is safe, the other
> one that it is not.
>
> Steve Weis here says that AES is not safe when using the same key for both
> signing and encryption:
>
> https://youtu.be/KDvt_0cafPw?t=36m45s
>

I think you need to be a bit careful about what is meant here by safe and
unsafe and think about it in the context of what you're concerned about.
Specific cryptographic attacks relating to using AES as the chosen block
cipher to underpin MAC OR the general principal of key separation.


>
>
> But Thomas Porrin says:
>
> "With HMAC vs AES, no such interference is known. The *general feeling* of
> cryptographers is that AES and SHA-1 (or SHA-256) are "sufficiently
> different" that there should be no practical issue with using the same key
> for AES and HMAC/SHA-1."
>
> http://crypto.stackexchange.com/a/8086/10979
>
> I've looked online, but don't know exactly what phrases to look for --
> "key reuse" is typically used in a "reusing key with same IV" sense, and
> "key type mixing" doesn't show very much either.  "key separation
> principle" brings up "On the Importance of the Key Separation Principle for
> Different Modes of Operation" which is firewalled, and a paper on Key Reuse:
>
> * https://crypto.stanford.edu/RealWorldCrypto/slides/kenny.pdf
>

 Key purpose reuse is what Weis goes on to talk about is the general idea
that every time you use a key you expose information about the key.  If you
are ever forced to have to change a key because it has been compromised
(either stolen or broken and recovered) then you are able to make
assertions about what you've lost, i.e. the data previously might not have
had integrity but it wasn't ever exposed.  Can I go back, check the
contents of my data and be satisfied that it is what was transmitted and
not interfered with but still be happy it's not been leaked.

The general perspective case to my mind probably doesn't warrant changing
an incumbent system (at least in any high priority) but would make me want
to encourage a change to the design of a system yet to be deployed if
that's an option.

Sorry if this is all a bit teaching granny to suck eggs but are you worried
about the general case or some specific attack? Because that matters a lot
in the context of your question.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20151106/12335db7/attachment.html>