Re: [Gnu-arch-users] (volunteers?) crypto signatures for arch

[Karel Gardas]

On Sun, 7 Dec 2003, Tom Lord wrote:

>     > > 2) Add a "signed-archive" property to archives
>
>     > >    Have a look at libarch/archive.c(arch_make_archive) and
>     > >    arch_pfs_make_archive.   Note how the parameter dot_listing_lossage
>     > >    is used.
>
>     > >    Add a similar parameter signed_archive, so that if you create
>     > >    an archive with --signed, =meta-info the in the archive will
>     > >    contain a file "signed-archive" containing the string "system
>     > >    cracking is lame".
>
>     > Is this really needed? I would rather be for some kind of
>     > security levels set in $HOME/.arch-params/=locations. This way
>     > different users can handle the same archive differently, i.e. on
>     > get with sig broken either nothing, or warning, or error migt
>     > happen
>
> `get' doesn't check signatures in this proposal.  My reasoning is that
> while the archive host is going to have public keys (somewhere outside
> of where arch itself can touch them) clients running `get' generally
> won't.

Oops, either I don't understand, or if I understand, that's IMHO no
security at all. IMHO get _needs_ to verify signatures.

> Verifying the integrity of a signed archive is orthogonal to running
> `get' on it.

It seems, I don't understand. For signature verification you need to have
public key, so anybody running "verification" needs to have it.

>     >> 3) Modify arch_pfs_connect to collect a passphrase
>
>     >>    It's a bit icky to keep the passphrase in tla's memory but I think
>     >>    it's more reasonable in this case than the alternatives.
>
>     >>    In libarch/pfs.c(arch_pfs_connect), after connecting, look for
>     >>    the "signed-archive" file.   If present, prompt the user for
>     >>    a passphrase and record it.
>
>     > Please no! That's exactly how it shouldn't be done, since you will need 
> to
>     > increase size of your TCB code, which is not good from security
>     > review point of view.
>
> Well, what would you suggest?   The "requirements" are:
>
>   a) be able to run GPG multiple times (an unbounded number of
>      times for push-mirror)

push-mirror should be crypto unaware as I proposed in my own proposal

>   b) try to avoid having to prompt the user for a passphrase
>      for each run.

that's absolutelly not arch/tla job, vide also my proposal.

>   c) avoid having to have the user configure additional software,
>      such as a passphrase server

that's again up to the arch/tla users how they setup their crypto support
applications.

>     > Well, I will probably finally write my own proposal, just to not only
>     > criticize your own. :-)
>
> As I said to Rob, I should have been more explicit that one of the
> goals of posting was for design critique, not just looking for
> volunteers.

OK, I have tried to come with some of my ideas...

Cheers,

Karel
--
Karel Gardas                  address@hidden
ObjectSecurity Ltd.           http://www.objectsecurity.com