On Thu, Mar 13, 2008 at 08:58:54AM -0400, Theodore Tso wrote:
> No, and you wouldn't want to use gpg because of the overhead it adds
> around an encrypted message. You would need to use a raw encryption
> algorithm, or one with very minimal wrapping. It's normally at this
Well, "raw encryption algorithm" is a bit vague here. :)
I thought about this a while ago and come to a few conclusions:
- encrypting before git sees content sucks, because you are either
sacrificing security (content X always encrypts to Y) or system
stability (git doesn't know that Y and Y' are really the same thing)
- encrypting at the object level (when we do zlib) sucks, because we
still want to name contents by their hash, which means the object
database index contains information about what's in your content.
There's also some per-object overhead. Plus any system without the
key can't do deltas.
- encrypting whole packfiles sucks for local storage, since you lose
the random access property (unless you go with something static like
an ECB mode, but then you are sacrificing security).
- encrypting whole packfiles is a bit better for transport. The
key-holding repo does the deltas and just treats the remote repo as
dumb storage (it can't be smart, since that would involve looking at
the data). Storage overhead is minimal if packfiles are a reasonable
size.
So I think the last makes the most sense, where your local repo is
totally unprotected, but you efficiently push git objects to a remote
untrusted repo.
You could probably do something totally external to git using bundles as
the primitive. Store an encrypted index on the remote that says "here
are the packs I have, and the objects they contain." Whenever you push,
pull the index (which is of course more network-intensive than regular
git protocol, but not as bad as pulling all the data) and calculate a
thin-pack bundle yourself. Encrypt the bundle and store remotely.
> point that that you'd need to bring in a security expert to ask a
> whole lot of questions about your exact use scenario, do a formal
> threat analysis, since there are all sorts of unanswered questions
> about what kind of key management solution you really need for your
> situation.
I don't know if a formal thread analysis is necessary. I think most
people are interested in "if the contents of remote storage X are
known, how much do people know about the _contents_ of my repo stored on
X?" and they don't care about masking the size, time of updates, etc.
That's a fairly straightforward application of cryptography. The tricky
part is doing it in a way that can still leverage some of git's
efficiencies.
> It's usually not as simple as "just encrypt it". How many people need
> to have access to the to the repository? Do you need to revoke access
> to the repository later? Who is allowed to give a new person access
> to the repository? etc., etc., etc.
Sure, those are all interesting questions for a complete system. But I
think it makes sense to incrementally try the basics first.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
