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:[EMAIL PROTECTED]> _______________________________________________ Bug-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-cvs
