Cryptography-Digest Digest #172

2001-04-18 Thread Digestifier

Cryptography-Digest Digest #172, Volume #14  Wed, 18 Apr 01 04:13:01 EDT

Contents:
  Re: Lorentz attractor... ("Douglas A. Gwyn")
  Re: LFSR Security (David Wagner)
  Re: Size of dictionaries ("Douglas A. Gwyn")
  Re: "UNCOBER" = Universal Code Breaker ("Douglas A. Gwyn")
  Re: "UNCOBER" = Universal Code Breaker ("Douglas A. Gwyn")
  Re: Note on combining PRNGs with the method of Wichmann and Hill (Bryan Olson)
  Re: XOR_TextBox:  Doesn't write to swap file if... (Anthony Stephen Szopa)
  Re: LFSR Security (Tim Tyler)
  Re: Size of dictionaries (wtshaw)
  Re: XOR TextBox Freeware:  Very Lousy. (David Schwartz)
  Re: Incomplete Blocks in Twofish ("Mike Moulton")
  Re: C code for GF mults ("Brian Gladman")
  Re: C code for GF mults (David Eppstein)
  Re: C code for GF mults ("Brian Gladman")



From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: Lorentz attractor...
Date: Wed, 18 Apr 2001 03:21:15 GMT

Richard Heathfield wrote:
 It was, in fact, a young tabby kitten who engineered the only
 ciphertext-based OTP break in history. The incident is shrouded in
 suspicious mystery, but we *can* be sure that the kitten in question
 belonged to a Mr Schroedinger. What he did to the kitten, when he
 discovered that it had learned his secret, remains uncertain.

We don't even know if the cat in question is still alive.

--

From: [EMAIL PROTECTED] (David Wagner)
Crossposted-To: sci.crypt.random-numbers
Subject: Re: LFSR Security
Date: 18 Apr 2001 03:21:22 GMT

Scott Fluhrer wrote:
One obvious way to extend this is to make the wild claim that, if the
keystream bits you do have, there exists a a_0  a_1  ...  a_{n+1} and n-1
distinct r_0, ..., r_{n-2}, you know the keystream output for b_{a_i + r_j}
for all i, j, then you can derive the taps for a virtual LFSR (which
hopefully isn't too hard to translate back into the normal form).

Ooh, nice.  Sounds promising.

Yes, it seems plausible that if you can find the taps for a virtual
LFSR, one can hope to recover the taps of the original LFSR.  Your
virtual LFSR is basically a recurrence relation
   b_{m+r_0} + b_{m+r_1} + ... + b_{m+r_n} = 0  for all m.
The associated polynomial is q(x) = x^r_0 + x^r_1 + .. + x^r_n.
Now the LFSR's polynomial is a divisor of q(x), so if you factor
q(x), you can get some candidates for the LFSR taps.  Alternatively,
if you get a few such q(x)'s, you can take their gcd.

It seems to me that one of the major remaining questions is this:
Suppose we know the keystream at some set of positions S (i.e., we
known b_s for s in S).  How do we find a_i's and r_j's so that
a_i + r_j is in S for all i,j?  Moreover, how much known text is
needed to ensure that such a_i,r_j's exist?

To rephrase the first question: We have a set S.  We want to find a
pair of sets, A and R, of cardinality = n such that A+R is a subset
of S.  Here A+R denotes {a+r : a in A, r in R}, and A represents the
set of a_i's, R the set of r_j's.  How large does S need to be?
Can we find A,R efficiently?

--

From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: Size of dictionaries
Date: Wed, 18 Apr 2001 03:29:50 GMT

Jim Gillogly wrote:
 ...  An example might be communicating
 with scientists on the 30-year Titan probe, assuming they had lost
 the use of their main antenna and can receive mail on only a very
 limited-bandwidth umbrella-sized telemetry antenna.  ...

Indeed, deep-space communication throughput is very limited even if
one *can* use the main antenna.  Another way of putting it is that
effective high-speed communication over such distances requires
far more power than is practical to provide.  In order to improve
the effective bit rate, heavy use is made of error-correcting
coding of the information, and the information is made as compact
as possible in the first place.  That's where application-specific
dictionaries can play an important role.

--

From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Wed, 18 Apr 2001 03:30:50 GMT

newbie wrote:
 Has cryptograhers thought to universal way to break any code?

Have you?

--

From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Wed, 18 Apr 2001 03:35:42 GMT

newbie wrote:
 This theory has to answer why is OTP likely unbreakable. It is not so
 sure.
 It is sure only in theory. Because the language domain is not infinite.
 There is not only redundancy is using the alphabet. There is redundancy
 in plain-text using. ...

Put simply, you do not know what you're talking about.
It is *easy* to show that a OTP properly employed provides
no information to the eavesdropper that he did not already 

Cryptography-Digest Digest #172

2000-11-16 Thread Digestifier

Cryptography-Digest Digest #172, Volume #13  Fri, 17 Nov 00 00:13:01 EST

Contents:
  Re: My new book "Exploring RANDOMNESS" ("Matt Timmermans")
  Re: vote buying... ("Trevor L. Jackson, III")
  Re: vote buying... ("Trevor L. Jackson, III")
  Breaking Leviathan (Paul Crowley)
  Re: vote buying... ("Trevor L. Jackson, III")
  Re: vote buying... ("Trevor L. Jackson, III")
  Re: vote buying... ("Trevor L. Jackson, III")
  Re: And you FBI people reading my messages ... this is just starting .. :) ... I 
know you are there . ("Alien8")
  short encripted message (my first first cript agor)  ("Alien8")
  Rijndael: Impossible differential cryptanalysis on 5 rounds ([EMAIL PROTECTED])
  Rijndael: Impossible differential cryptanalysis on 5 rounds ([EMAIL PROTECTED])
  Re: vote buying... (Paul Rubin)
  DES question: Has this ever been proven before? (Raphael Phan)



From: "Matt Timmermans" [EMAIL PROTECTED]
Crossposted-To: sci.math,sci.logic
Subject: Re: My new book "Exploring RANDOMNESS"
Date: Fri, 17 Nov 2000 03:13:21 GMT


"Greggy" [EMAIL PROTECTED] wrote in message
news:8v21tv$eoh$[EMAIL PROTECTED]...
 [...]
 In fact, have you considered making the book
 online and free to read through?  I for one have no curiosity for such
 a book if I have to pay for it.  Sounds like snake oil.  Or can I get
 my money back if I don't think it was worth the price?

Heh.  Did you actually notice _who_ wrote the book?




--

Date: Thu, 16 Nov 2000 22:16:32 -0500
From: "Trevor L. Jackson, III" [EMAIL PROTECTED]
Subject: Re: vote buying...

David Schwartz wrote:

 Paul Rubin wrote:

  That traceability is bad even if the election officials are honest and
  the election is fair.  Years later, Sheriff Bubba has worked his way
  up to being Supreme Dictator Bubba, has the election officials
  executed and gets the archived code numbers and uses the ballot data
  to locate everyone who voted against him.

 Won't work. It'll just give him the code numbers of everyone who voted
 against him. Remember, we were talking about a case where a citizen
 presents his electronic voting receipt to an official.

   You are looking at a scheme specifically designed to provide X and
 complaining that it doesn't provide Y. Of course not, it isn't designed
 to. Unless you want to argue that no scheme can provide both X and Y,
 your argument is pointless.
   
I may have missed something but I think I agree with this.  Any scheme
that solves all problems must do both X and Y, where X and Y are in
conflict with each other.
  
 What goal is in conflict with what goal?
 
  The goal of being able to check votes after the election (to detect
  fraud) is in conflict with the goal of not being able to check the
  votes (to protect voter secrecy).

 So long as you need the voter's help to check them, you can easily meet
 both goals.

Not quite.  If the voter can prove the validity of his vote than a person
threatening the voter can force him to reveal the validity token.  The only way to
protect the voter is to permit him to present a fake validity token.  But that
conflicts with the fraud detection mechanism because it can be used to hide fraud.



--

Date: Thu, 16 Nov 2000 22:30:02 -0500
From: "Trevor L. Jackson, III" [EMAIL PROTECTED]
Subject: Re: vote buying...

David Schwartz wrote:

 Paul Rubin wrote:
 
  David Schwartz [EMAIL PROTECTED] writes:
That traceability is bad even if the election officials are honest and
the election is fair.  Years later, Sheriff Bubba has worked his way
up to being Supreme Dictator Bubba, has the election officials
executed and gets the archived code numbers and uses the ballot data
to locate everyone who voted against him.
  
 Won't work. It'll just give him the code numbers of everyone who voted
   against him. Remember, we were talking about a case where a citizen
   presents his electronic voting receipt to an official.
 
  Nope.  Remember, Bubba already got the receipts from the voters back
  when he was still Sheriff and couldn't decode them.  Now he can decode
  them and there is hell to pay.

 He only got the receipts of those people who contested the vote. And he
 can't even be sure that the people who present the contest are the
 original voters. All he knows is that someone presented a voting receipt
 for a vote for candidate X and that this vote wasn't correctly counted
 for candidate X. Unless the system totally breaks down, the number of
 people issuing such disputes should be very small. The disputes could
 even be done anonymously. All that's needed to process the dispute are
 the numbers on the voting receipt.

The goal of being ab

Cryptography-Digest Digest #172

2000-07-07 Thread Digestifier

Cryptography-Digest Digest #172, Volume #12   Fri, 7 Jul 00 02:13:00 EDT

Contents:
  Re: Some dumb questions (John Savard)
  Re: Any crypto jokes? (potentially OT) ("Paul Pires")
  Re: Quantum Computing (Was: Newbie question about factoring) (TIEMANN BRUCE)
  Re: Prime Numbers? (TIEMANN BRUCE)
  Re: Prime Numbers? (David Lancashire)
  Re: A thought on OTPs (Joe Nilaad)
  Re: Compression  Encryption in FISHYLAND (Kurt Shoens)
  Re: Hash and Entropy (Benjamin Goldberg)
  Re: Prime Numbers? (Nicol So)
  Re: Hash and Entropy (JPeschel)
  Re: Any crypto jokes? (potentially OT) (Guy Macon)
  Porting Keys Between PGP, other Apps ("Ed Suominen")



From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Some dumb questions
Date: Fri, 07 Jul 2000 00:21:15 GMT

On Thu, 06 Jul 2000 17:40:00 +0200, Mok-Kong Shen
[EMAIL PROTECTED] wrote, in part:

Under which chapter/section of your webpage is the material
about SIGCUM? (Sorry that I did only a quick search.)

It's at

http://home.ecn.ab.ca/~jsavard/crypto/te0305.htm

The original version had 13 live wires into five rotors, with five
wires out giving the bits to XOR with a teleprinter character.

But the improved version had five live wires in, and the wires going
out were wired together from three rotor contacts, so the chance of a
bit being a one changed to 48.846%. Thus, getting rid of correlations
must have been considered as much more important than a little bias.

John Savard (teneerf -)
http://www.ecn.ab.ca/~jsavard/crypto.htm

--

From: "Paul Pires" [EMAIL PROTECTED]
Subject: Re: Any crypto jokes? (potentially OT)
Date: Thu, 6 Jul 2000 17:49:32 -0700

I am truly impressed with the volume and rational appearance of this post.

Does your day job require hip waders too?

Paul
. 
Trevor L. Jackson, III [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
 [EMAIL PROTECTED] wrote:

  How many cryptographers does it take to change a light bulb?

 Changing the light bulb is too hard (there can only be one AES, so we'll
never
 change anything).

 Turning on the light is about the right speed.  One needs to attempt every
 possible set of combinations of electrical switches, including the fuse
box,
 in order to determine which set of subsets of possible combinations enable
the
 light.  This technique fails in the presence of acoustic switches and BSR
X-10
 modules.

 Acoustic switches turn on the light and keep it on for a predetermined
period
 following the last significant sound.  Controlling the lights in the
presence
 of acoustic switches requires an analysis of the sensitivity settings of
the
 switches.  Thus each switch must be individually exhaustively exercised to
 determine the required volume level at each activation frequency.  This
 requires a form of differential spectral analysis which is beyond the
scope of
 this joke.

 BSR X-10 modules permit remote control of the light.  Since the switches
are
 typically controlled by a computer (or close facsimile) finding all of the
 possible controls that enable the light is equivalent to the halting
problem
 for the computer.  So deciding how to turn on the light is undecidable.
 Actually turning on the light requires even more effort.  In this
situation
 the author respectfully suggests candles.







--

From: [EMAIL PROTECTED] (TIEMANN BRUCE)
Crossposted-To: comp.theory
Subject: Re: Quantum Computing (Was: Newbie question about factoring)
Date: 7 Jul 2000 01:06:09 GMT

In article [EMAIL PROTECTED],
Paul E. Black [EMAIL PROTECTED] wrote:
Nick Maclaren wrote:
 However, some people believe that building a quantum computer is
 an exponentially complex problem, 

Interesting.  Could you give more details, for instance, who believes
that or what goes into it?  For instance, is it that designing a
quantum computer is exponentially complicated, or constructing it
(an exponential number of steps needed)?

-paul-
-- 
Paul E. Black ([EMAIL PROTECTED])

I have heard that quantum computers require as many bits in the readout of
some analog state as qbits in the data; thus, readout of a quantum state
to the nearest percent provides ~6-7 bits accuracy.  Reading out that
state to ppm-level accuracy would provide 20 qbits.  By the way, ppm-level
accuracy - not precision, accuracy - is extremely difficult, and would
afford only 20 bits, hardly enough to get excited about. Digging for the
next sigfig in the readout of some analog data is exponentially harder
than was the last one. 

This may have some bearing to the problem.


--

From: [EMAIL PROTECTED] (TIEMANN BRUCE)
Subject: Re: Prime Numbers?
Date: 7 Jul 2000 01:11:41 GMT

In article 8k2g60$8le$[EMAIL PROTECTED],  [EMAIL PROTECTED] wrote:

I understand the distinction now, thank you.  I had read an explanation
of Euclid's proof in an article in Scientifc American july 1988 p.

Cryptography-Digest Digest #172

2000-02-21 Thread Digestifier

Cryptography-Digest Digest #172, Volume #11  Mon, 21 Feb 00 05:13:02 EST

Contents:
  Re: Processor speeds. ("Douglas A. Gwyn")
  I will bring PGP to the masses h20 (PGP_for_ALL)
  Re: OAP-L3 Encryption Software - Complete Help Files at web site ("Douglas A. Gwyn")
  I will bring PGP to the masses h15 (PGP_for_ALL)
  efficiency of ecash schemes (ahbeng)
  Re: OAP-L3 Encryption Software - Complete Help Files at web site (Anthony Stephen 
Szopa)
  Re: Does the NSA have ALL Possible PGP keys? (John Underwood)
  Re: I stole also the diary and calendar of Markku J. Saarelainen ("ink")
  Re: EOF in cipher??? (Mok-Kong Shen)
  Re: Processor speeds. (Mok-Kong Shen)
  Re: NIST publishes AES source code on web (Mok-Kong Shen)
  Re: Keys  Passwords. (Mok-Kong Shen)



From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: Processor speeds.
Date: Mon, 21 Feb 2000 06:17:24 GMT

"John E. Kuslich" wrote:
 ... The performance they achieve on ray trace software would not
 be possible using the classic CRAY boat anchor computer.

Ray tracing is the epitome of a *parallel* task (each pixel can be
computed independently), while Cray computers have been *vector*
machines.  Also, as I noted previously, supercomputers normally
have incredibly high I/O performance, which cannot be matched by
distributed PCs.  You should use the appropriate tool for the
appropriate task.

By the way, we at BRL were perhaps the first to distribute ray
tracing among multiple computers on a local network.  (We used
big, fast SGIs rather than puny PCs, however.)  We also had a
couple of Crays and other supercomputers, but we didn't waste
them on much of our ray-traced imaging workload.

--

Date: 19 Feb 2000 14:17:06 -
From: PGP_for_ALL Use-Author-Address-Header@[127.1]
Subject: I will bring PGP to the masses h20

I will bring PGP to the masses

PGP can be used by all, can be used by the masses, but not in the current
implementation.

I have the strategic information to make PGP product to be used by all the
internet e-mail active users  not only by elite, educated and sophisticated
computer equipment users. 

I need to get association from influential entrepreneurial people to back me
up, to provide "invisible" success shield. 

I know that to have undisputed solutions does not bear much success before
they are backed by influential people. The key here is the "influential
people". As the history proved many times in the past, many outstanding ideas
has been lost due to the lack of influential back up at the first
presentation.

I see the enormous prestigious  financial benefits to be gained by PGP
company, at the same time I would like not be "left on the street homeless 
hungry" after disclosing my research  findings to appropriate people.

I'm using PGP encryption tools for very long time.
I know  understand almost from the beginning the importance of the benefits
associated with mass market encryption.
I know  understand almost from the beginning the problems associated with the
PGP software that shaped the past, and most importantly had very detrimental
impact on the wider spread use of this extraordinary product. 

In 1999 I realized the fact that PGP is the undisputed encryption tool in use.
On the other hand, I realized that PGP saturation is to fare from the accepted
level, from the level to be named "used by the masses". 

To say in other words, PGP is not used, is not accepted, will not be used,
will not be accepted by almost every user on the internet, until strategic
changes, changes that I'm proposing will be implemented. 

The past PGP development, the past release versions, the current version and
the undertaken development that will lead to future versions, are sufficiently
enough to indicate that PGP will not reach the "mass market saturation level"
without my proposed strategic changes. This is contrary to the undisputed
benefits that are provided by this excellent software.

Here are coming my observations  research. All of my suggestions indicates
that all of the above can be very easily changed, changed to make possible for
the PGP to become mass market product. I have the strategic information 
proposed required changes that should be made to make PGP accepted by the
masses, by all the uses of the e-mail encryption.

My ideas are proven by the past implemented strategies, the past examples of
the mass market products  services.
My ideas are based on the unsuccessful past products that make to the mass
market after changing global strategies.

My key is at http://www.mit.edu:8001/finger?[EMAIL PROTECTED]
I'm physically located in the NYC. My PGP_for_ALL account is not ANON
protected, I'm using it for the anti SPAM filtering purposes only.

--

From: "Douglas A. Gwyn" [EMAIL PROTEC

Cryptography-Digest Digest #172

1999-09-03 Thread Digestifier

Cryptography-Digest Digest #172, Volume #10   Sat, 4 Sep 99 02:13:03 EDT

Contents:
  Re: NSA and MS windows (Bruce Schneier)
  Re: 512 bit number factored (Bob Silverman)
  Re: 512 bit number factored (Paul Rubin)
  Re: Alleged NSA backdoor in Windows CryptoAPI (Bruce Schneier)
  THE NSAKEY (SCOTT19U.ZIP_GUY)
  Re: Schneier/Publsied Algorithms (Bruce Schneier)
  Re: 512 bit number factored (Eric Young)
  Re: Does SSL use RSA Keys? (Eric Young)
  Re: 512 bit number factored (Paul Rubin)
  Re: NSA and MS windows ("Thomas J. Boschloo")



From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: NSA and MS windows
Date: Sat, 04 Sep 1999 02:04:58 GMT

On Fri, 03 Sep 1999 14:27:30 -0700, Michael Slass [EMAIL PROTECTED]
wrote:

According to
http://www.cnn.com/TECH/computing/9909/03/windows.nsa/

"(CNN) -- A cryptography expert says that Microsoft operating systems
include a back door that allows the
National Security Agency to enter systems using one of the operating
system versions.

A few months ago in my newsletter Crypto-Gram, I talked about
Microsoft's system for digitally signing cryptography suits that go
into its operating system.  The point is that only approved crypto
suites can be used, which makes thing like export control easier.
Annoying as it is, this is the current marketplace.

Microsoft has two keys, a primary and a spare.  The Crypto-Gram
article talked about attacks based on the fact that a crypto suite is
considered signed if it is signed by EITHER key, and that there is no
mechanism for transitioning from the primary key to the backup.  It's
stupid cryptography, but the sort of thing you'd expect out of
Microsoft.

Suddenly there's a flurry of press activity because someone notices
that the second key is called "NSAKEY" in the code.  Ah ha!  The NSA
can sign crypto suites.  They can use this ability to drop a Trojaned
crypto suite into your computers.  Or so the conspiracy theory goes.

I don't buy it.

First, if the NSA wanted to compromise Microsoft's Crypto API, it
would be much easier to either 1) convince MS to tell them the secret
key for MS's signature key, 2) get MS to sign an NSA-compromised
module, 3) install a module other than Crypto API to break the
encryption (no other modules need signatures).  It's always easier to
break good encryption.

Second, NSA doesn't need a key to compromise security in Windows.
Programs like Back Orifice can do it without any keys.  Attacking the
Crypto API still requires that the victim run an executable (even a
Word macro) on his computer.  If you can convince a victim to run an
untrusted macro, there are a zillion smarter ways to compromise
security.

Third, why in the world would anyone call a secret NSA key "NSAKEY."
Lots of people have access to source code within Microsoft; a
conspiracy like this would only be known by a few people.  Anyone with
a debugger could have found this "NSAKEY."  If this is a covert
mechanism, it's not very covert.

I see two possibilities.  One, that the backup key is just as
Microsoft says, a backup key.  It's called "NSAKEY" for some dumb
reason, and that's that.

Two, that it is actually an NSA key.  If the NSA is going to use
Microsoft products for classified traffic, they're going to install
their own cryptography.  They're not going to want to show it to
anyone, not even Microsoft.  They are going to want to sign their own
modules.  So the backup key could also be an NSA internal key, so that
they could install strong cryptography on Microsoft products for their
own internal use.

But it's not an NSA key so they can secretly install weak cryptography
on the unsuspecting masses.  There are just too many smarter things
they can do to the unsuspecting masses.

My original article:
http://www.counterpane.com/crypto-gram-9904.html#certificates 

Announcement:
http://www.cryptonym.com/hottopics/msft-nsa.html

Nice analysis:
http://ntbugtraq.ntadvice.com/default.asp?sid=1pid=47aid=52

Useful news article:
http://www.wired.com/news/news/technology/story/21577.html
**
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN  55419  Fax: 612-823-1590
   Free crypto newsletter.  See:  http://www.counterpane.com

--

From: Bob Silverman [EMAIL PROTECTED]
Subject: Re: 512 bit number factored
Date: Sat, 04 Sep 1999 02:32:56 GMT

In article [EMAIL PROTECTED],
  [EMAIL PROTECTED] (DJohn37050) wrote:
 OK, some here are some reworded questions on RSA key size for Bob, Wei and
 anyone else to comment on:
 1. My understanding is that the GNFS has 2 steps: (A) Gathering equations,
 which can be done in parallel with little memory

As I said,  700 bits would require 2-3 Gbytes per machine to do the
sieving.

If you choose to call this '