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

[Will Sargent]

On Fri, Nov 6, 2015 at 6:01 AM, Max Kington <mkington at webhanger.com> wrote:

>
>
> 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?
>

This is a system I'm decommissioning, because homegrown crypto is a Bad
Idea.  I want to be able to assert that the reuse of keys here, while not
recommended, has not been actively broken (or at least, there are no
publications to that effect), and if they used AES-CTR and then immediately
MACed the result and didn't mix it with anything... then they're probably
fine.  Maybe.

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.
>

Right -- I know that AES-CTR + HMAC is a construction and so there are Ways
To Do That Wrong.  However, I can't know how users put them together.  I
have a library that exposes an encrypt method, and a sign (HMAC-SHA1)
method -- no real way to know how users composed them, if they did at all.

 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.
>

It's more general advice.  The encrypt method is not used at all within the
system itself, only signing is used.  Some end users found and started
using the encrypt / sign methods for their own crypto and so I'm
deprecating those methods and sticking large warnings over everything.
Then I'm going to point them at Kalium or Keyczar and wish them good luck.

Will.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20151106/3090a0d3/attachment.html>