Cryptography-Digest Digest #584, Volume #12       Fri, 1 Sep 00 06:13:01 EDT

Contents:
  Re: Looking for site regarding RSA patent (Paul Rubin)
  Re: Security in RSA 'e' (Mack)
  Re: QKD and The Space Shuttle (Mike Dicenso)
  Re: Question Regarding Encrypting CD-ROM -RW Disks (Mack)
  Re: test ([EMAIL PROTECTED])
  TEST (Jim Walsh)
  Re: Remark on practical predictability of sequences ("John A. Malley")
  Re: Post-ADK bug blues (Rich Wales)
  Re: Patent, Patent is a nightmare, all software patent shuld not be allowed (Thomas 
Wu)
  Re: Looking for Book Recommendations ([EMAIL PROTECTED])
  Re: 96-bit LFSR needed (Tim Tyler)
  Re: 4x4 s-boxes (Tim Tyler)
  Re: Remark on practical predictability of sequences (Mok-Kong Shen)
  Re: QKD and The Space Shuttle (Guy Macon)
  Re: Patent, Patent is a nightmare, all software patent shuld not be  (Mok-Kong Shen)

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Looking for site regarding RSA patent
Date: 1 Sep 2000 02:08:19 GMT

In article <[EMAIL PROTECTED]>,
Eric Lee Green  <[EMAIL PROTECTED]> wrote:
>It will probably decrease interest in elliptic curve cryptography in many
>circles. The problem with elliptic curve cryptography is that while the field
>as a whole is not patent-encumberered, there are several specific techniques
>within the field that are. So for applications where key length is not a
>problem (i.e., most Internet applications), I expect that interest in ECC will
>decrease, especially since RSA encryption is much easier to understand and
>implement for most mere mortals as vs. crypto/math gods (few really understand
>the math behind ECC, while many understand the math behind RSA).  

ECC is not that hard to implement, even if you don't understand it.
How many people understand the math behind the DSA signature algorithm,
i.e. really know why the formulas work?  But even if you don't know how
they work, you can write code that computes them.  ECC is the same way.


------------------------------

From: [EMAIL PROTECTED] (Mack)
Subject: Re: Security in RSA 'e'
Date: 01 Sep 2000 02:27:09 GMT

>Mack wrote:
>> Specifically it would seem that e and d should be greater than
>> 1/2 the length of N.
>
>Conservative approach. Most people use e = 3, 17, or 65537.
>There are known weaknesses to using e = 3 in some situations,
>but not in the ways that RSA is commonly used.
>
>

With SSL being a notable exception.
But that i more of an implementation
issue.




Mack
Remove njunk123 from name to reply by e-mail

------------------------------

From: Mike Dicenso <[EMAIL PROTECTED]>
Crossposted-To: sci.space.shuttle,talk.politics.crypto
Subject: Re: QKD and The Space Shuttle
Date: Thu, 31 Aug 2000 19:30:29 -0700



On Fri, 1 Sep 2000, John Savard wrote:

> 
> http://www.boeing.com/defense-space/space/ius/
> 
> which will be used to boost Chandra into its proper orbit.

That should be in the past tense, the mission was flown 23 July of last
year. :)
-Mike


------------------------------

From: [EMAIL PROTECTED] (Mack)
Subject: Re: Question Regarding Encrypting CD-ROM -RW Disks
Date: 01 Sep 2000 02:58:33 GMT

>In article <[EMAIL PROTECTED]>,
>zombywuf <[EMAIL PROTECTED]> wrote:
>>**** Post for FREE via your newsreader at post.usenet.com ****
>>
>>Microwaving CDs has a tendancy to release hydrogen cyanide and leaves the
>
>I'd be very interested to know the chemical mechanism for this; it doesn't
>sound very plausible to me.  CDs are made of polycarbonate plastic, which
>doesn't contain any nitrogen at all, much less CN groups.  Where does the
>cyanide come from?
>-- 
>Matthew Skala
>[EMAIL PROTECTED]              I'm recording the boycott industry!
>http://www.islandnet.com/~mskala/

All disks are not made of the same
material I believe there are three or
four different kinds.

If acrylic (polycyanate) is used in any
of them then HCN is a possible by
product of heating.


Mack
Remove njunk123 from name to reply by e-mail

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: test
Date: Fri, 01 Sep 2000 02:59:26 GMT

In article <[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] wrote:
> test
> Love, Jim

You passed.  Please post tests to alt.test

Tom


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: Jim Walsh <[EMAIL PROTECTED]>
Subject: TEST
Date: 1 Sep 2000 03:11:44 GMT
Reply-To: [EMAIL PROTECTED]

test
Love, Jim

"If a state is governed by the principles of reason,
poverty and misery are the subjects of shame.
If a state is not governed by the principles of reason,
riches and honors are the subject of shame."
Confucius, as quoted by Thoreau in Civil Disobedience.

------------------------------

From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Remark on practical predictability of sequences
Date: Thu, 31 Aug 2000 21:24:55 -0700


Mok-Kong Shen wrote:
> 
[ snip ]
> 
> Your work is certainly very interesting. However, I guess
> that your result could also be interpreted this way:
> ElGamal does not provide perfect secrecy (which no
> practical algorithm in fact does). 

It's more like: 

"using successive outputs of an LCG as the random exponential value in
the algorithm weakens the security of the ElGamal cipher."  

The problem of breaking the ElGamal encryption is equivalent to solving
the Diffie-Hellman Problem or the Discrete Logarithm Problem so its
secrecy is as "perfect" as the difficulty of solving those problems. The
Ciphertext-Only Attacks described in the paper exploit mathematical
operations/facts in common to ElGamal and the LCG to reduce the
difficulty of the attack to solving a modular polynomial equation - and
that is easier than solving the Diffie-Hellman or Discrete Logarithm
Problem. 

Hence, enciphering the output of a fast and predictable PRNG (like a
LCG) with a secure cipher (like ElGamal) does not always generate an
unpredictable PRNG output sequence.  Mathematical operations common to
the PRNG and the secure cipher can permit the prediction of the
enciphered sequence without knowledge of the cipher’s secret key or of
the PRNG’s parameters and without "brute-forcing" the secure cipher. 

This is evidence in favor of the original assertion - perhaps PRNGs
employing mathematical operations not in common with the operations
employed by the cipher prove more resistant to cryptanalysis and result
in output sequences "practically" unpredictable.

Two papers inspired the example and the attacks in this analysis:

A. SHAMIR, "On the generation of cryptographically strong pseudorandom
sequences", ACM Transactions on Computer Systems, 1 (1983) 38-44

and 

M. BELLARE, S. GOLDWASSER, D. MICCIANCIO, "Pseudo-Random Number
Generation within Cryptographic Algorithms: The DSS Case", Advances in
Cryptology - Crypto 97 Proceedings, Lecture Notes in Computer Science,
B. Kaliski ed., Springer-Verlag, 1997. 


>In some sense I suppose
> it is also remniscent of the opinion that in multiple
> encryption it is preferable to have adjacent ciphers of
> (widely) different nature.

Yes, it is. 


John A. Malley
[EMAIL PROTECTED]

------------------------------

From: [EMAIL PROTECTED] (Rich Wales)
Subject: Re: Post-ADK bug blues
Date: 1 Sep 2000 05:30:10 -0000

"A. Melon" wrote:

        > The discovery that Mallory can tamper with PGP v4
        > self-signatures to insert ADK's and thus trick
        > certain newer versions of PGP into giving the
        > session key to Mallory is pretty upsetting, . . .

More precisely, certain versions of PGP are honoring ADK info in a
section of a signature packet which "is not part of the signature
proper" (RFC2440, sec. 5.2.3.2).

        > I know the Cyber-Knights Templar have come up with a
        > derivative of PGP 2.6 that allows bigger RSA key sizes.
        > Likewise, the pgpi.org page has links to a variant
        > called Even-Better Privacy v2.7, that allows one to
        > subsitute HAVAL for MD5 as the hash function.

Between a longer encryption key or a stronger hashing function than
what PGP 2.6.3 provides, I'm not sure it really matters that much.

Even though MD5 isn't the best hashing function, my impression is
that it's probably more than adequate for signatures, because fabri-
cating a specific message with the same hash as something someone
else has previously signed is still well-nigh impossible.  So, if
I had to choose one or the other, I suppose I'd probably go for a
longer key.

And although a longer key couldn't hurt, a 2,048-bit RSA key is still
far beyond anyone's ability to crack, even though mathematicians have
been working on the underlying math problem for years.  If anyone
does manage to find a slick, quick way to factor a 2K-bit key, I dare
say that using a 4K-bit key -- or even an 8K-bit key -- probably will
not offer much more protection.

Rich Wales         [EMAIL PROTECTED]         http://www.webcom.com/richw/
PGP 2.6+ key generated 2000-08-26; all previous encryption keys REVOKED.
RSA, 2048 bits, ID 0xFDF8FC65, print 2A67F410 0C740867 3EF13F41 528512FA

------------------------------

From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: Patent, Patent is a nightmare, all software patent shuld not be allowed
Date: 31 Aug 2000 22:51:37 -0700

"Paul Pires" <[EMAIL PROTECTED]> writes:
> The entire patent can be viewed for free or downloaded for
> a modest charge at.
> 
> http://www.patents.ibm.com/
>  Just select patent number search and the number. It's a good
> site and cross referencing the patents cited as prior art, other
> co-inventors or other patents also assigned to the same
> company can sometimes be revealing.
> 
> Other texts could be supplied at the authors discretion but
> the patent stands or falls based on what is in it. i.e. it must teach the
> method claimed. "Extra" material can't help it and isn't real important
> when considering the patents merit other than a better look at the
> authors intent was.
> 
>  >Are there more texts about that patent that one
> > can read? Or are these texts inaccessible to the public?
> > Since the patent apparently has the potential of attacking
> > at the very root of PK applications, if I don't err, we
> > should pay due attention to the issue, I suppose.
> 
> I have to say that I'm with you on this one after a cursory look.
>  It appears:
> 
> 1, obvious and
> 
> 2, Anticipated  according to the prior art,
>  considering the breadth of the claims granted.
> 
> Didn't mean to shock you :-)
> 
> Paul

While we're on the subject of nightmare patents, does anybody care to
look at US Patent #5222140, "Cryptographic method for key agreement
and user authentication"?  It appears to cover protocols where the
server sends its public key to a client, the client encrypts a session
key with that public key, and the server recovers it by decrypting
with its private key.  Sound familiar to anyone?
-- 
Tom Wu                        * finger -l [EMAIL PROTECTED] for PGP key *
 E-mail: [EMAIL PROTECTED]       "Those who would give up their freedoms in
  Phone: (650) 723-1565              exchange for security deserve neither."
   http://www-cs-students.stanford.edu/~tjw/   http://srp.stanford.edu/srp/

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: Looking for Book Recommendations
Date: Fri, 01 Sep 2000 07:47:16 GMT

Hello,

Thanks to everybody, who suggested books on number theory and abstract
algebra.

I've finally decided to go with the following based on comments here,
reviews on amazon and the availablity:

"Elementary Number Theory" by G.A Jones and J.M. Jones
"Abstract Algebra" by Israel N. Herstein
"Elliptic Curves in Cryptography" by G. Seroussi, Nigel P. Smart, Ian
F. Blake
"Implementing Elliptic Curve Cryptography" by Michael Rosing

Anthony Mulcahy


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: 96-bit LFSR needed
Reply-To: [EMAIL PROTECTED]
Date: Fri, 1 Sep 2000 07:42:10 GMT

Mack <[EMAIL PROTECTED]> wrote:

: Half of it is indeed from that
: source.  The other half is from
: Dr. Mike's polynomial program

: I cobbled the two together.
: Dr. mikes determines the
: irreducibility very quickly.

The combination sounds good ;-)

I looked at Scott's program.
It didn't seem to use a large integer library.

It seemed to me that the time taken to factor the
modulus was the primary factor limiting performance.

I liked the LFSR stepping - and the idea of simply
testing all the periods that are factors, though.

Thanks for the reply - I'm happy to hear that
something useful's come out of the code.
-- 
__________  Lotus Artificial Life  http://alife.co.uk/  [EMAIL PROTECTED]
 |im |yler  The Mandala Centre   http://mandala.co.uk/  Namaste.

------------------------------

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: 4x4 s-boxes
Reply-To: [EMAIL PROTECTED]
Date: Fri, 1 Sep 2000 08:41:18 GMT

[EMAIL PROTECTED] wrote:
:   [EMAIL PROTECTED] (Mack) wrote:

:> bent is usually used to refer to functions which have non-linearity
:> which is maximum. They only occur on functions of 2n variables
:> and are not balanced.  You appear to be refering to nearly bent
:> functions.

: Ahem, according to "Perfect nonlinear Sboxes" by Kaisa Nyberg from
: Eurocrypt '91, we have and I quote.

: 2.  Bent Functions

: Let q be a positive integer and denote the set of integers modulo q by
: Zq.  Let "u = e^((2*pi*i)/q)" be the q'th root of unity in C, where i =
: the imaginary number sqrt(-1).  Let f be a function from the set Zn/q
: of n-tuples of integers modulo q to Zq.  Then the Fourier transform of
: u^f is defined as follows

: F(w) = 1/sqrt(q^n) * sum of (x in Zn/q) (u^(f(x) - w.x), for all w in
: Zn/q.

: Definition 2.1:  A function F: Zn/q -> Zq is bent if |F(w)| = 1 for all
: w.

: ---endquote--

: In this case for a 4x4 function we find that "1/sqrt(q^n)" is "1/sqrt
: (2^4)" which is "1/4".  Which means a WT output of '4' times 1/4 gives
: us "1" and we have a bent function.

Since your conclusion is fallacious, there must be an error in your
reasoning - I'll try to track it down.

AFAICS, the quotation you provide states matters correctly - Though I
don't fully understand everything they say.

Then we come to your argument - which I don't follow at all.

You seem to talk about a WT "output" of 4.  The WT outputs an array of
values, which is often converted to a single digit in the form of a
non-linearity figure.

Bent functions have maximum non-linearity.  A non-linearity of 4 is /not/
the maximum possible value for a 4-input boolean function.

The maximum non-linearity of such a function is 6.  This corresponds to a
WT with entries consisting entirely of +/-2.  An example of the LUT of
such a function is: {1 0 0 1 0 1 0 1 0 0 1 1 1 1 1 1}.
4 doesn't appear to come into it.

A bent function is one with maximum non-linearity.

To quote from http://www.io.com/~ritter/GLOSSARY.HTM:

  "[...] all true bent sequences, are not balanced".

I don't see how you can evade this fact.
-- 
__________  Lotus Artificial Life  http://alife.co.uk/  [EMAIL PROTECTED]
 |im |yler  The Mandala Centre   http://mandala.co.uk/  Namaste.

------------------------------

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Remark on practical predictability of sequences
Date: Fri, 01 Sep 2000 11:58:04 +0200



"John A. Malley" wrote:
> 
> Mok-Kong Shen wrote:
> >
> [ snip ]
> >
> > Your work is certainly very interesting. However, I guess
> > that your result could also be interpreted this way:
> > ElGamal does not provide perfect secrecy (which no
> > practical algorithm in fact does).
> 
> It's more like:
> 
> "using successive outputs of an LCG as the random exponential value in
> the algorithm weakens the security of the ElGamal cipher."
> 
> The problem of breaking the ElGamal encryption is equivalent to solving
> the Diffie-Hellman Problem or the Discrete Logarithm Problem so its
> secrecy is as "perfect" as the difficulty of solving those problems. The
> Ciphertext-Only Attacks described in the paper exploit mathematical
> operations/facts in common to ElGamal and the LCG to reduce the
> difficulty of the attack to solving a modular polynomial equation - and
> that is easier than solving the Diffie-Hellman or Discrete Logarithm
> Problem.
> 
> Hence, enciphering the output of a fast and predictable PRNG (like a
> LCG) with a secure cipher (like ElGamal) does not always generate an
> unpredictable PRNG output sequence.  Mathematical operations common to
> the PRNG and the secure cipher can permit the prediction of the
> enciphered sequence without knowledge of the cipher’s secret key or of
> the PRNG’s parameters and without "brute-forcing" the secure cipher.
> 
> This is evidence in favor of the original assertion - perhaps PRNGs
> employing mathematical operations not in common with the operations
> employed by the cipher prove more resistant to cryptanalysis and result
> in output sequences "practically" unpredictable.

As you sentence implied, the 'perfect' you mentioned is 
not 'absolute' but under some assumptions. What I mean by 
perfect secrecy is that defined by Shannon. As far as I 
know, no cipher other than the theoretical (ideal) OTP can 
offer EXACTLY that level of security. (Cf. also the term 
'provable security' in a recent thread about BBS.) So your 
result does confirm that ElGamal as a cipher is not 
absolutely perfect in my humble view.

Another point of practical nature is why one wants to
encipher a stream from a LCPRNG. If one wants to obtain
a stream difficult to predict (and then use it for other
purpose) using fast running LCPRNGs, one can mix a number 
of these and perform diverse means of 'scrambling', 
always bearing in mind that a theoretical unpredictability 
exactly comparable to the ideal OTP is never attainable 
in practice. (For a concrete example of a compound PRNG 
built on top of LCPRNGs in this sense see my web page.) 
If one likes, one can treat such a post-processed output 
from fast generators with an encryption algorithm, in the 
hope of further quality improvement. But one must again 
remember (from principle) that the output may be better 
or even much better but nonetheless never perfect.

I like to stress that the above comments in no way 
diminish the theoretical merits of your paper.

M. K. Shen
==========================
http://home.t-online.de/home/mok-kong.shen

------------------------------

From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: sci.space.shuttle,talk.politics.crypto
Subject: Re: QKD and The Space Shuttle
Date: 01 Sep 2000 09:48:31 GMT


John Savard wrote:
>
>On Wed, 30 Aug 2000 20:53:22 +0100, "Richard Bembridge"
><[EMAIL PROTECTED]> wrote, in part:
>
>>What kind of payloads can the Shuttle handle?
>
>The Space Telescope represented the upper limit.

Above that, you have to send pieces and assemble in orbit, which
gives you a much larger upper limit based on time/expense for
multiple shuttle flights.

>>What is the typical altitude of the Shuttle when in Low Earth Orbit (LEO)?
>
>About 250 miles.

The payload can, of course, be put at any altitute by sending booster
rockets up.  Again, the upper limit is based on time/expense for
multiple shuttle flights.



------------------------------

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Patent, Patent is a nightmare, all software patent shuld not be 
Date: Fri, 01 Sep 2000 12:10:13 +0200



Thomas Wu wrote:
> 
> While we're on the subject of nightmare patents, does anybody care to
> look at US Patent #5222140, "Cryptographic method for key agreement
> and user authentication"?  It appears to cover protocols where the
> server sends its public key to a client, the client encrypts a session
> key with that public key, and the server recovers it by decrypting
> with its private key.  Sound familiar to anyone?

I seems as if most people doing PK today are infringing on
lots and losts of patent rights. I find it very remarkable 
though that up till now nobody has noticed that (neither 
in this group nor in other crypto mailing lists). Would 
those who have expertise in patents or are comparatively 
knowledgeable in such matters kindly do the favour of 
examining the issues and say something practically useful? 
Thanks.

M. K. Shen
=========================
http://home.t-online.de/home/mok-kong.shen

------------------------------


** 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
******************************

Reply via email to