Cryptography-Digest Digest #593, Volume #9 Tue, 25 May 99 16:13:03 EDT
Contents:
Re: Why would a hacker reveal that he has broken a code? (John Savard)
Re: Biprime Cryptography, Part II (kurt wismer)
Re: Why would a hacker reveal that he has broken a code? (wtshaw)
Oriental Language Based Enryption ("Markku J. Saarelainen")
Re: DSA (Digital Signature Standard) and the Schnorr Patents (Vin McLellan)
Re: HushMail -- Free Secure Email ([EMAIL PROTECTED])
Re: Crypto export limits ruled unconstitutional (AllanW)
Re: HushMail -- Free Secure Email (John Kennedy)
Re: HushMail -- Free Secure Email ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Why would a hacker reveal that he has broken a code?
Date: Tue, 25 May 1999 18:07:20 GMT
"Jean Marc Dieu" <[EMAIL PROTECTED]> wrote, in part:
>Let's say a hacker breaks 3DES.
>What would make him declare to everyone his "discovery"?
Well, as others are noting, the number of honest people working in
this field exceeds in number and qualifications those who are trying
to break into communications for dishonest purposes.
It isn't likely that a hacker will be the first one to break 3DES.
>So, even if an algorithm has been proven empirically "good", we have no
>evidence that it hasn't been cracked, is that correct?
We have evidence that it can't be cracked by a certain group of people
with a certain level of expertise.
Hence, we _do_ have evidence that a lone hacker hasn't cracked it yet
- and evidence that the NSA hadn't cracked it, say, 20 years ago. What
we don't have is evidence that those posessing greater skills and
resources - the NSA today, or hackers 20 years in the future using
published discoveries and much faster computers - can crack a cipher
that seems good today.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: kurt wismer <[EMAIL PROTECTED]>
Subject: Re: Biprime Cryptography, Part II
Date: Tue, 25 May 1999 19:09:35 GMT
wtshaw wrote:
> <[EMAIL PROTECTED]> wrote:
> > another possibility might be to describe them as 2-key systems, though
> > that would actually be inventing a new term rather than using ones like
> > symmetric and asymmetric algorithms which already enjoy some use in the
> > community... (don't shoot the messenger)
>
> There are many possible algorithms that use multiple necessary keys. The
> public-private set of keys suggests strange possible names like
> Complementary Keypair Encryption.
well, that one is pretty good... and is more descriptive than
asymmetric, certainly... it does still have the above mentioned problem
that it isn't already currently in use, though...
--
"close your eyes and bow your head
i need a little sympathy
cause fear is strong and love's for
everyone who isn't me"
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Why would a hacker reveal that he has broken a code?
Date: Tue, 25 May 1999 11:40:59 -0600
In article <7icg2t$idr$[EMAIL PROTECTED]>, "Jean Marc Dieu"
<[EMAIL PROTECTED]> wrote:
> I see that you guys in sci.crypt have a nice sense of humour.
> Thanks for those who answered my (stupid I guess) question. ;-D
It's not a dumb question at all, guess you stumbled into a smart one...try
again?
--
Weathermen prosphesize and insurance companies predict, while both pretend to be doing
the other to get an audience.
------------------------------
From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Subject: Oriental Language Based Enryption
Date: Tue, 25 May 1999 14:30:47 -0700
I would be interested in learning a little more about some Oriental
language based encryption processes and systems. If anybody has any
information about this, please feel free to let me know .... Cheers !
Markku
------------------------------
From: Vin McLellan <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: DSA (Digital Signature Standard) and the Schnorr Patents
Date: Tue, 25 May 1999 14:01:35 -0300
Vin McLellan <The Privacy Guild> wrote:
> >...Bruce Schneier, who studied and wrote about the DSS patent issues
> >in Applied Crypto, certainly didn't glibly dismiss Schnorr's claims
> >as some have here.
Paul Rubin <[EMAIL PROTECTED]> referred to the Scriptures and
offered a quote in rebuttal:
.> "In my opinion, this finally puts to rest any patent dispute
between
.> Schnorr[1398] and DSA[897]: DSA is not a derivative of Schnorr, nor
.> even of ElGamal. All three are examples of this general
construction,
.> and this general construction is unpatented."
.> --Applied Cryptography (2nd ed.), p. 498.
(The "this" in the Schneier quote refers to what Bruce
described as the new and "remarkable" research on "Meta-El Gamal"
signature schemes published by Horster, Peterson and Mitchels in 1994
and '95. They argued that the Schnorr, El Gamal, and Kravitz's digital
signature schemes had a common antecedent in an unpatented general
construction they had discovered.)
What I was recalling was Schneier's discussion of the DSS
patent issues a few pages earler where, whatever his own opinion of
the Schnorr patents's scope, he discussed the potential and
then-current impact of the Schnorr challenge in terms that were
neither dismissive nor glib.
"Even if the U.S. courts rule in favor of the DSA, it is unclear what
other courts around the world would do. Is an international company
going to adopt a standard that may be legal in some countries but
infringers on a patent in others. This issue will take time to
resolve; at the time of this writing it isn't even resolved in the
United States." Quod vide: p. 493.
I've also read French and German analyses of the DSA which
seem to differ with our Sage from Minneapolis. Prof. Schnorr himself
-- a major force in European cryptography -- remains unrepentent and
confident of his position even today.
My point was far more pedestrian.
I merely assert that, in the early 1990s, the credible threat
of the Schnorr patents (in the hands of RSADSI) was a significant
factor in blocking, then, the widespread adoption of the DSS.
I also argue that this timely and successful use of the
Schnorr threat dealt a major blow to the NSA's strategy of using the
royalty-free DSS to dissuade major American multinationals from making
a commitment to RSA for digital signature functions and key-exchange.
Overseas, it was not even an issue. I think the British
banking network, for example, had already standardized on RSAPKC for
both digital signatures and key exchange.
It was only the NSA's virtally complete control over the US
standards orgs that had allowed the Agency to block the formal
standardization of public key cryptography in the US. (Where that
control was beginning to slip, as in the ANSI vote yea on the question
of whether the ISO should establish DES as an international standard,
the US spooks could and did resort to funny business in Geneva, where
yea votes were miscounted as nay, to get their way. The ISO then
decided that it would avoid further corruption and refused to consider
any standards in cryptography.)
In the US, for GAKed Capstone to have a chance to present
itself as a viable alternative to commercialized PKC, the NSA's
strategy was predicated on the general acceptance of royalty-free DSS
as a viable commercial standard.
Again, the DSS was not intended to serve alone, it was
expected and intended to be used with hierarchial key-management for
network efficiency and confidentiality. A digital sig scheme has
value in itself, but it can only serve its modern function if it can
be shared, transmitted, and securely validated at a remote site.
Neither RSA nor D-H were then allowed on the standards agenda
-- but right after the Escrowed Key Standard (EES) became FIPS 185, it
mysteriously appeared at the top of the agenda for Blake Greenley's
ANSI standards subcommittee. (I recall it took an overt revolt by the
industry reps, who argued that such an imposition was far beyond
Greenley's authority and totally at variance with ANSI procedures, to
force it off the agenda.)
I noted earlier that the DSS was a crucial element in the
NSA's strategy to inhibit vendor adoption and user access to
confidentiality through public key cryptography.
Roger Schlafly <[EMAIL PROTECTED]> found this an
outrageous suggestion:
>This is ridiculous. It is like saying that the Apple Macintosh was
>intended to thwart desktop computing because DOS was already widely >accepted. DSA
>was, and is, an alternative. Those who were happily using >RSA continued to do so.
>Govt users were supposed to use DSS, but I don't >think that was ever enforced.
>(There are govt agencies using RSA today.)
Very very few. The FIPS proscriptions, in the federal
bureaucracy, are the Law of the Land, and they have been rigidly
enforced by OMB and policed by NIST and the NSA. Waivers have been
few, rare, and mostly very recent.
[Even today -- a year after the NSA gave up on Fortezza
(because, said the Agency internally, it couldn't get secure
workstations for network management)-- it still takes a formal Waiver
Proclamation by the Director or CIO of a federal agency to allow any
federal entity to escape the DSS FIPS. The EPA announced such a FIPS
140 Waiver a week ago, so that the EPA could use the RSAPKC in Lotus
Notes. (See: <http://jya.com/epa051099.txt>)
[With few exceptions, commercial products which rely upon
RSAPKC have been completely shut out of the federal agencies by FIPS
185 and FIPS 186 -- which left the federal agencies almost totally
isolated from the COTS security products of the industrial
mainstream.
[If DoD Secretary Cohen, who had led the drive to reform
federal MIS procurement while he was in the Senate, had not taken over
the US Defense hierarchy, maybe the NSA would never have been forced
to come to terms with the market realities. In practical terms, the
federal DSS/ESS procurement requirements have had a devastating
impact on the commercial infosec options available to federal
agencies, and I suggest they are to blame for much of the
vulnerability common in US federal information systems today. The
crypto FIPS were designed to reshape the market. They were not
designed to improve the infosec of US federal agencies. The civil US
agencies were only one more set of sacrifices in the NSA's campaign to
maintain its capabilities. )
>>You can get key management with DSA just as easily as you can with >>RSA. It is
>called Diffie-Hellman.
You can indeed, but with your obsession with RSA, you miss
the point. The NSA's goal was to block software PKC. Software PKC for
efficient key management, not RSA, was the issue. The NSA had made
it clear that it was not going to permit D-H for key management to go
though the ANSI standards process either. COTS D-H for key
management was not an option for the feds after FIPS 185.
I remarked earlier:
.> [...] no one can deny they have effectively stalled widespread use
of
.> strong crypto for a fifteen years, and will for a bit longer.
Dr. Schafly responded:
>>They have stalled the export of strong crypto, but beyond that, the
>>influence has been minor. Strong crypto is completely unregulated
>>within the US. In some ways, the NSA has promoted the use of
>>crypto -- its endorsement of DES, DSA, SHA-1, etc were all
>>positive, IMO.
Wow. Minor influence.
We see things very differently.
The contest has always been over whether the NSA could block
efficient and effective crypto for confidentiality from being
integrated into mass market commercial and business products.
The typical big US computer or communications vendor probably
gets half of its revenue from overseas customers. US export regs on
useful crypto required products from those companies to be shipped
overseas only with woefully inadequate security functionality.
Interoperably concerns, among other things, meant that it was very
difficult to ship weak crypto overseas and expect strong crypto to be
used in the US market -- although the dollar cost of shoddy crypto
and strong crypto is about the same.
Effectively export regs paced the whole market in this
industry. And the inherently unpredicable and purposely subjective
way in which the NSA granted export licenses left US firms very
susceptable to backroom deals and secret concessions, corrupting the
product design and development process with a malovent interest which
had nothing to do with providing a quality product at a competitive
price.
Since non-Americans are as endowed with both pride and
intelligence as Americans are, I suspect the ramifications of this
system have profoundly damaged the confidence and trust with which
overseas customers view US products and vendors. And will for years
to come.
<Dr. Schafly's doubtless eridite analysis of Claus Schnorr's US patent
elided>
We could go round and round on this, but to little avail. I
think Schneier's comments, which I quote above, make it clear that at
least some people believed that the Schnorr patents were indeed a
credible threat to the DSA.
Dr. Schafly's interpretation of the Schnorr patent seems to
overlook the fact that in the European and Japanese patents, the
patent claims are not dependent in the way they are in the US
patent.
Prof. Schnorr -- who was apparently poorly served by a
European patent attorney unfamilar with the required format for US
patent applications -- concisely summed up the difference between his
EC and US patents in a post to the Coderpunks mailing list last year.
Students of patent law like Dr. Schafly and others may appreciate the
ramifications better than I do.
*>At two instances the claim in the US patent reads: "A method
according
*>to the preceding claim...." while the European patent says: "A
method
*>according to one of the preceding claims...."
*> A formulation "according to one of the preceding claims" is not
*>acceptable for US patents.
Suerte,
_Vin
========
"Cryptography is like literacy in the Dark Ages. Infinitely potent,
for good and ill... yet basically an intellectual construct, an idea,
which by its nature will resist efforts to restrict it to bureaucrats
and others who deem only themselves worthy of such Privilege."
_A Thinking Man's Creed for Crypto _vbm
* Vin McLellan + The Privacy Guild + <[EMAIL PROTECTED]> *
53 Nichols St., Chelsea, MA 02150 USA <617> 884-5548
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: HushMail -- Free Secure Email
Date: Tue, 25 May 1999 19:36:36 GMT
Nope, we aren't affiliated with any other company. We are an entity
unto ourselves.
Team Hush
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Is HushMail realated to a New Zealand Product called InvisiMail?
>
> Terry Ritter wrote:
> >
> > On Fri, 21 May 1999 18:43:49 -0700, in
<[EMAIL PROTECTED]>,
> > in sci.crypt Chem-R-Us <[EMAIL PROTECTED]> wrote:
> >
> > >Terry Ritter wrote:
> > >>
> > >> If this ends up being practical, it could obsolete PGP in many
cases,
> > >> and might change the practical situation for cryptography more
than
> > >> any court decision.
> > >
> > >Hmm... Requires Java. OK, I can live with that.
> > >
> > >Hmm... Requires Javascript. Not real excited about that. AT ALL...
> > >Turning on Javascript just to send encrypted email to other
hushmail
> > >people is not my idea of simple and easy, and certainly not secure
> > >(from an machine security view). Leaving my browser Javascript
> > >enabled all the time is a definite security NO-NO!!
> > >
> > >For the windoze weenies, it's just another false sense of security
> > >product. For serious Unix people, it's just more crap.
> > >
> > >Mixmaster remailers. Now there's some email security.
> > >
> > >My $0.02
> > >
> > >--
> > >Chem-R-Us
> >
> > HushMail requires JavaScript? Really?
> >
> > OK, I tried it: I turned off JavaScript in my Netscape 4.5, closed
> > all copies, restarted the program, checked that JavaScript was off,
> > and went back to HushMail. Everything came up fine. I entered my
> > user ID, then my passphrase, then selected my test email and read
it.
> >
> > As far as I can see, everything works fine *without* JavaScript.
> >
> > I then went back through these pages looking at source. Their main
> > page does have a JavaScript routine, which appears to be checking
for
> > MSIE version, since the system will not work on early browsers.
That
> > routine may not need to execute at all.
> >
> > So we see that having JavaScript off is *not* a problem for *my*
poor
> > little Win95 system. But I don't know, maybe it *is* a problem for
> > "serious Unix people" and their systems which are so much more
capable
> > than mine.
> >
> > ---
> > Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
> > Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
> > Free Encrypted Email www.hushmail.com [EMAIL PROTECTED]
>
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: AllanW <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Crypto export limits ruled unconstitutional
Date: Tue, 25 May 1999 19:44:29 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> AllanW wrote:
> >
>
> > The demonstration is more nonsensical than you seem to realize.
> > That translation program would itself be an encryption program!
> > Somehow I doubt that there is any special protection for
> > encryption programs which are used only to encrypt other
> > encryption programs.
>
> The main issue is export. The point is whether the English text is
> exportable. There is no problem of using the translation program
> even if it is regarded as an encryption program. (You are allowed
> to use crypto software of any strength in US. You needn't tell
> the authority that the text is from using the software.) If a
> program can translate any C program to English and back then
> it is a general software, just like software that translates
> programs written in one programming language to another. Is a
> compiler that translates C to assembler an encryption program?
But the translation program isn't much use unless there is a
way to translate it back into C code again. I assumed that this
meant that the translation program itself must also be exported.
But now I realize the folly in this. The translation program
really *IS* simple enough to describe the algorithm. All that's
needed, then, is a "white paper" describing how the translation
program works, along with a table listing all the pairs of C
code and corresponding translation.
CHANGING THE SUBJECT slightly, I wonder about a different type
of C-to-English translation program. The first kind of
translation results in pseudo-English: It uses familiar English
words and syntax, but has no meaning. The second type would
genuinely attempt to describe the algorithm embedded in a C or C++
program, although it would do so in precise ways that might be
easily translated back into C or C++
For instance, the second type of c-to-English would translate
this:
void TimesTable() {
int i, j;
for (i=1; i<=12; ++i)
{
/* Inner Loop */
for (j=1; j<=12; ++j)
{
printf("%3i", i*j);
}
printf("\n"); /* Go to next line */
}
} /* TimesTable */
into this:
This is subroutine TimesTable, which takes no arguments and
returns no value.
There are two local integers. "i" is not initialized. "j" is
not initialized.
Begin loop #1 where "i" is initialized to 1. Continue
while "i" is less than or equal to 12. Each time through
the loop, increment "i".
By the way: "Inner Loop".
Begin loop #2 where "j" is initialized to 1. Continue
while "j" is less than or equal to 12. Each time through
the loop, increment "j".
Write to standard output. The format specifier is "%3i".
The first expression is "i*j".
End loop #2.
Use format specifier "\n".
By the way: "Go to next line".
Write to standard output. The format specifier is "\n".
End loop #1.
End of subroutine TimesTable.
By the way: "TimesTable".
--
[EMAIL PROTECTED] is a "Spam Magnet" -- never read.
Please reply in newsgroups only, sorry.
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: John Kennedy <[EMAIL PROTECTED]>
Subject: Re: HushMail -- Free Secure Email
Date: Tue, 25 May 1999 19:31:01 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> > >If so, is there any way to automate that process?
> >
> > I would think that's possible, but I see no evidence that it's been
> > implemented in this case yet.
>
> If HushMail's aplet started doing bad things while pretending to do
good things, that would make it a Trojan of
> sorts. In which case, one's anti-virus software ought to pick it up
during/just after download - given suitable
> updates of course!?
Such updates will only occur after messages have been compromised, maybe
many messages, maybe your messages.
No, to be safe you need an automated way to verify the applet is good,
instead trying to catch bad applets after the fact.
Unfortunately the only ways I can think of to do that involve persistent
data and software on the client side, which negates one of the potential
advantages of a hushmail type system. But it seems to me that any method
of cerifying that the applet is good must involve testing it
with/against trusted software/data in your possesion that you've already
certified.
--
-- John Kennedy Best Anarchy Links->|
David Friedman http://www.best.com/~ddfr/ <-|
Niels Buhl http://www.math.ku.dk/~buhl/ <-|
Billy Beck http://www.mindspring.com/~wjb3/promise.html <-|
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: HushMail -- Free Secure Email
Date: Tue, 25 May 1999 19:56:25 GMT
We are not affiliated with any other company.
Team Hush
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Ritter) wrote:
>
> On Sat, 22 May 1999 08:59:42 -0400, in <[EMAIL PROTECTED]>,
> in sci.crypt [EMAIL PROTECTED] wrote:
>
> >Is HushMail realated to a New Zealand Product called InvisiMail?
>
> I have no idea. The only things I know about HushMail I got from
> their pages or the recent CNET article.
>
> ---
> Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
> Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
> Free Encrypted Email www.hushmail.com [EMAIL PROTECTED]
>
>
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
