{"thread":{"id":"31452","subject":"Encrypted repositories","startedAt":"2012-09-06T02:23:32Z","lastAt":"2012-09-08T04:10:08Z","messageCount":6,"participants":["Enrico Weigelt","Junio C Hamano","David Aguilar"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"198409","messageId":"f6682453-92bc-4f3b-9bf3-1910ca6fb307@zcs","threadId":"31452","inReplyTo":"fcbea7c0-b433-414b-abd3-b0e205a96fc5@zcs","subject":"Encrypted repositories","fromName":"Enrico Weigelt","fromEmail":"enrico.weigelt@vnc.biz","sentAt":"2012-09-06T02:23:32Z","receivedAt":"2012-09-06T02:23:32Z","isPatch":false,"sender":{"key":"enrico.weigelt@vnc.biz","avatar":"https://gravatar.com/avatar/15479654ea5be5109582e0713a8ab4bb258846099c516dd320dc686ef70a8a3e?d=mp&s=160"},"body":"Hi,\n\nI'm currently planning to implement an strong encryption in git\n(not like gitcrypt, but with encrypted blobs, directories, etc,\ndirectly in the core).\n\nThe idea goes like this:\n\n* blobs are encrypted with their (original) content hash as\n encryption keys\n* directory objects only hold randomized filenames and pointers\n to the encrypted blob (content hash of the encrypted data)\n* new ext-directory objects are holding a mapping of the\n randomized file names to the real ones and the encryption keys,\n stored encrypted similar to the blobs\n* ext-directory object is referenced by a special filename in\n the directory object.\n* commit objects also hold an encrypted section (eg. uuencoded)\n with the ext-directory node's key, additional commit text, etc,\n itself encrypted with the repository key\n\nThis way, the lowlevel / bare repository operations (including\nremote sync and gc) should continue to work, while only actual\naccess (eg. checkout or commit) need to be changed and have the\nrepository key available.\n\n\nWhat do you think about this approach ?\n\n\ncu\n-- \nMit freundlichen Grüßen / Kind regards \n\nEnrico Weigelt \nVNC - Virtual Network Consult GmbH \nHead Of Development \n\nPariser Platz 4a, D-10117 Berlin\nTel.: +49 (30) 3464615-20\nFax: +49 (30) 3464615-59\n\nenrico.weigelt@vnc.biz; www.vnc.de \n"},{"id":"198421","messageId":"7vvcfr4sq3.fsf@alter.siamese.dyndns.org","threadId":"31452","inReplyTo":"f6682453-92bc-4f3b-9bf3-1910ca6fb307@zcs","subject":"Re: Encrypted repositories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-06T05:37:24Z","receivedAt":"2012-09-06T05:37:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Enrico Weigelt writes:\n\n> * blobs are encrypted with their (original) content hash as\n> encryption keys\n\nWhat does this even mean?\n\nIs it expected that anybody who has access to the repository can\nlearn names of objects (e.g. by running \"ls .git/objects/??/\")? If\nso, from whom are you protecting your repository?\n\nHow does this encryption interact with delta compression employed in\npack generation?\n"},{"id":"198439","messageId":"e1f18eed-1096-4121-879a-4dd78627a4ba@zcs","threadId":"31452","inReplyTo":"7vvcfr4sq3.fsf@alter.siamese.dyndns.org","subject":"Re: Encrypted repositories","fromName":"Enrico Weigelt","fromEmail":"enrico.weigelt@vnc.biz","sentAt":"2012-09-06T13:56:29Z","receivedAt":"2012-09-06T13:56:29Z","isPatch":false,"sender":{"key":"enrico.weigelt@vnc.biz","avatar":"https://gravatar.com/avatar/15479654ea5be5109582e0713a8ab4bb258846099c516dd320dc686ef70a8a3e?d=mp&s=160"},"body":"Hi,\n\n> Enrico Weigelt writes:\n> \n> > * blobs are encrypted with their (original) content hash as\n> > encryption keys\n> \n> What does this even mean?\n> \n> Is it expected that anybody who has access to the repository can\n> learn names of objects (e.g. by running \"ls .git/objects/??/\")? If\n> so, from whom are you protecting your repository?\n\nWell, everybody can access the objects, but they're encrypted,\nso you need the repo key (which, of course isn't contained in\nthe repo itself ;-p) to decrypt them.\n\nThe whole tree will still be consistent even without encryption\nsupport (so, gc etc shouldn't break), but to actually _use_ the\nrepo (eg. checkout or adding new commits), you'll need the\nencryption support and the repo key (well, committing should\ntheoretically even work with diffrent repo key, even this doesn't\nmake much sense ;-)).\n\n> How does this encryption interact with delta compression employed\n> in pack generation?\n\nProbably not at all ;-o\nFor the usecases I have in mind (backups, filesharing, etc) this\nwouldn't hurt so much, if the objects are compressed before encryption.\n\n\ncu\n-- \nMit freundlichen Grüßen / Kind regards \n\nEnrico Weigelt \nVNC - Virtual Network Consult GmbH \nHead Of Development \n\nPariser Platz 4a, D-10117 Berlin\nTel.: +49 (30) 3464615-20\nFax: +49 (30) 3464615-59\n\nenrico.weigelt@vnc.biz; www.vnc.de \n"},{"id":"198473","messageId":"7vmx132aph.fsf@alter.siamese.dyndns.org","threadId":"31452","inReplyTo":"e1f18eed-1096-4121-879a-4dd78627a4ba@zcs","subject":"Re: Encrypted repositories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-06T19:49:30Z","receivedAt":"2012-09-06T19:49:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Enrico Weigelt writes:\n\n>> Enrico Weigelt writes:\n>> \n>> > * blobs are encrypted with their (original) content hash as\n>> > encryption keys\n>> \n>> What does this even mean?\n>> \n>> Is it expected that anybody who has access to the repository can\n>> learn names of objects (e.g. by running \"ls .git/objects/??/\")? If\n>> so, from whom are you protecting your repository?\n>\n> Well, everybody can access the objects, but they're encrypted,\n> so you need the repo key (which, of course isn't contained in\n> the repo itself ;-p) to decrypt them.\n\nSo, in short, blobs are not encrypted with the hash of their\ncontents as encryption keys at all.\n\n>> How does this encryption interact with delta compression employed\n>> in pack generation?\n>\n> Probably not at all ;-o\n>\n> For the usecases I have in mind (backups, filesharing, etc) this\n> wouldn't hurt so much, if the objects are compressed before encryption.\n\nFor that kind of usage pattern, you are better off looking at\nencrypted tarballs or zip archives.\n"},{"id":"198560","messageId":"0666bd29-b156-4c3d-b859-ab140d2f849e@zcs","threadId":"31452","inReplyTo":"7vmx132aph.fsf@alter.siamese.dyndns.org","subject":"Re: Encrypted repositories","fromName":"Enrico Weigelt","fromEmail":"enrico.weigelt@vnc.biz","sentAt":"2012-09-08T03:34:48Z","receivedAt":"2012-09-08T03:34:48Z","isPatch":false,"sender":{"key":"enrico.weigelt@vnc.biz","avatar":"https://gravatar.com/avatar/15479654ea5be5109582e0713a8ab4bb258846099c516dd320dc686ef70a8a3e?d=mp&s=160"},"body":"\n> > Well, everybody can access the objects, but they're encrypted,\n> > so you need the repo key (which, of course isn't contained in\n> > the repo itself ;-p) to decrypt them.\n> \n> So, in short, blobs are not encrypted with the hash of their\n> contents as encryption keys at all.\n\nNo, the blobs are encrypted with their content hash as key, and the\nencrypted blob will be stored with it's content hash as object id.\n\n> > For the usecases I have in mind (backups, filesharing, etc) this\n> > wouldn't hurt so much, if the objects are compressed before\n> > encryption.\n> \n> For that kind of usage pattern, you are better off looking at\n> encrypted tarballs or zip archives.\n\nNo, that doesn't give us anything like history, incremental\nsynchronization, etc, etc.\n\nWhat I finnaly wanna has is a usual git, just with encryption,\nbut I can live with loosing differential compression.\n\n\ncu\n-- \nMit freundlichen Grüßen / Kind regards \n\nEnrico Weigelt \nVNC - Virtual Network Consult GmbH \nHead Of Development \n\nPariser Platz 4a, D-10117 Berlin\nTel.: +49 (30) 3464615-20\nFax: +49 (30) 3464615-59\n\nenrico.weigelt@vnc.biz; www.vnc.de \n"},{"id":"198561","messageId":"CAJDDKr7kheuOoeiCyvh8eZTGTR3u8JZxaveKX8TyBrmLMA4msw@mail.gmail.com","threadId":"31452","inReplyTo":"0666bd29-b156-4c3d-b859-ab140d2f849e@zcs","subject":"Re: Encrypted repositories","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2012-09-08T04:10:08Z","receivedAt":"2012-09-08T04:10:08Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Fri, Sep 7, 2012 at 8:34 PM, Enrico Weigelt wrote:\n>\n>> > Well, everybody can access the objects, but they're encrypted,\n>> > so you need the repo key (which, of course isn't contained in\n>> > the repo itself ;-p) to decrypt them.\n>>\n>> So, in short, blobs are not encrypted with the hash of their\n>> contents as encryption keys at all.\n>\n> No, the blobs are encrypted with their content hash as key, and the\n> encrypted blob will be stored with it's content hash as object id.\n>\n>> > For the usecases I have in mind (backups, filesharing, etc) this\n>> > wouldn't hurt so much, if the objects are compressed before\n>> > encryption.\n>>\n>> For that kind of usage pattern, you are better off looking at\n>> encrypted tarballs or zip archives.\n>\n> No, that doesn't give us anything like history, incremental\n> synchronization, etc, etc.\n>\n> What I finnaly wanna has is a usual git, just with encryption,\n> but I can live with loosing differential compression.\n\nSomething like this?\n\nhttps://gist.github.com/873637\n\nI've never tried it myself, who knows if it works, but google found it\nwhen I searched for \"git clean smudge filter encryption\".\n\nI hope that helps,\n-- \nDavid\n"}]}