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 thus f[b] = 1 - Log[b] for 1<=b<=2
> /1
>
> More symbolic integration does not help much: on segment 2<=b<=3 we need
> the PolyLog function, and farther the expression grows madly.
>
> Recursive numerical integration with a general method works for b up to
> say 5, then gets terribly slow. A faster variant is to build sucessive
> polynomial approximations at points j+1/2 for integers j>=0:
>
> fj[x] = f[x + (j+1/2)] = sum(Aij * x^i) + O(x^n)
> 0<=i<n
>
> Convergence is reasonably quick. However any rounding error or
> truncation made in computing a segment affects the next ones as an
> absolute error, and since the function decreases quickly to 0, we get
> totaly innacurate results for b>12 when using 64 bits IEEE arithmetic.
>
> Anyone has a method working for b up to say 40 without using arbitrary
> precision arithmetic or too many magic values ?
> 19.25 7.2851e-28 | 19.5 2.3646e-28 | 19.75 7.6446e-29 | 20 2.4618e-29
I developed a method some years ago, ~ 1970. It was described in
``Numerical Solution of Some Classical Differential-Difference
Equations,'' (1989) , Mathematics of Computation, 53, 191-201,
but it requires extended precision arithmetic. Many reported results,
based on numerical integration and not using extended precision,
were found to be far off the true values.
George Marsaglia
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: cellular automata rng?
Date: Wed, 13 Sep 2000 10:58:30 GMT
I was reading up Wolfman's paper on CA and the cryptanaylsis as well (
abit hard to understand at 6am... :) ).
Anyways, from what I got out of it, using 500 bit CA keys requires
trivial work to break, but when you get passed 1000 bits it's hard...
Hmm.
Here's my question. Let's say I have a 2048 bit (multiple of 32 :) )
CA state, can I take the first n bits to encode n-bit blocks per
clocking? Or do I have to spread the sampling of n-bits througout the
state (every 2048/n bits) or can I only take one bit at a time?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Losing AES Candidates Could Be a Good Bet?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 13 Sep 2000 10:57:54 GMT
Zulfikar Ramzan <[EMAIL PROTECTED]> wrote:
: From what's currently known, Serpent has a much much bigger security
: margin than Rijndael, yet at the same time Rijndael was significantly
: more popular than Serpent according to a poll taken at the last AES
: conference. [...]
In the Serpent paper, the authors claim Serpent to be very secure.
Looking at the reasons they presented, it seemed to mainly boil down
to having more rounds than the compeition. The fact that individual
rounds used smaller non-linear functions - and thus probably had
a lower potential for confusion - didn't seem to get much mention.
Additional rounds are good - but hardly a very conclusive demonstration
of additional strength. For one thing there are attacks which do not
depend critically on the number of rounds used.
Having said that, Rijndael notoriously doesn't have many more rounds
than it needs to be secure - so a comparing of "safety margins" - i.e.
the ratio between the number of rounds which the best known successful
attack can break, and the actual number of rounds may suggest Serpent
being more secure.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ VIPAR GAMMA GUPPY.
------------------------------
Date: Wed, 13 Sep 2000 13:21:34 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Kryptcon
Runu Knips wrote:
> I'm not a crypto guru or such, but your
> algorithm is really bad.
I made an error in the sbox generation program, it
should read expr % 256, not expr % 255. The resulting
sbox of the expression looks a little better, even
if all entries are even, i.e. the algorithm leaks
the lowest bit.
/*
** Times of occurence:
**
** 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0
** 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0
** 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0
** 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0
** 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0
** 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0
** 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0
** 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0
** 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0
** 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0
** 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0
** 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0
** 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0
** 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0
** 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0
** 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0
*/
unsigned char sbox[256] = {
0, 238, 186, 100, 236, 82, 150, 184,
184, 150, 82, 236, 100, 186, 238, 0,
240, 190, 106, 244, 92, 162, 198, 200,
168, 102, 2, 124, 212, 10, 30, 16,
224, 142, 26, 132, 204, 242, 246, 216,
152, 54, 178, 12, 68, 90, 78, 32,
208, 94, 202, 20, 60, 66, 38, 232,
136, 6, 98, 156, 180, 170, 126, 48,
192, 46, 122, 164, 172, 146, 86, 248,
120, 214, 18, 44, 36, 250, 174, 64,
176, 254, 42, 52, 28, 226, 134, 8,
104, 166, 194, 188, 148, 74, 222, 80,
160, 206, 218, 196, 140, 50, 182, 24,
88, 118, 114, 76, 4, 154, 14, 96,
144, 158, 138, 84, 252, 130, 230, 40,
72, 70, 34, 220, 116, 234, 62, 112,
128, 110, 58, 228, 108, 210, 22, 56,
56, 22, 210, 108, 228, 58, 110, 128,
112, 62, 234, 116, 220, 34, 70, 72,
40, 230, 130, 252, 84, 138, 158, 144,
96, 14, 154, 4, 76, 114, 118, 88,
24, 182, 50, 140, 196, 218, 206, 160,
80, 222, 74, 148, 188, 194, 166, 104,
8, 134, 226, 28, 52, 42, 254, 176,
64, 174, 250, 36, 44, 18, 214, 120,
248, 86, 146, 172, 164, 122, 46, 192,
48, 126, 170, 180, 156, 98, 6, 136,
232, 38, 66, 60, 20, 202, 94, 208,
32, 78, 90, 68, 12, 178, 54, 152,
216, 246, 242, 204, 132, 26, 142, 224,
16, 30, 10, 212, 124, 2, 102, 168,
200, 198, 162, 92, 244, 106, 190, 240,
};
------------------------------
From: "root@localhost <spamthis>" <[EMAIL PROTECTED]>
Crossposted-To: alt.bible.prophecy
Subject: Re: question on the bible code
Date: Wed, 13 Sep 2000 07:29:56 -0400
"Mr. Noel Yaki" wrote:
>
> "Mikal 606" <[EMAIL PROTECTED]> wrote:
>
> >I understand many peoples deep desire to believe in this code.
> >But I ask you, what else does it add?Are you not already a believer?
> >Do you understand what I mean?
>
> Proverbs 1:7 - The fear of the Lord is the beginning of knowledge; fools
> despise wisdom and instruction.
>
> Ecclesiastes 1:18 - For in much wisdom is much vexation, and he who
> increases knowledge increases sorrow.
Two very profound passages. Both are favorites of mine.
... and the second is like unto the first, love they neighbor as
thyself.
-m-
--
If children don't know why their grandparents did what they
did, shall those children know what is worth preserving and what
should change?
http://www.cryptography.org/getpgp.htm
------------------------------
From: Anders Thulin <[EMAIL PROTECTED]>
Subject: Re: Police want help cracking code to find Enigma machine
Date: Wed, 13 Sep 2000 11:53:48 GMT
Dave Foulger wrote:
> DETECTIVES baffled by the theft of Bletchley Park's prized Enigma coding
> machine are using codebreakers to crack intricate riddles which they hope
> will lead to its recovery.
Considering that the text of the letter reads like some Korean stereo
equipment manuals do, I'm not surprised. I always thought they were in code.
--
Anders Thulin [EMAIL PROTECTED] 040-10 50 63
Telia Prosoft AB, Box 85, S-201 20 Malmö, Sweden
------------------------------
From: Daniel Leonard <[EMAIL PROTECTED]>
Subject: Re: Problem with Tiger hash algorithm and binary files
Date: Wed, 13 Sep 2000 12:07:34 GMT
On Wed, 13 Sep 2000, Konrad Podloucky wrote:
> From Eli Biham's Tiger page
> (http://www.cs.technion.ac.il/~biham/Reports/Tiger/):
> "[...]Note that in the original reference implementation that we have=20
> published in this page there was a typo that used the wrong bit
> order when it padded the '1' bit at the end of the message. It=20
> used the constant 0x80, rather than 0x01 to append this bit. The
> reference implementation and test results given above are already=20
> corrected. We are grateful to John Lull who found this typo."
This confused me more because while discussing with Mr. Antoon Bosselaers,
he told me that the correction was wrong.
==========
Daniel L=E9onard
OGMP Informatics Division E-Mail: [EMAIL PROTECTED]
D=E9partement de Biochimie Tel : (514) 343-6111 ext 5149
Universit=E9 de Montr=E9al Fax : (514) 343-2210
Montr=E9al, Quebec Office: Pavillon Principal G-312
Canada H3C 3J7 WWW :
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
