Cryptography-Digest Digest #486, Volume #9        Sat, 1 May 99 05:13:04 EDT

Contents:
  Re: Factoring breakthrough? (John Savard)
  Re: Factoring breakthrough? (Jim Gillogly)
  Re: Deadly threats (John Savard)
  Re: AES (John Savard)
  Re: Cryptanalysis ("Douglas A. Gwyn")
  Re: Factoring breakthrough? ("Tony T. Warnock")
  Re: Algorithms where encryption=decryption? (John Savard)
  Re: Weakness Found in Alternative Signature Format (David Hamilton)
  Re: Thought question:  why do public ciphers use only simple ops like shift and XOR? 
(Bryan G. Olson; CMSC (G))
  A question about encryption. ("Dan")
  Re: Deadly threats (wtshaw)
  Re: AES (DJohn37050)
  Re: Predicting calculator pseudo-random numbers (Piso Mojado)
  Re: UBE98 Vendor Admission ("Jay")
  Re: mcrypt (Nathan Kennedy)
  Re: Algorithms where encryption=decryption? (Wei Dai)
  Re: Extreme lossy text compression ("John A. Limpert")

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

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Factoring breakthrough?
Date: Fri, 30 Apr 1999 20:29:35 GMT

Jim Gillogly <[EMAIL PROTECTED]> wrote, in part:

>The world wonders.

Now, now. It's dangerous saying that in a cryptographic context. You never
know when you'll make somebody so upset, he'll miss his opportunity to sink
a battleship...

John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html

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

From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Factoring breakthrough?
Date: Fri, 30 Apr 1999 14:15:49 -0700

John Savard wrote:
> 
> Jim Gillogly <[EMAIL PROTECTED]> wrote, in part:
> 
> >The world wonders.
> 
> Now, now. It's dangerous saying that in a cryptographic context. You never
> know when you'll make somebody so upset, he'll miss his opportunity to sink
> a battleship...

Right-o.  That was an intentional reference, of course.

Now I'll go back to musing about Shamir exposing pixel-represented primes
through a stack of hundreds of films.

Hurm... at least we don't have to wait as long as for The Phantom Menace.
-- 
        Jim Gillogly
        Trewesday, 9 Thrimidge S.R. 1999, 20:56
        12.19.6.2.14, 10 Ix 2 Uo, Ninth Lord of Night

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

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Deadly threats
Date: Fri, 30 Apr 1999 21:25:04 GMT

"hapticz" <[EMAIL PROTECTED]> wrote, in part:

>if I continue to send deadly physical threats to high government officials
>in encrypted form without the keys, am i liable to be prosecuted?

At least under anti-spam laws, if nothing else...

John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html

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

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: AES
Date: Fri, 30 Apr 1999 21:27:09 GMT

"Anthony King Ho" <[EMAIL PROTECTED]> wrote, in part:

>There is sometimes wonder comes cross my mind why the AES is necessary.  I
>thought security is not based on the algorithm itself, key length can be
>increased to increase security, and algorithm such as Triple-DES is proven
>to be very secure.

1) Security IS based on the algorithm itself, first and foremost. If the
algorithm is poor, even if it has a very long key, it can be easily broken.

2) Even though Triple-DES is _believed_ to be secure, it is less efficient
than a single application of a cipher specifically designed to operate with
a larger key would be.

John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Cryptanalysis
Date: Fri, 23 Apr 1999 23:12:42 GMT

Casey Sybrandy wrote:
> Does anybody know where I can find some good papers on cryptanalysis
> in it's many forms?

In addition to Savard's suggestions, since you didn't specify that
the papers had to be on line, I'd suggest the Military
Cryptanalystics books (should be pointers in the sci.crypt FAQ).
While, due to their age, these don't explain more recent technical
methods, they do explain many important aspects of cryptanalysis
in general, as well as techniques that are useful against even
modern cryptosystems.

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

From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Factoring breakthrough?
Date: Fri, 30 Apr 1999 15:29:40 -0600
Reply-To: [EMAIL PROTECTED]

JCA wrote:

Bob Silverman wrote:

> > Don't speculate.  Wait until Tuesday and you will know.
> >
> > And your guess is grossly wrong.  The result is NOT a new algorithm.
> >
>     Damn I hate this uncertainty! Can't you give us a hint?

Shamir did the work. Let him announce it as he wishes. (With trumpets and
drums if wanted.)

Have a nice weekend.

Tony


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

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Algorithms where encryption=decryption?
Date: Fri, 30 Apr 1999 22:37:27 GMT

Emmanuel BRESSON <[EMAIL PROTECTED]> wrote, in part:

>Anne Veling wrote:

>> Or f(x)=1/x (not so useful for encryption)

>Why not ??? It works perfectly (computing modulo n, of course)

Even if n is secret, it wouldn't be terribly secure by itself...

John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html

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

From: [EMAIL PROTECTED] (David Hamilton)
Crossposted-To: alt.security.pgp,comp.security.misc,comp.security.pgp.discuss
Subject: Re: Weakness Found in Alternative Signature Format
Date: Fri, 30 Apr 1999 19:03:03 GMT

=====BEGIN PGP SIGNED MESSAGE=====

Jim Gillogly <[EMAIL PROTECTED]> wrote:

(snip)

>If we also assume Moore's Law will hold, we can go another bit deeper
>every eighteen months based solely on increased CPU horsepower, or two
>bits in three years.  Since 56-bit encryption is crackable in about
>two days on average for $0.25M, a similar expenditure would buy a
>128-bit crack in about a century.

Back in May 1997 Jim, I started a thread called 'IDEA Crackable Comparatively
Soon??' in alt.security.pgp, comp.security.pgp.discuss and sci.crypt. I
innocently assumed that Moore's Law held for all time and, after doing some
sums, I said 'I would guess (!) that a single IDEA encrypted message will
take 4 months or less to crack in 40-100 years from now.'

And I got well and truly dusted off (but it didn't hurt). My summary posting
of points made by others included: 'Bill Unruh and Paul Allen have
demonstrated/stated that Moore's Law doesn't hold indefinitely. My
understanding is that Paul thinks Moore's Law may hold for a maximum of 20
years leading to processors that will then be (for the very best case) 10,000
times as powerful as those of today.'  

> Naturally we can't assume it will
>hold up past where we see physical laws kicking in, but it's held up
>a lot longer than it seemed like it would a decade ago.

Seems reasonable to me. (I'm looking nervously over my shoulder as I type
this in case Bill/Paul are watching.)

Regards.


David Hamilton.  Only I give the right to read what I write and PGP allows me
                           to make that choice. Use PGP now.
I have revoked 2048 bit RSA key ID 0x40F703B9. Please do not use. Do use:-
2048bit rsa ID=0xFA412179  Fp=08DE A9CB D8D8 B282 FA14 58F6 69CE D32D
4096bit dh ID=0xA07AEA5E Fp=28BA 9E4C CA47 09C3 7B8A CE14 36F3 3560 A07A EA5E
Both keys dated 1998/04/08 with sole UserID=<[EMAIL PROTECTED]>
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: Signed with 2048 bit RSA key

iQEVAwUBNyn6qco1RmX6QSF5AQH+JQf/TZtMS6KVuUIGb+QxIeyZWQkvE2IdOfhE
3q3ezyGYZR2nc4xEekGd45b3Ahb0TY8icvLCFKtZS0nf1dLrvkoyFplfRX+X3Jxs
wAU4CmrZoXRr6Nm689/Qo2rptsmt65zEallcgSJZ1gu1V7SVaKbMauQ/VOLlG2in
blARKf4bcg2SK5opIhiFKr8sK+jmZrT1jF4yRYomX5RpGElJ9ubuZ992PAOqqgiA
L2ntIL80N2EaWH/7xj7ZYqRWtu72IV+oD7Z1x9oBYeFfUfZv7kA4ItbL2sJYUEa3
wq3qdCk7b6/tJVgThatUTq4pC74a1Ft3lXA30oMQtCDJfWZ/3vCaig==
=bomL
=====END PGP SIGNATURE=====

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

From: [EMAIL PROTECTED] (Bryan G. Olson; CMSC (G))
Subject: Re: Thought question:  why do public ciphers use only simple ops like shift 
and XOR?
Date: 25 Apr 1999 10:58:07 GMT

John Savard ([EMAIL PROTECTED]) wrote:
: [EMAIL PROTECTED] (Bryan G. Olson; CMSC (G)) wrote, in part:

: >This impression of the academic crypto community as a closed
: >club that ignores the work of outsiders is flat out false.  
: >Consider power and timing analysis - the entire area came
: >from the crypto left-field and was pioneered by a recent grad 
: >with a B.A. in biology.  The work was good, so now he's one 
: >of those respected cryptologists.  The various attacks I've 
: >heard on academics are invariably by those whose work is 
: >simply not of the same caliber.

: I have every respect for the advanced work done by people such as Eli Biham
: or David Wagner. And you're absolutely right that cryptography, like many
: other fields, has its cranks and quacks.

: However, I don't think it's appropriate to automatically conclude that
: everyone who expresses concern about the way in which the public
: cryptography field is going is necessarily a crank. For example, if even a
: layperson looks at DES, or IDEA, or SERPENT, and expresses the opinion that
: these designs all seem too regular, too repetitious, so that some form of
: analysis at least seems like it may be someday possible - well, if that is
: such a silly notion, what are you going to say to the people who designed
: MARS, who happen to be the among the well-qualified?

Quite right, but as I understood Mr. Ritter's statements, he's
deriding the crypto establishment for ignoring the work of
outsiders.  My counter is not the crypto community is right to 
generally ignore outsiders, but that in fact they do no such 
thing.

: >For an example of an idea the crypto community has ignored
: >because it is truly dreadful:

: >[...]
: >: And in this way we can have hundreds or thousands of different
: >: ciphers, with more on the way all the time.  That means that we can
: >: divide the worth of our information into many different ciphers, so
: >: that if any one fails, only a fraction of messages are exposed.

: >Absurdly naive.  In any real project or real enterprise, the 
: >same information is carried by many, many messages.  The degree
: >of protection of any piece of intelligence is that of the
: >weakest of the systems carrying it.

: While that is true, that just means that, for internal encryption in an
: organization, a method should not be used that allows employees to protect
: company data with ciphers their employer does not trust.

I agree it means that, but certainly not that it "just means" that.
Specifically, it should guide those employers in deciding how many
ciphers to designate as trusted.

[...]
: 'Dreadful' is not the same as 'not everywhere applicable'.

True, but I'm saying that in _all_ the real projects or enterprises
I know of, an attacker can gain most of the intelligence value in
the message traffic by compromising only a small percentage of the 
messages.  Are there projects in which documents do not go through
many revisions?  In which everyone works with a mutually exclusive
subset of the information?


There is a situation worse than having all one's eggs in one basket.
The problem with one basket is that there exists a potential failure
that would be catastrophic.  What's worse is a system in which any
one of many possible failures would be catastrophic.  If one accepts
that in realistic applications of cryptography the same intelligence
is available from many messages, then choosing from a thousand 
ciphers for each message moves us from one potential catastrophic 
failure to many potential catastrophic failures.


--Bryan





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

From: "Dan" <[EMAIL PROTECTED]>
Subject: A question about encryption.
Date: Sun, 25 Apr 1999 07:11:01 -0400

Hello all,

I am relatively new to the world of encryption so forgive me if this
question is simplistic.

If an encryption scheme encrypts characters in an 8 by 8 configuration like:

(input)    ABCDEFGHIJKLMNOPQRSTUVWXYZ
(output) 123456781234567812345678YZ  (numbers represent encrypted char)

In other words the input string is encrypted in 8 character blocks.

If a character is changes in the encrypted string within any 8 character
block only the characters in the same block are affected in the output.

(input)    1234567812X4567812345678YZ
(output)  ABCDEFGHXXXXXXXXQRSTUVWXYZ

If a string is less than 4 characters long the string is not encrypted, or
if a string is longer than a factor of 8 by 3 characters or less the excess
characters are not encrypted (4 to 8 characters over a factor of 8 are).

What type of cypher is this?

Thanks,

Dan [EMAIL PROTECTED]







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

From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Deadly threats
Date: Fri, 30 Apr 1999 17:39:01 -0600

In article <Oh0AgOwk#GA.255@cpmsnbbsa05>, "hapticz"
<[EMAIL PROTECTED]> wrote:

> if I continue to send deadly physical threats to high government officials
> in encrypted form without the keys, am i liable to be prosecuted?
> 
Best not to participate in such *momments of affirmation* with yourself to
begin with.  Now write, "Anarachy ain't necessarity pretty,"   1000 times
with a crayola, and then, kindly shred the results.

Best advice is not to badger the badger on too private a set of terms;
wait until a crowd has formed before pretending to do so.  On the chance
that your encryption is more trivial than you think it is, better not
really put your head in a noose.
-- 
If you think you are beaten, you are.
If you thing you dare not, you don't.

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

From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: AES
Date: 1 May 1999 02:03:30 GMT

Also, DES has a 64 bit blocksize, this allows text attacks (which do not
attempt to recover the key) after about 2**32 blocks are encrypted.  2**32
blocks are a lot, but are getting more feasible.
Don Johnson

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

From: Piso Mojado <[EMAIL PROTECTED]>
Subject: Re: Predicting calculator pseudo-random numbers
Date: Thu, 29 Apr 1999 09:30:38 -1000

Jim Gillogly wrote:
> 
> Piso Mojado wrote:
> > It is a myth that computers cannot generate random numbers.
> > A calculator is a computer. Please examine the random numbers that
> > my computer generated and compare them with random numbers from
> > a radioactive source. If you can tell which is which, please explain
> > how you decided:
> [snippage]
> > ca56e9e4e2b07dcd7d9e6d91afab9d909087f7d2466129627d40a86f7125996f
> [snippage]
> > The myth is only true for simple computers, not for modern PCs
> > with common resources. A calculator can have a resource like my
> > PC, which enables it to preform non-deterministically.
> 
> A simple frequency count on the two binary files shows a nice
> even distribution in the first sample with the highest frequency
> amongst the 512 bytes being 0x28, 30, 39, and 8e, all at freq=6.
> The nibbles are pretty evenly distributed, and so are the bits.
> The second sample has four bytes at freq=7, one at 9, and a very
> large outlier, 0x7d at 22.  Counting it by nibbles instead of
> bytes, 0x1 is far too low in the second sample; and the ratio
> of 1-bits to 0-bits is much higher in that sample.  Either your
> "computer generated random number" process is broken or the way
> you process your radioactive source is broken.  If we knew the
> details of how each was implemented, perhaps we could tell which
> is which.
> 
> If I had to make a guess I'd pick the first sample for the
> computer-generated one, since it's easy to make a sequence that
> looks superficially random.  "'Her English is too good,' he said,
> 'That clearly indicates that she is foreign.'"
> 
> --
>         Jim Gillogly
>         8 Thrimidge S.R. 1999, 15:03
>         12.19.6.2.13, 9 Ben 1 Uo, Eighth Lord of Night

Good work Jim, but the first set was radioactive, the second was
from my PC. The program only gathers nondeterministic bits from the
hardware events, it does not massage the bits to look more random.

So let's proceed with the intent of the original poster:

PREDICT THE NEXT RANDOM BITS! Here is the next line:

b179bac4d1593bd63ac35cfeb59894b1b15dafcaf82966d332703194b827f3a0

How would you have predicted that? I have 75k bytes in one file
so you can try to predict the NEXT line. If you can predict the 
next line in my hexadecimal file by May 5, I will pay $1000 USA
currency. If there are any takers, we can negotiate any other
guarantees that we all agree upon, such as someone to hold the
complete file to prove I am not making a moving target.

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

From: "Jay" <[EMAIL PROTECTED]>
Subject: Re: UBE98 Vendor Admission
Date: Sun, 25 Apr 1999 08:21:21 -0400


JPeschel wrote in message <[EMAIL PROTECTED]>...
>Despite the vendor knowing UBE's weakness,
>it's still being sold.

>  "We ourselves know how to break it with ICE.
>  That is being resolved now (you would need
>  to have access to the user's computer to
>  break it)."
>
>The last "fix" was to use Shrinker to
>protect the executables from disassembly.
>I suppose some SoftICE-hostile code
>will be the next "fix."
>

Don't they understand that if the code were right, there would be no need to
*protect* it all? Even open source would be secure.

jay




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

From: Nathan Kennedy <[EMAIL PROTECTED]>
Subject: Re: mcrypt
Date: Sun, 25 Apr 1999 20:20:09 +0800

[EMAIL PROTECTED] wrote:
> May I suggest adding compression?  That would make known
> plaintext attacks rather difficult.  Why not try the LZO compression
> library, it's free and really fast.

Because he's writing a replacement for crypt, not pgp.  I don't think you
know the Unix philosophy very well, a pile of little tools that can be put
together to do powerful things, specific tools that are good at one thing.

So I can say, cat secret | gzip | crypt pass | mail, and do that.  crypt's
place isn't compression.  It's encryption.  If you want a full
crypto-system in one package, get gnupg, at www.gnupg.org

Nate

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

From: [EMAIL PROTECTED] (Wei Dai)
Subject: Re: Algorithms where encryption=decryption?
Date: Sat, 1 May 1999 00:07:22 -0700

In article <7galtg$a9g$[EMAIL PROTECTED]>, [EMAIL PROTECTED] 
says...
> Let's consider permutations of order 2 with no fixed points
> (so n, the degree, must be even).  According to my calculations,
> there are
>                  n! / (2^(n/2) * (n/2)!)
> 
> such permutations.  (If anyone can get a closed form for the
> number of self-inverters including those with fixed points,
> please do post it.)

The total number of self-inverters (with n even) is:

Sum[n!/((n-2i)!*2^i*i!), {i,0,n/2}]

which Mathematica managed to simplify to:

(-I)^n*2^(n/2)* HypergeometricU[-(n/2), 1/2, -(1/2)]

where HypergeometricU is the confluent hypergeometric function U(a,b,z), 
although I have no idea what that means. Is that what you were looking 
for?

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

From: "John A. Limpert" <[EMAIL PROTECTED]>
Subject: Re: Extreme lossy text compression
Date: Sat, 1 May 1999 04:24:15 -0400


Jerry Coffin <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>, mok-
> [EMAIL PROTECTED] says...
>
> [ a table-driven CRC ]
>
> > Could you say what speed you can achieve with that on a typical
> > processor (in assembler and in C or other languages)? Thanks
> > in advance.
>
> I just did a quick check with a version I have lying around and it did
> around 5 megabytes a second a Pentium II/400.  In all honesty, I
> suspect that a faster disk would improve that more than a faster CPU
> though.

I ran benchmarks of various CRC schemes on a Pentium a few years ago. Most
ran in the range of 5-10 megabytes/second. The limiting factor appeared to
be main memory bandwidth, not CPU speed. They all seemed to blow out the L2
cache.





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


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