Cryptography-Digest Digest #580, Volume #11 Thu, 20 Apr 00 06:13:00 EDT
Contents:
Re: Requested: update on aes contest (Bruce Schneier)
RSA Cryptography Today FAQ (1/1) ([EMAIL PROTECTED])
Re: OAP-L3: Semester 1 / Class #1 All are invited. ("ink")
Re: ANN: Better optimized version of Serpent. (Gisle S�lensminde)
Re: password generator (Anton Stiglic)
Re: OAP-L3: Semester 1 / Class #1 All are invited. ("Trevor L. Jackson, III")
Re: A future tenant of the dog house?? (JCA)
Re: password generator (Anton Stiglic)
Re: password generator (Anton Stiglic)
Re: A future tenant of the dog house?? ("Trevor L. Jackson, III")
Re: potency of a congruetial generator (Mike Rosing)
Re: Requested: update on aes contest ("Trevor L. Jackson, III")
Re: OAP-L3: Semester 1 / Class #1 All are invited. (James Felling)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: Requested: update on aes contest
Date: Wed, 19 Apr 2000 16:25:13 GMT
On Mon, 17 Apr 2000 18:38:38 -0400, Anton Stiglic <[EMAIL PROTECTED]>
wrote:
>I went to FSE and AES3 last week in New York. It was the first time
>I had been in a conference that discusses about symmetric encryption.
>I have a few taughts...
>
>None of them have been obviously broken. Attacks that where
>presented against these 5 ciphers necessitate extreme amounts
>of memory and/or computation, and the attacks where just slightly
>better than brute force, and this on a limited number of rounds.
>What amazed me is the slim amount of people that are actually
>working on breaking these ciphers, all the interesting attacks
>came from either the Twofish team (or extended Twofish team)
>or from Knudsen or Biham or Lucks. The Mars, Rijndael and RC6
>team seemed to have not invested much effort in cryptanalysis.
>Interestingly enough, the only cipher that has not been attacked
>is Twofish.
People have tried, though. Sean Murphy and his group at Royal
Hollaway have writen about the "key separation" property, but have
not been able to turn that into an attack on any reduced-round
variants. Lars Knudsen presented an attack on Tuesday, which he
retracted on Thursday because it didn't work. We've tried, too.
>There were allot of performance analyses presentations.
>Performance analyses on software (ANSI C, assembly, Java, on
>different architectures), smartcards and FPGA (Field programmable
>Gate Arrays).
>There was allot of inconsistency between groups who programmed
>in the same environment, mostly du to the fact that they selected
>different optimization techniques or the fact that some groups were
>not aware of some optimization techniques the authors of the ciphers
>proposed or had in mind. Averaging everything out, Mars seemed
>to have the weakest performance on all platforms (Mars got a good
>banging at FSE and AES), RC6 came second in the poor performance
>area even dough they have the most elegant, and shortest, algorithm.
I found it very intreresting that, depending on the assumptions made,
algorithms could have vastly different performance characteristics.
>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.
I thought so, too. 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.
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
------------------------------
Crossposted-To:
talk.politics.crypto,alt.security.ripem,sci.answers,talk.answers,alt.answers,news.answers
Subject: RSA Cryptography Today FAQ (1/1)
from: [EMAIL PROTECTED]
reply-to: [EMAIL PROTECTED]
Date: 19 Apr 2000 16:27:21 GMT
Archive-name: cryptography-faq/rsa/part1
Last-modified: 1997/05/21
An old version of the RSA Labs' publication "Answers to Frequently Asked
Questions about Today's Cryptography" used to be posted here until May
1997. These postings were not sponsored or updated by RSA Labs, and
for some time we were unable to stop them. While we hope the information
in our FAQ is useful, the version that was being posted here was quite
outdated. The latest version of the FAQ is more complete and up-to-date.
Unfortunately, our FAQ is no longer available in ASCII due to its
mathematical content. Please visit our website at
http://www.rsa.com/rsalabs/ to view the new version of the FAQ with your
browser or download it in the Adobe Acrobat (.pdf) format.
RSA Labs FAQ Editor
[EMAIL PROTECTED]
------------------------------
From: "ink" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Wed, 19 Apr 2000 18:40:33 +0200
Anthony Stephen Szopa <[EMAIL PROTECTED]> schrieb
<snip>
Dear Mr Szopa,
whereas cryptology is concerned I'm a beginner, yet I eagerly
follow the discussions in this newsgroup, mostly lurking in the
back until I have some newbie-question, which is always answered
in the most kind ways. From my "innocent" point of view, though,
I have a few comments that I would like to contribute before
retiring into the lurking position again.
> You don't know what you are talking about.
Please don't start flamewars with such replies, stick to the facts
and people will remain friendly and calm.
> OAP-L3 has no bias because I say so, AND because I have provided
> a solid and sound argument why, in the Theory and Processes Help
> Files available at http://www.ciphile.com
No attribute of any kind is linked to any entity, just because
somebody *says so* - with this kind of reasoning, a fruitful
discussion is killed right away.
> True random numbers in: true random numbers out. This should be
> a no brainer.
It seems to me a well-accepted fact that in our world, a technically
realizable source of *true random numbers* does not exist, or is
even theoretically extremely hard to realize and understand. I
doubt whether you have found the philosopher's stone, but if you
have, please post evidence. A short description of your algorithms
(NOT ref. your help-files, which I have read and understood) would
be extremely helpful. It should be easy - just describe what you
do and that's it. People will analyse the process and may even
be able to help you find weaknesses and suggest improvements, which
would benefit you as well as the users of your software.
> Mr. Huuskonen claims that the current implementation of the random
> digit generator is not cryptologically sound. Have any of you
> asked Mr. Huuskonen if the output from the random digit generator
> is used to encrypt messages? No, none of you have. This is
> because none of you knows what they are talking about.
Such swings at a whole community are not justified. Please stick
to the facts, so readers who reply to you will do the same.
> The output from the random digit generator is not used to encrypt
> messages in OAP-L3.
Please do tell us then, what is it used for?
> the time attempting such an analysis. So the idea that the random
> digit generator is not cryptologically sound is a statement with no
> implications to the security of OAP-L3 software as currently
> implemented.
Maybe the more experienced people here would be able to tell you if
your algorithm is more cryptographically secure than other processes
used in the science.
May I add one last personal remark - please don't quote 19K of
messages before adding half a page of your own writing. Some of us
don't have access to a T1 line.
In the hope that I've contributed a little to the process of
bringing this discussion back to the ground of reason I remain
Yours sincerely
Kurt In Albon
------------------------------
From: [EMAIL PROTECTED] (Gisle S�lensminde)
Subject: Re: ANN: Better optimized version of Serpent.
Date: 19 Apr 2000 18:49:44 +0200
In article <[EMAIL PROTECTED]>, Runu Knips wrote:
>"Gisle S�lensminde" wrote:
>> In article <[EMAIL PROTECTED]>, Gisle S�lensminde wrote:
>> >
>> >A new implementation of the Serpent AES candidate cipher written
>> >is now available. This is the currently fastest available
>> >implementation of Serpent, and encrypts with a speed of 32 Mbit/s
>> >on a pentium pro 200. The formerly fastest algorithm encrypted
>> >with a speed of 26 Mbit/s on the same computer. The implementation
>> >is written in Ada.
>> >
>> >The improvement is based on the optimized sbox functions of
>> >Dag Arne Osvik. A link to the source can be found at the Serpent
>> >homepage.
>> >
>> >http://www.cl.cam.ac.uk/~rja14/serpent.html - serpent home page
>> >http://www.ii.uib.no/~gisle/serpent.html - direct link
>> >
>> >Dag Arne Osvik's paper on s-box optimization presented at AES3:
>> >
>> >http://csrc.nist.gov/encryption/aes/round2/conf3/papers/26-daosvik.pdf
>>
>> I forgot to tell about the licence:
>>
>> The licence is the same as the GNU Ada compiler GNAT's runtime,
>> which is GPL with the exception that it can be linked with commercial
>> software. (See the source files for details about this)
>
>You mean L-GPL ?
In spirit very similar to LGPL, but not exactly equal. The licence is very
common for many libraries written in Ada. The following header is part of the
source files. See especially the second section.
-- This is free software; you can redistribute it and/or modify it under --
-- terms of the GNU General Public License as published by the Free Soft- --
-- ware Foundation; either version 2, or (at your option) any later ver- --
-- sion. It is distributed in the hope that it will be useful, but WITHOUT --
-- ANY WARRANTY; without even the implied warranty of MERCHANTABILITY --
-- or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License --
-- for more details. You should have received a copy of the GNU General --
-- Public License distributed with GNAT; see file COPYING. If not, write --
-- to the Free Software Foundation, 59 Temple Place - Suite 330, Boston, --
-- MA 02111-1307, USA. --
-- --
-- As a special exception, if other files instantiate generics from this --
-- unit, or you link this unit with other files to produce an executable, --
-- this unit does not by itself cause the resulting executable to be --
-- covered by the GNU General Public License. This exception does not --
-- however invalidate any other reasons why the executable file might be --
-- covered by the GNU Public License. --
--
Gisle S�lensminde ( [EMAIL PROTECTED] )
ln -s /dev/null ~/.netscape/cookies
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: password generator
Date: Wed, 19 Apr 2000 12:54:47 -0400
This is a multi-part message in MIME format.
==============D8B29C2E7CCF02659F26FFE3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom St Denis wrote:
> 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;
> > }
> >
> > Something seems wrong with this function. I don't know what exactly
> > GetTickCount() returns, but if it's something greater or equal to 1,
> > you will always be returning 0. Here is why: in your while loop,
> > you XOR b with 1, b start at 0, so the first time in you get
> > b = 0 XOR 1 = 1. Every other iteration, you simply do
> > b = 1 XOR 1, which will always give you b = 1
> > (you might want to do something like a logical AND instead).
> > Now, when you go out of the while loop, you return b&1,
> > which I believe you do so as to get the last bit (inverted), so
> > you will always return 0 if you ever went in the while loop.
>
> Um actually no. 1 xor 1 = 0 xor 1 = 1 xor 1 = 0 ....
>
> Your analysis is wrong.
Yeah, I was mistaken, 1 xor 0 = 0, and then you get 0 xor 0 which is
0, and 0 and 0 and 0 and 0. So if you got the initial idea of my
analyses,
you will see that your counter argument doesn't help you out much..
You end up almost always returning 0&1, which is 0.
==============D8B29C2E7CCF02659F26FFE3
Content-Type: text/x-vcard; charset=us-ascii;
name="anton.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Anton Stiglic
Content-Disposition: attachment;
filename="anton.vcf"
begin:vcard
n:Stiglic;Anton
x-mozilla-html:FALSE
org:Zero-Knowledge Systems Inc;Security dev. team.
adr:;;;;;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Crypto Punk
x-mozilla-cpt:;0
fn:Anton Stiglic
end:vcard
==============D8B29C2E7CCF02659F26FFE3==
------------------------------
Date: Wed, 19 Apr 2000 13:03:59 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Anthony Stephen Szopa wrote:
...
> You don't know what you are talking about.
>
> You cannot even describe the process of how the final OTPs are
> created from start to finish.
...
> None of you have supported anything you have said.
...
> Have any of you asked Mr. Huuskonen if the output from the random digit generator
> is used to encrypt messages? No, none of you have. This is
> because none of you knows what they are talking about.
...
> "If you don't get it: you don't get it."
This set of statements leads to a an unresolved question. Given your contempt for the
sci.crypt readership, why do you bother posting here?
It appears that there are only two ways to resolve this. Either your characterization
of your
respondents is accurate, in which case your contributions to sci.crypt are a waste of
time, or
your characterization is inaccurate, in which case your resistance to the ideas
presented here
is a waste of time. Why are you wasting your time?
Please reply carefully. Less charitable readers will interpret the conflict as a
choice
between "Everyone in sci.crypt is an ignorant, uneducable idiot" or "A.S. Szopa is an
ignorant, uneducable idiot". Which way do you think they'll decide?
------------------------------
From: JCA <[EMAIL PROTECTED]>
Subject: Re: A future tenant of the dog house??
Date: Wed, 19 Apr 2000 09:48:36 -0700
For what it's worth, I am suspicious. Not only is the description
given little
more than hand waving, but saying that DES is extremely slow when
calculating
on long keys is nonsense: the DES key has a fixed 64 bit length, out of
which
only 56 are effective. In addition, practical brute force attacks on DES
have
been described in the literature since at least 1992. So much for it's
purported
unbreakability.
It does sound like the epitome of snake oil sales pitch.
James Muir wrote:
> I stumbled across "Polymorphic Cryptography" today:
>
> http://www.identification.de/crypto/index.html
> http://www.identification.de/crypto/descript.html
>
> Here's a quote from the splash page:
>
> "Common ciphers like DES and RSA are extremely slow when calculating on
> long keys. Polymorphic Cryptography is 10^1500 times as secure at
> comparable encryption speed!"
>
> Here's another one from the description page:
>
> "The widespread DES algorithm has long been supposed to be unbreakable.
> In January 1999 a test performed by RSA Data Security, Inc. (San Mateo,
> Calif., USA) proved that it takes less than 22.25 hours to crack the 56
> bit algorithm by brute-force (by trying all 256 possibilities)."
>
> Ouch... I hope they just forgot the "^" character. Is anyone
> suspicious?? I wonder if you get a free bottle of snake oil with every
> order?
>
> -James
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: password generator
Date: Wed, 19 Apr 2000 13:03:31 -0400
This is a multi-part message in MIME format.
==============CC0C3E785527E06FAB758B15
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Anton Stiglic wrote:
> Tom St Denis wrote:
>
> > 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;
> > > }
> > >
O.k., I stand corrected (and embarrassed), sorry about all the confusion.
It works out o.k.
Anton
==============CC0C3E785527E06FAB758B15
Content-Type: text/x-vcard; charset=us-ascii;
name="anton.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Anton Stiglic
Content-Disposition: attachment;
filename="anton.vcf"
begin:vcard
n:Stiglic;Anton
x-mozilla-html:FALSE
org:Zero-Knowledge Systems Inc;Security dev. team.
adr:;;;;;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Crypto Punk
x-mozilla-cpt:;0
fn:Anton Stiglic
end:vcard
==============CC0C3E785527E06FAB758B15==
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: password generator
Date: Wed, 19 Apr 2000 13:06:48 -0400
This is a multi-part message in MIME format.
==============F002328B330C6A1640F055E2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"Trevor L. Jackson, III" wrote:
> This is an interesting post. How did you become part of the ZKS development
> team without learning about fundamental boolean logic?
>
> These are fundamental logical operations AND and XOR. Their truth tables are
> as follows:
>
> 0 XOR 0 = 0
> 0 XOR 1 = 1
> 1 XOR 0 = 1
> 1 XOR 1 = 0
>
> 0 AND 0 = 0
> 0 AND 1 = 0
> 1 AND 0 = 0
> 1 AND 1 = 1
>
> Who taught you differently?
O.k., I'm sorry for the error, I just posted a quick reflexion. No need for all
that arragance, we already have Bob Silverman here for that.
==============F002328B330C6A1640F055E2
Content-Type: text/x-vcard; charset=us-ascii;
name="anton.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Anton Stiglic
Content-Disposition: attachment;
filename="anton.vcf"
begin:vcard
n:Stiglic;Anton
x-mozilla-html:FALSE
org:Zero-Knowledge Systems Inc;Security dev. team.
adr:;;;;;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Crypto Punk
x-mozilla-cpt:;0
fn:Anton Stiglic
end:vcard
==============F002328B330C6A1640F055E2==
------------------------------
Date: Wed, 19 Apr 2000 13:16:29 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: A future tenant of the dog house??
We definitely need a web site specializing in outrageous claims re crypto
products. I'm sure the vendors would like to have their products featured in
as many venues as possible. Of course once we created such a collection we
could invite them to criticize each other. With an adequate fitness function
something interesting might develop via Darwinian selection. ;-)
James Muir wrote:
> I stumbled across "Polymorphic Cryptography" today:
>
> http://www.identification.de/crypto/index.html
> http://www.identification.de/crypto/descript.html
>
> Here's a quote from the splash page:
>
> "Common ciphers like DES and RSA are extremely slow when calculating on
> long keys. Polymorphic Cryptography is 10^1500 times as secure at
> comparable encryption speed!"
>
> Here's another one from the description page:
>
> "The widespread DES algorithm has long been supposed to be unbreakable.
> In January 1999 a test performed by RSA Data Security, Inc. (San Mateo,
> Calif., USA) proved that it takes less than 22.25 hours to crack the 56
> bit algorithm by brute-force (by trying all 256 possibilities)."
>
> Ouch... I hope they just forgot the "^" character. Is anyone
> suspicious?? I wonder if you get a free bottle of snake oil with every
> order?
>
> -James
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: potency of a congruetial generator
Date: Wed, 19 Apr 2000 11:13:36 -0500
Tom St Denis wrote:
>
> p: prime
> a: multiplier
> b: b <- a - 1
> c: relatively prime to p
If p is prime, (p,c) = 1 for all c :-)
>
> Where 'b' is a multiple of all the prime factors of p-1.
by this you mean if p-1 = p1^r1 * p2^r2 * ... then
b = k*p1*p2*... ?
> Xi = aXi-1 + c mod p
>
> Is a linear congruetial generator of period p-1.
>
> Therefore the potency (dependancy on previous outputs?) is the s
> variable in, b^s = 0 mod p.
Where does s come from?
Patience, persistence, truth,
Dr. mike
------------------------------
Date: Wed, 19 Apr 2000 13:19:52 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Requested: update on aes contest
Bruce Schneier wrote:
> On Mon, 17 Apr 2000 18:38:38 -0400, Anton Stiglic <[EMAIL PROTECTED]>
> wrote:
> >I went to FSE and AES3 last week in New York. It was the first time
> >I had been in a conference that discusses about symmetric encryption.
> >I have a few taughts...
> >
> >None of them have been obviously broken. Attacks that where
> >presented against these 5 ciphers necessitate extreme amounts
> >of memory and/or computation, and the attacks where just slightly
> >better than brute force, and this on a limited number of rounds.
> >What amazed me is the slim amount of people that are actually
> >working on breaking these ciphers, all the interesting attacks
> >came from either the Twofish team (or extended Twofish team)
> >or from Knudsen or Biham or Lucks. The Mars, Rijndael and RC6
> >team seemed to have not invested much effort in cryptanalysis.
> >Interestingly enough, the only cipher that has not been attacked
> >is Twofish.
>
> People have tried, though. Sean Murphy and his group at Royal
> Hollaway have writen about the "key separation" property, but have
> not been able to turn that into an attack on any reduced-round
> variants. Lars Knudsen presented an attack on Tuesday, which he
> retracted on Thursday because it didn't work. We've tried, too.
>
> >There were allot of performance analyses presentations.
> >Performance analyses on software (ANSI C, assembly, Java, on
> >different architectures), smartcards and FPGA (Field programmable
> >Gate Arrays).
> >There was allot of inconsistency between groups who programmed
> >in the same environment, mostly du to the fact that they selected
> >different optimization techniques or the fact that some groups were
> >not aware of some optimization techniques the authors of the ciphers
> >proposed or had in mind. Averaging everything out, Mars seemed
> >to have the weakest performance on all platforms (Mars got a good
> >banging at FSE and AES), RC6 came second in the poor performance
> >area even dough they have the most elegant, and shortest, algorithm.
>
> I found it very intreresting that, depending on the assumptions made,
> algorithms could have vastly different performance characteristics.
>
> >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.
>
> I thought so, too. 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.
This is an interesting observation. If it generalizes to be applicable to the
community of open crypto as a group it says something negative about our
satisfaction with the current crop of ciphers.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Wed, 19 Apr 2000 12:13:10 -0500
> <Gigantic snip of epic proportions>
>
> You don't know what you are talking about.
>
> You cannot even describe the process of how the final OTPs are
> created from start to finish.
I can post the materials from your website which I have reviewed extensively. This
certianly
skirts the line as to describing clearly, but if it passes for you, I guess it will
have to
pass for me.
>
>
> OAP-L3 has no bias because I say so,
First good reason to doubt your credibility.
> AND because I have provided
> a solid and sound argument why, in the Theory and Processes Help
> Files available at http://www.ciphile.com
No, you have not provided a "solid and sound argument why" what you have provided is a
very,
very complex algorithim that does in many steps what most algorithims do in a few, and
still
have not explained how with the artifact laden Mix files one may generate clean OTPs.
>
>
> There is no more bias in the OTPs from OAP-L3 than there are from
> picking true random numbers since the recommended use requires
> that the user input true random numbers when choosing what
> processes to run and what input parameters to use in each process.
> True random numbers in: true random numbers out. This should be
> a no brainer.
Really? Your logic is flawed at at least two points
1) People are lousy pickers of "true random numbers" -- we tend to pick favorites, and
to
avoid certian patterns and select other "more random looking ones" -- hand generated
OTPs
were an insecure point in many early code departments.
2)A simple example of the falehood of random numbers in, random numbers out. - If I
write a
program and ask for a random number, and whatever I do my program outputs the number
4867,
then what I have is "random numbers in, single number out" -- while I do not claim
that your
program is flawed in any similar manner, just because I imput some random numbers, and
do some
calculations based on them all it means is that my program is at MOST as random as its
inputs,
and in many cases it means that my program is less random than its inputs.
>
>
> I have supported everything I have said here in this news group
> and in the Help Files available at my web site. None of you have
> supported anything you have said.
Your RNG ( used to generate your mix files) has a definite and obvious flaw that
should be
visible to anyone who has ever taken a serious look at it. There are points where the
10
digit permutation("scramble" may be easily masked out of the generated data, and given
since
that is no longer there, attacks versus the "Mix", "redistribute" and "scramble" are
easily
available. If you do not know of what I speak, ask, and I will gladly provide further
more
information. True this is a minor flaw( one of many), and as you have setup your code
data
under it is reasonably secure, but if 5 minutes of analisys of your mix file
generation gives
this, what other flaws lurk? Let me say this now "your algorithim is secure-- at
least versus
me", but I do not feel that the level of security it gives is close to that of much
easier to
use programs, nor do I feel that it provides any premium in any way versus existing
free
software such as PGP.
>
>
> Mr. Huuskonen claims that the current implementation of the random
> digit generator is not cryptologically sound.
True.
> Have any of you
> asked Mr. Huuskonen if the output from the random digit generator
> is used to encrypt messages?
No it is not, at leas not directly. It is not used to encode in the same way that in
a car
with power steering, turning the steering wheel does not actually move the wheels, it
moves
something which in turn makes something else move the wheels. -- the RNG is used to
make
things that are processed to make other things, that are combined with other things,
which
eventually after many steps, produces the output.
> No, none of you have. This is
> because none of you knows what they are talking about.
We aren't the only people in this discussion that don't seem to know what they are
talking
about.
>
>
> The output from the random digit generator is not used to encrypt
> messages in OAP-L3.
Semi-true
> And there is no way Mr. Huuskonen or anyone
> else is going to get the extensive secret data required to attempt
> an analysis as he has proposed.
Probably true, unless OAP-L3 goes into general use.
> If one could, they would also have
> access to the key and or the OTPs themselves, and would not waste
> the time attempting such an analysis.
Umm, real breaks of real cyphers are generally done by testing and eliminating possible
guesses -- this analisys is precisely the sort that would be done to aquire such data.
> So the idea that the random
> digit generator is not cryptologically sound is a statement with no
> implications to the security of OAP-L3 software as currently
> implemented.
Try "minimal" unless, of course, it is actually used to encrypt real quantities of
data.
>
>
> I guess it is like they say in Orange County, California:
>
> "If you don't get it: you don't get it."
And you sir, don't get it.
------------------------------
** 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
******************************
