Comment by zeroxfe | Hacker News Reader

Comment by zeroxfe | Hacker News Reader

I'm really happy about this. I have private repos for personal information (e.g., tax spreadsheets going back a decade) that I keep synchronized across machines, and have to jump through hoops to get an encrypted authoritative remote source. Right now I do that with an encrypted partition on a private VM.

And, it really sucks that GitHub does not encrypt data at rest:

--- SNIP from https://help.github.com/articles/github-security ---

We do not encrypt repositories on disk because it would not be any more secure: the website and git back-end would need to decrypt the repositories on demand, slowing down response times. Any user with shell access to the file system would have access to the decryption routine, thus negating any security it provides. Therefore, we focus on making our machines and network as secure as possible.

--- SNIP ---

Encrypted disks are now the norm across various cloud providers, as is HTTPS. The crypto overheads are really low, and their benefits significantly outweigh the risks of leaving clear-text data on disks.

Also, defense-in-depth is always worth pursuing. The claim "it would not be any more secure", is so far from true, it's almost insulting to their target audience.

Keep killin' it, Keybase! Great job!

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.

Exactly.

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.

Depends on who you are.... I know for us, physical datacenter security is tricky to ensure in a lot of countries, especially from government actors.

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.

> 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. :-)

Out of curiosity: why do you keep such documents in repositories instead of simply in a filesystem (on an encrypted volume, backed up and possibly synced across devices)? Tax spreadsheets usually don't change, so there's no need for version history (if anything, new rows for new years are added, but without changing past data).

I ask this because I'm trying to figure out a solution for myself for keeping sensitive personal information and I never thought about storing such documents in a repository. Maybe I am missing something and your use case will open my eyes. Thanks!

My tax sheets are updated throughout the year for various reasons (bonuses, side gigs, property sales, etc.), so I rely on the version history. I also keep a lot of other stuff that I update more rapidly (mostly in text documents.)

For me one big benefit is that it's distributed. I like to keep my important documents backed up on all the computers i have, on a USB drive stored in a safe location and also store the data with a cloud provider.

Now, if i update one document on computer A, and another document using computer B, i have to sync it to all other devices which is a PITA without git. You get into the situation where you don't know if the version on the USB drive was newer or older than the one on computer B etc, whereas with git all this is available in the version tree and there are nice merge tools available.

I've been planning to do this even for photos, for all the reasons above, but haven't taken the full step yet.

Wouldn't encrypted files with a service like Dropbox help? Containers usually sync well (only syncs changed parts). Only downside is that you can't access files without decryption software.

Dropbox, as all other "just-works" sync services, don't handle merge conflicts very good. Suddenly you have thousands of Filename_EditedByX(3).txt in every folder and dont know which one of them is the newest and don't have their most common ancestor version easily available for a 3-way merge.

To be fair, they cannot handle merge conflicts with encrypted containers. I find that merge conflicts almost always cause more trouble than the work of avoiding them from the start. As long as you don't share data (with containers unlikely), merge conflicts should be extremely rare (and anticipated).

I am not OP but I do the same as him.

I used to keep the data on Dropbox but switched to a repo because it felt to have better safety against user error. It's not all that hard to accidentally delete or modify a file in a filesystem. Given the commit process it's much harder to do in a repo.

Agree. Awesome way to keep dot files in sync across hosts without worrying about private github repos!

Wait, I think they are saying their backend integration such as forking through the web interface etc. would not work unless they decrypted your repo. Which makes sense - you should be using client software for all this!

Why don't more people use gitlab btw?

Out of curiosity, what are the benefits you're talking about?

Reply on news.ycombinator.com