Cryptography-Digest Digest #669
Cryptography-Digest Digest #669, Volume #13 Sat, 10 Feb 01 10:13:01 EST
Contents:
a exp b mod n ([EMAIL PROTECTED])
Re: OverWrite freeware completely removes unwanted files from hard drive (Hit1Hard)
Re: NPC (Bryan Olson)
Re: CipherText patent still pending (Bryan Olson)
Re: CipherText patent still pending (Bryan Olson)
Re: CipherText patent still pending (Bryan Olson)
Re: Shortened signatures (Matt J)
Password authentication with symmetric key exchange ([EMAIL PROTECTED])
Re: Shortened signatures (Quisquater)
Re: a exp b mod n (Tom St Denis)
Re: OverWrite freeware completely removes unwanted files from hard (Andreas
Gunnarsson)
Re: NPC (Benjamin Goldberg)
Re: Scramdisk, CDR and Win-NT (jungle)
What is kerebos? (B. Wooster)
Re: Rijndael S-box derivation (Benjamin Goldberg)
Re: What is kerebos? ("Sam Simpson")
Re: Rijndael S-box derivation ("Brian Gladman")
From: [EMAIL PROTECTED]
Subject: a exp b mod n
Date: Sat, 10 Feb 2001 10:12:22 GMT
Hi all!
I wanted to test a method that should return a exp b mod n. I copied it
from Bruce Schneier's Applied Cryptography. There are two such methods,
that I used with "unsigned long"s in C++, but both return 0 if a and b
get higher. n is a 32-bit prime number. Does anyone have some working
code?
THanks,
Heinz
Sent via Deja.com
http://www.deja.com/
--
From: Hit1Hard <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker,alt.conspiracy
Subject: Re: OverWrite freeware completely removes unwanted files from hard drive
Date: Sat, 10 Feb 2001 05:37:28 -0500
Anthony Stephen Szopa wrote:
>
> So where are these technological sophisticates: these brain drained
> mental armchair hackers, now?
>
They make sure the "crucial" information on the HD is encrypted with
their own encryption software.
wich is not placed on the system HD's.
Oh. And the swapfile is empty.
>
> Thanks for the grilling.
anytime.
--
Hit1Hard
--
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: NPC
Date: Sat, 10 Feb 2001 11:33:51 GMT
Peter Shugalev:
> I think someone tried to prove that either discrete log or
> factoring problem is NPC (not just NP). I'd like to see
> some results of these attempts.
The attempts have, to put it bluntly, failed.
Discrete log and factoring are poly-time reducible to
languages that are in the intersection of NP and CoNP. If
either is NP-Complete, then NP=CoNP.
For those not familiar with the definitions, CoNP is the
set of languages who's complements are NP. Languages in
NP are exactly those that have short-certifiers; informally,
if a string is in the language, then there exists a
poly-time verifiable proof that it's in the language. For
example to show a boolean expression is in SAT, one could
exhibit the satisfying assignment. But there's no
requirement that non-membership in an NP language be so
efficiently demonstrable.
Languages in CoNP have short-certifiers for non-membership.
If NP=CoNP, then any language with a short-certifier of
membership also has a short-certifier of non-membership.
The NP ?= CoNP conjecture is one of the great unsolved
problems. In this field, conjectures tend to either be
resolved very quickly (often by the time one has the
understanding to form them) or to remain open unto the
present. The NP != CoNP conjecture is like P != NP
in that it looks to be probably true and very hard to
prove.
Of course if P=NP then P=NP=CoNP.
> And if they are *not* NPC. Do you know any attempt to
> create a public key algorithm based on the problem
> that is known to be NPC?
"Based on" is too sketchy, as Peter Shugalev's remarks
suggested. We say that RSA is based on factoring, but
breaking it is at _most_ as hard as factoring. What we'd
like is a system such that we can reduce deciding an
NPC language to breaking the system.
The NP ?= CoNP problem seems fundamental here. The
true decryption constitues a certificate for the
correctness or incorrectness of any cryptanalysis.
Thus any system that allows unique decryption (and is
tractable) is reducible to something in the
intersection of NP and CoNP. And so a proof that
breaking it is NP-hard would also prove NP!=CoNP.
--Bryan
Sent via Deja.com
http://www.deja.com/
--
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: CipherText patent still pending
Date: Sat, 10 Feb 2001 11:40:16 GMT
IPeter Shugalev:
> I think someone tried to prove that either discrete log or
> factoring problem is NPC (not just NP). I'd like to see
> some results of these attempts.
The attempts have, to put it bluntly, failed.
Discrete log and factoring are poly-time reducible to
languages that are in the intersection of NP and Co
Cryptography-Digest Digest #669
Cryptography-Digest Digest #669, Volume #12 Wed, 13 Sep 00 09:13:00 EDT
Contents:
Re: Kryptcon (Runu Knips)
Re: Dickman's function (George Marsaglia)
cellular automata rng? (Tom St Denis)
Re: Losing AES Candidates Could Be a Good Bet? (Tim Tyler)
Re: Kryptcon (Runu Knips)
Re: question on the bible code ("root@localhost " <[EMAIL PROTECTED]>)
Re: Police want help cracking code to find Enigma machine (Anders Thulin)
Re: Problem with Tiger hash algorithm and binary files (Daniel Leonard)
Date: Wed, 13 Sep 2000 12:16:44 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Kryptcon
[EMAIL PROTECTED] wrote:
> While I appreciate you taking the time to look at
> my program, I do not appreciate you being a jerk
> and telling me that it is crap.
If you tell a woman that she's a whore you're a
jerk, but if you tell that to a whore you're just
saying the truth; maybe the bitter truth, of
course.
And your program is surely crap, I'm sorry. I
don't say this to insult you, I'm just saying
what I believe is true.
Just look at your code. Don't you see those
masses of errors ? In the key expansion, you
never test if the string length is less than
2 (which would cause an underflow). You take
the string length of your key schedule, but
there is no guarantee that there is actually
a zero byte. Too, the length of your key
schedule is 512, NOT strlen(key).
===
keywork():
u = strlen(key);
for(1; u <=511; 1) {
t = key[u-1] + key[(u-2) % 31];
key[u] = t;
u++;
}
and filework():
i = (i < strlen(key))?i:0;
inc = (pow(key[i],2) * 751 - key[i]);
==
But also cryptographically, this is no good
algorithm. You expression (k*k*751-k), for
example,
#include
int main (int argc, char *argv[])
{
int i;
for (i = 0; i != 256; ++i) {
printf ("%3d,", (i*i*751-i) % 255);
if ((i + 1) % 16) {
printf (" ");
} else {
printf ("\n");
}
}
return 0;
}
expands to the following, extremely bad sbox:
0, 240, 197, 126, 27, 155, 0, 72, 116, 132, 120, 80, 12, 171,
47, 150,
225, 17, 36, 27, 245, 180, 87, 221, 72, 150, 200, 222, 216, 182,
120, 30,
167, 21, 102, 155, 180, 177, 146, 87, 0, 140, 252, 81, 137, 165,
165, 137,
81, 252, 140, 0, 87, 146, 177, 180, 155, 102, 21, 167, 30, 120,
182, 216,
222, 200, 150, 72, 221, 87, 180, 245, 27, 36, 17, 225, 150, 47,
171, 12,
80, 120, 132, 116, 72, 0, 155, 27, 126, 197, 240, 0, 242, 201,
132, 35,
165, 12, 86, 132, 150, 140, 102, 36, 197, 75, 180, 2, 51, 72,
65, 30,
222, 131, 12, 120, 200, 252, 21, 17, 240, 180, 92, 231, 87, 170,
225, 252,
251, 222, 165, 80, 222, 81, 167, 225, 0, 2, 231, 177, 95, 240,
102, 191,
252, 30, 35, 12, 216, 137, 30, 150, 242, 51, 87, 95, 75, 27,
206, 102,
225, 65, 132, 171, 182, 165, 120, 47, 201, 72, 170, 240, 27, 41,
27, 240,
170, 72, 201, 47, 120, 165, 182, 171, 132, 65, 225, 102, 206, 27,
75, 95,
87, 51, 242, 150, 30, 137, 216, 12, 35, 30, 252, 191, 102, 240,
95, 177,
231, 2, 0, 225, 167, 81, 222, 80, 165, 222, 251, 252, 225, 170,
87, 231,
92, 180, 240, 17, 21, 252, 200, 120, 12, 131, 222, 30, 65, 72,
51, 2,
180, 75, 197, 36, 102, 140, 150, 132, 86, 12, 165, 35, 132, 201,
242, 0,
One can immediately see that, for example, zero
appears many times. So your expression
(i*i*751-i) in fact worses the properties of the
algorithm ! For example, there can never be a
difference of 1 to the original text.
I'm not a crypto guru or such, but your
algorithm is really bad.
--
From: George Marsaglia <[EMAIL PROTECTED]>
Crossposted-To: sci.math.num-analysis
Subject: Re: Dickman's function
Date: Wed, 13 Sep 2000 06:58:40 -0400
Francois Grieu wrote:
> I'm trying to find or devise simple C code to compute Dickman's
> function. For non-negative reals a, this function gives the proportion
> of integers N such that the highest prime factor of N is less that N^a.
> It verifies:
>
> /1
> F[a] = 1 for a>=1 F[a] = 1 - | F[t/(1-t)]/t dt for 0<=a<=1
>/a
>
> Reference: Donald E. Knuth, The Art of Computer Programming, volume 2,
> section 4.5.4, p367 (2nd ed) or p383 (3rd ed).
> Online ref: <http://mathworld.wolfram.com/DickmanFunction.html>
>
> Things I tried so far are very imperfect, but here they are. It is handy
> to define the auxiliary function f[b] = F[1/b] and we get
>
> /b
> f[b] = 1 for 0<=b<=1 f[b] = f[c] - | f[t-1]/t dt for b>=c>=1
>
Cryptography-Digest Digest #669
Cryptography-Digest Digest #669, Volume #11 Sun, 30 Apr 00 09:13:00 EDT Contents: Re: OAP-L3: Semester 1 / Class #1 All are invited. (Tom St Denis) Re: OAP-L3: Secure, but WAY more dificult to use than other equally secure programs (Anthony Stephen Szopa) Re: OAP-L3: Secure, but WAY more dificult to use than other(Tom St Denis) Re: Janet and John learn about bits (was Re: Problems with OAP-L3) (Anthony Stephen Szopa) Re: Janet and John learn about bits (was Re: Problems with OAP-L3) (Anthony Stephen Szopa) Re: Janet and John learn about bits (was Re: Problems with OAP-L3) (Anthony Stephen Szopa) Re: Janet and John learn about bits (was Re: Problems with OAP-L3) (Anthony Stephen Szopa) Re: Janet and John learn about bits (was Re: Problems with OAP-L3) (Mark Wooding) Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa) From: Tom St Denis <[EMAIL PROTECTED]> Crossposted-To: talk.politics.crypto Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited. Date: Sun, 30 Apr 2000 12:11:25 GMT Anthony Stephen Szopa wrote: > We are talking about encryption. > > We ARE talking about secure encryption. Gotcha so far. > If a random number generator is used for a purpose that does > not require security are you saying that it may somehow be > insecure for that use? We are not talking about random number generators though. > Crazy thinking. I'll bet. > It may be unsuitable for some reason but not insecure. > > T.H. is talking about the random digit generator from which he will > never obtain any useful input in practice for his supposed method of > determining the MixFile sequences. > > T.H. is making up his own problem and ignoring the OAP-L3 > implementation as it currently exists in an attempt to cast some > sort of doubt over OAP-L3. I already posted my problems, which you have yet to answer to. > He cannot answer a question by changing the question or imagining > another question. By "he" you are referring to yourself? > The question is whether or not OAP-L3 is secure. I say it is > secure: it is unbreakable when used according to > recommendations with a sufficiently long key. The Theory and > Processes Help Files support my position. > > I have yet to hear or see any evidence to the contrary after three > years. I am still waiting. Ok I will use your program and enter completely biased seeds... How secure is it now? Why not answer some of *MY* questions instead of changing the topic yourself. Tom -- From: Anthony Stephen Szopa <[EMAIL PROTECTED]> Crossposted-To: talk.politics.crypto Subject: Re: OAP-L3: Secure, but WAY more dificult to use than other equally secure programs Date: Sun, 30 Apr 2000 05:13:28 -0700 Richard Heathfield wrote: > > Tom St Denis wrote: > > > > Anthony Stephen Szopa wrote: > > > > > > Tom St Denis wrote: > > > > > > > > > So you should not waste anymore of your time conversing with me. > > > > > There are plenty of other suckers out there for your delectation. > > > > > > > > You see, you didn't respond to my questions. You just targteted *me*. > > > > How about you focus on your 'theory' and less the posters. > > > > > > > > Face it, your a troll. > > > > > > > > Tom > > > > > > Take my advice: > > > > > > Don't waste your breath. > > > > ARrg.. why don't you answer a real question? > > > > I am reminded of Saruman, arguing with hobbits. It (such banter) was a > clear sign that, whatever mastery of his art he had once had, he had > lost it. Whatever majesty he might have commanded, he was now nothing > but an itinerant beggar. > > The hobbits came out of it far better than Saruman, if I recall > correctly. > > I'm not sure why anyone is wasting time arguing with this guy. He's > clearly bright but, equally clearly, he's either an idiot or an idiot. I > don't know much about cryptography, but I do know this: no source code, > no trust. No algorithm, no trust. Mr Szopa's security should be placed > in his key - not in his algorithm, his source code, or his incendiary > rhetoric. And his algorithm does not place all the security in the key. > If it did, he'd be falling over himself trying to prove it by showing > the algorithm and the source. Instead, he's doing his best to convince > us that he's an idiot and, on the whole, he's succeeding. Anyone who > hurls abuse at teenagers and flames Doug Gwyn in the /same thread/ is > cle
Cryptography-Digest Digest #669
Cryptography-Digest Digest #669, Volume #10 Thu, 2 Dec 99 20:13:02 EST
Contents:
Re: Quantum Computers and Weather Forecasting ("Trevor Jackson, III")
Re: more about the random number generator (CLSV)
"Fingerprinting" an algorithm? (John Savard)
Re: Any negative comments about Peekboo free win95/98 message encryptor program ?
(Steve K)
Re: Why Aren't Virtual Dice Adequate? ("Trevor Jackson, III")
Re: Random Noise Encryption Buffs (Look Here) ("r.e.s.")
Re: Any negative comments about Peekboo free win95/98 message encryptor (Keith A
Monahan)
Date: Thu, 02 Dec 1999 19:26:48 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.physics,sci.geo.meteorology
Subject: Re: Quantum Computers and Weather Forecasting
John Savard wrote:
> Quantum computers potentially offer the possibility of performing a
> computation in parallel for an enormous number of different
> combinations of input parameters, and then producing a result for only
> one such combination if that combination produces a result that meets
> certain criteria.
>
> This may be useful to extend the range and accuracy of weather
> forecasting.
>
> Although chaos theory sets an irreducible limit to the useful range of
> advance forecasts of weather, based on the growth of random inputs
> caused by nonlinearities in the system,
>
> in practice, the limit imposed by the limitations in the precision and
> detail of input data about the state of the weather at a given moment
> impose a stricter limit.
>
> It is theoretically possible to obtain information about the missing
> components of the state of the Earth's atmosphere at a given time by
> the following technique: for each possible set of values for the state
> of the unobserved part of the Earth's atmosphere, run the equations
> backwards to obtain a long-term "prediction" of the weather on
> preceding days. That hypothetical state of the atmosphere which
> produces the longest-term accurate forecast in the reverse direction
> is the state most likely to be correct.
>
> Quantum computers would seem to directly lend themselves to such a
> computation, should they become practical. (However, the limit on
> search algorithms may be fatal, as even the square root of the number
> of possibilities here is prohibitively large.)
>
> Perhaps there is a mathematical technique possible that avoids such
> extravagance, by working with the state of the weather several days
> ago, and incrementally updating missing parts of the atmospheric state
> in response to forecast errors. The principle would be the same: to
> use the depth of available atmospheric data in time to substitute for
> the lack of detail in our knowledge of the state of the atmosphere at
> any one moment.
A critical threshold exists in all such modeling systems. One must insure
that the error bounds on the modeled state values grow more slowly that
the information gained at each step. In essence, the backward prediction
has to converge.
One may run such a simulation backwards by increments, and thus detect
improbable initial states early in the search. The ability to prune the
state/search space reduces the size of the problem but does not improve
the "convergence" rate.
--
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: more about the random number generator
Date: Fri, 03 Dec 1999 00:24:42 +
Anton Stiglic wrote:
> Brian Chase wrote:
> > Naive question here. Let's say you had access to some "optimum
> > compressor" which would take arbitrary data sets distill them into their
> > most compact form. By definition, the resulting data must have no
> > predictable redundancies, yes?
Correct.
> > Could you use optimally compressed data
> > sets as sources for random numbers?
That would be nice, however optimal compression can not be computed
in reasonable time.
> Your input would have to be random, so might as well just use the input
> (you'd have more bits of randomness).
> If you don't use random input, and I know about the compression algo
> you use, I could just reverse the output (decompress) and look at the
> results. If they don't look random, I know you are not using random inputs,
> and might be able to predict futur outputs.
In Kolmogorov complexity an incompressible string is
as random as you can get. The intuition is that a string that is
optimally compressed has no redundancy or patterns that you can
use to compress it. Because it has not (useful) patterns it is
also random. If you could decompress a string into a larger
random string. That larger string obviously has
Cryptography-Digest Digest #669
Cryptography-Digest Digest #669, Volume #9Sun, 6 Jun 99 07:13:03 EDT
Contents:
Re: Scottu: I actually saw something usefull (Horst Ossifrage)
Re: random numbers in ml ([EMAIL PROTECTED])
--- sci.crypt charter: read before you post (weekly notice) (D. J. Bernstein)
Re: random numbers in ml ("almis")
Re: Challenge to SCOTT19U.ZIP_GUY (SCOTT19U.ZIP_GUY)
KRYPTOS ([EMAIL PROTECTED])
Re: PGP Info wanted... (fungus)
Re: random numbers in ml ([EMAIL PROTECTED])
Re: Break this simple cipher (Rod Ramsey)
Re: random numbers in ml (HackZoid of SideRs)
Re: 8Bit encryption code. Just try and break it. - code3.ecr (0/1) (fungus)
message encoding in RSA ("Lau, Jeff")
From: Horst Ossifrage <[EMAIL PROTECTED]>
Subject: Re: Scottu: I actually saw something usefull
Date: Sat, 05 Jun 1999 22:16:14 -1000
[EMAIL PROTECTED] wrote:
>
> On his page there is a brief description of the algorithm. I found this
>
> Cn = S{ (((Cn-1) XOR (Pn)) + (Pn+1))mod 2^W }
>
> Which happens to be the round function, where
>
> Cnis the ciphertext at n
> S is the large S-box
> Pnis the plaintext at n
>
> Now I know little of actually starting an attack, but from what I
> briefly saw, he runs from 0-n 25 times. Errors in the ciphertext
> propagate forwards only though (note Cn-1 usage). If he ran this
> forwards and backwards this might help (note: would have to use Cn+1
> which I did not see on his page).
>
> Which leads me to think that the first set of n-25 words leaks info
> about the s-boxes. The key schedule does not look too proper though..
>
> ---snip
>
> Step 1: Create a memory array of 64K words ( words in hexadecimal
> terminology). Call this array List1[i]. These words will have addresses
> i from 0 to hex. The values initially stored in these locations
> are simply 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, f, 10, 11,
> 12, ... etc. up to hex. Each of these values will be selected only
> once by the algorithm, and the value will be put in a location of the S-
> Box memory array that is chosen by Rules defined below. After a value
> from location i is put in the S-Box, location i is written with a new
> value, according to the Rules defined below.
>
> Step 2: Use the keyraw.key file with location pointed to by j. This
> keyraw.key file may have less than 64K words. Call each word key[j].
> Start at location j=0 and use the value at that location according to
> the Rules defined below to make an entry in the S-Box. Then j will be
> incremented through the whole keyraw.key file, and j will wrap around
> as many times as needed to finish making the S-Box.
>
> Step 3: Set x=1. Take the key value at j=0, add 1 to it, mod ((2^16)-1-
> x) and put that number in S-Box location 0. Place key[j]+1 in List1[S-
> Box[j]].
>
> Step 4: Set x=2. Take the key value at j=1, add 1+j to it, mod ((2^16)-
> 1-x) , and place that value in S-Box[S-Box[j-1]]. Place key[j]+1 in
> List1[S-Box[j]].
>
> Step 5: Set x=3. Take the key value at j=2, add 1+j to it, mod ((2^16)-
> 1-x) , and place that value in S-Box[S-Box[j-1]]. Place key[j]+1 in
> List1[S-Box[j]].
> .
> .
> .
> Step Y: Increment x and j. Take key[j], add 1+j to it, mod ((2^16)-1-
> x), and place that value in S-Box[S-Box[j-1]]. Place key[j]+1 in List1
> [S-Box[j]].
>
> Simple, yet oh so powerful! Right? Get it? Huh? No? Well, tough. Learn
> it, love it, live it.
> ---snip
>
> Looks to complicated. I would love to see a pro hack at it. Why
> doesn't he just use a key schedule like RC4? RC4 is really simple
> (that's why I like it) to implement and avoids implementation errors.
>
> I will have to read more of the page:
>http://members.xoom.com/ecil/page2.htm
>
> Basically it's a codebook cipher using the previous/next cipher/plain
> text as entries into the table. I think it's a little too simple
> (the 'round function') to be sure.
>
> Tom
Hello Tom, I wrote the documentation page for David A. Scott
last year. It may have some errors in it, but David says he did
not proof read my description of his algorithm. I hope that someday
he will proof read that website and make any corrections that
are necessary. Until he says that the documentation is accurate,
you should only consider that document to be a rough draft.
Horst Ossifrage
--
From: [EMAIL PROTECTED]
Crossposted-To: comp.sys.cbm
Subject: Re: random numbers in ml
Date: 6 Jun 1999 04:43:05 GMT
Reply-To: [EMAIL PROTECTED] (Matthew Montchalin)
For the algorithm posted, it seems that different seeds require different
lengths of time to repeat. For instance, if the initia
