Mailing List Archive

On Fri, Dec 04, 1998 at 12:09:07PM +0000, Roger Burton West wrote:
>
> (1) Is there any interest in a secret-sharing encryption mode? The
> principle is that one has a message key which is split into sections,
> such that any (N) of the sections are sufficient to recreate the key,
> but any (N-1) are not. While it's not the sort of thing one might often
> want to do, I can see it being useful for secret-key backups, among
> others. I am familiar with the mathematical protocols and have written
> implementations of this sort of thing before.

It would be useful for other reasons, too. Things like 'role accounts'
with the Internic are sort of stupid without key-sharing. Either
everyone on the role-list has the same key (which means they can steal
it if they leave and forge mail that breaks your name service) or you're
back to having one person do the job which defeats the point of a role
account. I have no idea how places that host a million domain
customers handle it.

> (1a) does this cause any problem in the context of the OpenPGP
> standard?

It shouldn't: the commercial PGP's 'for business' can do it.

I haven't looked at how they handle the process, though, if each client
has to be signing at the same time, or if they have some sort of
repository and a server that handles it.

--
Brian Moore | "The Zen nature of a spammer resembles
Sysadmin, C/Perl Hacker | a cockroach, except that the cockroach
Usenet Vandal | is higher up on the evolutionary chain."
Netscum, Bane of Elves. Peter Olson, Delphi Postmaster

On Fri, 4 Dec 1998, brian moore wrote:
> It would be useful for other reasons, too. Things like 'role accounts'
> with the Internic are sort of stupid without key-sharing. Either
> everyone on the role-list has the same key (which means they can steal
> it if they leave and forge mail that breaks your name service) or you're
> back to having one person do the job which defeats the point of a role
> account. I have no idea how places that host a million domain
> customers handle it.

You don't need anything very fancy. Each individual who deals with
InterNIC transactions needs only to sign with their personal key and
submit to a local address, which just happens to be a quick script that
verifies the signature (rejecting the message if unauthorized), strips the
sig, and resigns it with the role signature, sending it off to
hostmaster@internic.net.

No muss, no fuss, and minimal work to get running.

Now, to really make that useful, you combine it with a local InterNIC
tracking system which tracks the progress of common tasks and
automatically responds to particular actions, or redirects responses to
the original local submitter. (Basically, you give every transaction a
local tracking number which you stick in the subject line of the message;
InterNIC always responds with it included in the new subject on the ACK,
which gives you the InterNIC tracking number which you reference all new
tasks from.)

That, however, is significantly more work to get running properly, and
requires a good deal of experimentation to help scripts automatically
recognize important responses (such as when to close the ticket ;-). It
took me a long time to trust it enough to hand it over to tech support...

I wish they'd just come up with a nice real-time system to talk to (which
they promised over a year and a half ago; I've probably still got the
email where they told me that); that would have eliminated all the
email-based tracking hackery I had to come up with. But this is truely
off-topic for this list, so I'll stop ranting now. ;-)

--
Edward S. Marshall <emarshal@logic.net> [ What goes up, must come down. ]
http://www.logic.net/~emarshal/ [ Ask any system administrator. ]

Linux labyrinth 2.1.129 #2 SMP Thu Nov 26 13:54:26 CST 1998 i586 unknown
7:50pm up 8 days, 5:03, 3 users, load average: 0.18, 0.06, 0.01

On Fri, Dec 04, 1998 at 08:02:15PM -0600, Edward S. Marshall wrote:
> On Fri, 4 Dec 1998, brian moore wrote:
> > It would be useful for other reasons, too. Things like 'role accounts'
> > with the Internic are sort of stupid without key-sharing. Either
> > everyone on the role-list has the same key (which means they can steal
> > it if they leave and forge mail that breaks your name service) or you're
> > back to having one person do the job which defeats the point of a role
> > account. I have no idea how places that host a million domain
> > customers handle it.
>
> You don't need anything very fancy. Each individual who deals with
> InterNIC transactions needs only to sign with their personal key and
> submit to a local address, which just happens to be a quick script that
> verifies the signature (rejecting the message if unauthorized), strips the
> sig, and resigns it with the role signature, sending it off to
> hostmaster@internic.net.

This breaks when someone steals the key from the central server: they
now have the ability to get around the "must have 2 signatures" rules.
If they copy it to a floppy, they can keep it as an insurance package
for when they get canned.

Icky.

There are ways to split keys (mathematically) that allow key sharing
with no central secret key storage. The "business" versions of PGP
claim to have it, though I haven't seen it. (I don't do Windows. :))

(I'd love to know how they do it protocol wise, because there are
interesting problems to solve to make it usable like allowing for it to
be handled in a time-shifted mechanism like email when not everyone can
open a socket to each other at the same time.)

--
Brian Moore | "The Zen nature of a spammer resembles
Sysadmin, C/Perl Hacker | a cockroach, except that the cockroach
Usenet Vandal | is higher up on the evolutionary chain."
Netscum, Bane of Elves. Peter Olson, Delphi Postmaster

On Fri, 4 Dec 1998, brian moore wrote:
> This breaks when someone steals the key from the central server: they
> now have the ability to get around the "must have 2 signatures" rules.
> If they copy it to a floppy, they can keep it as an insurance package
> for when they get canned.

Yes, you have a single point of failure. However, this assumes the
compromise of the host. Frankly, if someone has compromised a server that
houses critical keys on it, it's time to start issuing revokations anyway.

In other words, you can work around this. But...

> There are ways to split keys (mathematically) that allow key sharing
> with no central secret key storage.

...>this< is definitely preferred. ;-) However, unless I'm missing
something, you still need a centrally stored "half-key", unless you're
talking about having two unique individuals sign the InterNIC submission
(which seems like a lot of overhead for nothing)?

However, even with a central "half-key" stored, it doesn't do an attacker
who compromises the key any good at all without the other half. If the
attacker is one of your employees who do InterNIC submissions, though,
you're stuck back in the same boat as before...

Or did I miss something in your description (I'm probably automating
things more than you were suggesting...)?

--
Edward S. Marshall <emarshal@logic.net> [ What goes up, must come down. ]
http://www.logic.net/~emarshal/ [ Ask any system administrator. ]

Linux labyrinth 2.1.129 #2 SMP Thu Nov 26 13:54:26 CST 1998 i586 unknown
9:35pm up 8 days, 6:48, 3 users, load average: 0.04, 0.03, 0.15

On Fri, Dec 04, 1998 at 09:45:40PM -0600, Edward S. Marshall wrote:
> On Fri, 4 Dec 1998, brian moore wrote:
> > This breaks when someone steals the key from the central server: they
> > now have the ability to get around the "must have 2 signatures" rules.
> > If they copy it to a floppy, they can keep it as an insurance package
> > for when they get canned.
>
> Yes, you have a single point of failure. However, this assumes the
> compromise of the host. Frankly, if someone has compromised a server that
> houses critical keys on it, it's time to start issuing revokations anyway.
>
> In other words, you can work around this. But...

You're assuming the threat comes from the outside.

I've seen employees fired from ISP's (even those with root) that have
damaged their former employer by being naughty with resources they had
access to while employed.

(And, outside of the ISP world, it happens a lot more often. At least
most geeks think in binary so you know where they stand. Civilians are
random and rip off their employers all the time.)

> > There are ways to split keys (mathematically) that allow key sharing
> > with no central secret key storage.
>
> ...>this< is definitely preferred. ;-) However, unless I'm missing
> something, you still need a centrally stored "half-key", unless you're
> talking about having two unique individuals sign the InterNIC submission
> (which seems like a lot of overhead for nothing)?

But it keeps rogue ex-employees from doing any damage even if they are
rootly.

> However, even with a central "half-key" stored, it doesn't do an attacker
> who compromises the key any good at all without the other half. If the
> attacker is one of your employees who do InterNIC submissions, though,
> you're stuck back in the same boat as before...

Yep, which is why you don't keep even a half key. :)

> Or did I miss something in your description (I'm probably automating
> things more than you were suggesting...)?

There are methods of splitting the key so that any n pieces out of m
are needed to sign. You could have 30 employees and require 6 to sign
off. (And by playing math games, if you give three parts to trusted
employees, it would take only two of them to do it instead of 6
peons.) You'd have to fire a slew of 'em in order to have their pieces
used against you. (Enough time to get the Internic to change keys. :))

There's no need to store a central key: things just won't work without
all the pieces.

This is what the commercial PGP supposedly has. (They call it
'corporate key recovery', which basically allows portions of an
employees keys to be assigned to various corporate officers, so if
three VP's or whatever get together, they can get into an employee's
secured data. A good thing when someone get hit by a truck and has
the secret plans encrypted on his hard drive.)

With a good mechanism (and I haven't seen PGP's handling of this), it
can be pretty useful. I'd point you to their website where it explains
the magic, but the silly export rules at www.pgp.com/sdk/ where they
have such stuff doesn't work. (You can play with it all night, but you
still can't get in.)

--
Brian Moore | "The Zen nature of a spammer resembles
Sysadmin, C/Perl Hacker | a cockroach, except that the cockroach
Usenet Vandal | is higher up on the evolutionary chain."
Netscum, Bane of Elves. Peter Olson, Delphi Postmaster

On Fri, Dec 04, 1998 at 08:20:09PM -0800, brian moore wrote:

>(And, outside of the ISP world, it happens a lot more often. At least
>most geeks think in binary so you know where they stand. Civilians are
>random and rip off their employers all the time.)

Hey, I _like_ that way of putting it! :-)

>There are methods of splitting the key so that any n pieces out of m
>are needed to sign.

Yes, that's _exactly_ what I'm talking about implementing.

At the moment, I'm assuming I'd need a new packet descriptor,
"key fragment". The fragmentation/recombining process would have
to work on keys - invocation would be something like:

(1) - fragment this secret key (needs passphrase as usual)

(2) - recombine these fragment files to a secret key

(3) - encrypt this message and fragment the message key

(4) - use these fragment files to decrypt this message


The (3)/(4) mechanism would be sufficient for general purpose use,
with (1)/(2) only used occasionally - the only reason not to treat
the secret key as a message is that one wants to fragment the
"naked" rather than the encrypted key.

I'm assuming that getting the files to the same place is Not My
Problem. :-)

Cheers,

Roger

--
Roger Burton West
Frontline Administrator, Demon Internet Ltd - of _course_ I don't speak
Home: roger@firedrake.demon.co.uk for them!
Web: http://www.firedrake.demon.co.uk

brian moore <bem@cmc.net> writes:

> It shouldn't: the commercial PGP's 'for business' can do it.

I think I didn't yet response to this.

We will have secret sharing in the 1.1 version. What we should do now
is to build a stable 1.0 version and don't introduce more features.

I will soon move to a 0.9 version which will be a kind of code freeze.


Werner