Jerry Leichter wrote:
Not specifically, but you can simply take the first 64 bits from a
larger cryptographically secure hash function.
OK, I didn't know if it was right to do just that. We were thinking to
use that hash in an HMAC so the TCU and SO can know that they were
originated from someone who knows Kc and to protect it's integrity (see
With a hash, you need to be a bit fancier since, in and of itself, the
hash has no secret information. This can be done, but it would be
trickier; I'd go with the block cipher.
Best if we can avoid trickier things!. I was thinking of a hash so maybe
we could reuse the ones we were using on other parts of the protocol
(since probably asking to include support for a larger set of primitives
on all devices would be resisted); but we can, of course, just require
that the TCU generates a random challenge and leave the mechanism to be
defined by each implementation.
Note that there are published algorithms - even part of FIPS standards
- that do exactly what you need: Take a single random seed and safely
stretch it into a large number of random values. The ones in the
standards - and perhaps most of the ones out there - are old and
probably not up to contemporary standards.
Will take a look at them, thanks.
You're trying to produce a keyed hash function (or MAC) from a
non-keyed hash function. Just pre-pending the secret key is not
necessarily secure. I'd suggest using HMAC (with Kt the key, of course).
Yes, I was aware of this, the H should be an HMAC. AFAIK it shouldn't be
a problem, just some extra cycles and doing it the right way, right?
The 64 bits limitation is because the protocol only has 1 slot to
include *some* auth information, and it's a 64 bits field (yes, it has
been defined without knowing what exactly will go there ;)). The
protocol was defined by a working group and trying to changing it can
be... complicated... unless we have obvious arguments to show that it's
From that point, Kc is stored in SO and TCU, and every message
interchanged between the SO and TCU goes signed with Kc (for this we
need a H with max. 64 bits output...).
Signed? How? I don't understand the 64-bit limitation. I'm not sure
a 64-bit signing key is sufficient these days.
By signed I meant doing a HMAC(Kc, body of message (with auth field in
0, sic)). Would it be OK in this case to truncate the output of ie. a
HMAC-SHA1 to 64 bits? My crypto/math is not good enough to understand
how hard would be in this case to modify a msg to reuse a previous
Thanks for your comments Jerry!
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com