Cryptography-Digest Digest #589, Volume #11 Thu, 20 Apr 00 20:13:01 EDT
Contents:
Re: password generator ("Stou Sandalski")
Re: The Illusion of Security (JCA)
Re: password generator ("Joseph Ashwood")
Re: password generator (Tom St Denis)
Re: The Illusion of Security (Tom St Denis)
Re: password generator (Tom St Denis)
pollard-rho for polynomials (Tom St Denis)
Re: Requested: update on aes contest (lcs Mixmaster Remailer)
Re: Requested: update on aes contest (Andrew Carol)
Newbie question (Sean Glazier)
Re: Requested: update on aes contest (Bruce Schneier)
Re: Requested: update on aes contest (Bruce Schneier)
Re: pollard-rho for polynomials (Paul Rubin)
Re: Requested: update on aes contest (David Crick)
Re: Newbie question (Doug Stell)
Stop User Impersonation with Encryption ("C. Prichard")
Re: Newbie question (R124c4u2)
----------------------------------------------------------------------------
From: "Stou Sandalski" <tangui [EMAIL PROTECTED]>
Subject: Re: password generator
Date: Thu, 20 Apr 2000 13:20:58 -0700
"jan grant" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> How does this behave on a heavily-loaded* machine? Isn't there a danger
> of the while-loop never executing (due to preemption) and returning a
> higher percentage of zero bits?
Ok I hacked up some ghettofied(tm) code to see about how many 0s and 1s I
get on my dual cellerie 550 I ran the program 20 times and this is the
results I got:
it took (mostly) 156250ms to make each run, this was built with vc++ 6.0,
release build with optimize for speed.
0's: 5046, 1's: 4954;
0's: 5060, 1's: 4940;
0's: 4990, 1's: 5010;
0's: 5117, 1's: 4883;
0's: 5057, 1's: 4943;
0's: 4905, 1's: 5095;
0's: 4957, 1's: 5043;
0's: 5001, 1's: 4999;
0's: 5011, 1's: 4989;
0's: 4982, 1's: 5018;
0's: 5071, 1's: 4929;
0's: 5027, 1's: 4973;
0's: 4938, 1's: 5062;
0's: 4957, 1's: 5043;
0's: 4973, 1's: 5027;
0's: 5025, 1's: 4975;
0's: 5028, 1's: 4972;
0's: 5019, 1's: 4981;
0's: 4955, 1's: 5045;
0's: 4991, 1's: 5009;
I give the data in case someone wants to look at it, the code to test this
does not feel right to me... I don't know though... it looks as if its not
leaning toward either side, but I want to run some more tests with critical
sections and such and see what that does.
// Code: I seriously doubt its even remotely accurate as a bencmark
#include <windows.h>
#include <iostream>
int main(int argc, char* argv[])
{
long a, b, c, zero, one;
zero = 0;
one = 0;
for(int x = 0; x < 10000; x++)
{
b = 0;
a = GetTickCount();
while (a == GetTickCount())
b ^= 1;
c = GetTickCount();
// How does this infleunce the loop timing.. it should be only a few
instructions right? what bout the pipline?
if(b == 0)
zero++;
else
one++;
}
std::cout<<"0's: "<<zero<<", ";
std::cout<<"1's: "<<one<<";\n";
return 0;
}
------------------------------
From: JCA <[EMAIL PROTECTED]>
Subject: Re: The Illusion of Security
Date: Thu, 20 Apr 2000 13:18:46 -0700
[EMAIL PROTECTED] wrote:
> All Product ciphers based on DES and the Feistel Network can be broken
> without an Exhaustive Key Search.....
>
> The secret lies in the Non Linear F Function...This can be decomposed
> into Algebraic Linear Primitives...and the Key can be recovered
> relatively easily...The Backdoor Function...
>
You wouldn't care to explain this in detail, would you?
> It has been calculated that a 500 bit RSA key will take 20 seconds to
> break on a supercomputer......
>
Who has calculated that? Based on what premises? Would you care to
support your views somehow, or are you just talking through your
arsehole?
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: password generator
Date: Thu, 20 Apr 2000 13:40:36 -0700
How's this. I'm gonna be out the rest of the day so I can
leave it running. I'll hack up a program to test it, and
post the results from a loaded machine (32 copies of the
program running should supply enough load).
Joe
"jan grant" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Ignoring Anton's XOR mistake,
>
> Anton Stiglic wrote:
> >
> > Here are some comments on the code:
> >
> > static int trng_bit(void)
> > {
> > long a, b;
> >
> > b = 0;
> > a = GetTickCount();
> > while (a == GetTickCount())
> > b ^= 1;
> > return b&1;
> > }
>
> How does this behave on a heavily-loaded* machine? Isn't
there a danger
> of the while-loop never executing (due to preemption) and
returning a
> higher percentage of zero bits?
>
> jan
>
> * Forget the heavily-loaded part; how often/likely is a
preempt between
> the assignment to a and the while check?
>
> --
> perl -e 's?ck?t??print:perl==pants if $_="Just Another
Perl Hacker\n"'
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: password generator
Date: Thu, 20 Apr 2000 21:45:21 GMT
jan grant wrote:
>
> Tom St Denis wrote:
>
> > I am not sure what you mean by the preempt between the assign/while.
>
> > > > static int trng_bit(void)
> > > > {
> > > > long a, b;
> > > >
> > > > b = 0;
> > > > a = GetTickCount();
>
> If the scheduler interrupts the code at this stage...
>
> > > > while (a == GetTickCount())
> > > > b ^= 1;
> > > > return b&1;
> > > > }
>
> Then you'll just get zeroes out of it (assuming it doesn't get a chance
> to run for a little while). I was just wondering how likely that proved
> to be..?
It would have to interrupt for an entire second Plus look at the
routine 'trng_step()'
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: The Illusion of Security
Date: Thu, 20 Apr 2000 21:46:59 GMT
This is a joke right?
Tom
[EMAIL PROTECTED] wrote:
>
> All Product ciphers based on DES and the Feistel Network can be broken
> without an Exhaustive Key Search.....
>
> The secret lies in the Non Linear F Function...This can be decomposed
> into Algebraic Linear Primitives...and the Key can be recovered
> relatively easily...The Backdoor Function...
>
> The illusion that the Strength of an Algorithm is in the Key length is
> just that...an illusion....with detailed knowlage of the algorithm,
> Algebraic decomposition is possible with no significant computing
> power requirements...
>
> This is the biggest disinformation in history...all Public
> Product Ciphers are week and vulnerable...
>
> Public Key systems based on Large Primes are also breakable without an
> exhaustive key search....
>
> It has been calculated that a 500 bit RSA key will take 20 seconds to
> break on a supercomputer......
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: password generator
Date: Thu, 20 Apr 2000 21:49:47 GMT
Thanks for playing with the rng. I am trying to make a 16mb file with
the same rng, I will let the group know how it goes.
If you have any newer insight into the rng please let me know.
Tom
Stou Sandalski wrote:
>
> "jan grant" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > How does this behave on a heavily-loaded* machine? Isn't there a danger
> > of the while-loop never executing (due to preemption) and returning a
> > higher percentage of zero bits?
>
> Ok I hacked up some ghettofied(tm) code to see about how many 0s and 1s I
> get on my dual cellerie 550 I ran the program 20 times and this is the
> results I got:
> it took (mostly) 156250ms to make each run, this was built with vc++ 6.0,
> release build with optimize for speed.
>
> 0's: 5046, 1's: 4954;
> 0's: 5060, 1's: 4940;
> 0's: 4990, 1's: 5010;
> 0's: 5117, 1's: 4883;
> 0's: 5057, 1's: 4943;
> 0's: 4905, 1's: 5095;
> 0's: 4957, 1's: 5043;
> 0's: 5001, 1's: 4999;
> 0's: 5011, 1's: 4989;
> 0's: 4982, 1's: 5018;
> 0's: 5071, 1's: 4929;
> 0's: 5027, 1's: 4973;
> 0's: 4938, 1's: 5062;
> 0's: 4957, 1's: 5043;
> 0's: 4973, 1's: 5027;
> 0's: 5025, 1's: 4975;
> 0's: 5028, 1's: 4972;
> 0's: 5019, 1's: 4981;
> 0's: 4955, 1's: 5045;
> 0's: 4991, 1's: 5009;
>
> I give the data in case someone wants to look at it, the code to test this
> does not feel right to me... I don't know though... it looks as if its not
> leaning toward either side, but I want to run some more tests with critical
> sections and such and see what that does.
>
> // Code: I seriously doubt its even remotely accurate as a bencmark
> #include <windows.h>
> #include <iostream>
>
> int main(int argc, char* argv[])
> {
> long a, b, c, zero, one;
>
> zero = 0;
> one = 0;
>
> for(int x = 0; x < 10000; x++)
> {
> b = 0;
> a = GetTickCount();
>
> while (a == GetTickCount())
> b ^= 1;
>
> c = GetTickCount();
>
> // How does this infleunce the loop timing.. it should be only a few
> instructions right? what bout the pipline?
> if(b == 0)
> zero++;
> else
> one++;
>
> }
>
> std::cout<<"0's: "<<zero<<", ";
> std::cout<<"1's: "<<one<<";\n";
> return 0;
> }
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: pollard-rho for polynomials
Date: Thu, 20 Apr 2000 21:52:46 GMT
Has it ever been discussed in academia to use the pollard-rho method to
factor polynomials? I tried it out during english (I was bored, let's
say Hamlet is not all that interesting....). I factored
p = (x - 1)(x + 1)(x - 3)(x + 3)
Using this algorithm.
1. a = x + 1, b = x + 1
2. a = (a + x + 1)^2 mod p,
b = ((b + x + 1)^2 + x + 1)^2 mod p
3. d = gcd(a - b, p)
4. if (d <> 1) and (d <> p) then
d = factor
p = p / d
5. Goto 1 while isprime(p).
Was my choice of 'x + 1' good as a basis (instead of just '1' as in
pollard-rho for integers)?
Tom
------------------------------
Date: 20 Apr 2000 22:20:29 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: Requested: update on aes contest
Bruce Schneier writes
> The most fascinating thing, to me, is that every
> goup believed that they should be chosen as AES. On the surface, this
> is very surprising. The only explanation I can come up with is that
> ever goup knows their algorithm the best, and is most confident with
> it. Kind of like the "devil you know" as applied to block ciphers.
It's unbelievable that no one is able to see the obvious explanation.
The designers are motivated by ego. They want their cipher to be chosen
for the fame and fortune which will come from being the creator of the
standard cipher to used for the next few decades. Anyone who has spoken
to the participants is aware of the competitive nature of the contest.
Pretending that it doesn't exist is just another strategy to try to
increase the chances of winning.
Note that not only does each cipher creator say that his cipher is best,
each one comes up with performance metrics which show that his cipher is
one of the fastest! How can this possibly be explained as a "devil you
know" phenomenon? Of course, it can't. Rather, it is simply a matter
of salesmanship.
Each cipher creator knows that if he gets up and says that someone
else's cipher is better, he has lost. That's it, it's irrevocable.
His cipher will not be chosen. If even the creator doesn't trust it,
there is no way NIST could endorse it. Of course, therefore, each person
recommends his own cipher.
The fact that you are unable or unwilling to discuss this obvious fact
only reinforces its truth. If you openly stated that creators were
selfishly motivated by the desire to win, you would be admitting that
your own motivations were in this category. This would reflect badly
on you and on your cipher, and might hurt your chances of winning.
"Schneier admits that he's just supporting Twofish because he wants
to win."
This whole AES process has been a sad, embarrassing revelation of the
personal weaknesses and flaws of the leaders of the field. The spirit of
intellectual dishonesty which has pervaded the contest has been the exact
opposite of the goals and principles the participants claim to endorse.
It's not impossible that teams are actually committing the ultimate
intellectual crime by concealing weaknesses in the ciphers which they
themselves know about. They may be having strategy sessions in which
they speculate about whether specific attacks and potential problems in
their own ciphers might be discovered by their rivals. They organize
attack teams against other ciphers, hoping to tarnish each of them at
least slightly so that their own cipher comes out looking best.
We don't know what is going on internally. But the public evidence is
that these groups are not being intellectually honest. They cook their
tests to cast their own ciphers in the best possible light. They push
their own ciphers at the expense of others. They are doing everything
that it takes to win.
------------------------------
From: Andrew Carol <[EMAIL PROTECTED]>
Subject: Re: Requested: update on aes contest
Date: Thu, 20 Apr 2000 15:30:56 -0700
In article <[EMAIL PROTECTED]>, lcs Mixmaster
Remailer <[EMAIL PROTECTED]> wrote:
> It's not impossible that teams are actually committing the ultimate
> intellectual crime by concealing weaknesses in the ciphers which they
> themselves know about. They may be having strategy sessions in which
> they speculate about whether specific attacks and potential problems in
> their own ciphers might be discovered by their rivals. They organize
> attack teams against other ciphers, hoping to tarnish each of them at
> least slightly so that their own cipher comes out looking best.
But this is good. There is very little that humans endevour to do
where an attempt is not made to hide your own defects. The nice things
is that the competition is so fierce that they are better motivated to
find flaws in the OTHER guys stuff.
If I have a dozen teams and eleven of them are gunning for me, it's a
lot harder for me to promote any snake oil.
If it makes it any easier, ignore what they say about themselves and
pay a lot of attention to what they say about each other. It will
provide a starting point for neutral 3rd parties to mount attacks or
conduct performance tests based on what the biased people have claimed.
Again, this is a good thing. It's Darwinian.
--- Andy
------------------------------
From: Sean Glazier <[EMAIL PROTECTED]>
Subject: Newbie question
Date: Thu, 20 Apr 2000 18:46:27 -0400
hi,
I am new to cryptograpy. I am attempting to write an ssl implementation
in smalltalk. So I got a bunch of books and starting reading til my head
hurt.
I am doing RSA Encryption algoritms.
I can do RSA encryption however my ciphertext does not come out to be
the
same size as the palintext. I am assuming that this is a requirement.
even in the
text Applied cryptography by Bruce Schneier second edition page 468.
n = 3337
e = 79
d =1019
he takes the plain text M = 6882326879666683
and he breaks it into digts of three for the block size.
the first block encrypts as 688 raisedTo 17 mod 377 = 1570
you do this to the rest of them and each of the opererations end in a 4
digit
number except for the last one.
you combine them and what you have is a total number that is longer than
the
original.
so lets say you coerced the asci plain text in the c pointer to some
long integer
resulting in M above when you coerce it back and then run the reverse
algorithm. the
string sizes are no longer the same. how do you know how to break up the
resulting
cipher text C = 15702756209122762423158 ?
c is not the same size as m?!
using the reverse logic with n four digits long I then would do the
reverse
operation chosing a block size of 3, I do the reverse operation on 157
and not 1570.
the reverse operation on 157 yields the wrong answer of course. so my
question is how does this work. It seems to be a detail all these
documents and examples leave out. unless there are markers being
left around that allow yout to seprate the numbers again.
this may sound like a stupid question but i am new to this arena.
any help is apreciated.
Sean
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: Requested: update on aes contest
Date: Thu, 20 Apr 2000 23:12:31 GMT
On Wed, 19 Apr 2000 18:22:32 -0400, "Trevor L. Jackson, III"
<[EMAIL PROTECTED]> wrote:
>I know that you have stated that you are opposed to multiple selections.
>Would your position on this issue be influenced by a pair of selections
>distinguished by performance? Say Twofish or RC6 as primary, and R++ as
>secondary?
No. One standard. Only one. Not two. One.
Bruce
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: Requested: update on aes contest
Date: Thu, 20 Apr 2000 23:15:20 GMT
On 20 Apr 2000 22:20:29 -0000, lcs Mixmaster Remailer
<[EMAIL PROTECTED]> wrote:
>It's not impossible that teams are actually committing the ultimate
>intellectual crime by concealing weaknesses in the ciphers which they
>themselves know about. They may be having strategy sessions in which
>they speculate about whether specific attacks and potential problems in
>their own ciphers might be discovered by their rivals. They organize
>attack teams against other ciphers, hoping to tarnish each of them at
>least slightly so that their own cipher comes out looking best.
Not a chance. I believe that all the teams would just as quickly
publish attacks against their own ciphers as they would attacks
against others. The Twofish team has published the best results
against Twofish, for example.
Bruce
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: pollard-rho for polynomials
Date: 20 Apr 2000 23:39:25 GMT
In article <[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>Has it ever been discussed in academia to use the pollard-rho method to
>factor polynomials? I tried it out during english (I was bored, let's
>say Hamlet is not all that interesting....). I factored
There are already perfectly good deterministic algorithms for factoring
polynomials. It's a much easier problem than factoring integers.
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: Re: Requested: update on aes contest
Date: Fri, 21 Apr 2000 00:40:00 +0100
lcs Mixmaster Remailer wrote:
>
> Bruce Schneier writes
> > The most fascinating thing, to me, is that every
> > goup believed that they should be chosen as AES. On the surface, this
> > is very surprising. The only explanation I can come up with is that
> > ever goup knows their algorithm the best, and is most confident with
> > it. Kind of like the "devil you know" as applied to block ciphers.
>
> It's unbelievable that no one is able to see the obvious explanation.
>
> The designers are motivated by ego. They want their cipher to be chosen
> for the fame and fortune which will come from being the creator of the
> standard cipher to used for the next few decades.
A possible explanation. I think the more obvious one is that NIST
asked them to give a presentation on why THEIR algorithm should be
chosen. Adam Durana in a previous message actually said:
"The greatest part of the whole conference was definitely the end,
where a representative of each team had a chance to explain why
his cipher is better than the others, it was fun."
David.
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: Newbie question
Date: Thu, 20 Apr 2000 23:21:12 GMT
On Thu, 20 Apr 2000 18:46:27 -0400, Sean Glazier
<[EMAIL PROTECTED]> wrote:
>I am new to cryptograpy. I am attempting to write an ssl implementation
>in smalltalk. So I got a bunch of books and starting reading til my head
>hurt.
Crypto will do that to your head - and more.
>I am doing RSA Encryption algoritms.
>I can do RSA encryption however my ciphertext does not come out to be
>the
>same size as the palintext.
In RSA, each plaintext block must be numerically less than the
modulus. Therefore, the plaintext block size is chosen to be slightly
smaller than that of the modulus, e.g., round down to the next byte.
The ciphertext block will also be numerically less than the modulus
and probably the same size as the modulus.
> I am assuming that this is a requirement. even in the
>text Applied cryptography by Bruce Schneier second edition page 468.
>
>n = 3337
>e = 79
>d =1019
>
>he takes the plain text M = 688 232 687 966 668 3
>
>and he breaks it into digts of three for the block size.
>
>the first block encrypts as 688 raisedTo 17 mod 377 = 1570
>
>you do this to the rest of them and each of the opererations end in a 4
>digit
>number except for the last one.
>
>you combine them and what you have is a total number that is longer than
>the
>original.
Correct. You have essentially padded each block out to the modulus
size by adding insignificant leading zeros. In fact, Bruce shows it
this way on the bottom of page 498
>so lets say you coerced the asci plain text in the c pointer to some
>long integer
>resulting in M above when you coerce it back and then run the reverse
>algorithm. the
>string sizes are no longer the same. how do you know how to break up the
>resulting
>cipher text C = 1570 2756 2091 2276 2423 158 ?
Again, you break it into modulus size blocks, which is how it was put
together by the encryptor. I have inserted the spaces in the above
line to show the blocking, as Bruce shows it on p468,
>c is not the same size as m?!
>
>using the reverse logic with n four digits long I then would do the
>reverse
>operation chosing a block size of 3, I do the reverse operation on 157
>and not 1570.
You can't change the block size here, because it is determined by the
modulus. As Bruce shows on page 468 that 1570^1019 mod 3337 = 688,
which is correct.
>the reverse operation on 157 yields the wrong answer of course. so my
>question is how does this work. It seems to be a detail all these
>documents and examples leave out. unless there are markers being
>left around that allow yout to seprate the numbers again.
The marker is the modulus, plus agreement on the part of both parties
on how they shall do the blocking on some convienent boundary. Nothing
needs to be inserted into the cyphertext as a block marker.
Don't worry too much. Almost nobody would do a multiple-block RSA
operation, because it is too slow.
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Crossposted-To:
alt.ecommerce,alt.internet.commerce,alt.invest.technical-analysis.omega,alt.perl
Subject: Stop User Impersonation with Encryption
Date: Thu, 20 Apr 2000 23:50:00 GMT
In a noframes setting its possible to encrypt page tags with a new key =
each time a page is refreshed.
In critical online applications where information and services are =
accessed via membership status or are somehow purchased, user =
impersonation is a site security issue. Solutions have called for a =
client side cookie to authenticate users. With this solution it is often =
possible to simply distribute cookies and passwords to gain group access =
to restricted domains.
In a Perl wrapped site user authentication can be maintained without a =
client cookie by using encrypted page tags. The tags are encrypted =
uniquely for each user page so that they cannot be shared with other =
users. No client side cookie is required to authenticate each user after =
login.
Demonstration of the performance of CipherText II to encrypt page tags =
in a frames setting is at:
http://www.greentv.com/cgi-bin/cgiwrap/greentv/CRI/_nttc.cgi?page=3Dopene=
r&user_id=3D&env=3Dx
The algorithm is being used to encrypt tags so as to be transmittable =
within the default HTTP protcol without special conversion or =
filterring. It is another example of how CipherText can be practically =
applied to a job that other algorithms cannot.
A U.S. patent is pending on the CipherText algorithm.
Charles Prichard
www.greentv.com
------------------------------
From: [EMAIL PROTECTED] (R124c4u2)
Subject: Re: Newbie question
Date: 20 Apr 2000 23:52:48 GMT
>Sean Glazier
>the first block encrypts as 688 raisedTo 17 mod 377 = 1570
Any number mod 377 yields a maximum of 376, right? Are you keeping the
quotient? If you are, throw it away.
------------------------------
** 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
******************************
