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 CoNP. If
either is NP-Complete, then NP=CoNP.
For those not familiar with the definitions, CoNP is the
set of languages who's comp
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 stdio.h
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
/c
In the above, c could be any real but using c = floor[b] which gives a
simple recurence. For exemple on the segment 1=b=2 we get
/b
f[b] = 1 - | 1/t dt
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 clearly a few bits short of a byte. A thread plonk is tempting, but on the other hand it's mildly amusing to see just how deep a hole Mr Szopa can dig for himself before he finally sees what he's done to his reputation. -- Richard Heathfield "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999. C FAQ: http://www.eskimo.com/~scs/C-faq/top.html 34 KR Answers: http://users.powernet.co.uk/eton/kandr2/index.html (63 to go) You are better off ignoring the OAP-L3 encryption software package along with its Help Files. You n
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 some patterns
so it isn't random.
Regards,
Coen Visser
--
From: [EMAIL PROTECTED] (John Savard)
Subject: "Fingerprinting" an algorithm?
Date: Fri, 03 Dec 1999 00:41:59 GMT
On 19 Nov 1999 09:21:36 -0700, crippa [EMAIL PROTECTED]
w
