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

[ianG]

On 7/11/2015 02:24 am, Will Sargent wrote:
> On Fri, Nov 6, 2015 at 6:01 AM, Max Kington <mkington at webhanger.com
> <mailto:mkington at webhanger.com>> wrote:
>
>
>
>     On Wed, Nov 4, 2015 at 7:09 PM, Will Sargent <will.sargent at gmail.com
>     <mailto: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.


That's quite controversial.

  * It sort of posits that homegrown crypto causes people to act more 
dangerously, the so-called "false sense of security" ... but this isn't 
really how the world works.  In the real world, we run through the list 
of risks, do what we can to mitigate them, and then move on.  Those that 
we fail to close of, we accept.  We're at risk all the time against 
everything, it's just a set of different levels.

  * As a practical observation, home grown crypto is often shown to have 
weaknesses due to the simple lack of knowledge - fair enough given the 
limited time the home gardener has to pick up the skills.  But what is 
not shown very often is that the home grown crypto led to actual 
monetary damages, and that is because:

  * Homegrown crypto is a far better thing than no crypto, and while 
it's not being attacked by an actual person with cryptanalytic 
experience, it's knocking hordes of scammers, script kiddies, criminal 
gangs and what-have-you.  There still remains a tight negative 
correlation between cryptanalytic skills and criminal gangs, although 
the publication of academic results does tend to lead to the development 
of script exploits leading to potential dangers.

  * people in the crypto business like to say "homegrown crypto is a bad 
idea" so that they get the job.  But this is about their security not 
yours.  Unfortunately, the professionals who say that often can't do 
risk analysis so they can't see that their approach can take away 
important elements of your other security.  Leaving you worse off than 
if you focus on what is really hurting your business.


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


Sounds ok.


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


Ah.  So maybe what you really want is a library that exposes an 
encrypt&auth method.  This is called Authenticated Encryption or AEAD, 
and is a thing.  It's not so well standardised as yet, there is an 
active competition to provide it.  Probably the algorithm that is most 
popular in this vein is Chacha/Poly but even that is two algorithms 
composed.

(BTW, calling the HMAC-SHA1 'signing' isn't quite right.  Signing is 
reserved for public key ops, as they have long term reliability, whereas 
the use of HMACs is considered to be ephemeral, temporary, good enough 
to stop an attacker in the next minute.  Authentication is the verb most 
used there.)


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


Hmmm... you haven't established a harm as yet.  Maybe you know something 
else, but it doesn't seem like a huge problem that they're putting some 
extra encryption in place?


> Then I'm going to point them at Kalium or Keyczar and wish them good luck.


If you're moving them from an old deprecated library to a newer 
supported one, ok.  OTOH, if you're moving them from some standard 
inhouse thing that they already have, and are just adding another 
external dependency, well, that could cause issues on its own.



iang