Invariant Properties

  • rss
  • Home

Some Simple Questions

Bear Giles | May 7, 2013

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.

Comments
No Comments »
Categories
Uncategorized
Comments rss Comments rss
Trackback Trackback

Using Sequences as Encryption IVs

Bear Giles | May 5, 2013

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.

Comments
No Comments »
Categories
java, security
Comments rss Comments rss
Trackback Trackback

Archives

  • May 2020 (1)
  • March 2019 (1)
  • August 2018 (1)
  • May 2018 (1)
  • February 2018 (1)
  • November 2017 (4)
  • January 2017 (3)
  • June 2016 (1)
  • May 2016 (1)
  • April 2016 (2)
  • March 2016 (1)
  • February 2016 (3)
  • January 2016 (6)
  • December 2015 (2)
  • November 2015 (3)
  • October 2015 (2)
  • August 2015 (4)
  • July 2015 (2)
  • June 2015 (2)
  • January 2015 (1)
  • December 2014 (6)
  • October 2014 (1)
  • September 2014 (2)
  • August 2014 (1)
  • July 2014 (1)
  • June 2014 (2)
  • May 2014 (2)
  • April 2014 (1)
  • March 2014 (1)
  • February 2014 (3)
  • January 2014 (6)
  • December 2013 (13)
  • November 2013 (6)
  • October 2013 (3)
  • September 2013 (2)
  • August 2013 (5)
  • June 2013 (1)
  • May 2013 (2)
  • March 2013 (1)
  • November 2012 (1)
  • October 2012 (3)
  • September 2012 (2)
  • May 2012 (6)
  • January 2012 (2)
  • December 2011 (12)
  • July 2011 (1)
  • June 2011 (2)
  • May 2011 (5)
  • April 2011 (6)
  • March 2011 (4)
  • February 2011 (3)
  • October 2010 (6)
  • September 2010 (8)

Recent Posts

  • 8-bit Breadboard Computer: Good Encapsulation!
  • Where are all the posts?
  • Better Ad Blocking Through Pi-Hole and Local Caching
  • The difference between APIs and SPIs
  • Hadoop: User Impersonation with Kerberos Authentication

Meta

  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org

Pages

  • About Me
  • Notebook: Common XML Tasks
  • Notebook: Database/Webapp Security
  • Notebook: Development Tips

Syndication

Java Code Geeks

Know Your Rights

Support Bloggers' Rights
Demand Your dotRIGHTS

Security

  • Dark Reading
  • Krebs On Security Krebs On Security
  • Naked Security Naked Security
  • Schneier on Security Schneier on Security
  • TaoSecurity TaoSecurity

Politics

  • ACLU ACLU
  • EFF EFF

News

  • Ars technica Ars technica
  • Kevin Drum at Mother Jones Kevin Drum at Mother Jones
  • Raw Story Raw Story
  • Tech Dirt Tech Dirt
  • Vice Vice

Spam Blocked

53,314 spam blocked by Akismet
rss Comments rss valid xhtml 1.1 design by jide powered by Wordpress get firefox