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

[Will Sargent]

>
> This is a system I'm decommissioning, because homegrown crypto is a Bad
>> Idea.
>>
>
>
That's quite controversial.


Well, the first version used AES-ECB with unbounded input.  The second
version used AES-CTR without a MAC, and has a versioning scheme so it can
fall back to AES-ECB.  It's not something that needs to be around, and it
comes with no instruction manual.


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

I poked at this a bit with an AES-GCM proof of concept:
https://github.com/wsargent/jce-aes-cipher-poc but ultimately, it's better
handled by a high level crypto library.


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


Yeah, that vocab comes from Keyczar, which uses a "Signer" for both RSA
signatures and HMAC:

https://github.com/google/keyczar/wiki/HmacKey
https://github.com/google/keyczar/wiki/OperationSign


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


I don't see that there's an established harm or vulnerability, but it's not
something we want to maintain.


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


Right -- there is no "newer supported" one, and the current one has never
been supported, it was discovered.  It may cause some issues, but long term
moving to a supported library is the right move.

Will.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20151107/687d38af/attachment.html>