Cryptography-Digest Digest #601, Volume #12 Sun, 3 Sep 00 07:13:01 EDT
Contents:
Re: New cryption method... ("Stou Sandalski")
Re: R: R: R: R: R: Test on pseudorandom number generator. (Terry Ritter)
Re: Serpent S-boxes (again) (Mack)
Re: RSA public exponent (Jerry Coffin)
Re: Serpent S-boxes (again) (Mok-Kong Shen)
Re: I need an algorithm to determine the center of gravity for; ("Douglas A. Gwyn")
Re: Serpent S-boxes (again) (Mack)
Re: Steganography vs. Security through Obscurity (Mok-Kong Shen)
Re: 96-bit LFSR needed ("Tim Tyler")
Re: RSA public exponent (Paul Schlyter)
R: R: R: R: R: Test on pseudorandom number generator. ("Cristiano")
Re: New cryption method... (PROdotes)
Re: New cryption method... (PROdotes)
Re: Steganography vs. Security through Obscurity (Guy Macon)
----------------------------------------------------------------------------
From: "Stou Sandalski" <tangui [EMAIL PROTECTED]>
Subject: Re: New cryption method...
Date: Sat, 2 Sep 2000 20:12:05 -0700
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> PROdotes wrote:
> >
> > Well... the pseudo-code won't be necessary I guess... I gave an rude
> > description of the algorithm in the last post I made... To be "more
> > precise" the whole algorithm works as one big scrambler. Imagine it as
if
> > when you take a pega out of the newspaper, cut out some parts and
> > reasamble them. And the whol thing goes on and on till the finest level
> > is reached... there you scramble some more and do some binary
> > transformations. That's about it.
>
> I am sorry to say that a description of the above kind is
> much too vague for a proper discussion. For to be able to
> clearly know how the bits of the plaintext are processed
> to become the ciphertext, one needs far more detailed
> informations than an analogy of cutting out a newspaper
> and reassmbling the pieces. (There are a multitude of
> different ways of cutting and reassembling, isn't it?)
>
> It's a matter of whether you earnestly wish to have some
> input from readers of this group or not. If yes, you have
> to spend some time and effort to describe your algorithm
> in such a way that others could, in principle, write a
> program that does exactly what you have in mind. It is
> common experience that the chance of obtaining useful
> comments/critiques is in general positively correlated
> to the quality of description of the algorithm that is
> presented to the group.
>
<snip>
You don't get it do you? This guy does not want anyone to know what the
algorithm is because that's what makes it "so strong". He should have read
a bit more sci.crypt before posting his ridiculous attempts at crypto.
Stou
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: R: R: R: R: R: Test on pseudorandom number generator.
Date: Sun, 03 Sep 2000 03:54:19 GMT
On Sat, 02 Sep 2000 22:36:05 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] (Terry Ritter) wrote:
>[...]
>it seems to me that runs
>should have a combinatoric (probably binomial) distribution,
It's obviously been some time since I visited this; from:
http://www.io.com/~ritter/ARTS/RUNSUP.HTM
"The term probability function (the number of possibilities which can
be part of a run up or run down divided by the total number of
possibilities) is just another view of an old friend:
| N r
| Pt(N,r) = ( ) / N
| r
"The number of combinations of population N taken r at a time is the
number of possible runs up of length r *and higher*. So, to find the
probability of runs of a particular length we have:
| P(N,r) = Pt(N,r) - Pt(N,r+1)
which, for N = 256, produces the following correct results:
| Byte Runs Up/Dn Probability by Run Length
|
| r prob
|
| 1 0.501953125000
| 2 0.333328247070
| 3 0.124021545053
| 4 0.032684844686
| 5 0.006702946664
| 6 0.001126633669
| 7 0.000160449945
| 8 0.000019817478
| 9 0.000002159795
| 10 0.000000210491
| 11 0.000000018541
| 12 0.000000001489
| 13 0.000000000110
| 14 0.000000000007
| 15 0.000000000000
"These values closely match the experimental results from 2 billion (2
* 10**9) total runs. (The first 5 lines each match the experimental
results in 5 places after the decimal, lines 6, 7 and 9 match 6
places, line 8 matches 7 places, and line 10 matches 8 places.)"
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Serpent S-boxes (again)
Date: 03 Sep 2000 06:24:01 GMT
>
>Mack wrote:
>>
>> The number of s-boxes satisfying these criteria were
>> 30720 with no equation of order 2
>> 36864 with one equation of order 2
>>
>> Only 2672 equations made up all of the
>> s-boxes.
>>
>> The total number of s-boxes satisfying the
>> criteria is 67584*24=1622016
>
>Is there a typo? How does the figure 1622016 stand
>in relation to 30720 and 36864? Are there 1622016
>S-boxes that SATISFY all the criteria that you
>have given? How many S-boxes really satisfy ALL
>the criteria? Thanks.
>
>M. K. Shen
>
The 30720 and 36864 total 67584. As I stated in the
original post there should be 23 equivalent S-boxes that
are permutations of the boolean equations for
these s-boxes. so 67584*24 = 1622016.
The 23 equivalent s-boxes have not been checked.
However it is obvious that the Bijectiveness cirteria
hold regardless of the order of the equations.
Also the LAT and XOR table are independent of the
order of the equations. The other criteria apply to
the individual equations.
The only question is if property 8 always holds. ie.
the inverses always satisfy those criteria.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: RSA public exponent
Date: Sun, 3 Sep 2000 00:57:20 -0600
In article <8orbbk$88j$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> Is this really an issue nowadays? Aren't today's CPU's fast enough
> to do a full-length 1024-bit RSA operation, without CRT, in a fraction
> of a second anyway?
A fraction of a second doesn't mean the speed no longer matters. If
you're talking about signing hand-written email messages on a typical
desktop machine, the speed almost certainly doesn't matter. If
you're talking about something like a web server that extracts data
from a database and signs it before sending it out to a user, the
situation could change in a hurry: the signing could easily slow
things down enough to render the system unusable.
Of course there are also things like smart cards that still use much
slower CPUs than we're accustomed to on desktops as well. I'd
consider it a given that no matter how fast desktop CPUs get, there
will always be low-end market that wants to minimize cost, power
consumption and so on. We can probably expect these CPUs to remain
slow for a LONG time: improvements in technology are more likely to
be used to reduce cost and power consumption rather than to improve
speed.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Serpent S-boxes (again)
Date: Sun, 03 Sep 2000 09:46:15 +0200
Mack wrote:
>
> The 30720 and 36864 total 67584. As I stated in the
> original post there should be 23 equivalent S-boxes that
> are permutations of the boolean equations for
> these s-boxes. so 67584*24 = 1622016.
>
> The 23 equivalent s-boxes have not been checked.
> However it is obvious that the Bijectiveness cirteria
> hold regardless of the order of the equations.
> Also the LAT and XOR table are independent of the
> order of the equations. The other criteria apply to
> the individual equations.
>
> The only question is if property 8 always holds. ie.
> the inverses always satisfy those criteria.
So the impression, if I don't err, is that there are quite
a number of equivalent classes of S-boxes that satisfy
all the criteria. This means in particular that it is
principally feasible to employ more S-boxes in the cipher
or to apply additional criteria (if these could be sensibly
established).
M. K. Shen
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: I need an algorithm to determine the center of gravity for;
Date: Sun, 03 Sep 2000 03:40:46 -0400
[EMAIL PROTECTED] wrote:
> Let's say I have a bunch of wooden abc blocks
> (cubes, all the same size and weight).
> How can I determine where is the center of gravity for that object?
Pick some point (probably on a specific block) as origin.
For each of the orthogonal coordinates X,Y,Z:
Measure the distance from the origin to the center of each block
and add those distances, then divide by the number of blocks.
That gives the X,Y,Z coordinates of the center of gravity.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Serpent S-boxes (again)
Date: 03 Sep 2000 08:23:01 GMT
>
>
>Mack wrote:
>>
>> The 30720 and 36864 total 67584. As I stated in the
>> original post there should be 23 equivalent S-boxes that
>> are permutations of the boolean equations for
>> these s-boxes. so 67584*24 = 1622016.
>>
>> The 23 equivalent s-boxes have not been checked.
>> However it is obvious that the Bijectiveness cirteria
>> hold regardless of the order of the equations.
>> Also the LAT and XOR table are independent of the
>> order of the equations. The other criteria apply to
>> the individual equations.
>>
>> The only question is if property 8 always holds. ie.
>> the inverses always satisfy those criteria.
>
>So the impression, if I don't err, is that there are quite
>a number of equivalent classes of S-boxes that satisfy
>all the criteria. This means in particular that it is
>principally feasible to employ more S-boxes in the cipher
>or to apply additional criteria (if these could be sensibly
>established).
>
>M. K. Shen
>
It might be interesting to categorize the s-boxes
into a number of classes and see how many are actually
used in Serpent.
On further testing ALL inverses including those of all
permuted variants do indeed meet the same criteria.
All of the serpent s-boxes meet my criteria, but
are my criteria the ones actually used to select the serpent
s-boxes?
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Steganography vs. Security through Obscurity
Date: Sun, 03 Sep 2000 10:47:46 +0200
Guy Macon wrote:
>
> Mok-Kong Shen wrote:
> >
> >One of the best way, I suppose, is to publish some
> >commonly useful data, e.g. some daily or weekly
> >collected physical measurments, on a web page and embed
> >the message data in them. That way it's difficult to
> >trace out the recipients who access these to get the
> >messages.
>
> Usenet articles are better than web pages for this. An attacker can
> monitor everyone who reads a web page, but it would be much harder to
> monitor everyone who reads a newsgroup post.
I considered mainly publications of numerical data, for
which there is probably yet no newsgroup. Your opinion is
principally true, though. Suppose that there is a
newsgroup available that is not 'serious' (I believe in
fact that there are lots of them). Then one has much
freedom to write what is posted (which is nonsense anyway),
which means that it's easier to obtain good schemes to
conceal the secret messages. Since the communication
partners can operate from, say, internet cafes, tracing
these is practically impossible. BTW, if the partners
could access the internet at the same time points, then
another and presumably better possibility is evidently
a chatroom.
M. K. Shen
------------------------------
From: "Tim Tyler" <[EMAIL PROTECTED]>
Subject: Re: 96-bit LFSR needed
Date: Sun, 3 Sep 2000 10:45:34 +0100
"Mack" <[EMAIL PROTECTED]> wrote:
> TT wrote:
> >I looked at Scott's program. [...]
> >
> >It seemed to me that the time taken to factor the
> >modulus was the primary factor limiting performance.
>
> Not really it takes a shortcut. It has a table of
> factors. Since it only handles numbers up to
> 2^1024 he only has to include the factorization of
> 1020 numbers.
"He"? The version currently on Scott's site reads:
/*
*
* Find all the factors of 2^order-1 by brute force division.
* This divides by all the odd numbers less than the square root,
* [...]
* Not the fastest way, but one of the smallest. :)
*
*/
Of course, a table of factors would certainly make good sense.
I only meant that factorising was the bottleneck in Scott's
implementation - not that it was necessarily always going
to be the slow spot.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: RSA public exponent
Date: 3 Sep 2000 11:47:51 +0200
In article <[EMAIL PROTECTED]>,
Jerry Coffin <[EMAIL PROTECTED]> wrote:
> In article <8orbbk$88j$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
>
> [ ... ]
>
>> Is this really an issue nowadays? Aren't today's CPU's fast enough
>> to do a full-length 1024-bit RSA operation, without CRT, in a fraction
>> of a second anyway?
>
> A fraction of a second doesn't mean the speed no longer matters. If
> you're talking about signing hand-written email messages on a typical
> desktop machine, the speed almost certainly doesn't matter. If
> you're talking about something like a web server that extracts data
> from a database and signs it before sending it out to a user, the
> situation could change in a hurry: the signing could easily slow
> things down enough to render the system unusable.
The signing has to be done with the long and slow key anyway,
so there you're not helped if verification can be made with a short
and fast key.
> Of course there are also things like smart cards that still use much
> slower CPUs than we're accustomed to on desktops as well.
These smartcards usually encrypt using the private (i.e. slow) key
anyway. That's the purpose of these cards: to store the private key
in a secure way, so it only can be executed, but not read.
> I'd consider it a given that no matter how fast desktop CPUs get, there
> will always be low-end market that wants to minimize cost, power
> consumption and so on. We can probably expect these CPUs to remain
> slow for a LONG time: improvements in technology are more likely to
> be used to reduce cost and power consumption rather than to improve
> speed.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: "Cristiano" <[EMAIL PROTECTED]>
Subject: R: R: R: R: R: Test on pseudorandom number generator.
Date: Sun, 3 Sep 2000 12:16:41 +0200
> > Following your advice, my choice for PRNG fall in TT800 (do you know?).
>
> Do you mean MT800? (Mersenne Twister)
No. TT800 by M. Matsumoto (see the following).
I have tested also MT19937 (Mersenne Twister) but my output sequence differ
from that enclosed in the sample program (I think this is because of little
/ big endian machine).
#define N 25
#define M 7
unsigned long TT800_x[N]={ // initial 25 seeds, change as you wish
0x95f24dab, 0x0b685215, 0xe76ccae7, 0xaf3ec239, 0x715fad23,
0x24a590ad, 0x69e4b5ef, 0xbf456141, 0x96bc1b7b, 0xa7bdf825,
0xc1de75b7, 0x8858a9c9, 0x2da87693, 0xb657f9dd, 0xffdc8a9f,
0x8121da71, 0x8b823ecb, 0x885d05f5, 0x4e20cd47, 0x5a9ad5d9,
0x512c0c03, 0xea857ccd, 0x4cc1d30f, 0x8891a8a1, 0xa6b7aadb
};
unsigned long TT800(void)
{
unsigned long y;
static int k = 0;
static unsigned long mag01[2]={
0x0, 0x8ebfd028 // this is magic vector `a', don't change
};
if(k==N) { // generate N words at one time
int kk;
for(kk=0;kk<N-M;kk++)
TT800_x[kk] = TT800_x[kk+M] ^ (TT800_x[kk] >> 1) ^ mag01[TT800_x[kk] %
2];
for(;kk<N;kk++)
TT800_x[kk] = TT800_x[kk+(M-N)] ^ (TT800_x[kk] >> 1) ^ mag01[TT800_x[kk]
% 2];
k=0;
}
y = TT800_x[k];
y ^= (y << 7) & 0x2b5b2500; // s and b, magic vectors
y ^= (y << 15) & 0xdb8b0000; // t and c, magic vectors
y &= 0xffffffff; // you may delete this line if word size = 32
/*
the following line was added by Makoto Matsumoto in the 1996 version
to improve lower bit's corellation.
Delete this line to o use the code published in 1994.
*/
y ^= (y >> 16); // added to the 1994 version
k++;
return y;//( (double) y / (unsigned long) 0xffffffff);
}
------------------------------
From: PROdotes <[EMAIL PROTECTED]>
Subject: Re: New cryption method...
Date: Sun, 3 Sep 2000 12:16:25 -0700
> ...
> Another point is that you should avoid posting ciphertexts
> obtained from your algorithm, which I suspect you intended
> to do with the two new threads. For nobody has the time,
> interest and energy/resources to attempt to decrypt such
> stuffs output from an unknown algorithm.
Sorry for that... I didn't even think that someone would try decrypting
the file... Just... take a look...
Sorry again...
P.S. the "code" is in another post I just made.
------------------------------
From: PROdotes <[EMAIL PROTECTED]>
Subject: Re: New cryption method...
Date: Sun, 3 Sep 2000 12:17:00 -0700
> You don't get it do you? This guy does not want anyone to know what the
> algorithm is because that's what makes it "so strong". He should have read
> a bit more sci.crypt before posting his ridiculous attempts at crypto.
Hey... "if knowledge is power then to be unknown is to be unconquered"
The reason I'm not giving the whole code is that I have done just a part
of it and think that it still has "to less" combinations.
For now it's just a simple method. First. Scrambel the bytes switching
randomly two of them using the pass. as a seed and a controler for the
number of bytes that are swiched. Than convert the file to a "black-white
picture" and randomly invert some of the bytes. Then the vertical lines
are mixed up, and then tha same with the horizontal again. The result can
then be stored as an "grayscale picture" to get some "compersion" on the
file. so there are ((n*8)!)^2 * n^2 * 2 combinations for scrambling...
where n is the fix(sqrt(number of bytes)) + 1.
Want some more... got some remarks... want to piss me of... just say it.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Steganography vs. Security through Obscurity
Date: 03 Sep 2000 11:09:29 GMT
Mok-Kong Shen wrote:
>
>
>
>
>Guy Macon wrote:
>>
>> Mok-Kong Shen wrote:
>> >
>> >One of the best way, I suppose, is to publish some
>> >commonly useful data, e.g. some daily or weekly
>> >collected physical measurments, on a web page and embed
>> >the message data in them. That way it's difficult to
>> >trace out the recipients who access these to get the
>> >messages.
>>
>> Usenet articles are better than web pages for this. An attacker can
>> monitor everyone who reads a web page, but it would be much harder to
>> monitor everyone who reads a newsgroup post.
>
>I considered mainly publications of numerical data, for
>which there is probably yet no newsgroup.
[ alt.binaries.warez.ibm-pc.encrypted ]. Nobody will find
or even notice your data there.
>Your opinion is
>principally true, though. Suppose that there is a
>newsgroup available that is not 'serious' (I believe in
>fact that there are lots of them). Then one has much
>freedom to write what is posted (which is nonsense anyway),
>which means that it's easier to obtain good schemes to
>conceal the secret messages. Since the communication
>partners can operate from, say, internet cafes, tracing
>these is practically impossible. BTW, if the partners
>could access the internet at the same time points, then
>another and presumably better possibility is evidently
>a chatroom.
Yoou are confusing the question of who sent the data with
who has read it. For sending the data, internet cafes, etc.
are equal whether it's a web page upload or a newsgroup post
(and http://www.zeroknowledge.com/ is a better way to hide!).
Where Usenet shines is in monitoring who reads the data.
Web page data is at one location - easy to monitor. Usenet
data is distributed to millions of new servers all over the
world - much harder to monitor.
------------------------------
** 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
******************************
