Re: [Arx-users] Adding crypto to ArX

[Kevin Smith]

On Wed, 2004-12-08 at 20:18 -0500, Walter Landry wrote:
> Kevin Smith <address@hidden> wrote:

(Snipped confusion about what I was talking about. Trying again:)
> > > > When someone else registers your archive in
> > > the most ordinary way, then the public keys will be downloaded and
> > > stored in ~/.arx/archives/(archive name)/public_keys.  
> > 
> > It should probably display the fingerprint(s) at that point to allow
> > visual confirmation that we got the expected key.

At the moment that the key list is pulled from an archive, the
fingerprint(s) should be displayed so the user can confirm that they are
correct. Hm. That works great for single-user archives, but perhaps not
for archives with a bunch of keys in them.

I'm thinking that if someone intercepts my attempt to register the
wlandry archive, they could substitute their own archive with its own
key. I would think I was using stuff signed by you, but I wouldn't be.
Maybe that attack would be hard enough to pull off that it's not worth
defending against.

Even so, the doc should probably recommend that fingerprints be verified
(if the expected values are known) as soon as a remote signed archive is
first accessed. 

> > It would be nice if ArX would detect that the two files are not 
> > identical and notify the user so they can choose how to proceed. 
> > At that point, a quick way for the user to accept the new keys 
> > might be a nice touch (to avoid the un/re-register thing).
> 
> I don't think I want to do this.  Adding and deleting keys from an
> archive that you have already registered should be a rare occurance.
> If it is too quick and easy to accept new keys, then people may not
> notice an intrusion.

(I mentioned this in my other recent email, but...)

I still think it should _notify_ clients, especially for deletes. I
agree that it does not have to be easy to accept newly added keys.

> You just have to make sure that you have accounted for all of the data
> and metadata, and you have to be sure that you can't replace one
> manifest with another.  For example, suppose you have foo.stable and
> foo.gaping_security_hole branches, both signed by you.  You want to
> make sure that someone getting foo.stable isn't tricked into getting
> foo.gaping_security_hole.

Ah. So it's basically a question of thoroughness now, and also if/when
stuff is added to the definition of a revision. As opposed to rocket
science. Not that thoroughness is easy, mind you...

> The signed archive doesn't have any cached revisions, then tla will
> grab patches from the unsigned archive.  If the signed archive does
> have cached revisions, then someone who breaks into the host may be
> able to delete them anyway.  They only have to have a copy of the
> archive when that revision was not archived.  Since cached revisions
> are often created and destroyed, that should not be too hard in
> practice.
> 
> This problem arises because tla does not sign revisions, only patches.
> I would imagine it would take a lot of work to be able to sign
> revisions.  It was certainly non-trivial for ArX.

I think I get it. Good to know.

Kevin