4 ms·

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

by c7b 3y ago

HWR_14 3y ago
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"
- devit 3y ago
  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).
  - HWR_14 3y ago
    Thanks for the correction. I assumed getpass() did some crypto work in addition to just getting raw keyboard input.
sangnoir 3y ago
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.
- kevincox 3y ago
  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.
Vervious 3y ago
That said shamir's secret sharing is one of the easiest constructions to reason about so I think the risk is much smaller there
- nullc 3y ago
  Experience disputes that. I've found that a random implementation of SSS is more likely to be insecure than a random implementation of ECDH.
pravus 3y ago
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.
- eru 3y ago
  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.

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

by c7b 3y ago

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

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"

devit 3y ago
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).
- HWR_14 3y ago
  Thanks for the correction. I assumed getpass() did some crypto work in addition to just getting raw keyboard input.

sangnoir 3y ago

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.

kevincox 3y ago
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.

Vervious 3y ago

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

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

pravus 3y ago

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.

eru 3y ago
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.