Shared Secret Key Length

Question

I'm trying to create an authenticated HTTP service endpoint by using shared secret.

A good example is Flickr signing scheme.

I'd like to know what is the best public key and secret key length? I'm almost sure people will say arbitrary, but would like to know what are the general opinion and why.

Another question, Flickr uses MD5 to generate the "signature". I read that MD5 is no longer secure, what are the alternatives to MD5? And since consumers of the service will need to generate this signature, bonus point for ease of use and multi-platform library support.

Answer 1

As for alternatives to MD5 goes, I think the SHA family of hash functions are considered the de-facto replacements. They come in different flavours with different hash sizes:

• SHA1
• SHA256
• SHA512

Obviously the newer versions (with longer hashes), will provide more security. There has been reports that SHA1 is broken, but for most practical applications, I would still consider it secure.

When selecting a shared key length, I would go for a length around the same length as the length of the hash value, in order to have a sufficient space of possible keys. It seems to me that choosing a longer key would give no added benefit. If someone where to brute-force attack your application, theoretically they would have found the key when they have tried as many keys as there are possible hash values. (Disclaimer : I am not a cryptographics expert and might be wrong on the previous statement).

Today, SHA is supported on most platforms, including .NET and Java.

Answer 2

An alternative to MD5 is would be the MD6 Hash Algorithm but it is not ready yet.
Meanwhile, here is a good read on secure hashing from Bruce Schneier.

Also, look at the NIST cryptographic hash project and
their tentative timeline of development of New Hash Functions
Another recent discussion -- SHA-3 Second Round Candidates Released, July 2009

Answer 3

How secure does your service have to be? What will happen if someone brute-forces the key? And if you're truly concerned, why aren't you using SSL with client-side certificates?

These are the general questions that you need to answer for your particular project, before you can decide the best approach to encryption.

Case study: In an application that I'm developing, I encrypt (not hash) key data using DES (yes, plain DES), and decrypt by the service. All URLs have to be generated by the server, which holds the shared key. There's an optional timestamp to limit validity of the URL: if you access the service with an expired URL, you get a 403 back. The data in question is relatively low value, and there will be no fiduciary considerations if the encryption is broken.

Can it be broken by consumer equipment? Sure.

Is there a high payoff to breaking it? Not at all.

Why not just send the data in plaintext? Because we want to ensure some level of control. My primary goal is keeping script kiddies from creating a denial-of-service attack with constant inserts/updates.

Incidentally, the data in the plaintext never appears anywhere else in the communication between client and server. Which means that, even if someone brute forces the key, they have to apply some sort of heuristic to learn that they've broken the key. Security via Obscurity, yes, but sometimes obscurity is useful.

Answer 4

When choosing key sizes, NIST Special Publication 800‑57 (Part 1), §5.6 is a useful guide. The credit card industry's recommendation is for "strong" security, which I interpret as 112 "bits of security" or better. The NIST guidelines show that corresponds to triple-DES (or a small bump up to 128-bit AES) for symmetric ciphers and a 2048-bit key for RSA. See Table 2 for a rough equivalence.

For hash algorithms, it depends on the application. If you don't need interoperability with widely deployed cryptographic applications, try to use SHA-224 or better. In some cases, though, interoperability might require SHA-1, in spite of its emerging vulnerability to collision attacks.

Answer 5

Flickr signing scheme is completely broken. Never use it gain.

http://netifera.com/research/flickr%5Fapi%5Fsignature%5Fforgery.pdf