On Feb 27, 2009, at 2:13 PM, Santiago Aguiar wrote:
* Is there any standard cryptographic hash function with an output
of about 64 bits? It's OK for our scenario if finding a preimage for
a particular signature takes 5 days. Not if it takes 5 minutes.
Not specifically, but you can simply take the first 64 bits from a
larger cryptographically secure hash function. If the nature of your
usage is that an attack requires finding a preimage to an externally
specified hash value, 64 bits is reasonably secure. (If being able to
find a pair of values with the same hash value, 64 bits is way too
short.)
* Suppose a cryptographically secure random number is stored on the
device from factory, could I use the output of a block cipher
applied to this number as a way to generate new random numbers
(since the output from the cipher should not be distinguishable from
random data)? In case yes, could I do this with a hash instead of a
cipher?
Both of these techniques have been used. If you want a simple
security argument for the block cipher case, use the pre-stored random
number as the key and encrypt 0, 1, 2, and so on. If some can use
this output to get the key; or if given encryptions up to n, they can
guess the encryption at n+1, then the cipher could not be used in
counter mode (since what you are getting is exactly the counter-mode
encryption of an all-0-bits message). Obviously, you'll have to store
the counter across boots, since otherwise you repeat values.
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.
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.
For those interested, this is what we are proposing at the time:
Every TCU (the device) comes pre-installed from factory with a Kt
known to the device and DENATRAN.
SO-> TCU (device): sends a SMS with GPRS connection information
(apn, user, pass, server IPs/ports). The mechanism so that this
first SMS is not a big issue have been, reasonably, covered.
TCU->SO: challenge
SO->DENATRAN: challenge, SO_id
DENATRAN->SO: H(Kt, challenge, SO_id), Kc=H(Kt, challenge)
SO->TCU: H(Kt, challenge, SO_id), SO_id
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).
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.
-- Jerry
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
