Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL

[Ethan Blanton]

I'm not sure this is useful, but here goes.

Robert White spake unto us the following wisdom:
> As for bob+foocorp; people who expect to be able to use the email
> addresses aren't necessarily going to be wanting to see/create/use
> +foocorp, nor remove same, particularly since now you are leaking
> "foocorp" into a data stream where it may not be welcome (sub of
> a sub contractor etc).

Both Timothy and I brought up this specific format for a particular
reason -- many (of not most) mailers strip +<appendage> from email
addresses before delivering mail.  All of the mail addresses I
currently use will accept such appendages, for example.  For this
reason, this is commonly used to differentiate usage of a single
mailing address when necessary.  No address must be created or removed
for this to happen.

As to whether there is information leakage, that of course is a
different issue.

> >No, the default should stay as it is to prevent people accidentally
> >exposing their keys. We probably also don't want to encourage uses that
> >break monotone's basic assumptions, it'd be much better to get around to
> >fixing the assumptions instead...
>
> Why the default should be to protect the encrypted keys at the cost
> of potentially conflating the entire set of active databases is beyond
> me. But even so, the _default_ should be configured into the database
> on a per-instance case.

Monotone generally settles on security first; many users (myself
included) consider this a good thing.  A single, well-known key store
is much easier to keep track of and secure than a variety of databases
being shipped all over the network for various reasons.  Yes, those
keys are protected, but they're protected by a passphrase which is
almost certainly not very good, cryptographically speaking.  Yours may
be spectacular, but it's many deviations from the norm, if that is the
case.  :-)

> For instance "genkey" could create .monotone/keys/keyid by default
> but all the key operations should check for "select * from privatekey
> where keyid=indicated" before checking for .monotone/keys/indicated.
> Then there would be a import/export operation for having the key
> in or not-in the database as desired.  Meanwhile "migrate" wouldn't
> write to .monotone/keys/keyid ever, nor would dropkey delete a secret
> key file _EVER_ since if you _ARE_ using the same key in multiple
> databases, that would _ALWAYS_ be wrong.  This would lead to one code path
> that would allow for the keys to remain wherever they already were,
> and individual users would be able to decide whether they wanted
> their keys conflated in one directory or stored within their databases.

An option to explicitly move keys to a database, and use
database-stored keys if present, doesn't seem too terrible to me.
Presumably anyone doing such a thing would be aware that they are
creating a security-related situation of which they need to remain
aware.  It absolutely seems like something which should be opt-in to
me, however.  I can't say I'm a big fan due to the fact that it
complicates a rather important part of the security model ... but then
again, I won't be the one implementing it, either.

> It's a freaking land mine.

That's interesting ... I found the in-database keys to be a "freaking
land mine", and was quite pleased several years back when they were
ditched in favor of a filesystem key store.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
                -- Cesare Beccaria, "On Crimes and Punishments", 1764

signature.asc
Description: Digital signature