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

Phillip Hallam-Baker phill at hallambaker.com
Sat Nov 7 15:47:43 EST 2015


I think this particular discussion demonstrates the difference between
the breaker and the builder mentality and why being skilled at one is
not necessarily an indication of skill at the other.

>From my point of view as a builder, the question of whether there is a
risk from using one key with two separate ciphers is irrelevant as
that is something I never do. If I need separate encryption and
authentication keys, I will generate them using one way functions k1 =
H(m, x1), k2 = H(m, x2). I always take the conservative approach
unless there is a really, really good reason to work at the bleeding
edge.

>From the point of view of a breaker, the question of how the designer
should have built the system isn't very relevant. What they care about
is whether a particular system can be broken. And so if you are
starting from a system that has mixed up two types of crypto, the
question is very relevant.


What I think the industry needs is more of a balance between breakers
and builders and in particular, we need builders to step up and be
willing to be as visible as the breakers. Building secure systems is
hard. And people start laughing the minute you even suggest you can do
that.

Breaking is also rather more entertaining. I love to hear someone
describe how they roto-rooted the braindamaged security system in some
car as much as the next person. That stuff is funny. And so we have
conferences that now have more than half the tracks made up of
'hackers and threats' tracks.

This is a problem because the reason employers send people to those
conferences is that they want secure stuff, not employees who have
been thoroughly entertained for a week hearing about the braindamage
in other people's products.

Google's recent change of slogan from 'don't be evil' to 'do the right
thing' is actually an important and necessary step. It is a sign of
maturity. As Marcus Ranum pointed out, enumerating badness is a
failing objective, there is an infinite amount of badness and so if
your guide to choosing a path is not doing the wrong thing, you will
never start off. 'Don't do it wrong' is a paralyzing approach to
security because there is very rarely a perfectly secure option on the
table and sometimes what appears to be the correct path isn't the
right one to take.


More information about the cryptography mailing list