Re: [task #4633] GPG-Signed Commits

[Derek Price]

Jim Hyslop wrote:

>> I think we are discussing replay attacks, inserted at any of a number of
>> locations:
>
>
> Yes, in this branch of discussion, we are. I meant in the more general
> case of overall documentation for this feature.
>
> I'll start pulling together a list of attacks we've identified. Should
> I put that up on the CVS Wiki at ximbiot? (which reminds me, I haven't
> updated the other discussion paper I already put up with your comments).


That is fine.  It would probably be useful to repost the link in this
thread when you are done.

> I'm not sure whether a CVS client can defend itself against *any*
> attack from a compromised server. The client is at the mercy of the
> server.


Not from any sort of replay attack in the general case where the client
requests revisions based on a tag or branch name (including where the
lack of a branch name implies the tip of the trunk).

> Maybe we need to start thinking about ways of detecting and foiling a
> compromised server: keeping a GPG signature of the CVS executable,
> running an independent utility that scans the repository checking
> revision signatures, etc.


This is part of what I've been attempting to point out in this thread.  :)

> Even at 1 million connections per second, it will take (if my
> calculations are correct) close to 600,000 years to exhaust the number
> space. So I say go for the easy route, scenario 2.


Yes, I had already decided to go with an arbitrarily long sequence
number for either scenario 1 or scenario 2, using an adder based on the
same overflow detection technique but incrementing an arbitrarily long
string of bytes a byte at a time.  The code isn't much more complicated
and should be fast enough for the number of bytes likely to be needed -
it probably even requires less compile-time detection of things like
integer sizes.

I was also going to base62 encode the result for signing.  base62
because Mark Baushke recently committed code to main.c using it to
encode commitids in this manner, it doesn't break RCS 5.7 when
positioned as an RCS "word" (see rcsfile.5 for the definition of
"word"), and it takes up less space than base10 encoding.

> I agree, with one caveat: if the server is compromised, I don't think
> we can trust any commitinfo/loginfo messages it generates.


True, but messages generated up until the compromise would still be
usable and, since the server would not have any way of deleting or
replacing old messages in the secure archive, even suspect messages
might be useful in detecting someone rewriting old revisions after the
initial messages were generated.

Also, even a compromised server cannot generate changes that check valid
unless some client keys are also compromised, so the signatures of the
contents of the secure archive can still be verified too.

> Actually, this raises a separate concern: my signature is either valid
> or it isn't. As I recall, the proposal is not necessarily to store the
> exact thing I've signed, but just the signature itself. This raises
> the question - if my signature encompasses both the delta and the
> entire file, and if suddenly becomes invalidated, what got tampered
> with: my file as checked in, or the delta? Or do we just not worry
> about it, and retrieve the latest backup file that validates the
> signatures properly?


I would argue that we not worry about it and retrieve the latest backup
that checks valid.  I was thinking that it might be better to keep diff
and full-content signatures separate, though I haven't given it much
thought yet.  It might allow reconstruction if only one was tampered
with without a backup to separate them, and signing the same sequence id
with each could correlate them securely.

Regards,

Derek

-- 
Derek R. Price
CVS Solutions Architect
Ximbiot <http://ximbiot.com>
v: +1 717.579.6168
f: +1 717.234.3125
<mailto:derek@ximbiot.com>