NODE 55bf13d6Re: Security flaws introduced by "other readers" in CMR
Greg Broiles <gbroiles@netbox.com>Thu, 16 Oct 1997 09:48:21 +0800
Tim May <tcmay@got.net> wrote:
>Truly sensitive stuff--stuff about takeovers, foreign production plans, new
>products, etc.--will be encrypted with channels having no nosy security
>guards or Corporate Crypto Compliance Police silently listening in.
>
>Which means we're back to square one. So why does PGP, Inc. bother?
Because they've got customers who will pay for CAKware.
Why will customers pay for it? Same reason the FBI wants GAK, even though
motivated/well-informed crypto users will superencrypt or otherwise bypass
the enforcement mechanisms. If you're the C in CAK or the G in GAK, access
to some data is better than access to no data - and the possibility of
enforcement radically alters the risk/benefit calculus of even intelligent
actors who see their interests as contrary to those of the [C,G].
As Jon Callas confirmed at the recent Cpunks physical meeting, the current
CAK/CAM/whatever system has very weak code re policy enforcement - for
example, it'll allow otherwise forbidden messages to pass through its
filters if even the "--- BEGIN PGP MESSAGE ---" lines are altered or
removed. It won't disassemble tar or zip or uuencode packages, or otherwise
attempt to discover simple attempts to bypass the enforcement mechanisms.
They're not trying to stop determined covert communicators - that's not
their threat model.
--
Greg Broiles | US crypto export control policy in a nutshell:
gbroiles@netbox.com | Export jobs, not crypto.
http://www.io.com/~gbroiles | http://www.parrhesia.com
NODE 3e0299e4Re: Security flaws introduced by "other readers" in CMR
TruthMonger <tm@dev.null>Thu, 16 Oct 1997 16:37:55 +0800
I also know a man in Tucson, Arizona, who installed a $10,000 home
security system and then cut the wire to the alarm bell, because it
was too loud.
I recognize the dangers inherent in PGP's move toward Corporate
Message Recovery, but I also recognize that there will be a thousand
Joe Schmoe's adversely affected by it for every CypherPunk who gets
backdoored as a result of misuse of the technology.
I think that it is admirable that a number of CypherPunks are railing
loudly against something which is more likely to bring other people to
grief, rather than themselves.
I truly believe that PGP has made some serious errors in their
current implementation of Corporate security software, but it is
something that is indeed coming, like it or not, and I have more
confidence that there may be better hope for proper changes in the
package in the future, than I would in the 'Pretty Louis Freeh
Privacy' software company was the first to develop the technology.
My advice? (Thanks for asking...)
1. Help to install/develop the package at companies which are run
by decent humans, and truly have good intentions. Explain the pros
and cons to them, and what you feel are moral areas to consider
before making changes in your suggested modus operandi.
Oh yes...and put in a back door, or some such, so that you may
have a chance to make necessary changes if the situation changes
in the future.
2. Help to install/develop the package at companies which need it
and will get some such program in the future, regardless of the
ethical functionality of the package. Explain your feelings in
regard to the ethics of control versus privacy and try to help
them understand that basic human decency is in their long-term
interest.
Put in *several* back doors, so that you can route around any
damage they cause by putting profits ahead of ethics.
3. Help to install/develop the package at companies which have
the worst of fascist, evil intentions. Don't bother explaining
the ethical issues, as they will only use them as guidelines to
do the opposite.
Put a time-bomb in the son-of-a-bitch which will explode in
a few months time and put them completely out of business.
I have put some type of backdoor in *every* product I have
developed. I have used the backdoor *once*, in order to rescue
a company from their own stupidity.
I did not inform them of my 'fix,' but let them believe that
the system 'fixed itself.' (Right...it happens all the time...)
If I *had* informed them that I had fixed their fuck-up via a
backdoor I had built in, I have no doubt they would have thanked
me profusely for my foresight, and then demanded that I remove
the backdoor.
There was one application I developed that had the potential
to make me a very rich person if I chose to misuse a backdoor
in the future. I had to sit down, recognize the temptation and
my own weakness, and decide if it was still in my client's best
interest if I installed a back door in the product.
The company out-and-out screwed me out of several thousand
dollars at the end of the project, and I am rather proud to
report that I considered and rejected the use of the backdoor
I installed in order to 'enforce' *justice* (and it took less
than a minute to decide it was not worth 'taking the chance' of
being wrong, and therefore a thief--or being 'right' and still
being a thief).
I am proud of the CypherPunks who are speaking their mind, even
if it means aligning themselves against the Holy Grail of privacy
and security.
I believe that we should rail loud and long against those things
which we perceive to be against the interests of the privacy and
security of the individual cogs in the corporate machinery, but
should still promote the interests of a company which is probably
the best horse to back, even if there are no future guarantees.
I also believe that we should search hard and long for ways to
throw a serious fuck into said program, just in case...
I have already found one exploitable weakness in PGP's CMR
implementation, which shall remain my own secret.
Any further exploitable weaknesses I find will be shared with
others, privately.
I wish that Viacrypt had not tied their CMR software to PGP's
reputation, since it is a product based on a different concept,
but I also wish that I had picked different numbers for last
week's million dollar lottery.
I am willing to give Viacrypt time to recognize whether or not
they have compromised ethics to a certain extent, in return for
convenience and market position. I try not to 'Nuke the bastards!'
on a whim, but I am always ready and willing to do so if it
becomes undeniably clear that it is time to take a stand.
I would like to thank those who have spoken out on both sides
of the issue involved, particularly in light of their willingness
to seek and listen to alternative viewpoints. I hate having to
sort through people's righteously held prejudices in order to
get to the fruits of their analytic labors.
The issues involved in Viacrypt's choice of direction and their
chosen implementation of corporate security software is truly a
nadir point in encryption development. It is too important an
issue for any of us to take a predetermined stance in order to
defend our private points of view and predilections.
'Schindler's List' provided an excellent viewpoint of things not
always being what they seem, or not ending up the way they started
out. At the same time, the film may be a bogus representation of
the true facts of life involved in the situation.
A different approach by Schindler may have resulted in a better
or worse resolution to the events, and we shall never know, but I
do believe that the man did the best that he could.
I plan on doing the best I can to further the spread of strong
encryption, regardless of whether or not any particular product
or implementation makes me nervous at a certain stage of its
development.
However, I truly hope that, if I am in error, someone believing
and doing the exact opposite of myself will prevail.
Besides death and taxes, there is one other thing that I think
is undeniably certain...world events are changing at such an
increasingly fast pace that, regardless of the direction the
future takes, it is *not* going to be boring.
TruthMonger
NODE f26b8980Re: Security flaws introduced by "other readers" in CMR
Adam Back <aba@dcs.ex.ac.uk>Thu, 16 Oct 1997 23:43:27 +0800
Greg Broiles <gbroiles@netbox.com> writes:
> Tim May <tcmay@got.net> wrote:
>
> >Truly sensitive stuff--stuff about takeovers, foreign production plans, new
> >products, etc.--will be encrypted with channels having no nosy security
> >guards or Corporate Crypto Compliance Police silently listening in.
> >
> >Which means we're back to square one. So why does PGP, Inc. bother?
>
> Because they've got customers who will pay for CAKware.
I have tried to express this trade off, and to make suggestions of how
to work within this frame work to hinder GAK take up:
(from http://www.dcs.ex.ac.uk/~aba/grdesign/:)
Principle 4: deployment wins. Violating any of principles 1, 2 or 3
whilst still remaining better than GAK-neutral can be justified where
deployment is thereby increased to the extent that the reduced GAK
resistance of the product can be justified by the overall increase in
GAK resistancy in the target jurisdictions. This can be expressed
loosely as the equation: introduced resistancy = deployment x
resistancy rating
Corollary 4: Where a profit function outside the individuals control
interferes with GR maximisation of principle 4, continuing in this
environment may be justifiable where this tactic helps promote global
GAK resistance in the target jursidiction. Examples of novel ways of
making the best of this imposed profit function overlayed on the
solution space of designs may be: attempts to subvert standardisation
processes to make the standards GAK resistant even for GAK neutral
developers, or to code GAK resistant implementations for GR-neutral
employers without informing them of these coding decisions, or to
promote GR implementation and protocol design to contacts in the
cryptographic developer community, or to anonymously release useful
proprietary GR optimisation technology, or to sabotage ergonomics or
reliability functions in implementations of very low GR rated designs.
> Why will customers pay for it? Same reason the FBI wants GAK, even though
> motivated/well-informed crypto users will superencrypt or otherwise bypass
> the enforcement mechanisms. If you're the C in CAK or the G in GAK, access
> to some data is better than access to no data - and the possibility of
> enforcement radically alters the risk/benefit calculus of even intelligent
> actors who see their interests as contrary to those of the [C,G].
I agree.
> As Jon Callas confirmed at the recent Cpunks physical meeting, the current
> CAK/CAM/whatever system has very weak code re policy enforcement - for
> example, it'll allow otherwise forbidden messages to pass through its
> filters if even the "--- BEGIN PGP MESSAGE ---" lines are altered or
> removed. It won't disassemble tar or zip or uuencode packages, or otherwise
> attempt to discover simple attempts to bypass the enforcement mechanisms.
> They're not trying to stop determined covert communicators - that's not
> their threat model.
It is a property of fielded systems that the majority of users will
work within the functionality provided by it. This property can be
used by all 3 sides of the debate. It is a politically neutral
mechanism.
1. It can be used by PGP Inc (who evaluate the tradeoffs between
socially desirable properties and ergonomics and come up with the
belief that CMR optimal solution). They point out (rightly) that the
fact it is possible to easily hack around demonstrates some GAK
resistance. I would argue however that it is not a very great
addition. I have been trying to persuade PGP Inc that it is possible
to implement more highly GAK resistant products within their profit
function and user requirement set using the CDR (corporate data
recovery).
2. It can be used by people such as us who consider different
tradeoffs to be optimal, in that we can field systems which make it so
that the system has to be hacked before it could be used for GAK. The
obfuscation can always be hacked around, almost by definition, but a
large beaurocratic organisation such as a government will find it
difficult logisitically to organise the development of GAK enabling
patches, and deploy these, and to persuade people to apply the
patches.
3. It can be used by people such as perhaps TIS who have cost
functions highly sensitive to not upsetting the government, and
therefore field on behalf of government GAK enabled systems. They can
make it as hard to hack around as they can. The difficulty of hacking
around and the difficulty of widely deploying the cypherpunks
"anti-gak patch for TIS mandatory GAKware v1.0" means that they partly
succeed.
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`