monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] private keys: per-database vs. per-user


From: Bernhard Reiter
Subject: Re: [Monotone-devel] private keys: per-database vs. per-user
Date: Thu, 20 Jan 2005 15:42:48 +0100
User-agent: Mutt/1.5.6i

On Wed, Jan 19, 2005 at 08:09:09AM +0100, Richard Levitte - VMS Whacker wrote:
> In message <address@hidden> on Tue, 18 Jan 2005 21:28:33 -0800, Nathaniel 
> Smith <address@hidden> said:
> 
> njs> My question, though, is this.  Would we want to continue to
> njs> support storing keys in one's database at all?
> 
> (yes, at least the public keys :-))

As they are public, this is unproblematic unless for space.

> njs> Can anyone come up with any use cases where it is important to
> njs> store separate private keys for separate projects?
> 
> There's the typical paranoid case: what happens if someone steals or
> cracks your private key?  Do you really want *all* the projects you
> take part in (not just *your* projects) to be exposed at once?  If my
> private key was stolen (not likely, but I can't assume it's
> impossible), monotone will be affected since it is used to sign
> whatever I contribute there.

Does this actually match realistic attack vectors?
When one of your private key gets stolen 
usually you have had a breach of security a while ago that 
will have involved the surroundings.
E.g. a break-in on your home machine, that will involve all keys.
Cracked keys are rare.

While we are at security scenarios, let me take a stance for GnuPG.
Yes I have read the FAQ that says:
        * GPG as a subprocess is slow, tricky and fragile; 
        crypto++ in-process is fast, simple and reliable.
        * OpenPGP packet format is quite baroque, we need much less
          than it can do

Both points are probably true, 
though the gpgme library helps a bit against the tricky and fragile part.

Still I guess that especially certification handling done with GnuPG
could provide some advantages for monotone:
        * Handling of a trust database.
        * Already good understanding of peer to peer signing in the
        potential users page (PGP keysigning)

There is also the advantages of modern GnuPG developments:
        * x509 handling (e.g. like for S/MIME) integrated via gpgme,
        so you can almost have both like Kmail does in Ägypten
        (www.gnupg.org/aegypten2/)
        * possibilitiy for PKI handling for x509 (esp. CRLs, OSCP)
        * Possibility to save the private keys in hardware tokens,
        like smartcards 

I only testplayed monotone a bit yet,
but when development really gets distributed a lot,
I think that automatical handling of trust for certificates
will get a lot more important for practical use.

Monotone could implement a lot by itself and being more on the point
on the coupling of actions, needed capabilities of the format
and version control, but on the other hand it would need to reimplement 
components that others try to get right for a long time in GnuPG.

Best,
        Bernhard

Attachment: pgpmleQdXwsED.pgp
Description: PGP signature


reply via email to

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