Cryptography-Digest Digest #294, Volume #12      Thu, 27 Jul 00 01:13:01 EDT

Contents:
  Re: "Symmetric" RSA encryption (David A. Wagner)
  Re: "Symmetric" RSA encryption (David A. Wagner)
  Re: how strong is my own encryption? (Shawn Willden)
  Re: AESC-stream cipher (David A. Wagner)
  Re: Re: PGP US Versions Broken,no good?? (Edward A. Falk)
  Re: How is the security of Outlook Express encryption ? (Edward A. Falk)
  Re: microwave cd (Shawn Willden)
  Re: PGP US Versions Broken,no good?? ([EMAIL PROTECTED])
  Re: how strong is my own encryption? (Adam Durana)
  Re: AESC-stream cipher (Jerry Coffin)
  Re: AESC-stream cipher (Jerry Coffin)
  Re: Re: Re: PGP US Versions Broken,no good?? (Chirag Patnaik)
  Re: Elliptic Curves encryption (Jerry Coffin)
  Re: School question for you regulars. (David A Molnar)
  Re: The Purple Cipher (World War II) (wtshaw)

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

From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: "Symmetric" RSA encryption
Date: 26 Jul 2000 17:25:06 -0700

John Myre  <[EMAIL PROTECTED]> wrote:
> "David A. Wagner" wrote:
> > What you have suggested is very similar to the Pohlig-Hellman
> > cipher, which also uses number theory for symmetry crypto.
> 
> Right, but then A and B know the same secret.

Good point.  No, I guess I can't think of any applications of this
property of RSA.  Interesting, though...

> > By the way, it's not such a good idea to encrypt both directions in
> > a related way.
> > directions.  (For instance, if you can convince Bob to encrypt chosen
> > messages for you, you can also read anything encrypted by Bob, with your
> > above idea.)
> 
> Isn't that a basic caveat with RSA?  I mean, that's why we have
> OAEP; and you never sign something exactly as anyone else gave
> it to you.  Assuming Alice and Bob randomize their messages
> appropriately, is there still a difficulty?

You're right.  No, I don't know of any difficulty, as long as both
use OAEP for encryption, and check the format of all decrypted messages.

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

From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: "Symmetric" RSA encryption
Date: 26 Jul 2000 17:34:29 -0700

John Myre  <[EMAIL PROTECTED]> wrote:
> Let n be the modulus, and e and d be the exponents, as
> usual.  The idea is to let one party (say, Alice) know
> n and e, and the other party (Bob) knows n and d, and that
> is it.  In particular, the factors of n are gone.
[...]
> Given randomly selected e's, could some number of pairs of
> people use the same n?

Well, re-using n is dangerous, because if any e_i is leaked somehow to
anyone who knows the corresponding d_i, then that person can factor n
and then learn e_j from d_j or vice versa.  So three conspiring parties
can learn the key of a fourth party.

But, if for some reason you can make the assumption that anyone who
knows e_i won't know the corresponding d_i, and if you assume that all
the e_i's are generated uniformly at random from (Z/phi(n)Z)^*, then I
can't see any attacks.  If you get to see all the e_i's, you can learn
a few of the small prime factors of phi(n), because no e_i will ever be
divisible by any factor of phi(n), but you can't learn anything more,
I think.

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

Subject: Re: how strong is my own encryption?
From: Shawn Willden <[EMAIL PROTECTED]>
Date: 26 Jul 2000 18:41:37 -0600

[EMAIL PROTECTED] (Mark Wooding) writes:

> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > The case of HAC is so singular that I wonder any such exceptions
> > occur in other fields of science. One has therefore to pay
> > particular tribute to Menezes et al. for having made their book
> > freely available, thus furthering studies in crypto whose
> > advancement is apparently contrary to the wish of certain
> > democratic governments.

> Indeed.  The HAC authors have done a fine and worthy thing.  I'm not
> particularly fond of the concept of intellectual property, but I do
> sincerly hope that Menezes, van Oorschot and Vanstone haven't lost
> out too badly as a result of this brave and commendable decision.
> Their book has a proud place on my shelf.

>From where I sit I don't think it has hurt them too badly.  In the
first place, authors of technical books very rarely make anything on
royalties, and HAC is an intensely technical book.  They usually get a
(small) advance that is never fully recouped.  In the second place,
everyone I know (a small sample of a half-dozen or so) who is really
interested in HAC has purchased a copy.

It's even possible that it has help them.  It was after looking things
up in downloaded chapters that I decided I needed to buy a copy.

Shawn.

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

From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: AESC-stream cipher
Date: 26 Jul 2000 17:42:14 -0700

Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
> "David A. Wagner" wrote:
> > In principle, you might be right that it is best to do end-to-end
> > measurements of time to encrypt a large file rather than microbenchmarks
> > of time to encrypt memory repeatedly, but in practice, I disagree.
> >
> > End-to-end measurements can give us a very good understanding of
> > performance in one very limited niche -- e.g., file encryption -- but
> > it is hard to generalize from them to other settings where the cost of
> > I/O may differ dramatically.  Therefore, the most useful measurements
> > seem to be raw encryption time (from memory, caches warm, etc.).
> 
> By this I assume you mean the cipher code and the supporting data structures
> are in cache, but not the text stream.

No, I mean _everything_ in warm cache -- cipher code, S-boxes, plaintext.
In some usages, the plaintext will be in cache.  In others, it won't.  You
learn nothing about the former situation if you measure with cold cache.
In contrast, with warm cache, you learn something about both contexts: it's
fairly easy to get a rough estimate of the cost of a cache miss.

Besides, in most cases, either the text will already be in cache or you
will have saved the next thing to touch it from having to take a bunch of
cache misses; and if it's not that way and performance matters a lot to you,
you can often engineer your system to ensure that it will be that way.

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

From: [EMAIL PROTECTED] (Edward A. Falk)
Crossposted-To: alt.security.pgp
Subject: Re: Re: PGP US Versions Broken,no good??
Date: 27 Jul 2000 00:45:03 GMT

In article <[EMAIL PROTECTED]>,
Chirag Patnaik  <[EMAIL PROTECTED]> wrote:
>On 24 Jul 2000 00:46:54 GMT, Edward A. Falk thought that we should
>read this:
>
>:>  -rw-rw-r--   1 falk       927363 Apr  7  1999 pgp50i-unix-src.tar.gz
>
>
>I compiled the same file and it worked without a hitch.


I'll be damned.  I was able to compile it with gcc too.  I guess
the problem is limited to the Solaris compilers.

I'm curious as to how in the world the gcc compiler thought this

    static const char *license = "\
    PGP for Personal Privacy, Version 5.0 (Unix)\n\
        ...
    copyright and other proprietary notices.  You may not copy the printed\n\
!   materials accompanying the Software Product.
    \n\
    3.      UPGRADES AND SUPPORT.  If this Software Product is labeled as an\n\
        ...


was correct code.  Note the missing "\n\" at the end of the
marked line.


Anyway, I don't think I'd say "without a hitch".  Gcc also gave
me these warnings and more as it compiled:

  bnprime.c:368: warning: declaration of `rand' shadows global declaration
  bngermain.c:51: warning: declaration of `div' shadows global declaration
  pgpFileFIFO.c:204: warning: comparison between signed and unsigned
  pgpMem.c:190: warning: unsigned value >= 0 is always 1
  pgpDebug.c:527: warning: declaration of `pgpaFailed' shadows a parameter
  pgpPrsBin.c:648: warning: `DoRawFlush' defined but not used
  pgpRngRead.c:1645: warning: passing arg 3 of `ringPoolGetName' from incompatible 
pointer type

Many of these are minor, but some send a chill down my spine.  Please
tell me the official version of pgp doesn't ship with these warnings.



This is all kind of beside the point though, since 5.0i is kind of
obsolete.  Where is the best, most current version of pgp for Unix
nowadays?

--
-ed falk, [EMAIL PROTECTED]  See *********************#*************#*
http://www.rahul.net/falk/whatToDo.html    #**************F******!******!*!!****
and read 12 Simple Things You Can Do       ******!***************************#**
to Save the Internet                       **#******#*********!**WW*W**WW****

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

From: [EMAIL PROTECTED] (Edward A. Falk)
Subject: Re: How is the security of Outlook Express encryption ?
Date: 27 Jul 2000 00:49:01 GMT

Damn, I need to get my eyes checked.  For a moment there, it
looked like you said "security" and "Outlook Express" in
the same line.

--
-ed falk, [EMAIL PROTECTED]  See *********************#*************#*
http://www.rahul.net/falk/whatToDo.html    #**************F******!******!*!!****
and read 12 Simple Things You Can Do       ******!***************************#**
to Save the Internet                       **#******#*********!**WW*W**WW****

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

Subject: Re: microwave cd
From: Shawn Willden <[EMAIL PROTECTED]>
Date: 27 Jul 2000 00:58:12 GMT

> Are there any municipal garbage incenerators still operating in the
> USA?  I thought the EPA banned them years ago.  Throw something in
> the garbage now, and it goes into a landfill.

There's one in my area.  It uses the heat from the waste to generate
power as well.  The burn plant is somewhat picky about what kinds of
wastes it burns, yard waste and most household waste are fine, no
liquid wastes, rubber, plastic or painted items are allowed and metal
is disliked (because they have to clean it out).  A few CDs could be
slipped into a pile of grass clippings with no trouble.  Of course,
for the truly paranoid this isn't a good choice because after you dump
the trash into the big concrete trench it's driven by a giant s truly paranoid this 
isn't a good choice because after you dump
the trash into the big concrete trench it's driven by a giant screw
into the building where you lose sight of it for quite a while before
it gets to the flames.

Shawn.

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

From: [EMAIL PROTECTED]
Subject: Re: PGP US Versions Broken,no good??
Crossposted-To: alt.security.pgp
Date: Thu, 27 Jul 2000 02:38:53 GMT

In sci.crypt Edward A. Falk <[EMAIL PROTECTED]> wrote:
> This is all kind of beside the point though, since 5.0i is kind of
> obsolete.  Where is the best, most current version of pgp for Unix
> nowadays?

I personally prefer GNU Privacy Guard (www.gnupg.org). It doesn't
include RSA or IDEA, so it's free from patent issues, and it
interoperates with PGP. It's also less of a soap-opera type
distribution scheme, being outside the US. (No floating out books on
rubber rafts to a scanner in the Cayman Islands :)

The two caveats are that it won't work for PGP RSA keys, and that it
supports more block ciphers, so it's possible to accidently choose one
that a PGP user can't read.

-- 
Matt Gauthier <[EMAIL PROTECTED]>

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

From: Adam Durana <[EMAIL PROTECTED]>
Subject: Re: how strong is my own encryption?
Date: Thu, 27 Jul 2000 02:37:38 GMT

If you are still interested in why this cipher is weak, here is an
example.  Say you encrypt an e-mail with a five character password.  I
know the first five characters of the e-mail to be "hello" and I have
intercepted the e-mail.  Now that I have the ciphertext, plaintext, and
I know how you encrypt your messages.  I can do, C - P = K.  Since your
method of encryption is P + K = C.  So I do that for the first 5 bytes
of the message that I know and I have recovered the whole key and can
read the rest of the message.  There are other ways to break this such
as frequency analysis.  If you are just starting with cryptography
don't let this get you down, everyone starts with something along these
lines.  Good luck.

- Adam


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

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

From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: AESC-stream cipher
Date: Wed, 26 Jul 2000 21:26:17 -0600

In article <8lnkdo$r4h$[EMAIL PROTECTED]>, 
[EMAIL PROTECTED] says...
> In principle, you might be right that it is best to do end-to-end
> measurements of time to encrypt a large file rather than microbenchmarks
> of time to encrypt memory repeatedly, but in practice, I disagree.

I'm not objecting to the basic notion of a micro-benchmark.  I'm 
objecting to taking something that applies in only a microscopic 
situation, and attempting to give it as a measurement of the overall 
performance of the algorithm, especially without any support 
statistics to tell us anything about what they mean (e.g. type and 
speed of processor used).

IOW, I'd consider it perfectly reasonable to use a micro-benchmark 
and give results something like:

        Encrypting 16 bytes of data on a Pentium II takes 
        approximately 35 machine cycles.  This could 
        theoretically lead to an encryption rate of 
        approximately 174 megabytes/second on a 400 MHz 
        Pentium II processor.

I do NOT consider it reasonable, however, to simply state that "the 
speed of the algorithm is 180 MB/s" without any other qualifications, 
which is what happened here.

-- 
    Later,
    Jerry.
 
The universe is a figment of its own imagination.

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

From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: AESC-stream cipher
Date: Wed, 26 Jul 2000 21:26:21 -0600

In article <Pine.OSF.4.05.10007261917370.31901-100000
@sable.ox.ac.uk>, [EMAIL PROTECTED] says...

[ ... ] 

> i think it would be worth writing a test program, identical to the
> encryption program but with the encryption function replaced with a noop.
> then try it.

It would probably be worth the small amount of time for the original 
author to do so.  To do so myself, I'd have to start by rewriting his 
entire program in C or C++ (or something else for which I have a 
compiler) and IMO, that's more trouble than it's worth.

> agreed about the key setup, not quite so sure about the IO. you're
> probably right with your 10% SWAG, but i have been bitten by ropey IO in
> my code (i assume Alex hasn't packed his code with hardcore IO stuff,
> whereas the system copy command probably talks to the file system at a
> fairly low level (?)).

Oddly enough, no.  The built in command took just over 30 seconds to 
copy the file in question.  Using reasonably optimized code, I can 
manage the same thing in just over 13 seconds.  As such, I'm sure I 
could produce a really simple encryption program that was actually 
FASTER than the normal copy command (though it'd still be slower than 
my own copier).

-- 
    Later,
    Jerry.
 
The universe is a figment of its own imagination.

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

From: Chirag Patnaik <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: Re: Re: PGP US Versions Broken,no good??
Date: Thu, 27 Jul 2000 09:28:56 +0530

On 27 Jul 2000 00:45:03 GMT, Edward A. Falk thought that we should
read this:

:>Anyway, I don't think I'd say "without a hitch".  Gcc also gave
:>me these warnings and more as it compiled:


yes, it does show those errors. What I meant without a hitch was, it
went just as it was supposed too. :-)

I screwed again anyhow, when I ran an update script, among other
things it was to install ssh, and horrors of horrors I had 6.5.2 and
now 50i wouldn't install and it is damn painful. I can't get anywhere.
any suggstions as to where and if I can get a binary of the same.

Chirag
-- 
http://india.4mg.com/ The very best of Indian Links.
http://www.chiragpatnaik.com/ A little about Me.
http://www.thehungersite.com/ Click and feed the Hungry.
____________________________________________________________________________
Crib, Because it is your right to do so.

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

From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curves encryption
Date: Wed, 26 Jul 2000 21:54:03 -0600

In article <OsWL$219$GA.279@cpmsnbbsa07>, [EMAIL PROTECTED] says...
> It sure seems to be. OTOH the RSA patent expires soon, and that would
> certainly put it on even ground with ECC, ECC takes much smaller keys, but
> RSA transfers actual data. They really seem to be the best for different
> purposes.

RSA _can_ be used to transfer actual data, but it's MUCH slower than 
most symmetric algorithms, so it's normally used to encrypt a key 
used with a symmetric algorithm.

-- 
    Later,
    Jerry.
 
The universe is a figment of its own imagination.

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

From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: School question for you regulars.
Date: 27 Jul 2000 04:25:39 GMT

The Gorf <[EMAIL PROTECTED]> wrote:
> come from on the job.  As it is, I believe that my best bet is Mathematics
> at the University of Washington, with a alot of side concentration in
> computer science.  That way I will get very solid (and advanced later with a
> Masters) math knowledge, while getting the programming languages that I will
> need to use.  Thanks for all the input guys.

Yes, you need math. Just dive in and take everything you can handle. 
I'm trying to do that. 

One piece of advice I got a long time ago was (paraphrased) "surround
yourself with what you're interested in. See when some of it *speaks to
you*." Been doing that ever since, and it really pays off. 

Sometimes in odd ways. Last term I audited a course in number theory. 
Just recently I noticed that Chevalley's Theorem, which is a statement
about zeroes of polynomials in finite fields, might be applicable to
a problem involving the question "how much does division help in 
evaluating polynomials?" I'm not totally sure that this holds up yet, 
but I wouldn't have the idea without having audited a course which isn't
required or particularly relevant to my computer science major (or,
as it turned out, cryptography for the most part). 

The other piece of advice someone gave me was "take LOTS of statistics" --
and you know, right now I wish I'd listened to him earlier. Especially if
you're at all interested in cryptanalysis.

One thing to keep in mind is that what your degree says isn't that big a
deal. It's what you take and what you learn. I'm a computer science major,
for instance, because I'm interested in eventually implementing these neat
algorithms and protocols. At the same time, I am able to take lots of math
courses. As long as I make graduation requirements, it hardly matters.

-David

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

From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: The Purple Cipher (World War II)
Date: Wed, 26 Jul 2000 22:15:09 -0600

In article <[EMAIL PROTECTED]>, Charles Petersen
<[EMAIL PROTECTED]> wrote:

> i *think* that each wiper has 25 outputs each of which has it's own
> separate wiring. 

The guts of Purple was made from scavenged telephone stepper relays, which
came in standard 10 and 25 position forms, as I remember from equipment
that I had to service, with loud and fairly reliable action at about the
speed of a rotary dial. They had two selector inputs, step and reset.
-- 
Pat B. reminds us that he served in the Nixon Administration for 
six years.  How can he be proud of that? 

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


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