* encrypted repositories?
@ 2009-07-17 15:14 Matthias Andree
2009-07-17 16:06 ` Michael J Gruber
` (3 more replies)
0 siblings, 4 replies; 17+ messages in thread
From: Matthias Andree @ 2009-07-17 15:14 UTC (permalink / raw)
To: git
Greetings,
I have a rather special usage scenario.
Assume you have a repository where you want to work on embargoed
information, so that not even system administrators of the server you're
pushing to can get a hold of the cleartext data.
"Server" would be a central reference repository that I can push to.
"Client" would by my working computer that has a clone of the crypted
repo, and an unencrypted checkout of it. Perhaps the client would also
need an unencrypted copy of the repo (for performance reasons, I'm not
sure about that) that gets encrypted on the fly when pushing and decrypted
when fetching.
Examples of use might be press releases of upcoming products, written
exams for students, whatever.
Requirements:
- "client" that is about to push must encrypt the data before pushing it
to the server.
- all data (including file names, log messages,
Allowed restrictions:
- "server" limited to bare repositories
- initial version limited to symmetric encryption with pre-shared secret
In a later step, some key management and asymmetric crypto would be
useful, but that's not crucial now. In my current scenario, those who are
working on the embargoed material would trust one another.
How would one go about this from the user side? I sincerely doubt I have
the resources (time!) to actually implement this in Git.
TIA
--
Matthias Andree
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: encrypted repositories?
2009-07-17 15:14 encrypted repositories? Matthias Andree
@ 2009-07-17 16:06 ` Michael J Gruber
2009-07-17 20:22 ` Jakub Narebski
2009-07-17 16:30 ` Matthias Kestenholz
` (2 subsequent siblings)
3 siblings, 1 reply; 17+ messages in thread
From: Michael J Gruber @ 2009-07-17 16:06 UTC (permalink / raw)
To: Matthias Andree; +Cc: git
Matthias Andree venit, vidit, dixit 17.07.2009 17:14:
> Greetings,
>
> I have a rather special usage scenario.
>
> Assume you have a repository where you want to work on embargoed
> information, so that not even system administrators of the server you're
> pushing to can get a hold of the cleartext data.
>
> "Server" would be a central reference repository that I can push to.
> "Client" would by my working computer that has a clone of the crypted
> repo, and an unencrypted checkout of it. Perhaps the client would also
> need an unencrypted copy of the repo (for performance reasons, I'm not
> sure about that) that gets encrypted on the fly when pushing and decrypted
> when fetching.
>
> Examples of use might be press releases of upcoming products, written
> exams for students, whatever.
>
> Requirements:
> - "client" that is about to push must encrypt the data before pushing it
> to the server.
> - all data (including file names, log messages,
>
> Allowed restrictions:
> - "server" limited to bare repositories
> - initial version limited to symmetric encryption with pre-shared secret
>
> In a later step, some key management and asymmetric crypto would be
> useful, but that's not crucial now. In my current scenario, those who are
> working on the embargoed material would trust one another.
>
>
> How would one go about this from the user side? I sincerely doubt I have
> the resources (time!) to actually implement this in Git.
If the server can not decrypt anything then it can not serve anything,
at least not as a git server. Note that if you're really fussy about
security then you should not allow the server to see even the DAG (which
would be the case if you encrypt blobs only), which makes it impossible
to do any smart serving.
So, why not share some form of remote storage on which you have an
encrypted luks partition? That way you can even set up multiple access
keys and revoke them when necessary.
Michael
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: encrypted repositories?
2009-07-17 15:14 encrypted repositories? Matthias Andree
2009-07-17 16:06 ` Michael J Gruber
@ 2009-07-17 16:30 ` Matthias Kestenholz
2009-07-17 19:38 ` Linus Torvalds
2012-08-02 14:52 ` J-S-B
3 siblings, 0 replies; 17+ messages in thread
From: Matthias Kestenholz @ 2009-07-17 16:30 UTC (permalink / raw)
To: Matthias Andree; +Cc: git
On Fri, Jul 17, 2009 at 3:14 PM, Matthias Andree<matthias.andree@gmx.de> wrote:
>
> How would one go about this from the user side? I sincerely doubt I have the
> resources (time!) to actually implement this in Git.
>
Maybe you could send around packages created by git-bundle as
pgp-encrypted emails, and keep the original on your computer on an
encrypted filesystem? You could also encrypt the bundles and put them
onto a public server if that suits you better than email.
The biggest advantage of this approach would be that it can be done
now, and no changes to git itself are required.
Matthias
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: encrypted repositories?
2009-07-17 15:14 encrypted repositories? Matthias Andree
2009-07-17 16:06 ` Michael J Gruber
2009-07-17 16:30 ` Matthias Kestenholz
@ 2009-07-17 19:38 ` Linus Torvalds
2009-07-17 20:22 ` John Tapsell
2009-07-20 12:09 ` encrypted repositories? Matthias Andree
2012-08-02 14:52 ` J-S-B
3 siblings, 2 replies; 17+ messages in thread
From: Linus Torvalds @ 2009-07-17 19:38 UTC (permalink / raw)
To: Matthias Andree; +Cc: git
On Fri, 17 Jul 2009, Matthias Andree wrote:
>
> Assume you have a repository where you want to work on embargoed information,
> so that not even system administrators of the server you're pushing to can get
> a hold of the cleartext data.
If the server can't ever read it, you're basically limited to just one
story:
- use rsync-like "stupid" transports to upload and download things.
- a "smart" git server (eg the native git:// style protocol is not going
to be possible)
and you strictly speaking need no real git changes, because you might as
well just do it by uploading an encrypted tar-file of the .git directory.
And there is literally no upside in doing anything else - any native git
support is almost entirely pointless.
You could make it a _bit_ more useful perhaps by adding some helper
wrappers, probably by just implementing a new transport name (ie instead
of using "rsync://", you'd just use "crypt-tgz://" or something).
Now, that said, there are probably situations where maybe you'd allow the
server to decrypt things _temporarily_, but you don't want to be encrypted
on disk, and no persistent keys on the server, then that would open up a
lot more possibilities.
Of course, that still does require that you trust the server admin to
_some_ degree - anybody who has root would be able to get the keys by
running a debugger on the git upload/download sequence when you do a
upload or download.
Maybe that kind of security is still acceptable to you, though?
IF that is the case, then at least in theory we could add support for
"encryption key exchange" to the native git protocol, and then you could
have encryption over the network access (ssh obviously already does that,
but I'm including things like the anonymous git:// protocol too), and
you'd have encrypted data on disk, but git-upload-pack would be able to
decrypt things in order to do deltas etc.
But see above: in order for that to work, you do have to allow the pack
upload and download processes on the server to decrypt things (in memory).
So it would not be "absolutely secure".
Linus
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: encrypted repositories?
2009-07-17 16:06 ` Michael J Gruber
@ 2009-07-17 20:22 ` Jakub Narebski
0 siblings, 0 replies; 17+ messages in thread
From: Jakub Narebski @ 2009-07-17 20:22 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Matthias Andree, git
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Matthias Andree venit, vidit, dixit 17.07.2009 17:14:
> >
> > I have a rather special usage scenario.
> >
> > Assume you have a repository where you want to work on embargoed
> > information, so that not even system administrators of the server you're
> > pushing to can get a hold of the cleartext data.
> >
> > "Server" would be a central reference repository that I can push to.
> > "Client" would by my working computer that has a clone of the crypted
> > repo, and an unencrypted checkout of it. Perhaps the client would also
> > need an unencrypted copy of the repo (for performance reasons, I'm not
> > sure about that) that gets encrypted on the fly when pushing and decrypted
> > when fetching.
> >
> > Examples of use might be press releases of upcoming products, written
> > exams for students, whatever.
> If the server can not decrypt anything then it can not serve anything,
> at least not as a git server. Note that if you're really fussy about
> security then you should not allow the server to see even the DAG (which
> would be the case if you encrypt blobs only), which makes it impossible
> to do any smart serving.
There was shown here on git mailing list script which was meant to
help in situation where you have repository with sensitive deta,
discovered repository corruption or bug in git, and cannot be
reproduced otherwise. But I think it didn't encrypt repositry, but
just emulate it's structure.
As to encrypting repository: you can encrypt blobs (content of files),
you can encrypt filenames (but the structure remains) or you can put
files in a flat encrypted structure, and you can encrypt commit
messages and comitter and author info, and encrypt / rename branch
names. Still some DAG structure will be visible, and need be visible
for "smart" git server (access via ssh and git protocols) to work.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: encrypted repositories?
2009-07-17 19:38 ` Linus Torvalds
@ 2009-07-17 20:22 ` John Tapsell
2009-07-17 20:40 ` Linus Torvalds
2009-07-20 12:09 ` encrypted repositories? Matthias Andree
1 sibling, 1 reply; 17+ messages in thread
From: John Tapsell @ 2009-07-17 20:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthias Andree, git
2009/7/17 Linus Torvalds <torvalds@linux-foundation.org>:
>
>
> On Fri, 17 Jul 2009, Matthias Andree wrote:
>>
>> Assume you have a repository where you want to work on embargoed information,
>> so that not even system administrators of the server you're pushing to can get
>> a hold of the cleartext data.
>
> If the server can't ever read it, you're basically limited to just one
> story:
Why couldn't you have the actual code encrypted, but have the server
still know about the SHAs etc? You would expose the actual commit
structure, but that might be acceptable?
John
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: encrypted repositories?
2009-07-17 20:22 ` John Tapsell
@ 2009-07-17 20:40 ` Linus Torvalds
2009-07-17 20:42 ` Linus Torvalds
0 siblings, 1 reply; 17+ messages in thread
From: Linus Torvalds @ 2009-07-17 20:40 UTC (permalink / raw)
To: John Tapsell; +Cc: Matthias Andree, git
On Fri, 17 Jul 2009, John Tapsell wrote:
>
> Why couldn't you have the actual code encrypted, but have the server
> still know about the SHAs etc? You would expose the actual commit
> structure, but that might be acceptable?
Even that wouldn't really work, because you'd never be able to generate
any deltas.
So there would be no real advantage. In fact, there would be only
disadvantages, because without any delta generation, you'd now have to
actually transfer _more_ data.
Linus
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: encrypted repositories?
2009-07-17 20:40 ` Linus Torvalds
@ 2009-07-17 20:42 ` Linus Torvalds
2009-07-18 19:09 ` encrypted repositories? with git-torrent? Thomas Koch
0 siblings, 1 reply; 17+ messages in thread
From: Linus Torvalds @ 2009-07-17 20:42 UTC (permalink / raw)
To: John Tapsell; +Cc: Matthias Andree, git
On Fri, 17 Jul 2009, Linus Torvalds wrote:
>
> On Fri, 17 Jul 2009, John Tapsell wrote:
> >
> > Why couldn't you have the actual code encrypted, but have the server
> > still know about the SHAs etc? You would expose the actual commit
> > structure, but that might be acceptable?
>
> Even that wouldn't really work, because you'd never be able to generate
> any deltas.
>
> So there would be no real advantage. In fact, there would be only
> disadvantages, because without any delta generation, you'd now have to
> actually transfer _more_ data.
Oh, if you let the server know all the SHA's at _all_ levels (ie down to
the blob itself), and then just make the blobs be encrypted, we'd be able
to do some trivial optimizations, like only sending the actual blobs that
changed. HOWEVER. That would reveal absolutely tons of data about the
repository, and about the history. You'd have lost a _lot_ of security.
Linus
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: encrypted repositories? with git-torrent?
2009-07-17 20:42 ` Linus Torvalds
@ 2009-07-18 19:09 ` Thomas Koch
2009-07-20 12:13 ` Matthias Andree
0 siblings, 1 reply; 17+ messages in thread
From: Thomas Koch @ 2009-07-18 19:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: John Tapsell, Matthias Andree, git
Wouldn't this be a use case for git-torrent?
http://code.google.com/p/gittorrent/
http://repo.or.cz/w/VCS-Git-Torrent.git
As I understand it, all data would be stored decentraliced and the (optional?)
central server only saves, who has which objects.
(Just hearing a podcast on bittorrent while reading GIT mailinglist :-)
Thomas Koch, http://www.koch.ro
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: encrypted repositories?
2009-07-17 19:38 ` Linus Torvalds
2009-07-17 20:22 ` John Tapsell
@ 2009-07-20 12:09 ` Matthias Andree
2009-07-20 13:48 ` Jakub Narebski
2009-07-20 15:30 ` Jeff King
1 sibling, 2 replies; 17+ messages in thread
From: Matthias Andree @ 2009-07-20 12:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Am 17.07.2009, 21:38 Uhr, schrieb Linus Torvalds
<torvalds@linux-foundation.org>:
>
>
> On Fri, 17 Jul 2009, Matthias Andree wrote:
>>
>> Assume you have a repository where you want to work on embargoed
>> information,
>> so that not even system administrators of the server you're pushing to
>> can get
>> a hold of the cleartext data.
>
> If the server can't ever read it, you're basically limited to just one
> story:
>
> - use rsync-like "stupid" transports to upload and download things.
>
> - a "smart" git server (eg the native git:// style protocol is not going
> to be possible)
I don't know all its features, apparently it's online recompression - this
is no longer going to be available.
> and you strictly speaking need no real git changes, because you might as
> well just do it by uploading an encrypted tar-file of the .git directory.
> And there is literally no upside in doing anything else - any native git
> support is almost entirely pointless.
>
> You could make it a _bit_ more useful perhaps by adding some helper
> wrappers, probably by just implementing a new transport name (ie instead
> of using "rsync://", you'd just use "crypt-tgz://" or something).
>
> Now, that said, there are probably situations where maybe you'd allow the
> server to decrypt things _temporarily_, but you don't want to be
> encrypted
> on disk, and no persistent keys on the server, then that would open up a
> lot more possibilities.
> Of course, that still does require that you trust the server admin to
> _some_ degree - anybody who has root would be able to get the keys by
> running a debugger on the git upload/download sequence when you do a
> upload or download.
>
> Maybe that kind of security is still acceptable to you, though?
No, the server can't be allowed access to the keys or decrypted data.
I'm not sure about the graph, and if I should be concerned. Exposing the
DAG might be in order.
It would be ok if the disk storage and the over-the-wire format cannot use
delta compression then. It would suffice to just send a set of objects
efficiently - and perhaps smaller revisions can be delta-compressed by the
clients when pushing.
I admit haven't checked how the current git:// over-the-wire protocol[s]
work[s]. I think client-side delta compression may require limiting the
graph depths or delta size (when exceeded, the client must send the
standalone self-contained object rather than a delta), so that the server
can refuse patches when the delta nesting or size gets too deep/big.
I think this would generate the git server to something like a storage
device for objects, perhaps with the DAG if exposed.
On a more general note, is someone looking into improving the http://
efficiency? Perhaps there are synergies between my plan of (a) encryption
and (b) more efficient "dumb" (http/rsync/...) protocol use.
--
Matthias Andree
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: encrypted repositories? with git-torrent?
2009-07-18 19:09 ` encrypted repositories? with git-torrent? Thomas Koch
@ 2009-07-20 12:13 ` Matthias Andree
0 siblings, 0 replies; 17+ messages in thread
From: Matthias Andree @ 2009-07-20 12:13 UTC (permalink / raw)
To: thomas, Linus Torvalds; +Cc: John Tapsell, git
Am 18.07.2009, 21:09 Uhr, schrieb Thomas Koch <thomas@koch.ro>:
> Wouldn't this be a use case for git-torrent?
> http://code.google.com/p/gittorrent/
> http://repo.or.cz/w/VCS-Git-Torrent.git
>
> As I understand it, all data would be stored decentraliced and the
> (optional?) central server only saves, who has which objects.
I wonder about latency and accessibility here if clients are disconnected.
Seems this is more for transferring repositories to large numbers of
customers as sort of content distribution network for high load, rather
than low connectivity - and the latter is my prime concern and also a
detail of my scenario.
--
Matthias Andree
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: encrypted repositories?
2009-07-20 12:09 ` encrypted repositories? Matthias Andree
@ 2009-07-20 13:48 ` Jakub Narebski
2009-07-21 8:30 ` Matthias Andree
2009-07-20 15:30 ` Jeff King
1 sibling, 1 reply; 17+ messages in thread
From: Jakub Narebski @ 2009-07-20 13:48 UTC (permalink / raw)
To: Matthias Andree; +Cc: Linus Torvalds, git
"Matthias Andree" <matthias.andree@gmx.de> writes:
> On a more general note, is someone looking into improving the http://
> efficiency? Perhaps there are synergies between my plan of (a)
> encryption and (b) more efficient "dumb" (http/rsync/...) protocol
> use.
There was idea about improving http:// efficiency, but it was via
crating git-over-HTTP aka. "smart" HTTP server, i.e. you would have to
have DAG exposed, like for git:// and ssh://
On the other hand for http:// server need only "dumb" web server, and
additional metadata generated by git-update-server-info. It is client
who does "walking" the DAG, so all data including server metadata can
be encrypted, and decrypted on-the-fly by client.
I don't know though what information leakage you would get from
existence of loose objects and packfiles, and their sizes. Probably
negligible...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: encrypted repositories?
2009-07-20 12:09 ` encrypted repositories? Matthias Andree
2009-07-20 13:48 ` Jakub Narebski
@ 2009-07-20 15:30 ` Jeff King
2009-07-21 8:25 ` Matthias Andree
1 sibling, 1 reply; 17+ messages in thread
From: Jeff King @ 2009-07-20 15:30 UTC (permalink / raw)
To: Matthias Andree; +Cc: Linus Torvalds, git
On Mon, Jul 20, 2009 at 02:09:28PM +0200, Matthias Andree wrote:
> No, the server can't be allowed access to the keys or decrypted data.
>
> I'm not sure about the graph, and if I should be concerned. Exposing
> the DAG might be in order.
>
> It would be ok if the disk storage and the over-the-wire format
> cannot use delta compression then. It would suffice to just send a
> set of objects efficiently - and perhaps smaller revisions can be
> delta-compressed by the clients when pushing.
The problem is that you need to expose not just the DAG, but also the
hashes of trees and blobs. Because if I know you have master^, and I want
to send you master, then I need to know which objects are referenced by
master that are not referenced by master^.
So now you have security implications, because I can do an offline
guessing attack against your files (i.e., calculate git blob hashes for
likely candidates and see if you have them). Whether that is a problem
really depends on your data.
Not to mention that it makes the protocol a lot more complex, as you
would be encrypting _parts_ of objects, like the filenames of a tree,
and the commit message of a commit object.
I suppose in theory you could obfuscate the sha1's in a way that
preserved the object relationships but revealed no information. That is,
the server would have one "fake" set of sha1's, and the client would map
its real sha1's to the fake ones when talking with the server. But that
is again potentially getting complex.
-Peff
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: encrypted repositories?
2009-07-20 15:30 ` Jeff King
@ 2009-07-21 8:25 ` Matthias Andree
2009-07-23 10:40 ` Jeff King
0 siblings, 1 reply; 17+ messages in thread
From: Matthias Andree @ 2009-07-21 8:25 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, git
Am 20.07.2009, 17:30 Uhr, schrieb Jeff King <peff@peff.net>:
> On Mon, Jul 20, 2009 at 02:09:28PM +0200, Matthias Andree wrote:
>
>> No, the server can't be allowed access to the keys or decrypted data.
>>
>> I'm not sure about the graph, and if I should be concerned. Exposing
>> the DAG might be in order.
>>
>> It would be ok if the disk storage and the over-the-wire format
>> cannot use delta compression then. It would suffice to just send a
>> set of objects efficiently - and perhaps smaller revisions can be
>> delta-compressed by the clients when pushing.
>
> The problem is that you need to expose not just the DAG, but also the
> hashes of trees and blobs. Because if I know you have master^, and I want
> to send you master, then I need to know which objects are referenced by
> master that are not referenced by master^.
Yes, you need to know that. Not all of the push logic needs to be
implemented on the server though.
In my scenario, the server degenerates into sort of a general object store
- I really don't expect much smartness there. What is easily available
(clients providing deltas rather than full objects) could be exploited,
and that's it.
We can always have two local repositories, one reference and one checkout.
The reference is a decrypted (unencrypted) copy of the set of objects on
the server, and I could use that for tracking the server-side view (for
instance, what are master^ and master pointing at so I can derive git
rev-list master^...master, what do I need to send to the server).
I'm well aware that crypto requires more efforts on the client side if we
don't trust the server, that's just natural.
The question is: which VCS can serve my scenario?
> So now you have security implications, because I can do an offline
> guessing attack against your files (i.e., calculate git blob hashes for
> likely candidates and see if you have them). Whether that is a problem
> really depends on your data.
Or look at commit frequency and push sources. There's always a leak of
information even if I just upload a series of
blah-2009MMDD-NNN.tar.lzma.gpg files... The data is going to be obsolete,
say, 3 months; students then write the exam and then it's sort of public
anyways. Even if your model does not entail not publishing exams (as
opposed to embargoed press releases under development), but you can't
prevent someone from writing their recollection of the problems from
memory afterwards and sharing it with other students.
> Not to mention that it makes the protocol a lot more complex, as you
> would be encrypting _parts_ of objects, like the filenames of a tree,
> and the commit message of a commit object.
>
> I suppose in theory you could obfuscate the sha1's in a way that
> preserved the object relationships but revealed no information. That is,
> the server would have one "fake" set of sha1's, and the client would map
> its real sha1's to the fake ones when talking with the server. But that
> is again potentially getting complex.
Is your concern that the object name (SHA1) is derived from the
unencrypted version?
--
Matthias Andree
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: encrypted repositories?
2009-07-20 13:48 ` Jakub Narebski
@ 2009-07-21 8:30 ` Matthias Andree
0 siblings, 0 replies; 17+ messages in thread
From: Matthias Andree @ 2009-07-21 8:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Linus Torvalds, git
Am 20.07.2009, 15:48 Uhr, schrieb Jakub Narebski <jnareb@gmail.com>:
> "Matthias Andree" <matthias.andree@gmx.de> writes:
>
>> On a more general note, is someone looking into improving the http://
>> efficiency? Perhaps there are synergies between my plan of (a)
>> encryption and (b) more efficient "dumb" (http/rsync/...) protocol
>> use.
>
> There was idea about improving http:// efficiency, but it was via
> crating git-over-HTTP aka. "smart" HTTP server, i.e. you would have to
> have DAG exposed, like for git:// and ssh://
>
>
> On the other hand for http:// server need only "dumb" web server, and
> additional metadata generated by git-update-server-info. It is client
> who does "walking" the DAG, so all data including server metadata can
> be encrypted, and decrypted on-the-fly by client.
Fine by me, and seems to be some "minimal disclosure to server".
> I don't know though what information leakage you would get from
> existence of loose objects and packfiles, and their sizes. Probably
> negligible...
Dunno. Given that it's just a collection of object sizes, you can't tell
from the SHA1 if the object in question is tree, tag, blob, or commit.
I'm really not after on-the-fly delta re-compression on the server-side
for crypto stuff. I'm more thinking along the lines of zsync/bsdiff/xdelta
(http://zsync.moria.org.uk/ for the least-known) - but zsync can't work on
encrypted data. Perhaps encrypting the diffs could work, but then what's
the difference to using the http:// and update-server-info related
material and combining that with client-side on-the-fly (de/en)cryption?
--
Matthias Andree
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: encrypted repositories?
2009-07-21 8:25 ` Matthias Andree
@ 2009-07-23 10:40 ` Jeff King
0 siblings, 0 replies; 17+ messages in thread
From: Jeff King @ 2009-07-23 10:40 UTC (permalink / raw)
To: Matthias Andree; +Cc: git
On Tue, Jul 21, 2009 at 10:25:50AM +0200, Matthias Andree wrote:
> >The problem is that you need to expose not just the DAG, but also the
> >hashes of trees and blobs. Because if I know you have master^, and I want
> >to send you master, then I need to know which objects are referenced by
> >master that are not referenced by master^.
>
> Yes, you need to know that. Not all of the push logic needs to be
> implemented on the server though.
Yes, though fetching is much harder, since the server is the one holding
the information about how the transfer can be optimized. Still, you
should be able to achieve roughly the same performance as http fetching
from a dumb server.
> Or look at commit frequency and push sources. There's always a leak
> of information even if I just upload a series of
> blah-2009MMDD-NNN.tar.lzma.gpg files... The data is going to be
> obsolete, say, 3 months; students then write the exam and then it's
> sort of public anyways. Even if your model does not entail not
> publishing exams (as opposed to embargoed press releases under
> development), but you can't prevent someone from writing their
> recollection of the problems from memory afterwards and sharing it
> with other students.
> [...]
> Is your concern that the object name (SHA1) is derived from the
> unencrypted version?
Yes. You are potentially leaking considerable information about the
unencrypted contents which an attacker could use to guess those contents
(especially if the file is mostly composed of low-entropy parts, like
text formatting).
-Peff
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: encrypted repositories?
2009-07-17 15:14 encrypted repositories? Matthias Andree
` (2 preceding siblings ...)
2009-07-17 19:38 ` Linus Torvalds
@ 2012-08-02 14:52 ` J-S-B
3 siblings, 0 replies; 17+ messages in thread
From: J-S-B @ 2012-08-02 14:52 UTC (permalink / raw)
To: git
To Matthias.
My name is John Brumbelow, and I know how to solve your issue. Its requires
client-driven-encryption, such that the server never gets the data
un-encrypted, ever, and thus can never decrypt it, but yet, on behalf of the
client, and other clients, users can still search, partially search,
wild-char-search, document-reference-search, and most important, sort data
stored on the server, that the server (and its administrators) can never
"see" cause it never left the client making/editing it, un-encrypted.
Note the key phrase is client-driven-encryption, not, client-encryption.
That is, the client drives the encryption process in conjunction with the
server(s).
This makes it so the data can never be stolen from the server, even if a
villan showed up at the server and held the administrators hostage, or at
any point beyond the client.
There is more...
I also know how to further obfuscate the data, as it is being made, to
protect the end user, so if the villan showed up at the client, and held
them hostage and/or hacked their computer(s), their data would still be
protected. This is not just a simple, extra-hash over the data, but
something that gives the villan fake/false data, which could be
traced/tracked, by the server/authorities.
Please email me at John-S-Brumbelow@hotmail.com
--
View this message in context: http://git.661346.n2.nabble.com/encrypted-repositories-tp3275970p7564308.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2012-08-02 14:52 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-07-17 15:14 encrypted repositories? Matthias Andree
2009-07-17 16:06 ` Michael J Gruber
2009-07-17 20:22 ` Jakub Narebski
2009-07-17 16:30 ` Matthias Kestenholz
2009-07-17 19:38 ` Linus Torvalds
2009-07-17 20:22 ` John Tapsell
2009-07-17 20:40 ` Linus Torvalds
2009-07-17 20:42 ` Linus Torvalds
2009-07-18 19:09 ` encrypted repositories? with git-torrent? Thomas Koch
2009-07-20 12:13 ` Matthias Andree
2009-07-20 12:09 ` encrypted repositories? Matthias Andree
2009-07-20 13:48 ` Jakub Narebski
2009-07-21 8:30 ` Matthias Andree
2009-07-20 15:30 ` Jeff King
2009-07-21 8:25 ` Matthias Andree
2009-07-23 10:40 ` Jeff King
2012-08-02 14:52 ` J-S-B
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.