Cryptography-Digest Digest #711

2001-02-18 Thread Digestifier

Cryptography-Digest Digest #711, Volume #13  Sun, 18 Feb 01 17:13:00 EST

Contents:
  Re: Metallurgy and Cryptography (Steve Portly)
  Re: My encryption system. ("Doom the Mostly Harmless")
  Re: National Security Nightmare? (Mok-Kong Shen)
  Re: Super strong crypto (Hard)
  Re: Super strong crypto (David Wagner)
  Re: ideas of D.Chaum about digital cash and whether tax offices are (Frog2)
  Re: Super strong crypto (Mok-Kong Shen)
  Re: The Kingdom of God (William Hugh Murray)
  Re: Super strong crypto ("Douglas A. Gwyn")
  Re: The Kingdom of God (William Hugh Murray)
  Re: Super strong crypto ("Douglas A. Gwyn")
  Re: The Kingdom of God (John M Price PhD)
  Re: The Kingdom of God ("Douglas A. Gwyn")
  Re: The Kingdom of God (William Hugh Murray)
  Re: The Kingdom of God (William Hugh Murray)
  Re: The Kingdom of God ("Trevor L. Jackson, III")
  Re: CipherText patent still pending (Benjamin Goldberg)



From: Steve Portly <[EMAIL PROTECTED]>
Subject: Re: Metallurgy and Cryptography
Date: Sun, 18 Feb 2001 14:33:43 -0500



Tad Johnson wrote:

> Hello All ---
>
> I just realized something:
>
> Don COPPERsmith...
> Bob SILVERman...
> Benjamin GOLDberg...
>
> What the heck is going on here?

Gee those are old resister banding codes from the 60's
Maybe we made a wrong turn and ended up in the Museum?

I wish they would make those signs easier to read.



--

From: "Doom the Mostly Harmless" <[EMAIL PROTECTED]>
Subject: Re: My encryption system.
Date: Sun, 18 Feb 2001 19:36:31 GMT


>   Time to set an appointment with a psychiatrist...
>
> Take it easy, you will be in good company.
>
> BNK


Hey!  Some of us who /do/ see shrinks might not want to be associated with
this "gentleman."


--
To air is human
  --Doom.



--

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: National Security Nightmare?
Date: Sun, 18 Feb 2001 20:49:15 +0100



"Douglas A. Gwyn" wrote:
> 
> Mok-Kong Shen wrote:
> > As to technological knowledgeable peoples, are you sure
> > that you have every and absolute good grounds to blame
> > those that deviate from an ethical line in countries
> > where teaching staffs in universities could barely
> > support a moderate sized family with their salaries?
> 
> I don't know where you're getting your ideas, but I
> certainly never said nor implied that.  My opinion is
> that the War on Drugs is worse than hopeless because
> the real problem is the demand for the product, not
> the production of the drugs.

You said, if I interpreted your words correctly, that 
ethics and education solve the problems or at least help
in very essential ways and that tracking of nodes of the
criminals on the internet could be done as effectively as 
done in war on drugs (in tracking the drug traffic). My 
opinions were that ethics apparently wouldn't work in face 
of hunger or the like (extreme low income etc.) and that 
war on drugs hasn't provided a good record to show the 
efficacy of tracking techniques, for it in fact fails, as 
you also agreed.

> > ... All this serves to support my prediction
> > that the surveillance apparatus of communications would
> > have their efficacy reduced to almost negligibility in
> > the (hypothetical but possible) case where all common
> > people make use of encryption, thus creating a situation
> > of an order of magnitude more difficult to deal with
> > than what alreay is today.
> 
> No, as I said that is not where the real problem lies.

There we disagree. My point is that the capacity (resources)
by far wouldn't suffice in that (hypothetical) situation, 
which is implicitly contained in what NSA's director said
in my interpretation.

M. K. Shen

--

From: [EMAIL PROTECTED] (Hard)
Subject: Re: Super strong crypto
Date: Sun, 18 Feb 2001 19:47:59 GMT

On Sun, 18 Feb 2001 01:23:11 -0600, [EMAIL PROTECTED] (wtshaw) wrote:

>In article <[EMAIL PROTECTED]>, Steve Portly
><[EMAIL PROTECTED]> wrote:
>> 
>> The implementations that pop into mind would be temptingly easy to modify
>> into much stronger configurations.  Unless there is some new breakthrough
>> that will balance the equation, I don't see an organization like NIST
>> approving such a cipher scheme?
>
>Do you always do what you are told?
I know, I know...  it was directed to Steve but IMHO:

If he actually does viable work in the crypto world which equates to
making a living while providing prudent reality-based security for
clients than, with respect to NIST, he probably should.

But if he wants to *not* work in cr

Cryptography-Digest Digest #711

2000-09-18 Thread Digestifier

Cryptography-Digest Digest #711, Volume #12  Mon, 18 Sep 00 19:13:00 EDT

Contents:
  Re: A conjecture - thoughts? (Andru Luvisi)
  Re: Chosen and known attacks - are they possible ?? (DJohn37050)
  Re: Optimization for speed question. ("Tor Rustad")
  Re: A conjecture - thoughts? (David A. Wagner)
  Re: A conjecture - thoughts? (Mok-Kong Shen)
  Re: Extremely slow in DES software implementation ([EMAIL PROTECTED])
  Re: QUESTION ABOUT ALGORITHMS (Terry Ritter)
  Q: Crypto-PC (Mok-Kong Shen)
  transformation completeness and avalanche effect ("Stanley")
  Re: A conjecture - thoughts? (John Myre)
  Re: Software patents are evil. (Roger Schlafly)
  Re: For the Gurus ("root@localhost " <[EMAIL PROTECTED]>)
  Re: A conjecture - thoughts? (Andru Luvisi)
  Re: Optimization for speed question. ("Dann Corbit")
  Re: A conjecture - thoughts? (Ian Goldberg)
  Re: ExCSS Source Code (Bryan Olson)
  Re: 20 suggestions for cryptographic algorithm designers (Benjamin Goldberg)
  Re: winace encryption algorithm (Benjamin Goldberg)
  Re: One-way encryption (David Hopwood)



From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: A conjecture - thoughts?
Date: 18 Sep 2000 13:16:47 -0700

Mok-Kong Shen <[EMAIL PROTECTED]> writes:
> Andru Luvisi wrote:
> > 
> > I have the following conjecture:
> > 
> > If f() and g() commute, that is f(g(x)) = g(f(x)) for all x, then
> > f() and g() are both powers of some base function, b^y(x_0, x),
> > where x_0 and x are the same the first time through, x_0 stays the
> > same on every itteration, and the output is fed back into x.
> 
> The notation b^y(x_0, x) isn't quite clear for me.
> Could you illustrate with an example?
> 
> M. K. Shen

What I'm trying to get at is that the function is iterated, but has a
parameter which is set when it is called and stays the same.  For
example:

 f(x) = x^5
 g(x) = x^27

f(x) = b^4(x_0, x)
g(x) = b^27(x_0, x)
where b(x_0, x) = x*x_0


Argh.  Let me put it in C notation:

int b(int x_0, int x) {
  return x_0 * x;
}

int b_to_the_n(x, n) {
 int i, x_0;
 
 for(i = 0, x_0 = x; i < n - 1; i++) {
   x = b(x_0, x);
 }

 return x;
}

Does that make it any clearer?  An iterated function with a memory of
its first argument.

More examples:
f(x) = x + 5
g(x) = x + 27

b(x_0, x) = x + 1(no need for x_0 in this case)
f(x) = b^4(x_0, x)
g(x) = b^26(x_0, x)

Or:
f(x) = x * 5
g(x) = x * 27

b(x_0, x) = x + x_0
f(x) = b^4(x_0, x)
g(x) = b^26(x_0, x)

Is there some other accepted notation for this sort of thing?

Andru
-- 
Andru Luvisi, Programmer/Analyst

--

From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Chosen and known attacks - are they possible ??
Date: 18 Sep 2000 20:42:33 GMT

Chosen ciphertext assumes the adversary has access to your decrypter for a
time, but not all time and uses this to try to recover the key stored inside. 
It is the most powerful attack.
Don Johnson

--

From: "Tor Rustad" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: Optimization for speed question.
Date: Mon, 18 Sep 2000 22:40:24 +0200

"Dann Corbit" <[EMAIL PROTECTED]> wrote in message
> "Tor Rustad" <[EMAIL PROTECTED]> wrote in message

[...]

> > Is it the figure 2^{-80} you argue about?  I don't know how many times
> > your
> > program can be run without giving the wrong answer on todays HW. However,
> > 2^{80}
> > is a *very* big number, IIRC the number of microseconds since Big Bang is
> > approx. the same magnitude as this figure!
> >
> > I simply don't beleave that your program could have been run anywhere near
> > this figure, without giving the wrong answer...
>
>
> Miller-Rabin does not issue a certificate of primality.  Only a
> "probably-prime" status with a margin of error.  It is a good "first test"
> to see if you want to waste time trying to prove a number prime or not, but
> it cannot be used to show that a number is prime.  Only that it might be
> prime.

The error probability of Miller-Rabin is easy to control, to me proving
something on a computer beond a 2^{-80} error probability does not make the
proof better.

For sake of argument, let us increase the security margin to 2^{-160}. Then if a
provable prime algorithm gives a different result than Miller-Rabin did, which
method is right?

My bet would be the algorithm which used the less CPU time...


> > You did 2 weeks of optimization work, I would instead choosen to drop
> > Lucas-Lehmer and Jacobi sum test and settled for probable primes...
>
> Nonsense.  If you want to prove something, Miller-Rabin is simply the wrong
> way to go about it.  That is becau

Cryptography-Digest Digest #711

2000-05-05 Thread Digestifier

Cryptography-Digest Digest #711, Volume #11   Fri, 5 May 00 13:13:01 EDT

Contents:
  Re: AEES Advanced (Runu Knips)
  Re: Tempest Attacks with EMF Radiation (Diet NSA)
  Re: GPS encryption turned off ([EMAIL PROTECTED])
  Re: I saw this in /. and I thought of you (all) (arnold yau)
  Re: Crypto Export  ([EMAIL PROTECTED])
  Re: mod function? (Tom St Denis)
  Re: U-571 movie (back on topic) (Jim Reeds)
  Re: U-571 movie (back on topic) (Thomas Scharle)
  Re: SBOX program using ideas from CA and ST (CAST design) (Tim Tyler)
  Re: U-571 movie (back on topic) (Jim Gillogly)
  Re: RC6 as a Feistel Cipher (Anton Stiglic)
  Re: GPS encryption turned off (Paul Koning)
  Re: Interleaving for block encryption (Paul Koning)
  Re: GPS encryption turned off (Paul Koning)
  Re: mod function? (Mark Wooding)
  Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails on  (Andoni)
  Re: KRYPTOS Something new ? ([EMAIL PROTECTED])



Date: Fri, 05 May 2000 17:14:23 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: AEES Advanced

ink wrote:
> A statement like "If the program is too slow, use a faster
> computer" should be banned.

I agree fully. Good programs are simple and fast.

--

Subject: Re: Tempest Attacks with EMF Radiation
From: Diet NSA <[EMAIL PROTECTED]>
Date: Fri, 05 May 2000 08:20:30 -0700


In article <
8eu5co$57l$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Richard Herring)
wrote:

>If you wish to accept snake-oil salesmen as authorities on the
correct
>use of scientific terminology, that's your prerogative.
>

If the snake-oil salesman are more
correct than you are (in the context this
thread is discussing), then why not accept
their correct use of the terminology?


>I've still never seen anyone competent use "EMF" to mean
>"electric & magnetic field".


Then perhaps you are not familiar, for
instance, with the U.S. Department of
Energy, the National Institute of
Environmental & Health Safety, or various
National Labs. See, e.g. :

http://www.pnl.gov/molbio/bioelec.htm

http://www.niehs.nih.gov/emfrapid

http://www.emf-data.org




"640K of memory ought to be enough for anybody"   - Bill Gates (1981)
=
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!


--

From: [EMAIL PROTECTED]
Subject: Re: GPS encryption turned off
Crossposted-To: sci.geo.satellite-nav
Date: Fri, 05 May 2000 15:24:34 GMT

In sci.crypt Paul Rubin <[EMAIL PROTECTED]> wrote:
> OTAR still seems worrisome.  Say the attacker "borrows" a live receiver
> (e.g. by bribing or seducing the GI in the bar) for long enough to
> extract the algorithm and internal keys, and then gives the unit back
> to the GI so it stays on the whitelist.  (If necessary, the unit given
> back to the GI is a new one that's been newly programmed with the old
> unit's keys, since the old unit has been physically trashed by the key
> extraction process).  Now the attacker gets all the key updates which
> s/he can propagate into other receivers.  The entire security seems
> to rest on the physical tamper resistance of the handheld receiver.
> That seems like a serious vulnerability to me.

Current practices deal with this reasonably well though. For one, GPS
units are a sensitive item and thus cannot be removed from the armory
without signing by serial number. It's also illegal to transport them
in a privately owned vehical. Seducing a GI in a bar presumes that GPS
routinely travel to bars with GIs which is clearly not the case. ;)

The same applies to replacing compromised units with a new one. Since
they're accounted by serial number at least every twelve hours, you'd
need an almost real-time method of casting the case with the correct
number.

There's also the serious issue of finding a keyed device. They're
normally only filled on real-world deployments or for very special
occasions such as verifying a land navigation course. In either case,
it would be difficult to steal one.

-- 
Matt Gauthier <[EMAIL PROTECTED]>

--

From: arnold yau <[EMAIL PROTECTED]>
Subject: Re: I saw this in /. and I thought of you (all)
Date: Fri, 05 May 2000 10:41:12 +0100

> I didn't see the point in having a go at thise specially as no 
> algorithm has been posted (just a tiny fragment of plaintext).

well... one incentive would be the astronomical amount of $25.00 in gift
certificate, but I am not paritcularly tempted to spend hours on it
either.

One point I think is worth making is that even though this may not be
'real' cryptography (as

Cryptography-Digest Digest #711

1999-12-09 Thread Digestifier

Cryptography-Digest Digest #711, Volume #10   Thu, 9 Dec 99 16:13:01 EST

Contents:
  Re: If you're in Australia, the government has the ability to modify  (Vernon 
Schryver)
  Re: NP-hard Problems (Anton Stiglic)
  symmetric encryption based on integer factoring (Tom St Denis)
  Re: Random Noise Encryption Buffs (Look Here) ("Tony T. Warnock")
  Re: If you're in Australia, the government has the ability to modify your files. >> 
4.Dec.1999 (zapzing)
  Re: Synchronised random number generation for one-time pads ("Tony T. Warnock")
  Re: NSA should do a cryptoanalysis of AES (wtshaw)
  Re: Shamir announces 1 sec break of GSM A5/1 (Tim Tyler)
  Re: Shamir announces 1 sec break of GSM A5/1 (Tom St Denis)
  Re: If you're in Australia, the government has the ability to modify your files. >> 
4.Dec.1999 (wtshaw)
  Re: Digitally signing an article in a paper journal (wtshaw)
  Re: NSA should do a cryptoanalysis of AES ("karl malbrain")
  Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamirdescribe
in a paper ... (Jim Dunnett)
  Re: NSA future role? (Jim Dunnett)
  Re: NSA future role? (Jim Dunnett)
  Re: Synchronised random number generation for one-time pads (Tim Tyler)
  Re: Synchronised random number generation for one-time pads (Tim Tyler)
  Re: Shamir announces 1 sec break of GSM A5/1 (Troed)
  Re: NSA future role? (JCA)



From: [EMAIL PROTECTED] (Vernon Schryver)
Crossposted-To: alt.privacy
Subject: Re: If you're in Australia, the government has the ability to modify 
Date: 9 Dec 1999 10:38:50 -0700

In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
>Greg wrote:

>> If you have Microsoft Windows and Internet Explorer, your
>> government has the ability to modify your files. ...

>It would be nice if you could get your facts straight.
>Presumably you're talking about the so-called "NSAkey".
>If so, you've completely mischaracterized it.

Yes, the NSAKey nonsense was silly, but what about an ActiveX applet signed
in the normal way by a nominally legitimate outfit using its official key?
How many people go to the trouble of trying to make Internet Explorer
ignore ActiveX, especially given the obscurity of those buttons, the
warnings from IE after you fiddle with them, and the hassles should you
want to "update" your version of Windows or IE or just check to see what
updates Microsoft is suggesting today?

What about an Outlook Express email attachment?

A paranoid cynic might view the idiotic hysteria about nonsense
such as the NSAkey, the PIII ID, and IPv6 addresses as calculated
efforts make the suckers think--er--feel there are no real problems.


Vernon Schryver[EMAIL PROTECTED]

--

From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: NP-hard Problems
Date: Thu, 09 Dec 1999 13:26:15 -0500


I guess it would depend on the definition of the reduction
used. There is more than one definition of reduction in
complexity theory.  The one in Intro to Algorithms, from
Cormen, Leiserson and Rivest define reductions as beeing
done in polynomial time of languages (decisional based).

Anton


--

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: symmetric encryption based on integer factoring
Date: Thu, 09 Dec 1999 19:02:02 GMT

I was plumbing around with the idea of a cryptosystem based around
factoring such as

C = (P * g^x) mod p
P = (C * g^-x) mod p

Where given the ciphertext you have to factor it to determine what the
plaintext could be [as long as p is prime, and g is a generator, and
that the mult. inverse of g is a gen as well].   Each message would
have their own 'x' derived somehow [RNG?]

I then proceded to brutally assalt it.  I made an attack using one
known plaintext if you re-use 'x' or use 'x' values close together [by
exploiting the base].

So then I ask what would be a good method of choosing new 'x' values
per message?  I was thinking of making x odd, then X=x, x' = x + X, so
the gap between successive X values is not known.  Could the same
attack exploit it?

Just an idea :)

I would love feedback.


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

--

From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Thu, 09 Dec 1999 12:15:23 -0700
Reply-To: [EMAIL PROTECTED]

"Douglas A. Gwyn" wrote:

> "Trevor Jackson, III" wrote:
> > Guy Macon wrote:
> > > [EMAIL PROTECTED] (Tony T. Warnock) wrote:
> > > >The most probable waiting time between decays is zero.
> > > No it isn't.
> > How do you fogiure otherwise?  Given an exponential decay expect

Cryptography-Digest Digest #711

1999-06-13 Thread Digestifier

Cryptography-Digest Digest #711, Volume #9   Sun, 13 Jun 99 07:13:05 EDT

Contents:
  Re: Slide Attack on Scott19u.zip (SCOTT19U.ZIP_GUY)
  Re: Slide Attack on Scott19u.zip ([EMAIL PROTECTED])
  Re: Challenge to SCOTT19U.ZIP_GUY (Thomas Pornin)
  Re: RSA example with small numbers ([EMAIL PROTECTED])
  Re: DES ([EMAIL PROTECTED])
  Re: Slide Attack on Scott19u.zip ([EMAIL PROTECTED])
  Re: Slide Attack on Scott19u.zip (SCOTT19U.ZIP_GUY)
  Re: Yet another simplecipher (YASC) ([EMAIL PROTECTED])
  Re: cant have your cake and eat it too ("Douglas A. Gwyn")
  Re: Caotic function ("Douglas A. Gwyn")
  Re: DES ("Douglas A. Gwyn")
  --- sci.crypt charter: read before you post (weekly notice) (D. J. Bernstein)
  Re: RSA msg length... (Eric Young)



From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Slide Attack on Scott19u.zip
Date: Sun, 13 Jun 1999 01:25:44 GMT

In article <7jumfq$b1m$[EMAIL PROTECTED]>, 
[EMAIL PROTECTED] (David Wagner) wrote:
>In article <7jue3a$2ci0$[EMAIL PROTECTED]>,
>SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>>  Just what do you mean bypass the fact the first and last round
>> are different. DO you mean your attacking a reduced version
>> of Scott19u. I think that reduced version attack was kind of what
>> Paul Onions did a long time ago?
>
>I'm not suggesting to attack a reduced version.

Then you have to face the fact of the two other passes
front and back and also the fact that 8 bytes is the smallest
file. so there can be no attack less than 64 bits.

>
>I'm referring to the earlier comment that the same S-box entry
>will not be used in the first and last round, since in all likelihood
>the 19-bit input to the S-box will be different.
>This fact was claimed to make slide attacks impossible.
>
>I was suggesting that this fact might not be so bad (for the attacker)
>as it seems; that you can still make slide attacks work, even though
>different S-box entries are used.
>
>> >
>> >The primary equation is C[i] = S{(P[i] + P[i+1]) xor C[i-1]},
>> 
>>  Actually in your notation it is C[i]=S{(C[i-1] xor P[i]) + P[i+1]
>>   where if the first 19 bits of Pass call P[0] then C[-1] is the last
>>  nineteen bits used in the file. The min file length is 64 bits.
>
>Oops, serves me right for not looking it up.  Anyhow my point below it
>is still valid (I think), you just have to change the equations slightly.
>
>>  THe complete file is rotated 9 bits up so the the top 9 bits of C[0] go to
>>  bottom of the file. Also there is a first and last round the Paul function
>> that is different from the 23 rounds that are represented by the
>> equations above. When one gets to the end of file it borrows for the top
>> of file rest of C[0] and C[1] so that the most C[m] is such that parts of the
>> last P[n] and P[n+1] could be using parts od C[0] and C[1] The Paul function
>> named after Paul Onions is very short and you can see the code to see
>> how that interacts with things.
>
>Ok, I have to admit you lost me here.  Sorry.

Then lets do one pass of these 23 repeated center passes for scott19u.zip

  You lay the file out in memory so you have 64 bits. 
   then define the last 19 bits is C[-1]   then one you
  do C[0]= S{ (C[-1] xor P[0] ) + P[1]}  
   know copy the contents of C[0] to the bottom of the file 
   you know have 83 bits.
   note P[0] the first 19 bits P[1] the  next 19 bits.

   know comes the hard part replace the top 10 bits of P[0]
   with the last 10 bits of C[0].   We have just calculated
   the first 10 bits out for the pass.

   Do C[1]= S{(C[0] xor P[1]) + P[2]}   place C[1] right after the
   loction in memory where C[0] is. That way know all of P[0]
   is rewritten this pass and the first 10 bits of P[1]


   Do C[2]= S{(C[1] xor P[2])+ P[3])  place C[2] right after C[1]
   you know have from the top replaced 10 + 19 + 19 for 48 bits
   at this point P[3] has 7 bits of itself and the top 12 bits of C[0]
   Since 48 + 19  = 67 is greater than 64 the original lenght of
   file you are done this pass calling the main equatiion
   but there is 64-48  16 bits left 

  so you shift up the file from the bottom so that P[3] is placed next 
  to C[2]   This is a 9 bit shfit. Notice that when you calulated C[0]
  at front of pass and added this to bottom of file. You end up having
  the nine bits lost from the first C[0] now at the bottom. This means
  that for the 64 bit file only 3*19  57 bits are replaced so that 7  bits
  are not changed this pass but are rotated in the file up 9 bit positions.
  this means that those 7 bits which have not changed get changed
  during the next pass since they are part of P[2] on the next pass.
 
  


David A. Scott
--