Cryptography-Digest Digest #671

2001-02-10 Thread Digestifier

Cryptography-Digest Digest #671, Volume #13  Sat, 10 Feb 01 17:13:01 EST

Contents:
  Re: ideas of D.Chaum about digital cash and whether tax offices are  ("Trevor L. 
Jackson, III")
  Re: ideas of D.Chaum about digital cash and whether tax offices are  ("Trevor L. 
Jackson, III")
  Re: Cryptologia back-issues .. a wishful idea for the publishers (Sundial Services)
  Re: Mono cipher, genetic algorithm .. appropriate "Crossover?" (Sundial Services)
  Re: RSA is not secure in many instances... (Tom St Denis)
  Mono ciphers and genetics .. a bacterial twist! (Sundial Services)
  Re: NPC ("Peter Shugalev")
  Re: Purenoise defeats Man In The Middle attack? (Tom St Denis)
  Re: The Kingdom of God (Tom St Denis)
  Re: UNIX Crypt for DOS (David Hopwood)
  Re: Mono cipher, genetic algorithm .. appropriate "Crossover?" ("Robert Reynard")
  Re: The Kingdom of God (BlackIce)
  Re: I encourage people to boycott and ban all Russian goods and  services, if the 
Russian Federation is banning Jehovah's Witnesses  ... ("Sam Simpson")
  Re: RSA is not secure in many instances... (David Schwartz)
  Re: I encourage people to boycott and ban all Russian goods and   (David Schwartz)
  Re: The Kingdom of God ("drumstik")
  Re: The Kingdom of God ("drumstik")



From: "Trevor L. Jackson, III" [EMAIL PROTECTED]
Reply-To: don't
Crossposted-To: sci.crypt,talk.politics.crypto,alt.cypherpunks
Subject: Re: ideas of D.Chaum about digital cash and whether tax offices are 
Date: Sat, 10 Feb 2001 20:16:36 GMT

"Thomas J. Boschloo" wrote:

 I am not talking about a one grand GPS bullet or some other form of
 smart bullet. Just some sci-fi (emphasis on 'fi') way to trace all
 bullets around the world.

OT, but in context. Professionals in the science/speculative fiction industry
_hate_ the degenerate "sci-fi" as an ugly hollywood-ism.  They use the term
sf.

Note that immediate consequence of forcing the use of such projectiles (by
outlawing the production of any other), would be that all crimes would be
committed by police and/or military bullets.  Arsenal theft is an industry of
respectable size.


--

From: "Trevor L. Jackson, III" [EMAIL PROTECTED]
Reply-To: don't
Crossposted-To: sci.crypt,talk.politics.crypto,alt.cypherpunks
Subject: Re: ideas of D.Chaum about digital cash and whether tax offices are 
Date: Sat, 10 Feb 2001 20:16:36 GMT

"Thomas J. Boschloo" wrote:

 I am not talking about a one grand GPS bullet or some other form of
 smart bullet. Just some sci-fi (emphasis on 'fi') way to trace all
 bullets around the world.

OT, but in context. Professionals in the science/speculative fiction industry
_hate_ the degenerate "sci-fi" as an ugly hollywood-ism.  They use the term
sf.

Note that immediate consequence of forcing the use of such projectiles (by
outlawing the production of any other), would be that all crimes would be
committed by police and/or military bullets.  Arsenal theft is an industry of
respectable size.


--

Date: Sat, 10 Feb 2001 13:20:40 -0700
From: Sundial Services [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: Cryptologia back-issues .. a wishful idea for the publishers

You know, when I see references to materials in issues long since dead,
I sorely wish that journals such as Cryptologia would RE-PUBLISH their
old material on a SUBSCRIPTION web-site.

In other words, you can see an abstract of the papers on file.  If you
want to read the full thing, you enroll in the site using a
credit-card.  You can then purchase the full text of the article you
want, in (say) PDF or PS form, and download it to your computer. 
Authors would receive royalties as usual.

I'd cheerfully pay a reasonable fee for this and it would unlock the
vast resource of knowledge that was thus-far produced only in print
form.  Those words are still desirable ... still valuable.



John A. Malley wrote:
[...]
 Perhaps "The Use of Genetic Algorithms in Cryptanalysis" by Robert A. J.
 Matthews in "Cryptologia", vol. 17, Number 2, April 1993, may answer
 your question. (Believe it or not I picked up a small stack of past
 editions of this journal in a second hand bookstore a while ago and this
 article was the first one I read after buying them. :-) )
[...]

==
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:[EMAIL PROTECTED]  (PGP public key available.)
 Fast(!), automatic table-repair with two clicks of the mouse!
 ChimneySweep(R):  "Click click, it's fixed!" {tm}
 http://www.sundialservices.com/products/chimneysweep

--

Date: Sat, 10 Feb 2001 13:22:04 -0700
From: Sundial Services [EM

Cryptography-Digest Digest #671

2000-09-13 Thread Digestifier

Cryptography-Digest Digest #671, Volume #12  Wed, 13 Sep 00 13:13:00 EDT

Contents:
  Re: (Jury Selection) Re: Carnivore article in October CACM _Inside_Risks (Robert H. 
Risch)
  Re: Dickman's function (Francois Grieu)
  Re: Bytes, octets, chars, and characters (mike burrell)
  Re: For the Gurus ("root@localhost " [EMAIL PROTECTED])
  Re: (Jury Selection) Re: Carnivore article in October CACM _Inside_Risks (Yiorgos 
Adamopoulos)
  Re: IDEA - PGP (John Myre)
  Re: Need Tiger hash results for sample test data ([EMAIL PROTECTED])
  Re: MIRACL (John Myre)
  Re: For the Gurus (Jim Gillogly)
  Re: For the Gurus ("root@localhost " [EMAIL PROTECTED])
  Re: (Jury Selection) Re: Carnivore article in October CACM _Inside_Risks (Rich Wales)
  Re: Can anyone decrypt this? ("David Kocmoud")
  Re: Crypto Related Pangrams (Doug Kuhlman)
  Re: For the Gurus (Mok-Kong Shen)
  Re: Scottu19 Broken (Mok-Kong Shen)
  Re: For the Gurus (Jim Gillogly)
  Re: nice simple function ("Douglas A. Gwyn")
  Re: Police want help cracking code to find Enigma machine ("Douglas A. Gwyn")



From: Robert H. Risch [EMAIL PROTECTED]
Crossposted-To: comp.security.misc,alt.security,talk.politics.crypto,us.legal
Subject: Re: (Jury Selection) Re: Carnivore article in October CACM _Inside_Risks
Reply-To: [EMAIL PROTECTED]
Date: Wed, 13 Sep 2000 13:40:41 GMT

On 12 Sep 2000 10:06:43 GMT, [EMAIL PROTECTED] (Yiorgos
Adamopoulos) wrote:

Among the rules, is the ability of a
lawyer to recite a speech to a hostile witness and force him to answer
yes or no as to whether what the lawyer just said is true.  The

Here also.  But usually it is followed by a judge asking ``why yes?''.

witness can only explain his answer if a the lawyer on the same side
as the witness later asks him "non leading" questions that are crafted
to refute the former lawyer's speech.  Any such thing goes on in a
Greek Court?

Does this mean that witnesses have an opportunity to testify in their
own words in a Greek Court?  In the US, the lawyers are fanatical in
their desire to control witnesses.  It is quite proper here for a
lawyer to object that a witness is giving a "narrative".

RHR

--

From: Francois Grieu [EMAIL PROTECTED]
Crossposted-To: sci.math.num-analysis
Subject: Re: Dickman's function
Date: Wed, 13 Sep 2000 15:51:45 +0200

[EMAIL PROTECTED] (D. J. Bernstein) wrote:

 Francois Grieu  [EMAIL PROTECTED] wrote:
  I'm trying to find or devise simple C code to compute Dickman's 
  function.
 
 There's a rho() function in psibound: http://cr.yp.to/psibound.html

Dickman's rho(b) is of course the f[b] = F[1/b] in my original message.

I tried Dan's rho() function in  rho.c  found at 
http://cr.yp.to/psibound/psibound-0.50.tar.gz
and it does just what I wanted. Thanks a lotn Dan ! Somehow this code 
circumvents the error propagation problem encountered in my methods, 
without using extended precision. It agrees nicely with the values I 
derived.

By any chance, is there a reference on the algorithm used and/or the 
math behind it ? Has it to do with

/b 
  f[b] = (1/b)  |  f[t] dt   for  b=1
   /b-1

that Peter-Lawrence Montgomery kindly pointed, and does seem an 
excellent formula (with error propagation, intuitively, relative rather 
than absolute) ?


   Francois Grieu

--

From: mike burrell [EMAIL PROTECTED]
Subject: Re: Bytes, octets, chars, and characters
Crossposted-To: comp.lang.c
Date: Wed, 13 Sep 2000 14:05:25 GMT

In comp.lang.c Jerry Coffin [EMAIL PROTECTED] wrote:
 In article 8plkse$2bl$[EMAIL PROTECTED], [EMAIL PROTECTED] says...
 Pray tell, what does C99 do to help people deal with large files easier 
 than in the C89 days?  Is long long related in any way to fseek and 
 friends?

 Yes and no -- it's not required to be, but it's relatively 
 straightforward to use it as an fpos_t that (as an extension) allows 
 arithmetic on file positions.

this still has nothing to do with long long.  if i'm an implementor of a
system with 32-bit longs and 64-bit fpos_t's, i could do:
typedef __WackyOS_64bit_uint fpos_t;
just as easily as i could do:
typedef unsigned long long fpos_t;
i.e. a rose by any other name ;)

-- 
 /"\ m i k e   b u r r e l l
 \ / ASCII RIBBON CAMPAIGN   [EMAIL PROTECTED]
  XAGAINST HTML MAIL,
 / \  AND NEWS TOO, dammit   finger [EMAIL PROTECTED] for GPG key

--

From: "root@localhost spamthis" [EMAIL PROTECTED]
Subject: Re: For the Gurus
Date: Wed, 13 Sep 2000 10:29:31 -0400

wtshaw wrote:
 
 In article [EMAIL PROTECTED], Mok-Kong Shen
 [EMAIL PROTECTED] wrote:
 
  "root@localhost " wrote:
  
   If I wanted to design a simple manual system that I felt was

Cryptography-Digest Digest #671

1999-12-03 Thread Digestifier

Cryptography-Digest Digest #671, Volume #10   Fri, 3 Dec 99 06:13:01 EST

Contents:
  Re: NP-hard Problems (David A Molnar)
  Re: Elliptic Curve Public-Key Cryptography (Paul Rubin)
  Re: Encrypting short blocks (Markus Peuhkuri)
  Re: Encrypting short blocks (Markus Peuhkuri)
  how to combine hashes to build a 128-bit key? (Juergen Thumm)
  Re: Noise Encryption ("Tim Wood")
  Re: brute force versus scalable repeated hashing ("Tim Wood")
  Re: brute force versus scalable repeated hashing ("Tim Wood")
  Re: more about the random number generator (Guy Macon)
  Re: Random Noise Encryption Buffs (Look Here) (Dave Knapp)
  Re: Random Noise Encryption Buffs (Look Here) (Dave Knapp)
  Re: Random Noise Encryption Buffs (Look Here) (Dave Knapp)
  Re: Why Aren't Virtual Dice Adequate? (Guy Macon)
  Re: Random Noise Encryption Buffs (Look Here) (Anthony Stephen Szopa)



From: David A Molnar [EMAIL PROTECTED]
Subject: Re: NP-hard Problems
Date: 3 Dec 1999 05:34:33 GMT

Bill Unruh [EMAIL PROTECTED] wrote:
 In [EMAIL PROTECTED] [EMAIL PROTECTED] (James Pate Williams, 
Jr.) writes:

What are some problems that are NP-hard but not NP-complete? I know

 Well, it is not known if there are any NP hard problems. But assuming
 that say factoring is NP hard, I believe it is not NP complete.

This does not match my understanding of NP hard problems at all. :-(
As in "head explodes at reading previous two posts" out of joint
with what I know. Let me write what I think and hopefully we can resolve
this.  

From what I understand :

When we say that a problem P is "NP-hard", we mean that 

a) we have a decision problem P defined with respect to some language of
   strings L. That is, we have an alphabet $\Sigma$ and a string 
   $s \in \Sigma^*$ -- a string $s$ consisting of some concatenation
   of symbols in the alphabet and of unbounded length -- and we are
   asking the question "Is the string s in the language L??" 

b) an efficient reduction exists from this problem over L to every other
   decision problem P' for an NP-language L'. Let's expand on what
   that means :

a "reduction" is a process for rewriting problem questions
for one problem in terms of those for another problem. 
In this case, we want something which will let me
take a query for a problem P' 

(1) "Is this string s in L' ??"

and `reformat' it such that I can create a new string 
and new query like so 

(2) "Is this string f(s) in L ??"

(f being some rewriting process or function) 

and knowing the answer to query (2) will give me
the answer to query (1). 

Put another way - say I know how to solve (2). So I figure
out how to use it to solve (1). What I "do to figure it
out" can be identified with a "reduction." 


 efficient : means that the reduction takes a polynomial
number of steps in some useful parameter, like the 
length of the input. 


SO if a problem P is NP-hard, it has this really cool property :
if we can solve P, we can solve all problems in NP. 
This is because for every problem in NP, there exists
a reduction which will let us take our method of 
solving P and use it to solve anything we want. 



Notice at this point that we haven't said anything about whether P is
deciding a language which is actually IN the class NP or not. That's
where NP-complete comes in :


We say a problem is "NP-complete" if it is 

a) NP-hard (as above)
b) concerning a language in NP

The NP-complete problem everyone always points to is SATISFIABILITY
: given this logical expression, what values make it true? Karp 
showed back in the 70's that you can simulate a universal Turing Machine
by building enough formulae. So SATISFIABILITY is NP-hard.

My confusion at the statement "it is not known if there are any
problems which are NP hard" is that since Karp, lots of ppl have
gone through and shown problems NP-complete and NP-hard in
something like the sense I'm outlining here. 

The original question was 

"Are there NP-hard problems which are not NP-complete?"

From my understanding, this is equivalent to :

"Are there problems which would let us solve all other 
problems in NP if we could do them easily, but are not
themselves in NP ?"


I think so. Now let me try something I'm not so sure of and try to 
give an example. 

Consider the problem of enumerating *all* bit-strings of length $k$. 
There's $2^k$ of them, so it takes exponential time. Also exponential
space. Let's say you have a magic box which takes one step to 
enumerate them all and also search them for whatever you happen to want. 

Say you w

Cryptography-Digest Digest #671

1999-06-06 Thread Digestifier

Cryptography-Digest Digest #671, Volume #9Sun, 6 Jun 99 16:13:03 EDT

Contents:
  Re: "Cipher Systems", Beker  Piper?
  Re: evolving round keys
  Re: Challenge to SCOTT19U.ZIP_GUY (Tim Redburn)
  Re: Scottu: I actually saw something usefull (Tim Redburn)
  Re: Challenge to SCOTT19U.ZIP_GUY (Thomas Pornin)
  Re: evolving round keys (Terry Ritter)
  SCOTT16U Key Generation (SCOTT19U.ZIP_GUY)
  Re: Finding a 192 bit hash (Was: Using symmetric encryption for hashing) (Boris 
Kazak)
  Re: SCOTT19U pass in nut shell (Richard Iachetta)
  Re: KRYPTOS ("Douglas A. Gwyn")
  Re: Challenge to SCOTT19U.ZIP_GUY (SCOTT19U.ZIP_GUY)
  Re: Challenge to SCOTT19U.ZIP_GUY (Tim Redburn)
  Re: Challenge to SCOTT19U.ZIP_GUY (SCOTT19U.ZIP_GUY)
  Re: SCOTT19U pass in nut shell (SCOTT19U.ZIP_GUY)
  Key lengths vs cracking time ("Jan Wessels")
  Re: Challenge to SCOTT19U.ZIP_GUY (Thomas Pornin)



From: [EMAIL PROTECTED] ()
Subject: Re: "Cipher Systems", Beker  Piper?
Date: 6 Jun 99 15:22:09 GMT

Terry Ritter ([EMAIL PROTECTED]) wrote:
: Well, I can only do so much:  I just checked and -- yes, indeed --
: found it in the references from no less than three of my Cryptologia
: articles from the early 90's, plus the crypto DSP article.  

Yes, your site is one of the places my web search turned up.

: Cipher Systems has much more about feedback shift registers (FSR's)
: than we find in most modern texts.

: The text also has more crypto statistics and practical cryptanalysis
: of older systems than we find in modern texts; for example, they talk
: about attacking the M209 quite a bit.  In that sense it is more
: down-to-earth than modern texts.  It has two chapters on classical
: Shannon theory, the chapter on LFSR's and another on NLFSR's.

Well, from this, it seems that they do cover material that tends not to
occur in other sources, and which is, at least according to rumour,
touching a bit more closely on the still-classified early electronic
cipher devices of the post-rotor era.

John Savard

--

From: [EMAIL PROTECTED] ()
Subject: Re: evolving round keys
Date: 6 Jun 99 16:58:34 GMT

[EMAIL PROTECTED] wrote:

: If you have a strong enough char. then you can simply remove the delta
: from adjacent blocks.

I was thinking about your initial question - why do the keys remain
constant - and David Wagner's comments related to your following example,
just changing the whitening keys.

A static whitening key is indeed 'invisible' to differential
cryptanalysis. However, if the whitening keys are completely
unpredictable, you won't have two blocks whose difference is ever known:
but if your method of varying the whitening keys has any weaknesses, they
remain open to attack.

So I accept that that kind of scheme is still weak, since the two pieces
are, to a certain extent, open to separate attacks. But if you vary the
subkeys instead - which lets out using a standard DES chip - and use a
secure scheme, this _is_ a good method.

: How can you patent a swap?  It's a table (or function) which is
: dynamically updated.  You cannot patent a swap, or at least you
: shouldn't.

The essence of Terry Ritter's invention is this: after a byte has been
encrypted from a lookup table, perform a swap which involves as one of the
two bytes swapped the entry used in encrypting the byte. This was original
at the time, and has the benefit of combining the nonlinearity of a lookup
table with a high degree of efficiency in changing its contents, by only
changing the part that really matters - the part that was previously used.

John Savard

--

From: [EMAIL PROTECTED] (Tim Redburn)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Sun, 06 Jun 1999 18:31:30 GMT

On Sun, 06 Jun 1999 15:07:42 GMT, [EMAIL PROTECTED] wrote:

snip

Look at : http://members.xoom.com/ecil/page2.htm

Which briefly describes the algorithm.

snip

I originally looked at those pages some time
ago, in fact they were what I based my
analysis of his S-Box generation on.

However, as I showed, the sums in the pages
are inaccurate, but David refuses to correct them.
Anyone else reading the pages is likely to duplicate
work that has already been done by others, without
actually realising it (I wasn't the first to point
out problems with Davids S-Box generation).


When commenting about the accuracy of those
pages, all David is prepared to say is that he
would have written them differently. 

He refuses to give a concrete yes or no as to whether
they give a completely accurate description of his
algorithm.

Until David corrects the parts that have been pointed
out to him as incorrect, AND until he confirms absolutely the
accuracy of the rest of the document, I am not going
to spend time analysing it further, and I wouldn't
recommend any one else does either.

Without absolute confirmation from David as to the documents