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

[Max Kington]

On 7 Nov 2015 02:25, "Will Sargent" <will.sargent at gmail.com> wrote:
>
> 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 wouldn't have said homegrown use of crypto was necessarily a bad idea
(tm). In fact I'd go soc far as to say that we should be careful to not
make that an unqualified statement and say what we consider the risk there.
What we usually worried about is home spun algorithms (with poor
properties) and poor constructions of known ones. Assembling the tools in
the toolbox is in my book fine if you know what you're doing.
>
>> 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.

I think on that basis you can't necessarily say this is bad.

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

If that's the case and that seems fair enough they still need to use the
pieces sensibly and using certainly NaCl still means you can shoot yourself
in the foot.  Keyczar I guess less so.

BUT!

Two things, in my world cryptographic libraries need creating as special
kinds of assets so that if they later found to be flawed we can find them.
This may not be a worry for you but consider if you're introducing more
complexity which you don't need.

Change it when you need to which I guess you're kind of doing.

Secondly if people are going to do a rethink and think more broadly about
key management then that's a deeper bit of reengineering and if the
opportunity presents itself that might be a better (or additional) legacy
to your review.

Are you decommissioning it in whole *because* of the crypto? Or just these
libraries all be the quality of their use by the parent app is unknown? I
didn't quite follow that.

Cheers
M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20151109/6230353d/attachment.html>