Hacker News Reader

Comment by c7b | Hacker News Reader

Does this count as an instance of 'don't roll your own crypto'?

I think it's more of an instance of "it works on my computer"; not testing on an environment sufficiently similar to production, and applying a change that cannot be rolled back.

This is the key. The rollback mechanisms were broken. Re-encrypting data is incredibly scary because if you lose the new key you have effectively lost your data. It is important to ensure that you have up-to-date backups of the previously encrypted data and key before you start.

A better solution may have been multi-key support. Some test records could be encrypted with the new key and the system let run for a week or so. Then all new records could start being encrypted with the new key and run for another week. Once everything looks good a background job could be started to convert all data to the new key. Then the old key can be retired (other than as needed for backups).

Although they did have the key printed in an envelope, so it sounds like that would have been an effective recovery solution once they remembered.

Eh, yes and no. With proper testing this issue should have been caught. But this is also an example of how small details in crypto can become a huge issue and domain knowledge counts for a lot. As soon as the story turned to getpass() on Solaris I already knew what it was because the 8-character limit is pretty famous if you've worked on old Unix systems.

I once had to explain to some coworkers from another team why they shouldn't 'helpfully' truncate leading and trailing spaces from my password, and why they need to handle 'special' characters, too.

They couldn't believe that anyone wants trailing spaces on their password.

Not at all. The problem was that the crypto for the same library on two different OSes was implemented differently, which lead to an error encrypting on Linux and decrypting on Solaris. Ironically, this would have been avoided if they had rolled their own.

It is an instance of "make sure you have backups when deploying to production"

Not the crypto, but rather the getpass() function, which simply reads a password from standard input without echoing it.

Since the function uses a static buffer, there is a limit on the password length, which apparently on Solaris was set to the absurdly low value of 8 (glibc uses a more reasonable value: 8192).

Thanks for the correction. I assumed getpass() did some crypto work in addition to just getting raw keyboard input.

That said shamir's secret sharing is one of the easiest constructions to reason about so I think the risk is much smaller there

Experience disputes that. I've found that a random implementation of SSS is more likely to be insecure than a random implementation of ECDH.

Reply on news.ycombinator.com