* Encrypted repositories
[not found] <fcbea7c0-b433-414b-abd3-b0e205a96fc5@zcs>
@ 2012-09-06 2:23 ` Enrico Weigelt
2012-09-06 5:37 ` Junio C Hamano
0 siblings, 1 reply; 6+ messages in thread
From: Enrico Weigelt @ 2012-09-06 2:23 UTC (permalink / raw)
To: git
Hi,
I'm currently planning to implement an strong encryption in git
(not like gitcrypt, but with encrypted blobs, directories, etc,
directly in the core).
The idea goes like this:
* blobs are encrypted with their (original) content hash as
encryption keys
* directory objects only hold randomized filenames and pointers
to the encrypted blob (content hash of the encrypted data)
* new ext-directory objects are holding a mapping of the
randomized file names to the real ones and the encryption keys,
stored encrypted similar to the blobs
* ext-directory object is referenced by a special filename in
the directory object.
* commit objects also hold an encrypted section (eg. uuencoded)
with the ext-directory node's key, additional commit text, etc,
itself encrypted with the repository key
This way, the lowlevel / bare repository operations (including
remote sync and gc) should continue to work, while only actual
access (eg. checkout or commit) need to be changed and have the
repository key available.
What do you think about this approach ?
cu
--
Mit freundlichen Grüßen / Kind regards
Enrico Weigelt
VNC - Virtual Network Consult GmbH
Head Of Development
Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59
enrico.weigelt@vnc.biz; www.vnc.de
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Encrypted repositories
2012-09-06 2:23 ` Encrypted repositories Enrico Weigelt
@ 2012-09-06 5:37 ` Junio C Hamano
2012-09-06 13:56 ` Enrico Weigelt
0 siblings, 1 reply; 6+ messages in thread
From: Junio C Hamano @ 2012-09-06 5:37 UTC (permalink / raw)
To: Enrico Weigelt; +Cc: git
Enrico Weigelt <enrico.weigelt@vnc.biz> writes:
> * blobs are encrypted with their (original) content hash as
> encryption keys
What does this even mean?
Is it expected that anybody who has access to the repository can
learn names of objects (e.g. by running "ls .git/objects/??/")? If
so, from whom are you protecting your repository?
How does this encryption interact with delta compression employed in
pack generation?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Encrypted repositories
2012-09-06 5:37 ` Junio C Hamano
@ 2012-09-06 13:56 ` Enrico Weigelt
2012-09-06 19:49 ` Junio C Hamano
0 siblings, 1 reply; 6+ messages in thread
From: Enrico Weigelt @ 2012-09-06 13:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi,
> Enrico Weigelt <enrico.weigelt@vnc.biz> writes:
>
> > * blobs are encrypted with their (original) content hash as
> > encryption keys
>
> What does this even mean?
>
> Is it expected that anybody who has access to the repository can
> learn names of objects (e.g. by running "ls .git/objects/??/")? If
> so, from whom are you protecting your repository?
Well, everybody can access the objects, but they're encrypted,
so you need the repo key (which, of course isn't contained in
the repo itself ;-p) to decrypt them.
The whole tree will still be consistent even without encryption
support (so, gc etc shouldn't break), but to actually _use_ the
repo (eg. checkout or adding new commits), you'll need the
encryption support and the repo key (well, committing should
theoretically even work with diffrent repo key, even this doesn't
make much sense ;-)).
> How does this encryption interact with delta compression employed
> in pack generation?
Probably not at all ;-o
For the usecases I have in mind (backups, filesharing, etc) this
wouldn't hurt so much, if the objects are compressed before encryption.
cu
--
Mit freundlichen Grüßen / Kind regards
Enrico Weigelt
VNC - Virtual Network Consult GmbH
Head Of Development
Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59
enrico.weigelt@vnc.biz; www.vnc.de
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Encrypted repositories
2012-09-06 13:56 ` Enrico Weigelt
@ 2012-09-06 19:49 ` Junio C Hamano
2012-09-08 3:34 ` Enrico Weigelt
0 siblings, 1 reply; 6+ messages in thread
From: Junio C Hamano @ 2012-09-06 19:49 UTC (permalink / raw)
To: Enrico Weigelt; +Cc: git
Enrico Weigelt <enrico.weigelt@vnc.biz> writes:
>> Enrico Weigelt <enrico.weigelt@vnc.biz> writes:
>>
>> > * blobs are encrypted with their (original) content hash as
>> > encryption keys
>>
>> What does this even mean?
>>
>> Is it expected that anybody who has access to the repository can
>> learn names of objects (e.g. by running "ls .git/objects/??/")? If
>> so, from whom are you protecting your repository?
>
> Well, everybody can access the objects, but they're encrypted,
> so you need the repo key (which, of course isn't contained in
> the repo itself ;-p) to decrypt them.
So, in short, blobs are not encrypted with the hash of their
contents as encryption keys at all.
>> How does this encryption interact with delta compression employed
>> in pack generation?
>
> Probably not at all ;-o
>
> For the usecases I have in mind (backups, filesharing, etc) this
> wouldn't hurt so much, if the objects are compressed before encryption.
For that kind of usage pattern, you are better off looking at
encrypted tarballs or zip archives.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Encrypted repositories
2012-09-06 19:49 ` Junio C Hamano
@ 2012-09-08 3:34 ` Enrico Weigelt
2012-09-08 4:10 ` David Aguilar
0 siblings, 1 reply; 6+ messages in thread
From: Enrico Weigelt @ 2012-09-08 3:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
> > Well, everybody can access the objects, but they're encrypted,
> > so you need the repo key (which, of course isn't contained in
> > the repo itself ;-p) to decrypt them.
>
> So, in short, blobs are not encrypted with the hash of their
> contents as encryption keys at all.
No, the blobs are encrypted with their content hash as key, and the
encrypted blob will be stored with it's content hash as object id.
> > For the usecases I have in mind (backups, filesharing, etc) this
> > wouldn't hurt so much, if the objects are compressed before
> > encryption.
>
> For that kind of usage pattern, you are better off looking at
> encrypted tarballs or zip archives.
No, that doesn't give us anything like history, incremental
synchronization, etc, etc.
What I finnaly wanna has is a usual git, just with encryption,
but I can live with loosing differential compression.
cu
--
Mit freundlichen Grüßen / Kind regards
Enrico Weigelt
VNC - Virtual Network Consult GmbH
Head Of Development
Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59
enrico.weigelt@vnc.biz; www.vnc.de
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Encrypted repositories
2012-09-08 3:34 ` Enrico Weigelt
@ 2012-09-08 4:10 ` David Aguilar
0 siblings, 0 replies; 6+ messages in thread
From: David Aguilar @ 2012-09-08 4:10 UTC (permalink / raw)
To: Enrico Weigelt; +Cc: Junio C Hamano, git
On Fri, Sep 7, 2012 at 8:34 PM, Enrico Weigelt <enrico.weigelt@vnc.biz> wrote:
>
>> > Well, everybody can access the objects, but they're encrypted,
>> > so you need the repo key (which, of course isn't contained in
>> > the repo itself ;-p) to decrypt them.
>>
>> So, in short, blobs are not encrypted with the hash of their
>> contents as encryption keys at all.
>
> No, the blobs are encrypted with their content hash as key, and the
> encrypted blob will be stored with it's content hash as object id.
>
>> > For the usecases I have in mind (backups, filesharing, etc) this
>> > wouldn't hurt so much, if the objects are compressed before
>> > encryption.
>>
>> For that kind of usage pattern, you are better off looking at
>> encrypted tarballs or zip archives.
>
> No, that doesn't give us anything like history, incremental
> synchronization, etc, etc.
>
> What I finnaly wanna has is a usual git, just with encryption,
> but I can live with loosing differential compression.
Something like this?
https://gist.github.com/873637
I've never tried it myself, who knows if it works, but google found it
when I searched for "git clean smudge filter encryption".
I hope that helps,
--
David
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-09-08 4:11 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <fcbea7c0-b433-414b-abd3-b0e205a96fc5@zcs>
2012-09-06 2:23 ` Encrypted repositories Enrico Weigelt
2012-09-06 5:37 ` Junio C Hamano
2012-09-06 13:56 ` Enrico Weigelt
2012-09-06 19:49 ` Junio C Hamano
2012-09-08 3:34 ` Enrico Weigelt
2012-09-08 4:10 ` David Aguilar
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.