arx-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Arx-users] Adding crypto to ArX


From: Walter Landry
Subject: Re: [Arx-users] Adding crypto to ArX
Date: Thu, 09 Dec 2004 21:13:04 -0500 (EST)

Kevin Smith <address@hidden> wrote:
> 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.

Actually, the complete key list is only shown when you run "arx
archives".  You only see the one key that signed a revision when you
are downloading.

> 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.

This is the usual problem of key exchange.  There is no good solution.
However, because we're using gpg, the key may have been already
verified.

> 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. 

I have added some blurbs to the manual.

> > > 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.

Ok.  However, now we get into the problems of implementation.  To tell
whether a key has been deleted, as opposed to some other modification
of the public key list, would require parsing gpg's output.  Yuck.

However, it is fairly easy to tell whether the list of public keys
changed.  I can compare the SHA-256 of the local and remote keys.
This means that we would have to download the public keys everytime we
want to verify a checksum.  Done (arx.2.1,142).

Walter





reply via email to

[Prev in Thread] Current Thread [Next in Thread]