Invariant Properties

Some simple questions for the developers of Garmin Training Center, the bundled software with Garmin GPS sports watches.

Why does your graph include paces of -15 or even -30 minutes/mile?

You can NEVER have a negative pace. It’s a positive pace going in the opposite direction. All this does is compress the range of the meaningful information, often to the point where it’s unusable.

Why does your graph include paces of more than 60 minutes/mile?

This one is a little more ambiguous. I’ve never seen my pace slower than 60 minutes/mile when I have it set to auto-pause. (I’m not actually going that slowly, it’s when I’m stopped at traffic lights or because my dog is doing dog stuff.) So for me anything beyond that, again, compresses the useful data to where it’s unusable.

I suppose it’s possible that you can see a slower pace if the watch isn’t set to auto-pause… but if someone is going that slowly does a chart even make sense? Isn’t this in the realm of the drift we see from the nature of the GPS system itself?

Why does your graph of heart rates include 250 beats-per-minute?

Can someone have a HR over 200 BPM?

Outside of a hospital?

Okay, I’ll grant that a teenager with a naturally high heart rate range could have a HR just over 200. But NOBODY is going to have a HR over 250 BPM. So why does the chart include that wasted space?

The bigger lesson

The technical lesson, of course, is that auto-ranging needs to be used intelligently. A lot of the time there are natural constraints on the meaningful range, be them physical, legal, or anything else. If you ignore that you can seriously compromise the usefulness of your charts.

This application has had this problem for a very long time and it’s very visible to anyone who uses it. Why wasn’t it fixed years ago? Is it a case where the only thing worse than learning your website has been down for a day is realizing that your website has been down for a day and nobody noticed? Is the app so bad that nobody ever uses it?

For what it’s worth this is a big reason why I stopped using Training Center a few years ago. I only noticed this because I recently bought a newer watch and that required a newer version of Training Center (to download data from the watch) and it still has the same problem.

Anyone using low-level encryption libraries should know that you need both a SecretKey and a “random” IV. The easiest way to get a good IV is to use a SecureRandom instance to generate the necessary value.

This approach has one major drawback – it requires you to store or transmit a 16- or even 32-byte value. This is not always a trivial concern. As one example many applications require the user to enter a BASE-32-encoded license key and including a full IV can double the length of the license key. Longer keys can be a real headache when dealing with low-bandwidth channels such as a telephone call to customer support or stickers on optical media – people are more likely to mis-enter the key, you have to use a smaller font which could cause problems for visually impaired users, etc.

Another example is database records. A full IV can significantly increase the size of a record that contains only an integer primary key and an encrypted value – that means fewer records per page. Records/page isn’t a big concern on smaller databases but it matters as you scale up.

What if the full IV could be replaced by a 4-byte counter? That drops 12 bytes per record, or a staggering 20 characters when using BASE-32 encoding.

• Using the counter directly is insecure. Merging the counter with a salt, e.g. by using XOR or adding it using BigInteger math, is better but still relatively insecure.
• Encrypting the counter with the same encryption key as the data is also insecure.
• Encrypting the counter using a separate encryption key is secure. You don’t have to mix the counter with a salt but there’s no downside to it.

The last approach gives us another benefit – it’s a natural way to split the effective encryption key into two pieces that can be stored independently. (E.g., one key is stored on the filesystem outside of the webapp and the other key is provided via the application container using JNDI.) If we use a salt with the counter we have three pieces that can be stored independently.

This gives us a lot of flexibility when using a low-level library like JCE. Higher-level libraries like ESAPI or GPG handle IVs themselves but it’s often possible to explicitly set the IV. For instance the ESAPI CipherSpec class provides a mechanism to set the IV.

Does this mean that we should always use a sequence to generate an IV? No – it requires a little more effort to generate an IV from a sequence than to use a random byte array. You also have to consider the possibility that someone will “improve” the implementation later and use the same encryption key for IV and data, or remove the encryption altogether. However it’s a good tool to have in your arsenal for the times when it is appropriate.