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
* 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
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.
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
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.
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
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.
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com