Discussion:
commercial data recovery
(too old to reply)
Zooko Journeyman
1970-01-01 00:00:00 UTC
Permalink
[Note-- I am not subscribed to ietf-open-pgp at this time. My
apologies if this submission from a non-subscriber is
unwanted. I will be brief. --Zooko]


Adam, I applaud your effort to steer discourse toward
productive work re: GAK, CMR, CDR. I haven't thought about
your idea enough to have a definite opinion, but at first blush
it seems a promising strategy to design high-security and
forward-secrecy for communication but recovery/sharing features
for stored data.


I wonder if it is too much early-days to start talking about
advanced protocols e.g. secret-splitting in IETF-Open-PGP?
Probably so. Better just punch out a standard with current
tech...



Hm. What about the idea of storing your data remotely (for
cost-efficiency, safety, etc.) using encryption to maintain
your privacy? In that case, the distinction between comms and
storage keys is blurred. A company may choose to e.g. store
all long-term data at Zooko's Backup Server, encrypted in such
a way that some combination of corporate keys (controlled by
individual employees and/or departments) is necessary to
decrypt each package of data. This would open the door, as you
fear, for a government to mandate that _its_ key be added to
each set, with authority to open any package even without the
cooperation of any corporate keys.


I'm not sure how to weigh the relative risks and benefits.
I (ever so humbly) think that Zooko's Backup Server would be a
great value for businesses, and that part of that value would
be the ability to make data unlockable by various keys, both
for administrative/internal security purposes and for
robustness against accidents and saboteurs.


Zooko's Backup Server can be physically located in a country
free of such intrusive organizations, but of course it is the
intrusive organizations of the _client's_ country that become
important with that kind of protocol...


Regards,

Zooko

P.S. There is already a company whose name I have forgotten
that offers hard-drive backups over TCP/IP. They use some
encryption but I don't know how strong.
a***@xs4all.nl
1970-01-01 00:00:00 UTC
Permalink
On Tue, 14 Oct 1997, Zooko Journeyman wrote:

> Zooko's Backup Server can be physically located in a country
> free of such intrusive organizations, but of course it is the
> intrusive organizations of the _client's_ country that become
> important with that kind of protocol...

How about also having Alex' Backup Server, and using some
shared-secret/whatever tech to ensure that you need to contents of _both_
servers to actually reconstruct the data. This would be a 'Distributed
Encrypted Backup Sysyem'.

This might make it very hard for anyone to access your data without your
knowledge/cooperation.

And if you use something like Onion Routers, it might even be quite
impossible for some lawenforcement agency to actually find out which one
of those encrypted files on the servers contains your backup.

Alex

---
I dabble in techno-house and sometimes,
I do that badass hip-hop thang...
But the F U N K gets me every time!
Adam Back
1997-10-14 13:29:33 UTC
Permalink
Zooko Journeyman <***@xs4all.nl> writes:
> Adam, I applaud your effort to steer discourse toward
> productive work re: GAK, CMR, CDR. I haven't thought about
> your idea enough to have a definite opinion, but at first blush
> it seems a promising strategy to design high-security and
> forward-secrecy for communication but recovery/sharing features
> for stored data.

Thank you. I would encourage others to read the proposal, and
provide criticisms of it.

> I wonder if it is too much early-days to start talking about
> advanced protocols e.g. secret-splitting in IETF-Open-PGP?
> Probably so. Better just punch out a standard with current
> tech...

I agree entirely. The motivation for attempting to formalise the CDR
design principles, and for exploring designs which are non-GAK
compliant is based on these lines of reasoning, that we should:

1. Persuade PGP Inc that there are less GAK friendly ways of
implementing data recovery

2. If that argument fails, and in the event that PGP were to try to
influence the IETF OpenPGP forum to adopt any features relating to
pgp5.5 GAK compliant functionality into the OpenPGP standard that we
have an alternate proposal well enough thought through to compete
with PGP's CMR proposal with sound technical arguments.

3. Of improving the state of the technology by working to include
forward secrecy as much as possible into secure email messaging.
This is a very effective method of giving the bird to the
GAKkers, by purposefully destroying communications keys as soon as
possible after the fact. This is consistent with the CDR design
goal: make the GAKkers job as difficult as possible. Frustrating the
GAKkers is a fun, morally satisfying activity.

> Hm. What about the idea of storing your data remotely (for
> cost-efficiency, safety, etc.) using encryption to maintain
> your privacy? In that case, the distinction between comms and
> storage keys is blurred. A company may choose to e.g. store
> all long-term data at Zooko's Backup Server, encrypted in such
> a way that some combination of corporate keys (controlled by
> individual employees and/or departments) is necessary to
> decrypt each package of data. This would open the door, as you
> fear, for a government to mandate that _its_ key be added to
> each set, with authority to open any package even without the
> cooperation of any corporate keys.

The application you describe has very interesting implications for the
CDR vs CMR debate.

I think that one way that you could implement remote backup in a way
which is sympathetic to CDR design principles like this:

- The communications security aspect could be acheived via the normal
design for securing communications derived from the CDR design
principles. That is using short lived communications keys with no
third party access to communications in transit without access to
hard disks at either end.

- The data would be super-encrypted to the companies backup recovery
storage key(s).

This technically violates the CDR design goal and principles of not
allowing third party access to communicated data, super encryption
doesn't negate this, it is just more structuring.

However, super-encryption does minimise the damage by preserving CDR
principle that recovery of data should require physical compromise of
one or both end points, which I think is an important principle, and
a useful property in this case.

This lesson leads to the corollary to the CDR principles that:

- if you can't keep to the principle of not transmitting data with third
party recovery information attached,

that:

- super-encryption of the transmitted recoverable data can be
used to at least preserve the requirement for one or both ends of
the communication to be compromised to effect third party access.



But still, the remaining way that this system could be perverted would
be as you say for the GAKkers to demand to be one of the storage
accessors for the encrypted disk backup, and for the GAKkers to then
attempt to coerce the remote storage service provider to hand over the
ciphertext, or for the government to set themselves up as a central
provider of off site backup services.

The GAKkers desire for automatic access to communicated storage data
is frustrated to the maximal extent possible by those CDR design
principles we have managed to retain. To achieve automated access the
GAKkers must start replacing software, and we have prevented automatic
snooping of our backup data whilst it is in communication, with
software we have fielded.

- CDR design principles do not prevent someone modifying software, but
as we all know deployed systems are additional obstacles to overcome:
they have to coerce some company in to implementing the new software
with built in GAK, and they have to coerce everyone into replacing
their existing software with this unpopular new software.

Widely deployed systems can be large obstacles. The mess the US IRS
in with their millions of lines of hard to modify source attest to
this fact.

The IRS scenario has some lessons for us, for possible additional CDR
design principles:

- keep the source code out of reach of GAKkers so that they can not
coerce us so easily to modify it. Off shore backup might be useful;
destroy the backup recovery key if GAK comes in.

- make systems non-interoperable where this does not interfere with
functionality

- have mandatory GAK company contingency plans such as moving the
company to Switzerland.

That first suggestion costs so much in the loss of user access to
source code to assure ourselves that there is no backdoor that we
probably can't employ it. The other two look like sound principles to
me.


> Zooko's Backup Server can be physically located in a country
> free of such intrusive organizations, but of course it is the
> intrusive organizations of the _client's_ country that become
> important with that kind of protocol...

One comfort which can be drawn from the above design using super
encryption inside a communications envelope protected with short lived
non-escrowed communication keys, is that the fielded software could
not be used as-is to prevent the practice of jurisdiction shopping.

Another comfort is that companies can, even if forbidden from using
offshore remote backup facilities, simply stop using remote backup
facilities at all, unless the GAKkers really go overboard and demand
that all citizen units will run this government remote backup software
to upload diffs of their disks to government run backup services. I'm
sure they would love to do that, and charge you for the "service" too.

Also I expect there would be significant political hurdles for the
GAKkers to overcome in mandating government run remote backup services
for citizen units, or even for companies in our countries.

Adam
--
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
Tim May
1997-10-14 21:28:01 UTC
Permalink
I have an even simpler solution to the problem of how the OpenPGP committee
should solve the key recovery/message recovery/corporate/GAK problem: Don't.

Just decide and announce that neither plaintext nor key recovery will be
part of the OpenPGP spec. This is a cleaner and simpler approach, and the
functions of encryption are placed front and center.

(Let some other task force deal with building some kind of "OpenGAK" or
"OpenSnoopware" program!)

That is, OpenPGP need only worry about providing a robust, secure, etc.,
open standard for end-to-end encyption (communication) and local encryption
(storage). Don't try to solve the "disaster planning" problem ("Alice hit
by a truck") by building snoopware/escrow into the core cryptosystem, and
don't try to solve the snoopware ("What is Alice saying to Bob?") desires
of companies either.

For comparison, we certainly don't see the world's telecommunications
bodies, committees, and companies working on a "conversation recovery" mode
to make the job of enforcing the U.S. Digital Telephony and similar
wiretapping desires.

Dealing primarily with communication and file security is what PGP has
historically focussed on, in all versions from 1.0 to 5.0 (not counting the
anomaly of ViaCrypt). Sounds fine to me. The "mission" of PGP and other
public key cryptosystems (until now) has been to secure communications and
files, not to provide mechanisms for corporations to monitor
communications. (Disaster planning, for "what if Alice gets hit by a
truck?" scenarios, are of course handled by having Alice lock up her
private keys in her safe, or perhaps her department manager's safe,
whatever. This is a dangerous security flaw, if the key is released, but
has the advantage that it's a fairly conventional recovery approach, and is
not built into the cryptosystem itself. Trying to solve this problem, that
of "backup keys" or "spare keys" floating around, is not easy in any
case...OpenPGP would do well to just avoid the issue and let conventional
disaster planning measures deal with the problem.)

If corporations, agencies, governments, etc., want to have access to
Alice's files, to Alice's communications to Bob, this is really a file
managment and archiving strategy problem, not something OpenPGP has to
concern itself with.

Keep it Simple, Stupid. KISS. Often the simplest approach to dealing with
complex specifications and conflicting desires is to just ignore them.

Let Big Brother and Little Brother try to get snoopware deployed when
OpenPGP is widely available.

Whether PGP, Inc. will go along with this is unlikely, but this doesn't
change the reasons for keeping OpenPGP true to the original aims of PGP.

--Tim May

The Feds have shown their hand: they want a ban on domestic cryptography
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May | Crypto Anarchy: encryption, digital money,
ComSec 3DES: 408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets,
Higher Power: 2^2,976,221 | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."
Andrew Bromage
1997-10-14 23:58:50 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----

G'day all.

Zooko Journeyman wrote:

> I wonder if it is too much early-days to start talking about
> advanced protocols e.g. secret-splitting in IETF-Open-PGP?

One list member has encouraged me to write an internet-draft for a key
quorum system, so I am. The trouble is that my proposed implementation
needs some info that isn't in the current IETF draft (the format of the
"string to key" object).

Is it actually documented anywhere that we can access?

Cheers,
Andrew Bromage
Rick Smith
1997-10-15 19:14:19 UTC
Permalink
While I think that a variety of robust and successful products will proably
emerge that support various types of key recovery, I strongly agree with
Tim on engineering grounds: Keep It Simple, Stupid.

When it comes to deciding on the contents of a standard, let's keep in mind
that we're working with a relatively new technology. We'll make more
progress by standardizing proven concepts, and these integrated key
recovery hacks don't have the operating history that vanilla PGP has. If
anything, my experience with Guard keying suggests that the proposed
mechansims aren't enough. The problem has more hair than our sheepdog.

I don't think the protocol standard needs to take a political statement
about key recovery mechanisms, but it *must* outline the protocol's
traditional security objectives pretty much the way Tim outlined them. That
sets the context for a robust protocol that has a successful history.

Now I need to shut off my mailer and go pack my suitcase.

Rick.
***@securecomputing.com Secure Computing Corporation
"Internet Cryptography" now in bookstores http://www.visi.com/crypto/
Tim May
1997-10-15 18:46:32 UTC
Permalink
At 12:14 PM -0700 10/15/97, Rick Smith wrote:
>While I think that a variety of robust and successful products will proably
>emerge that support various types of key recovery, I strongly agree with
>Tim on engineering grounds: Keep It Simple, Stupid.
>
>When it comes to deciding on the contents of a standard, let's keep in mind
>that we're working with a relatively new technology. We'll make more
>progress by standardizing proven concepts, and these integrated key
>recovery hacks don't have the operating history that vanilla PGP has. If
>anything, my experience with Guard keying suggests that the proposed
>mechansims aren't enough. The problem has more hair than our sheepdog.
>
>I don't think the protocol standard needs to take a political statement
>about key recovery mechanisms, but it *must* outline the protocol's
>traditional security objectives pretty much the way Tim outlined them. That
>sets the context for a robust protocol that has a successful history.

Thanks for the comments, and the support is nice, too.

As Rick notes, the whole "foobar recovery" (where foobar may be plaintext
messages or keys) technology is untested, besides being dangerous in
various ways.

It represents an escalation of complexity, both for the users and the
developers. (My message is being directed at the OpenPGP folks trying to
figure out what features to support, not to PGP, Inc., which can make its
own decisions about how to spend its engineering and marketing
resources...though I hope they are taking the reactions of many of us to
heart.)

At this stage, where governments of the world are planning to make foobar
recovery mandatory (either GAK or GAP), it's a bad time to launch an
untested and potentially dangerous technology. As others have noted,
Congress is already using PGP's support of message recovery as evidence
that industry can rise to the challenge of providing message recovery for
law enforcement.

OpenPGP needs to stick to basics. And PGP, Inc. needs to get back to basics.

--Tim May


The Feds have shown their hand: they want a ban on domestic cryptography
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May | Crypto Anarchy: encryption, digital money,
ComSec 3DES: 408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets,
Higher Power: 2^2,976,221 | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."
Continue reading on narkive:
Loading...