It certainly depends on the threat model, but in this case I have to agree with Github---adding at-rest encryption would be unlikely to make their product significantly more secure, and it would certainly be nowhere as secure as Keybase.
With Keybase, the data is encrypted on the client, and the keys stay on the client. Assuming the crypto is done right, there is fundamentally no way for Keybase to read the data, and therefore no way for an attacker to get the data by way of compromising Keybase. The only way for an attacker to get the data is by compromising the client machine, which is a very different threat model.
With the model you're proposing for Github, the data would be encrypted for transfer (via HTTPS or SSH), but then it would be immediately decrypted again on the server. Even if it is encrypted again before it's put onto the disk, fundamentally the key lives on the server (and has to in order to provide Github's feature set) and so an attacker who had compromised the machine would simply grab the key before going after the files on disk. The actual additional security you get is really not that significant.
Personally, I appreciate Github's stance on this. There have been a number of "secure" products (see e.g. Lavabit) that have really been snakeoil because they used the approach above. I'll take honesty over false promises any day---at least with the former, I understand my risk and can take steps to mitigate appropriately.
> Even if it is encrypted again before it's put onto the disk, fundamentally the key lives on the server (and has to in order to provide Github's feature set) and so an attacker who had compromised the machine would simply grab the key before going after the files on disk. The actual additional security you get is really not that significant.
It's not just compromised machines that you have to worry about -- that's what the higher layers of security are for:
It's also:
- poor disk decommissioning (e.g., your staff throws away disks without properly erasing them.)
- poor machine management -- machines assigned to one owner, then moved to a new one.
- bugs in storage management systems that leak data (e.g., block replicators, etc.)
Also, note that the keys don't have to be on disk. Most cloud providers configure hosts to get keys via PXE boot, for exactly this reason.
To be clear -- I don't disagree with you about thinking about the threat model, and in many cases it's not necessary to do this. But I do think that GitHub is now a very large player in an enterprise market, so I can't let them off so easily. :-)
The only thing that at-rest encryption would prevent is someone walking into a datacenter (or wherever the drives are physically stored) and nabbing one. An attacker is much more likely to gain access to a live system, where the data would be readily accessible.
At one point, DigitalOcean didn't scrub VM drives when reassigning to other customers unless you explicitly requested it (see https://news.ycombinator.com/item?id=6983097 for info). Using at-rest encryption would mean that the only thing that needs to be securely destroyed is the encryption key -- which shouldn't be stored on disk anyways -- at which point the contents of the drive are rendered meaningless.
Any bug (or poor security practices) at a cloud provider means that data not encrypted at rest could potentially leak to the next customer who the cloud provider assigns your old storage to. There's still a possibility for a cloud provider to leak data via lousy key management, but not storing unencrypted data greatly reduces the attack surface.
With Keybase, the data is encrypted on the client, and the keys stay on the client. Assuming the crypto is done right, there is fundamentally no way for Keybase to read the data, and therefore no way for an attacker to get the data by way of compromising Keybase. The only way for an attacker to get the data is by compromising the client machine, which is a very different threat model.
With the model you're proposing for Github, the data would be encrypted for transfer (via HTTPS or SSH), but then it would be immediately decrypted again on the server. Even if it is encrypted again before it's put onto the disk, fundamentally the key lives on the server (and has to in order to provide Github's feature set) and so an attacker who had compromised the machine would simply grab the key before going after the files on disk. The actual additional security you get is really not that significant.
Personally, I appreciate Github's stance on this. There have been a number of "secure" products (see e.g. Lavabit) that have really been snakeoil because they used the approach above. I'll take honesty over false promises any day---at least with the former, I understand my risk and can take steps to mitigate appropriately.