In Review: when sharing code wastes time

At work we have a shared library for crypto-related utilities maintained by the security team. Recently, I used this library to generate SHA-1 and SHA-256 encoded keys in a database. There was no SHA-512 utility, so I rolled my own using java.util and java.security.

When a colleague attempted to query the database, he discovered some interesting quirks of the encoding scheme I had used:

• All 3 routines (SHA-1, SHA-256, SHA-512) used base64-encoding, whereas most examples of SHA-X use a lower-case base16 (hex) encoding.
• The SHA-1 base64 encoder used an old XML lib that was last updated in 2013.
• The SHA-256 base64 encoder used an apache-commons encoder.
• The SHA-512 base64 encoder used java.util.Base64
• The apache-commons and java.util base64 encoders produced the same results, but the old XML one did not.
• None of these implementations was thread-safe, and I was assuming they all were.

This all meant our database was returning a lot less data than we knew was stored there.

My knee-jerk reaction was to write my own SHA-X encoders for my clients to use. This is somewhat justified, but I feel bad for introducing yet another "standard" -- even if it only applies to this one database and its clients.

At the end of the day, we wasted several engineering man-hours trying to figure out what was going on. We ended up rewriting code and rebuilding our database. We now use only the java.util.Base64 encoder, which follows the MIME standard.

Ironically, it took me maybe two minutes to write the SHA-512 encoder I used when I couldn't find an existing one. Using the existing SHA-1 and SHA-256 implementations cost us several hours.

The lesson here? I am not sure. But I know I'm going to be more careful when reaching into shared libraries for common utilities -- especially when alternatives exist right there in java.util.